NAPTIFY 拡張プロトコル規則

拡張プロトコルの機能番号・メッセージ番号の割り当てと、拡張追加時の規則。互換クライアント・サーバーの開発者向け。

本ページは、Naptify が OpenNap プロトコルに加える拡張のうち、クライアント・サーバー間の拡張である Naptify Client Protocol(略称 NCP)の共通規則と、Naptify 拡張全体の番号割り当てをまとめたものである。他のクライアント・サーバーの開発者が、Naptify との互換性を保ったまま拡張に対応できるようにすることを目的とする。各メッセージのフィールド構成など、個別機能の詳細は本ページの対象外である。

1. 基本方針

  • 拡張は、OpenNap プロトコル仕様の原典 [NAP] に準拠する。フレーム形式(長さ 2 バイトと種別 2 バイトのヘッダー、いずれもリトルエンディアン、続いてペイロード)と文字列形式は [NAP] §2 のとおりである。
  • 既存メッセージの意味は変更しない。
  • 既定の動作は [NAP] のままとする。拡張機能は、能力交換(§3)で双方の対応を確認できた接続でのみ使用する。
  • 旧来のクライアント・サーバー(本拡張を実装していないもの)には、拡張メッセージを送信しない。例外は、クライアントが最初に送信する能力申告(9200)のみである。
  • クライアント名やサーバーのバージョン文字列などの自己申告で、拡張機能を有効にしてはならない。自己申告は偽装できるため、権限や機能の判定には使用しない。
  • 拡張を使用しても、サーバーの規則(転送要求回数の制限、Leech の扱いなど)は同様に適用される。
  • 独自の暗号方式は作らない。暗号化通信には標準の TLS を使用する。

2. 番号割り当て

Naptify 拡張は、9000〜9499 の番号を使用する。NCP は 9200〜9389 で、機能ごとに 10 番ずつ区切る。他のクライアント・サーバーとの互換性を保つため、使用中の番号はすべて本節に掲載する。方向欄の C はクライアント、S はサーバーを表す。

2.1 範囲

範囲 用途
9000〜9199 Naptify Guild Protocol(サーバー間接続)
9200〜9209 能力交換(相手能力通知、クライアント証明書の指紋、サーバー設定値の照会を含む)
9210〜9219 暗号化通信(TLS)への切り替え
9220〜9229 認証(チャレンジレスポンス)
9230〜9239 接続圧縮
9240〜9249 共有一括登録と完了通知
9250〜9259 検索・参照結果の一括送信
9260〜9269 再接続時の共有引き継ぎ
9270〜9279 転送中継の拡張
9280〜9289 構造化通知
9290〜9299 文字コード UTF-8、ギルド同名ユーザー
9300〜9309 構造化管理要求
9310〜9319 予約
9320〜9329 マルチログイン IM 同期
9330〜9389 NAP 広域分散バックアップ(9380〜9389 は予備)
9390〜9399 NCP 実装者向けテスト用
9400〜9489 Naptify Peer Protocol(クライアント間接続)
9490〜9499 Naptify Peer Protocol 実装者向けテスト用

9000〜9199 の各番号は、Naptify Guild Protocol 仕様(参考文献)に記載している。

2.2 状態の定義

状態 意味
使用中 用途と使い方が確定した番号
設計中 用途と番号のみ確定した番号。メッセージは未確定
後回し 用途と番号のみ確定し、設計を保留している番号
予約 使用しない番号。他の用途にも転用しない
使わない 機能番号としてのみ使用し、メッセージ種別としては使用しない番号
  • 設計中・後回し・予約の番号のメッセージは、送信してはならない。受信した場合は、未知の番号として扱う(§4)。
  • 表にない番号(各範囲の空き)は未割り当てであり、送信してはならない。
  • テスト用の範囲(9390〜9399、9490〜9499)は、実装者が手元のテストで使用するための番号であり、公開実装間の通信には使用しない。

2.3 NCP 機能番号

