要約
- 移行モードでは HMAC-MD5 を送信しつつ受信検証を省略でき、未実装装置もそのタイプを受理し得る。キャプチャ上の MAC は入口の強制を証明しない。
- 複数パスワード、purge 専用規則、ロールオーバー後の系列回復は別々の権限である。認証成功もトポロジーの正しさや転送結果まで証明しない。
送信の準備完了と受信の強制開始は同日とは限らない
RFC 5304 は Authentication Information TLV の認証タイプ 54 を HMAC-MD5 に割り当てる。Authentication Value をゼロにし、LSP では checksum と Remaining Lifetime もゼロにして計算する。これは検証手順であり、検証実行の証跡ではない。
移行モードでは自分の PDU に HMAC を入れても、受信した HMAC を調べなくてよい。段階導入には便利だが、パケット観測だけでは移行開始と移行完了を区別できない。見た目は同じでも、片方の受信機は検査し、もう片方は通過させる。
HMAC-MD5 未実装の装置がそのタイプを含む PDU を受理してもよいという互換条項もある。フィールドは能力を強制できない。一方、実装済み装置が該当情報を受信した場合、不正な値は破棄しなければならない。境界はパケットではなく受信機の能力と設定にある。
監査には、実装、検証スイッチ、候補鍵、計算結果、受理判断、状態反映が必要だ。RFC 5304 は 2008 年の Standards Track であり、RFC 3567 を置き換えた。HMAC-MD5 の現在の採用を勧める資料として扱ってはならない。
鍵ローテーション中の成功は、どの鍵の成功か
適用範囲も分かれる。Level 1 SNP は area、Level 2 SNP は domain、IIH は link-level の認証文字列を使い、LSP と異なる場合がある。全体を「IS-IS auth 有効」と呼ぶと範囲差が消える。
ローテーションでは複数パスワードを試せる。通信を止めずに移行できる反面、成功カウンターだけでは新旧どちらが一致したか分からない。旧鍵の権限を本当に消したと証明するには、候補集合、選択、期間、スコープ、終了時点が必要だ。
重複期間は暗号の欠陥ではなく、複数資格を意図的に信頼する政策である。期限がなければ一時的権限が恒久化する。RFC 5310 は後に Key ID と HMAC-SHA の security association を導入したが、ID 表示だけで全受信機の設定一致は証明できない。
purge は削除権限を持つ別のメッセージ形態
purge は Remaining Lifetime をゼロにして LSP を除去する。RFC 5304 は発信側に LSP 本体の削除と認証 TLV の付加を求め、受信側に未認証 purge と他 TLV を含む purge の拒否を求める。
攻撃者が正規 LSP をコピーし、寿命だけゼロにして秘密を知らずに削除を広げることを防ぐ。受信した情報を再送する力と、その情報を削除する力を分ける規則だ。
したがって purge 監査は、HMAC 成功だけでなく、空の本体、許可された TLV のみ、適切な鍵、削除効果を記録する。余分な本文を持つ purge の拒否は、相互運用障害ではなく安全な判断かもしれない。
新しい秘密でも古い系列に追いつけない
パスワード変更直後にプロセスが再起動すると、新しい鍵で系列 1 から LSP を出すことがある。隣接装置は古い高い系列を保持しており、新しい低い値を拒否する。通常なら自分の古い LSP の反射から高い値を学ぶ。
しかし古いコピーは古い鍵で認証され、新プロセスには検証できない。自分が作った過去状態を認証できず、系列権限を取り戻せない。RFC 5304 は、認証失敗でもローカル System ID と高い系列を持つ LSP を検知し、系列だけ進めて再発信する方法を示す。
攻撃者も同じ条件を作れるため、カウンターが推奨される。未認証の内容を採用するのではなく、限定された座標でローカル系列を修復する。それでも例外の使用は不可視であってはならない。
有効な HMAC は正しいルーターを作らない
この機構は平文パスワードより攻撃コストを上げるが、replay や DoS を一般に消さず、侵害・故障・誤設定されたルーターを止めない。鍵保持者は正しい HMAC で誤ったトポロジーを送れる。
HMAC が示すのは、受理鍵の保持者が覆われた内容を生成したことだ。変更の正当性、LSDB 一致、FIB、利用者配送は別証拠である。保証はアルゴリズム、鍵、実装、全共有者の秘密保持にも依存する。
分析の限界
現在の実装や導入を推定せず、新設計に HMAC-MD5 を推奨しない。現行判断には RFC 5310 と新しい指針が必要だ。現場確認には設定、拒否カウンター、選択鍵、移行時刻、purge ログ、LSDB とデータ面が要る。
結論は受信側の証拠にある。フィールド、能力、検証、鍵、メッセージ別権限、結果を一つの「認証済み」に畳まない。
出典
- RFC 5304:IS-IS 暗号認証
- RFC 5304 プレーンテキスト
- RFC Editor の RFC 5304 情報
- IETF Datatracker の RFC 5304
- RFC 5304 の履歴
- RFC 5304 の参照文書
- RFC 5304 を参照する文書
- RFC 5304 の正誤表
- RFC 1195:TCP/IP での OSI IS-IS
- RFC 3567:旧 IS-IS 暗号認証
- RFC 2104:HMAC
- RFC 5310:IS-IS 汎用暗号認証
- RFC 4593:ルーティングプロトコルの一般的脅威
- RFC 5709:OSPFv2 HMAC-SHA 認証
- RFC 8177:YANG Key Chains
- RFC 8247:IKEv2 アルゴリズム指針
- RFC 5303:IS-IS 三方向ハンドシェイク
- Heng Lu:On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu:Running Code Primary
- Heng Lu:On the Agency Problem at the Core of Internet Governance
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
