要約

  • RFC 9986では、受信側が鍵付きISAAC列から導いた32ビットのAuth Keyを照合する。一致は共有材料を知る送信者と許容範囲の列位置を示せるが、パケットの他フィールドを認証しない。
  • 証拠は実装、discriminator、鍵の世代、seed、列ウィンドウ、ISAACページ状態、照合結果、後続MCI再認証を一つの時系列に置く必要がある。経路やサービスの正常性まで代弁させてはならない。

受信試験の表には、緑色のセルが一つあった。expectedとreceivedが同じ32ビット値だったからだ。ところが監査報告では、そのセルが「パケット認証成功」に変わった。計算は正しくても、報告の主語が大きすぎた。

これは特定の製品や障害を述べる事例ではない。RFC 9986の境界を運用記録に写した仮想例である。Meticulous Keyed ISAACはRFC 9985の最適化認証でLCIを担う。仕様は同時に、この形式のパケットが署名もパケット単位の認証も受けず、状態変化を通知してはならないと定める。

照合が答えるのは限定された問いだ。共有秘密とBFDセッションの入力、seed、許容される列位置から、相手と同じ32ビット値を再現できたか。一致は秘密を知り、列の状態が合っている送信者のシグナルになる。しかしDiagnostic、State、各種フラグ、タイマー、discriminatorなど、パケットの残りを暗号学的に束ねない。

Auth Keyという名前やAuthentication Sectionという配置は、保証範囲を増やさない。実務で見るべきなのは名称ではなく、計算に入ったバイトと入っていないバイトである。

RFC 9986のセクションには認証種別、長さ、Key ID、seed、シーケンス番号オフセット、32ビットAuth Keyが入る。受信側はKey IDとseedを確認し、受信ウィンドウ内の位置を選び、候補値を導出する。そこで一致しても、通過したのはLCI固有の検査であり、他フィールドに対するMAC検証ではない。

RFC 8439の認証付き暗号と比べると違いが明瞭になる。そこではタグが暗号文と関連データを結び付ける。この比較はBFDへのアルゴリズム提案ではない。一つの疑似乱数出力を比べることと、内容に結び付いたタグを検証することを同じ「認証」に押し込めないための物差しだ。

ISAACの検証には時間状態がある。出力はページ単位で生成され、内部状態は破壊的に前へ進む。損失や遅延、許容される並べ替えに対応するため、受信側は先のページを試算する場合がある。RFC 9986は、その際に状態を保存し、試算後に復元するよう求める。未来を調べただけで現行状態が動けば、次の正当なパケットを拒否し、監査時の再現も壊す。

seedはセッションの時代を区切る。Upへ移るたびに新しいseedを使い、そのUp期間中は固定する。「Key ID一致」だけのログでは、どのUp期間の何番目を受け入れたのか分からない。seed、Upエポック、列位置、ウィンドウ判断を組にしなければならない。共有秘密そのものを公開せず、プロビジョニングとローテーションの世代だけを記録することはできる。

限定的な鍵再利用が許されても、鍵管理が消えるわけではない。セッション固有入力が出力を分ける一方、一つの鍵が多くのセッションを覆えば、漏えい、ずれたローテーション、記録欠落の影響は広がる。レビュー単位は「ISAAC有効」ではなく、鍵の世代、対象セッション群、派生入力、責任者、有効期限である。

RFC Editorの記録は文書をExperimentalとする。計算量を下げる代わりに安全性を下げ、ISAACをこの用途で「せいぜい許容できる」ものとして扱い、暗号解析が限られ証明もないと認める。別のIETFプロトコルへの転用にも適さない。IACRの分析は慎重さの根拠であって、RFC 9986実装への攻撃実績ではない。

相互運用性も推測できない。RFC 9986はRFC 9985の特定構成向けであり、通常のRFC 5880認証と当然に相互運用するわけではない。IANA BFD Parametersに値が登録されても、それは実装、普及、稼働実績の証明ではない。

RFC 5881が扱うのは限定された単一ホップ転送経路である。RFC 7419、RFC 8177、RFC 9127は暗号とBFDの周辺条件を示すが、LCI値の受理を経路選択、アプリケーション処理、利用者体験の証明にはしない。

RFC 9985の周期的MCI再認証は別の制御であり、不適切なUp状態が続く時間を設定間隔に応じて制限できる。途中のISAAC形式パケットの内容を遡って認証する機能ではない。記録は関連付けるべきだが、同一視してはいけない。

Heng Luの現実の層を適用すれば、標準、実装能力、鍵設定、観測したAuth Key、BFD状態、クライアント反応、サービス結果は別々になる。Running-Code PrimacyはRFCの看板より実装の観測を優先し、Minimum Initial Specificationは共通の受領記録を狭く保ち、その先の判断を責任ある運用者に残す。

受領記録には、RFCとerrataの基準、実装build、両端discriminator、Key ID、鍵の導入・更新世代、seedとUpエポック、送受信列位置、ウィンドウ規則、ISAACページと保存・復元、照合結果、完全性保護されないフィールド、MCI結果、クライアント反応、判断責任者、ロールバック条件を置く。秘密を漏らさずに、受理ロジックを再現できる粒度が必要だ。

一致は無価値ではない。証明していないことまで背負わせないからこそ、価値が残る。

出典