機能番号は、能力交換(§3)の 9200・9201 で交換する。

機能番号 名称 用途 状態
9203 大型ペイロード 双方向で、ペイロード 65535 バイトまでのフレームを使用する(メッセージなし) 使用中
9204 相手能力通知 転送・直接参照の相手が対応するクライアント間機能を、サーバーが通知する 使用中
9205 クライアント証明書の指紋 クライアント間の暗号化通信で相手を検証するため、証明書の指紋をサーバーが中継する(暗号化通信内で、9204 と同時にのみ合意する) 使用中
9207 サーバー設定値の照会 サーバーで自分に適用される規則の値を照会する(§5.6) 使用中
9210 暗号化通信(TLS)への切り替え 接続の途中で暗号化通信に切り替える 使用中
9220 認証(チャレンジレスポンス) 暗号化通信のない経路でも、パスワード自体を送らずにログインする 設計中
9230 接続圧縮(zlib) ログイン後のフレームを zlib で圧縮して送信する 使用中
9231 接続圧縮(zstd) zstd による圧縮。サーバーは合意しない 予約
9240 共有一括登録と完了通知 共有登録の完了を通知し、確定した件数を受け取る 使用中
9250 検索・参照結果の一括送信 検索・参照の結果をまとめて送信する 後回し
9260 再接続時の共有引き継ぎ 短時間の切断後に、共有一覧を再送せずに済ませる 後回し
9270 双方ポート 0 の転送中継 双方が外部から接続を受けられない場合の転送を、サーバーの指示で成立させる 設計中
9272 IPv6 アドレス クライアント間転送のために IPv6 アドレスを受け渡す 使用中
9274 ハッシュ検索と所持確認 共有ファイルにハッシュを付与して同一内容を検索し、サーバーが所持を確認する(9203 と同時にのみ合意する) 使用中
9278 分散ダウンロード集約 複数の相手から受信した同一ファイルの転送を、1 件にまとめて通知する(実装しない) 予約
9280 構造化通知 文言内にしかない情報を、値として受け取る 設計中
9290 文字コード UTF-8 合意した接続のメッセージを UTF-8 にする 使用中
9295 ギルド同名ユーザー ユーザーを、名前と所属サーバーの組で伝達する 設計中
9300 構造化管理要求 BAN などの管理操作を、チャットコマンドではなくメッセージで行う 設計中
9310 予約 生存確認には [NAP] の 751・752 を使用するため、使用しない 予約
9320 マルチログイン IM 同期 同一ユーザーの他端末が送信した IM を、自端末の送信 IM として受信する 使用中
9330 NAP 広域分散バックアップ ユーザーの分散バックアップ領域を集約し、ファイルバックアップに使用する(暗号化通信内で、9203・9274 と同時に、かつサーバーで有効な場合にのみ合意する) 使用中
9400 Naptify Peer Protocol 対応 クライアントが Peer Protocol への対応を申告する。サーバーは 9204 で転送相手に通知する 使用中

2.4 NCP メッセージ番号(9200〜9329)

