要約

  • RSVP Cryptographic Authentication v2の草案は、2026年9月30日までTEAS作業部会の最終意見募集にある。9月27日に第02版が提出されたが、RFCとして承認されたわけではない。
  • 別の有効なセキュリティ関連付けがあれば、失効した関連付けを使うメッセージは破棄する。一方、適用可能な関連付けがすべて失効した場合には、最後のものを使って認証を続ける例外が書かれている。
  • 例外は認証を省く許可ではない。有効期限の運用上の境界を一時的に緩めるため、警告を受け、後継を導入し、例外が終わった証拠を残す必要がある。

期限を過ぎた鍵で署名されたメッセージが届いたとする。受信側に新しい有効なセキュリティ関連付けがあれば判断は明快だ。草案では古い関連付けに対応するメッセージを暗号処理せず破棄しなければならない。後継が用意された後も古い鍵を漫然と使える仕様ではない。

難しいのは、後継の有効な関連付けそのものが存在しないときだ。受信規則は、失効した関連付けでメッセージを検証するよう記す。さらに第5.4節は、適用可能な関連付けがすべて失効した「異常な場合」を扱う。無認証の状態へ戻ることは受け入れられない一方、予約の中断がより広いネットワーク障害につながり得るため、管理者への通知を行い、最後の関連付けを一時的に無期限として扱うべきだという。延長、管理者による削除、新しい関連付けの設定が終点となる。

ここで通過するのは時間制限であって、暗号学的な検査ではない。RSVPのINTEGRITYオブジェクトにある認証値や再送攻撃を抑えるシーケンス番号の検証は残る。ただし、メッセージが以前の鍵で正しく認証されたことと、その鍵を今も通常の方針の範囲で使ってよいことは別の判断である。草案自身も「すべて失効」を強く望ましくない状況と位置付け、運用者に予防を促している。

予防策は抽象論だけではない。実装には、保護するインターフェースまたは隣接ノードごとに少なくとも二つの有効な関連付けを同時に保持する能力を求める。重複する有効期間を設ければ、時計のずれがあっても切り替えやすい。送信元アドレスと鍵識別子で受信側はどの関連付けを使うか決める。しかし実装能力の記述は、特定のネットワークで二本目の鍵が配布済みであるという観測ではない。

標準化手続きも進行中だ。TEASは9月16日に作業部会の最終意見募集を始めた。セキュリティ分野の早期レビューは21日、第01版について鍵管理の説明と異常時のトレードオフが改善されたとしてReadyと評価した。27日の第02版は引用や文章の調整、提案中の登録表への注記が中心で、最後の鍵を延命する規則を新設したものではない。個別レビューはIESG承認の代わりにならない。

暗号アルゴリズムの問題とも分けておきたい。基礎草案は特定の変換を必須としない仕組みを規定し、提案するIANA登録表ではHMAC-MD5をSHOULDとしながら旧式で将来廃止予定と注記する。HMAC-SHA2は別の作業部会草案だ。登録表の表現だけで現場の装置が何を実装し、いつ鍵を交換したかは分からない。

運用で必要なのは、例外を始めた時刻、影響する隣接ノード、受け入れた認証済みメッセージ、警告の行き先、後継が実際に有効になった時刻を結び付ける記録だろう。これはDaniel Kadeによる管理上の提案であり、TEASの要求を装ったものではない。サービスを守るための緊急措置が、期限を設けた意味そのものを消さないようにするためだ。

出典