要約

  • 2026年10月1日付のTCPM作業部会草案第08版は、提案中のKMAC256-KDFがNIST SP 800-56C Rev. 2のKMAC#変種に従うと明記した。SP 800-185が当初定義したKMAC256とは引数の組が異なり、ネットワークバイト順の32ビット値「1」はKDFの版を示すとも説明する。
  • 導出式、提案する128ビットMAC、試験ベクトルは第07版にもあった。今回の変更は読み方の明確化であり、稼働中の鍵が変更された証拠でも、RFC承認でもない。

ある装置の仕様書に「KMAC256対応」と書かれていても、対向装置とTCP-AOの認証が成功するとは限らない。マスター鍵が同じでも、どの変種にどの順番で接続の文脈やカウンターを渡すかが違えば、導出されるトラフィック鍵は一致しない。実際のパケットが照合するのは機能名ではなく計算結果だ。この差を縮めるための文章上の変更が、最新の草案にある。

draft-ietf-tcpm-tcp-ao-algs-08の3.1.2節は、KMAC256-KDFをNIST SP 800-56C Rev. 2の4.1節にある単段階の導出方式、そのKMAC#変種に結び付けた。元のSP 800-185によるKMAC256とは引数の扱いが違うと明示する。32ビットのカウンターは従来どおり値が1で、ネットワークバイト順に符号化する。第08版はさらに、その値がKDFの版を表すと説明した。第07版との比較で重要なのは、式やベクトルの新設ではなく、この変種の同定である。

式には132バイトのゼロのソルト、カウンター、Zとして渡すマスター鍵、FixedInfoとなるTCP接続の文脈、256ビットの出力長、ASCIIのKDFという文字列が入る。得られる256ビットの鍵を用い、提案するKMAC256-128は128ビットのMACを作る。もう一つのHMAC-SHA256-128はHKDF-SHA256を鍵導出に用いる。二方式の提案自体も、TCP-AOに載る16バイトのMACが40バイトのTCPオプション領域のうち20バイトを使うことも、第08版で初めて現れた話ではない。

そこで実装試験では、アルゴリズム名の選択画面だけを確認して終えるべきではない。独立した実装同士で中間のトラフィック鍵を比較し、TCPオプションを認証範囲に含める場合と除く場合のMACを草案の試験ベクトルと照合する。これは本文の運用上の提案であって、IETFが新設した認証制度ではない。不一致なら、変種、引数の順序、カウンターの符号化、接続文脈、出力長を順に調べる。単にBGPセッションが切れたという観測だけでは原因を特定できない。

草案はマスター鍵を少なくとも256ビットとし、暗号方式の強度だけではプロトコル実装上の迂回を防げないとも注意する。しかし製品間の障害事例や普及率は示していない。TCP-AOが保護するのはBGPを運ぶTCP接続であり、個々の経路広告の正当性まで認定するものではない。鍵の世代を安全に切り替えられたかという別の問題も、今回の変種指定だけでは解決しない。

Datatracker上では、文書はTCPMの活動中のInternet-Draftで、状態はI-D Exists。本文の表題部はStandards Trackを志向する一方、Datatrackerの予定ステータス欄は(None)で、承認済みRFCではない。現時点で変わったのは、同じ名前が指すべき計算手順をより厳密に示したことだ。採用判断には、両端が本当に同じ鍵を得るという証拠がなお要る。

出典