番号 名称 方向 用途 状態
9200 能力申告 C→S 使用したい機能番号を申告する 使用中
9201 能力応答 S→C 申告のうち、サーバーも対応する機能番号を返す 使用中
9202 能力交換エラー S→C 共通のプロトコルバージョンがないことを返す 使用中
9203 大型ペイロード — 機能番号のみ。メッセージ種別としては送信しない 使わない
9204 相手能力 S→C 転送・直接参照の相手と合意済みのクライアント間機能を通知する 使用中
9205 証明書の指紋登録 C→S 自身の証明書の指紋を登録・解除する 使用中
9206 相手の指紋 S→C 転送相手の証明書の指紋を渡す 使用中
9207 設定値照会 C→S 規則の値を照会する 使用中
9208 設定値 S→C 項目名と値を返す 使用中
9209 設定値終了 S→C 応答の終了を通知する 使用中
9210 切り替え要求 C→S 暗号化通信への切り替えを要求する 使用中
9211 切り替え承諾 S→C 切り替えを受け入れる。この後に TLS ハンドシェイクを開始する 使用中
9212 切り替え拒否 S→C 現在は暗号化通信を使用できないことを返す 使用中
9230 zlib 圧縮フレーム 双方向 複数のフレームをまとめ、zlib で圧縮して運ぶ 使用中
9231 zstd 圧縮フレーム — 使用しない 予約
9240 登録終了 C→S 一連の共有変更を送り終えたことを通知する 使用中
9241 登録完了 S→C 確定した共有件数と容量を返す 使用中
9242 登録完了エラー S→C 共有・検索機能が現在使用できないことを返す 使用中
9272 IPv6 アドレス登録 C→S IPv6 アドレスを登録・解除・確認する 使用中
9273 IPv6 アドレス通知 S→C 確認用トークン、確認結果、転送相手の IPv6 アドレスを通知する 使用中
9274 ハッシュ登録・検索 C→S 共有ファイルにハッシュを付与する、またはハッシュで検索する 使用中
9275 ハッシュ通知 S→C 登録拒否、検索結果行のハッシュ、ハッシュ検索結果、ハッシュ解除を通知する 使用中
9276 所持確認要求 S→C ハッシュを付与したファイルを所持しているか確認する 使用中
9277 所持確認応答 C→S ファイルの一部と照合用ハッシュを返す。または未所持を返す 使用中
9278 分散ダウンロード集約通知 C→S 実装しない 予約
9279 分散ダウンロード集約エラー S→C 実装しない 予約
9310〜9319 予約 — 使用しない 予約
9320 送信 IM の複製 S→C 同一ユーザーの他端末が送信した IM を通知する 使用中

9220〜9229、9250〜9269、9270・9271、9280〜9309 のメッセージ番号は、設計中・後回しの機能用に確保している。個別番号は未確定である。

2.5 NAP 広域分散バックアップ番号(9330〜9389)

