要約

  • RFC 2385は両端が同期すれば接続中の鍵変更を認めたが、調整のためのプロトコル内交渉も鍵識別子も定義しなかった。
  • RFC 5925のTCP-AOでは、KeyIDが現在のセグメントの認証に使ったMKTを示し、RNextKeyIDが送信者が今後の受信に使える状態のMKTを相手に伝える。

二台のルーターが認証済みセッションを保ち続けているとする。鍵を更新すべき時刻が来ても、旧鍵で作られたセグメントはまだネットワーク内にいるかもしれない。時計だけで一斉に切り替えれば、わずかなずれで正当な通信が認証失敗になる。接続を作り直せば整理できるが、維持したかった状態も失う。

1998年のRFC 2385は、主にBGPセッションを守るためTCP MD5 Signature Optionを定義した。保護対象の各セグメントに16バイトのMD5ダイジェストを載せ、両端が別途設定した秘密を計算に使う。接続中の鍵変更は、両端で同期できる限り認められていた。しかし、現在の鍵を示す番号も、次の鍵への準備を知らせる交換もなかった。

2010年のRFC 5925はTCP-AOによって状態を明示した。Master Key Tuple（MKT）は接続の選択条件、識別子、鍵材料、アルゴリズムとパラメータをまとめる。そこから特定の接続と方向に対応するトラフィック鍵を派生する。インスタンス化済みMKTの中身は接続中に変えない一方、利用可能なMKT集合は更新でき、接続は使用するMKTを切り替えられる。

移行を示すのが一バイトずつのKeyIDとRNextKeyIDである。KeyIDは、そのセグメントの認証に使ったMKTを指定する。RNextKeyIDは、送信者が今後受け取るセグメントに使える状態のMKTを告知する。相手はその信号とRFCの移行規則に基づき、自分の送信MKTとKeyIDをいつ切り替えるかを判断する。番号自体は秘密でも世界共通名でもなく、当該接続の設定内で使う索引にすぎない。鍵は方向別なので、送信鍵と受信準備は別々に進む。

これにより完全な同時切替は不要になる。一方が次の受信用MKTを設置し、RNextKeyIDでそのMKTを使える状態だと伝える。相手はその信号を確認し、RFCの状態規則に従って自分の送信KeyIDをいつ変えるかを判断するのであり、次のTCPセグメントで直ちに切り替えるよう命じられるわけではない。移行中は旧鍵も一定範囲で受け付け、飛行中だったセグメントを検証できる。進捗が通信上に現れ、時計や失敗だけに頼らず確認できる。

もっともTCP-AOは鍵配布プロトコルではない。マスター秘密を交渉せず、誰に設定権限があるかも決めない。MKTは静的設定または外部の帯域外機構から届く。TCP-AOが扱うのは、既に承認された鍵の使用順序である。

既存のTCP MD5接続をそのままTCP-AOへ移すこともできない。両者は異なるオプションを使い、同一接続での併用は禁止される。TCP MD5には確立後にセキュリティ方式を変更する経路がないため、新方式への移行は新しい接続を要する。その後のTCP-AO内部の鍵更新は、接続状態を維持して実行できる。

RFC 5926は相互運用に必要なMACと鍵導出方式を定めるが、運用鍵や共通の更新周期は決めない。TCP-AOは真正性と完全性を守り、リプレイへの耐性を加える一方、アプリケーションデータを暗号化しない。

一次資料