要約

  • 10月1日付のdraft-ietf-tcpm-tcp-ao-algs-08は、KMAC256-KDFがNIST SP 800-56C Revision 2のKMAC#変種に準拠すると明記した。SP 800-185の汎用KMAC256という名称だけでは契約を特定できない。
  • 運用者が残すべき証拠は、草案版、公開引数と符号化、接続コンテキスト、既知解ベクトル、TCP-AOオプションのバイト列、対向での検証結果を結ぶ一つの実行記録である。

相互接続試験で両装置の設定画面を並べる。どちらにもKMAC256と表示されている。ここで試験項目を「一致」にすると、最も重要な差異が画面の下に残る可能性がある。名称は同じでも、鍵導出に使った関数変種と引数の組み立てが同じとは限らない。

TCPMの草案第08版は、その境界を文章にした。KMAC256と引数はNIST SP 800-185で定義された一方、SP 800-56C Revision 2は引数集合の異なるKMAC#という変種を定義している。草案のKMAC256-KDFは後者に準拠する。さらに、ネットワークバイト順で表す32ビット整数1がKDFの版を示すと追記された。

現状を正確に呼ぶ必要がある。これはStandards Trackを意図した作業中のInternet-Draftであり、RFCではない。TCPMは2026年11月のIESG提出を目標に掲げるが、目標は提出や承認を意味しない。取得時点のIANA登録簿にあるTCP-AOアルゴリズムはSHA1とAES128であり、HMAC-SHA256-128とKMAC256-128は草案が追加を求めている段階だ。

第08版のKDF入力は具体的である。saltは132バイトの全ゼロ。counterはネットワークバイト順の32ビット値1。ZはMaster Key。FixedInfoはTCP-AO接続コンテキスト。出力は256ビット。カスタマイズ文字列はASCIIのKDFである。必要なTraffic Keyも256ビットなので、呼び出しは一回となる。

続くMAC計算では別の契約を使う。導出済みの256ビットTraffic Keyを鍵とし、RFC 5925に従って構成したメッセージを入力にする。MAC側のカスタマイズ文字列は空で、KMACに128ビットを直接要求する。16バイトのMACを含むTCP-AOオプション全体は、TCPオプション用40バイトのうち20バイトを占める。

したがって、KDF側のKDFとMAC側の空文字列を一つの「既定値」として扱ってはならない。ライブラリAPIが引数を別名で表示しても、また一部を内部値として隠しても、実装は同じバイト列を同じ役割に置かなければならない。

FixedInfoにも接続固有の意味がある。RFC 5925は、送信元と宛先のアドレス、ポート、初期シーケンス番号をコンテキストに含める。Traffic Keyは方向別だ。ACKのないSYNでは未確定の宛先ISNにゼロを使い、その後は既知の組を使う。視点の反転を誤れば、Master Keyが一致していても導出結果は一致しない。

パケットだけでも契約全体は読めない。TCP-AOオプションにはKind、Length、KeyID、RNextKeyID、MACがあるが、MACアルゴリズム名は入らない。アルゴリズムと鍵の対応は、帯域外で設定されたMaster Key Tupleにある。同じKeyIDを観測しても、その番号に両端が同じ意味を与えた証拠にはならない。

BTWが提案する制御は、アルゴリズム実行インスタンスの受領記録である。草案版、KDFとMACの識別子、NIST文書版、salt、counterとバイト順、出力長、二つのカスタマイズ文字列、秘密を含まないMKT識別子、製品とbuildを記録する。既知解ベクトル結果のハッシュ、実パケットのオプションバイト、対向検証、TCP状態、上位プロトコル結果までを同じ鎖に結ぶ。

Master Keyや本番Traffic Keyを記録してはならない。証跡の完全性と秘密の露出は別問題である。管理された鍵IDと公開ベクトルを使えば、本番秘密をログに残さず実装経路を比較できる。

草案にはIPv4とIPv6のKMAC試験ベクトルがあり、他のTCPオプションを認証対象に含める場合と除く場合を扱う。あるbuildがベクトルを通過したことは、その固定入力の計算が一致した証拠になる。しかし、現場のMKT、接続方向、KeyID、実際に認証したメッセージまでは証明しない。

証拠は段階ごとに保つべきだ。機能を広告すること、既知解が一致すること、一つのセグメントが検証されること、TCPがEstablishedになること、BGPなどのアプリケーションが進むことは別々の観測である。すべてを「KMAC256対応」と呼べば、障害時に層を切り分けられない。

Heng LuのMinimum Initial Specificationは、この共通部分を小さく、同時に厳密に保つ考え方を与える。関数変種、引数の役割、符号化、コンテキスト、長さは同じ結果に必要な共通事実である。ライブラリや鍵保管、監視方式はローカルに選べるが、計算契約はローカル化できない。

Running-Code Primacyに従えば、名称より再現可能なベクトルと実際のバイトを重く見る。Reality Layersに従えば、草案、登録要求、設定、鍵導出、セグメント検証、接続、サービスを混同しない。これはDaniel KadeによるHeng Luの編集的応用で、IETFやNISTの主張ではない。

同時に、推測を広げてはならない。第08版はKMACやTCP-AOの破綻を示さず、第07版の実装不一致も、特定ベンダーの誤りも証明していない。以前のSecurity Directorateレビューは新しい組の利点、長い出力、オプション空間を問うたが、それが今回の追記を生んだとは公開資料から断定できない。

今回の変更が示すのは、アルゴリズム名が互換性の対象ではなく、その背後の関数インスタンスが対象だということだ。前者しか保存しなければ、障害時に章題だけ残る。後者を保存すれば、変種、鍵、コンテキスト、セグメント、アプリケーションの問題を分けられる。

出典