番号 名称 方向 用途 状態
9330 参加登録 C→S PC と分散バックアップ領域の容量を登録して参加する 使用中
9331 状態通知 S→C 使用量、貢献スコア、最大バックアップ容量などを通知する 使用中
9332 状態照会 C→S 保管単位の状態を照会する 使用中
9333 保管単位状態 S→C 保管単位の破片と預け先の状態を返す 使用中
9334 共有ファイル登録 C→S 共有中のファイルをバックアップ対象に登録する 使用中
9335 保有者通知 S→C 同一内容の保有者数と接続率を返す 使用中
9336 所有者証明要求 S→C パスキーの鍵による署名を要求する 使用中
9337 所有者証明 C→S 署名を返して所有者であることを示す 使用中
9338 予約 — 削除した番号。転用しない 予約
9339 エラー S→C 広域分散バックアップのメッセージに対するエラーを返す 使用中
9340 預け先要求 C→S 破片の預け先を要求する 使用中
9341 預け先候補 S→C 預け先候補と許可を返す 使用中
9342 受け入れ指示 S→C 預け先に、破片を受け入れるよう指示する 使用中
9343 配置申請 C→S 所有者が、許可に基づいて配置する破片を申請する 使用中
9344 受領報告 C→S 預け先が、破片を受領したことを報告する 使用中
9345 配置確定通知 S→C 所有者に配置結果を通知する 使用中
9346 保管単位確定 C→S 保管単位の破片配置を確定する 使用中
9347 保管単位削除 C→S 保管単位を削除する 使用中
9348 破片削除 C→S 破片を 1 つ削除する 使用中
9349 破片送信 C→S サーバーの分散バックアップ領域へ破片を送信する 使用中
9350 確認要求 S→C 預け先が破片を保持しているか確認する 使用中
9351 確認応答 C→S 破片の一部と照合用ハッシュを返す。または未保持を返す 使用中
9352 保管予定破片一覧 S→C 預け先が保持しているはずの破片の一覧を送信する 使用中
9353 保管中破片一覧 C→S 預け先が実際に保持している破片の一覧を送信する 使用中
9354〜9359 予約 — 使用しない 予約
9360 復元要求 C→S 保管単位の復元を要求する 使用中
9361 復元許可 S→C 破片を保持する相手と許可を返す 使用中
9362 提供指示 S→C 破片を保持する相手に、提供するよう指示する 使用中
9363 復元完了報告 C→S 復元の完了を報告する 使用中
9364 サーバー破片範囲要求 C→S サーバーの分散バックアップ領域にある破片の一部を要求する 使用中
9365 サーバー破片範囲 S→C サーバーの分散バックアップ領域にある破片の一部を送信する 使用中
9366〜9369 予約 — 使用しない 予約
9370 バックアップ台帳保存 C→S 暗号化したバックアップ台帳をサーバーに預ける 使用中
9371 バックアップ台帳保存結果 S→C 保存したバックアップ台帳のバージョンを返す 使用中
9372 バックアップ台帳要求 C→S 預けたバックアップ台帳を要求する 使用中
9373 バックアップ台帳 S→C 預けたバックアップ台帳を返す 使用中
9374 分割鍵(サーバー)保存 C→S 分割鍵(サーバー)をサーバーに預ける 使用中
9375 分割鍵(サーバー) S→C 預けた分割鍵(サーバー)を返す 使用中
9376 旧組合せ消去 C→S パスキーを紛失した場合に、9337 の代わりに送信し、旧ユーザー名と鍵の組合せ記録の消去を依頼する。消去は猶予期間(10 日)の後に行い、その間に旧組合せの鍵で所有者証明が通れば取り消す 使用中
9377 参加終了 C→S 広域分散バックアップを無効にしたことを通知する 使用中
9378 消去取消通知 S→C 旧組合せ消去の依頼を取り消したことと、依頼の日時を通知する 使用中
9379 予約 — 使用しない 予約
9380〜9389 予備 — 使用しない 予約

2.6 Naptify Peer Protocol 番号(9400〜9489)

Naptify Peer Protocol は、クライアント間でデータポート上で使用する拡張である。相手の対応状況は、サーバーが 9204 で通知する(NCP 機能番号 9400)。Peer Protocol 内の機能番号は、9400・9401 で交換する。このほか、名前・ファイル名の文字コードには、NCP と同じ機能番号 9290(文字コード UTF-8。メッセージなし)を使う。9290 を合意した接続だけ名前・ファイル名を UTF-8 にし、合意していない接続は CP932 とする(§5.2)。

番号 名称 方向 用途 状態
9400 能力申告 クライアント間 接続した側が、使用したい機能番号を申告する 使用中
9401 能力応答 クライアント間 申告のうち、受けた側も対応する機能番号を返す 使用中
9402 能力交換エラー クライアント間 共通のプロトコルバージョンがないことを返す 使用中
9410 切り替え要求 クライアント間 暗号化通信(TLS)への切り替えを要求する(機能番号) 使用中
9411 切り替え承諾 クライアント間 切り替えを受け入れる 使用中
9420 範囲要求 クライアント間 ファイルの指定範囲を要求する(機能番号) 使用中
9421 範囲応答 クライアント間 要求された範囲を返す。後続にファイル内容が続く 使用中
9422 範囲拒否 クライアント間 範囲要求を拒否する 使用中
9423 送信申告 クライアント間 ファイルを渡す側から接続した場合に、送信するファイルを示す 使用中
9424 受領終了 クライアント間 受領の完了を通知する 使用中
9430 圧縮 — ファイル内容を zstd で圧縮して送信する(機能番号。メッセージなし) 使用中
9440 ハッシュツリー要求 クライアント間 受信内容を検証するためのハッシュツリーを要求する(機能番号) 使用中
9441 ハッシュツリー応答 クライアント間 ハッシュツリーを返す 使用中
9442 ハッシュツリーなし クライアント間 ハッシュツリーを返せないことを通知する 使用中
9450 同一相手への複数接続 — 同一の相手へ複数の接続を張り、範囲を分割して並行受信する(機能番号。メッセージなし) 使用中
9460 取得済み範囲要求 クライアント間 受信途中のファイルについて、相手が保持している範囲を照会する(機能番号) 使用中
9461 取得済み範囲 クライアント間 保持している範囲を返す 使用中
9470 直接参照一覧要求 クライアント間 共有一覧を圧縮形式で要求する(機能番号) 使用中
9471 直接参照一覧 クライアント間 圧縮した共有一覧を返す 使用中
9480 許可提示 クライアント間 広域分散バックアップで破片を受け渡す際に、サーバーが発行した許可を提示する(機能番号) 使用中
9481 破片範囲要求 クライアント間 破片の指定範囲を要求する 使用中
9482 破片範囲応答 クライアント間 要求された範囲を返す。後続に破片内容が続く 使用中
9483 破片受け渡し拒否 クライアント間 破片の受け渡しを拒否する 使用中
9484 破片ハッシュツリー要求 クライアント間 破片を検証するためのハッシュツリーを要求する 使用中
9485 破片ハッシュツリー応答 クライアント間 ハッシュツリーを返す 使用中
9486 破片受領終了 クライアント間 破片の受領を完了した、または中止したことを通知する 使用中
9487〜9489 予約 — 使用しない 予約

3. 能力交換(9200・9201)

3.1 機能番号

拡張機能は、その機能の先頭メッセージの番号(機能番号)で表す。たとえば、暗号化通信(TLS)への切り替えは 9210、共有一括登録と完了通知は 9240 である。メッセージを持たず、合意のみで有効になる機能もある(大型ペイロードの 9203。§5.1)。機能番号の一覧は §2.3 を参照する。

3.2 メッセージ

能力交換には、9200(能力申告)・9201(能力応答)・9202(能力交換エラー)を使用する(§2.4)。9200 と 9201 は、プロトコルバージョン(NCP は 1)と機能番号の並びを運ぶ。

3.3 申告と合意の手順

  1. クライアントは、TCP 接続の最初のメッセージとして 9200 を送信し、使用したい機能番号を列挙する。クライアントから先に送信するのは、サーバーから先に送信すると、拡張を認識しない旧来のクライアントに届いてしまうためである。
  2. サーバーは、他のメッセージより先に 9201 を返す。 – プロトコルバージョンは、サーバーが対応するもののうち、申告値以下で最大のものを返す。 – 機能番号は、申告のうちサーバーも対応するものだけを返す。未知の機能番号は黙って除外する。順序に意味はない。同じ番号が重複して申告された場合は 1 回だけ返す。 – 機能番号の並びは空でもよい(どの機能も使用しない)。
  3. 共通のプロトコルバージョンがない場合、サーバーは 9201 の代わりに 9202 を返す。その後も接続は継続し、どの機能も合意しないまま [NAP] のとおりに進む。
  4. 形式が不正な 9200 を受信したサーバーは、接続を切断する。
  5. 9201 に含まれた機能のみが合意済みであり、その接続の間だけ有効である。
  6. 暗号化通信(TLS)への切り替え(9210)を合意した場合は、切り替え後、暗号化通信内の最初のメッセージとして 9200・9201 を再度交換する。暗号化通信前の応答は改ざんされうるため、暗号化通信内の 9201 による合意のみを有効とし、それ以前の合意は破棄する。
  7. 最初のメッセージ以外で受信した 9200 は、サーバーは無視する(応答を返さず、合意も変更しない)。例外は 6 の、暗号化通信内での再交換のみである。
  8. 機能によっては、他の機能と同時に申告した場合のみ、または暗号化通信内でのみ合意できる。条件を満たさない場合、サーバーはその機能を 9201 に含めない。
  9. リダイレクト用ポート(メタサーバー)は 9200 を受け付けない。クライアントはそこへ 9200 を送信してはならない。
  10. その後、ログイン([NAP] の 2)へ進む。能力交換は、パスワードを送信する前に完了させる。

3.4 合意に至らない相手への対応

旧来のサーバー

旧来のサーバーには、ログイン前に未知の番号を受信すると、無視するものと切断するものがある。クライアントは、拡張の使用方法を「自動」「常に」「使わない」から選択できるようにする(既定は「自動」)。

  • 自動: 最初のメッセージとして 9200 を送信し、クライアント設定の時間だけ応答を待つ。
  • 9201 を受信した場合は、拡張対応サーバーとして記録し、§3.3 の手順で進む。
  • 応答がない場合は、拡張非対応サーバーとして記録し、同じ接続のまま 9200 なしでログインする。
  • 切断された場合は、拡張非対応サーバーとして記録し、再接続して 9200 なしでログインする。
  • 一度でも 9201 を返したサーバーが、9200 に応答しない、または切断した場合は、拡張非対応とは記録せず、接続失敗として扱って再接続する(応答を止めさせて暗号化なしの接続へ誘導する攻撃を防ぐため)。
  • 常に: 必ず 9200 を送信する。応答がない、または切断された場合は、接続失敗として扱って再接続する。
  • 使わない: 9200 を送信せず、[NAP] のとおりにログインする。

暗号化通信で接続した実績のあるサーバーが、応答したうえで暗号化通信を使用しないと回答した場合(9201 に 9210 が含まれない、または切り替えを拒否した場合)、クライアントは黙って暗号化なしで継続せず、ユーザーに警告すべきである。証明書の指紋をユーザーが承認して接続していたサーバーでは、ログイン前にユーザーの承認を求めなければならない。承認がなければ、ログインを送信しない。

旧来のクライアント

  • 旧来のクライアントは 9200 を送信しないため、サーバーはその接続で拡張機能を合意せず、拡張メッセージを送信しない。[NAP] のとおりに扱う。
  • 9201 で合意しなかった機能のメッセージは、相手が拡張に対応していても送信しない。

4. 未知の番号を受信した場合

  • ログイン後に受信した未知の番号は、無視しなければならない。
  • ログイン前に受信した未知の番号は、切断してもよい。
  • ただし NCP の範囲(9200〜9389)の番号は、ログインの前後を問わず、未知であっても切断せずに無視しなければならない。将来の機能との互換性を保つためである。
  • 合意していない機能のメッセージを受信した場合も、未知の番号として無視する。
  • Naptify Peer Protocol の接続では、9400〜9499 の未知の番号を無視しなければならない。範囲外の番号を受信した場合は、切断してもよい。

5. 共通規則

5.1 フレームサイズ

  • 大型ペイロード(機能番号 9203)を合意した接続では、双方向とも、ペイロード 65535 バイトまでのフレームを送信してよい。受信側はこれを受け付けなければならない。
  • 合意していない接続では、ペイロード 8192 バイトを超えるフレームを送信しない(旧来のクライアント・サーバーの上限)。
  • 9203 は、メッセージ種別としては使用しない。

5.2 文字コード

  • 既定は [NAP] と同じで、日本国内の運用では CP932 である。
  • UTF-8 は、能力交換で 9290 を合意した接続でのみ使用する。合意した接続では、メッセージを UTF-8 にする。
  • 合意していない接続へは、CP932 で表せない字を、人が読む文では「?」にして送る。ファイル名など、相手がその文字列で要求を返すものは送らない。
  • サーバー間のリンクは、Naptify 同士では UTF-8、FaceNap・SlavaNap とは CP932 である。

5.3 フィールドとエラー

  • 整数は 10 進の ASCII で記述する。名前・ファイル名の形式は [NAP] と同じである。
  • 圧縮データなど文字にならない内容は、メッセージのペイロードにそのまま格納する。
  • エラーは、機能ごとのエラーメッセージで返す。理由は番号で表し、表示用の文言は参考として添えるだけにする。受信側は文言を機械的に解析しない。

5.4 生存確認

  • 生存確認には、拡張メッセージを使用せず、[NAP] の 751・752 を使用する。
  • 本拡張に準拠するクライアントは、サーバーからの 751 server に、ただちに 752 server で応答しなければならない。

5.5 番号の使用

  • 番号を使用する前に、§2 の表で他の用途の番号と重複しないことを確認する。
  • 予約の番号は使用しない。設計中・後回しの番号と、表にない番号も送信しない(§2.2)。
  • テスト用の範囲の番号は、手元のテスト以外では使用しない。

5.6 サーバー設定値の照会(9207〜9209)

クライアントが、サーバーで自分に適用される規則の値(チャットの連投制限、検索回数の制限など)を、文言を解析せずに値として取得するための仕組みであり、拡張規則の一部として扱う。

  • 能力交換で 9207 を合意した接続で、ログイン後にのみ使用する。
  • クライアントが 9207 で照会し、サーバーが 9208 で項目名と値を返し、9209 で応答を終了する。サーバーから自発的には送信しない。
  • 項目名は、英小文字・数字・アンダースコア(_)・ピリオドのみで構成する固定の綴りである。
  • 値は、真偽(0・1)、10 進整数、または項目ごとに定めた英小文字の語のいずれかである。返せない場合は、次の語を返す。
  • none: サーバーにその機能がない。
  • exempt: 照会したユーザーには適用されない。
  • unknown: サーバーが知らない項目名である。
  • 値は、サーバー設定値そのものではなく、照会した接続に実際に適用される値である。
  • クライアントは、未知の項目名の行を読み飛ばす。9209 は応答終了の目印であり、返却された項目数では判断しない(項目は改訂で増えることがある)。
  • 項目を追加する、または意味を変更する場合は、先に仕様を改訂する。サーバーが独自の項目を追加してはならない。

6. 拡張追加時の規則

  • 拡張機能は、番号付きのメッセージとして定義する。要求・応答・終了・エラーは、それぞれ別番号のメッセージにする([NAP] の検索 200 → 201 … 202 と同じ形式)。
  • 番号は §2 の割り当てに従い、機能ごとに 10 番単位で区切った範囲から取得する。使用前に §2 の表で重複しないことを確認し、予約の番号は使用しない(§5.5)。
  • 機能には機能番号を付与し、能力交換で合意した接続でのみ使用する。
  • 既存の [NAP] メッセージの意味は変更しない。
  • エラー理由は番号で表す(§5.3)。
  • サーバーの規則を迂回する形にしない(§1)。
  • 機能・番号・項目を追加する場合や意味を変更する場合は、先に仕様を改訂してから実装する。

付録 A. 互換:UTS1 方式の暗号化接続

UTS1 は、一部の OpenNap 互換クライアントが独自に定めた暗号化接続の方式である。NAPTIFY 拡張プロトコルの一部ではなく、番号も割り当てない(§1 のとおり、NAPTIFY の暗号化通信は標準の TLS〈9210〉を使用する)。この付録は、UTS1 のクライアントを受け付けるサーバーのための互換の記述である。naptify-server は、暗号化通信を受け付ける設定が有効な場合に受け付ける(既定は有効)。

A.1 位置づけ

  • UTS1 は、[NAP] の接続を始める前の前段の取り決めである。握手の後は、ログイン(2)を含むすべての [NAP] メッセージが、暗号化した枠の中を流れる。
  • 握手の後は、ほかの接続と同じく、最初のメッセージとして能力交換(9200・9201)を行う(§3.3)。合意の条件も同じである。暗号化通信(TLS)への切り替え(9210)は合意せず、暗号化通信内でのみ合意できる機能(9205・9330)も合意しない。
  • クライアント間の通信には使用しない。

A.2 握手

  1. クライアントは、接続の先頭で 53 バイトの挨拶を送る。UTS1(55 54 53 31)、C(43)、X25519 の公開鍵 32 バイト、乱数 16 バイトの順。
  2. サーバーは、接続の先頭 4 バイトが UTS1 で 5 バイト目が C の場合に UTS1 とみなす。5 バイト目が C でない場合は、通常の [NAP] メッセージとして読む。
  3. サーバーは一時の X25519 の鍵を生成し、53 バイトの挨拶を返す。UTS1、A(41)、公開鍵 32 バイト、乱数 16 バイトの順。クライアントは 5 秒待つ。
  4. 双方は X25519 の共有値を求める。共有値がすべて 0 の場合は接続を切る。
  5. salt = SHA-256(クライアントの挨拶 53 バイト ‖ サーバーの挨拶 53 バイト)。okm = HKDF-SHA256(IKM = 共有値、salt、info = utatane-go/server/v1、長さ 72 バイト)。
  6. クライアントからサーバーへの向きは、鍵 okm[0:32]、nonce の先頭 okm[64:68]。サーバーからクライアントへの向きは、鍵 okm[32:64]、nonce の先頭 okm[68:72]。
  7. 握手に失敗した場合は接続を切る。暗号化していない通信には戻らない。

A.3 枠

  • 形式は BE32(L) + AES-256-GCM の暗号文(認証タグ 16 バイトを含む)。L は平文の長さ + 16。AAD は長さの 4 バイト。
  • nonce = 先頭 4 バイト ‖ BE64(連番)。連番は向きごとに 0 から始め、枠ごとに 1 増やす。
  • 平文は 1 枠 32768 バイトまで。受信時は、L が 16 未満、または L − 16 が 32768 を超える枠を不正とする。
  • 平文 0 バイトの枠(L = 16)は終了の目印である。接続を閉じる側は、終了の枠を送ってから閉じる。
  • 認証に失敗した枠、または長さが範囲外の枠を受けた場合は、それ以降を読まずに接続を切る。不正な枠を飛ばして後続の枠を読まない。
  • 枠の中身はバイト列である。[NAP] メッセージは枠をまたいで組み立てる。

A.4 安全性

  • UTS1 は、通信を傍受するだけの第三者から内容を守る。
  • サーバーの真正性を確かめる手順(証明書、事前に共有した鍵、チャレンジレスポンスなど)は持たない。このため、通信経路に割り込んでサーバーになりすます攻撃(中間者攻撃)は防げない。なりすました相手には、ログインのパスワードも読まれる。
  • 手順はクライアントが定めているため、サーバー側だけで確認の手順を追加することはできない。中間者攻撃への備えが必要な場合は、標準の TLS(9210)を使用する。

A.5 試験値

RFC 7748 §6.1 の鍵(サーバー=Alice、クライアント=Bob)、クライアントの乱数 00〜0f、サーバーの乱数 10〜1f で計算した値。

okm    5609cbcd01f5882306614d168b2feeb8da2c45c12d29991659b568b00fe4dc6c74f5213bc17a9991853d8c689f325b8ccf050c1420f885fb6f4c8fed1fc7e75d679730b2c6b7e173
C→S 連番 0 'hello'   0000001557b0401a0c4bad261d77760dfecc7bc1a3a8685a65
C→S 連番 1 終了       00000010abbf8d2ae136071c1cdcc4e35397b5bf
S→C 連番 0 'world'   0000001534e4cf01fedb5ddc45880171f9b6a11f2cb986021b
S→C 連番 1 終了       00000010a36f93a38b92eb56ccd7e96289a9c9fb

参考文献

  • [NAP] drscholl@users.sourceforge.net(OpenNap プロジェクト)”napster messages”。原文の日付は 2000-04-07、変更履歴は 2001-04-07 まで。https://opennap.sourceforge.net/napster.txt
  • Naptify Guild Protocol: https://naptify.net/docs/guild-protocol/