要約

  • RFC 5387 はネットワーク層と上位層で一方向または分担された認証を認める一方、チャネル結合は両端で値を交換し検証する必要があると整理した。
  • 中継者が二つの有効な IPsec SA を連結すれば、各区間の暗号保護は正しくても、アプリケーション同士が一つの直接チャネルを共有するという主張は偽になる。

認証の向きと証拠の形

公開サービスでは、サーバーだけが身元を示し、利用者は匿名のまま接続することがある。業務システムでは逆に、利用者を上位層で強く認証し、ネットワーク層は別のサービス主体を扱うことがある。すべての層に同じ認証を繰り返させれば、鍵の保管場所と設定不整合だけが増える場合もある。

RFC 5387 は BTNS の対称・非対称モードを区別する。A-CBB では片側だけが通常の IKE 資格情報を持つことができる。上位層の認証も一方向でよい。たとえばクライアントをアプリケーションで、サーバーを IKE で認証し、異なる層で二方向を補完する設計が可能だ。

しかし、チャネル結合まで一方向にはできない。中間者攻撃を防ぐには、両端が結合値を交換し、自分の観測と一致するかを確かめる必要がある。誰が身元を証明するかは方針であり、両者が同じ下位チャネルを使っているかは共有事実である。

非対称な権限配置は許される。共有事実を片側の証言だけで確定することは許されない。この差が RFC 5387 の中心である。

二つの正しい SA が作る誤った全体

経路上のプロキシがクライアントと SA A を、サーバーと SA B を確立する。両方に機密性、完全性、リプレイ防止がある。プロキシは一方で復号し、上位層のデータを転送して、もう一方で再び保護する。

各端点の監視は正しく「IPsec で保護」と報告する。それでもアプリケーション端点間に直接の保護チャネルはない。SA のネットワーク端点と、上位プロトコルの端点が一致していないからだ。

RFC 5387 は、SA 作成から得られる特定の SA ペアを識別する情報を上位認証に組み込む考え方を示す。RFC 5056 は一般化して、アプリケーションの双方が同じチャネル結合データを観測したことを検証するよう求める。プロキシが二本を連結したなら、双方の値は異なり、結合された認証は失敗する。

「IPsec 対応」は機能一覧でしかない。必要な運用証拠は、このセッションでどの値を両端が見て、どちらも検証し、差異にどう反応したかである。方式名や IP アドレスだけではインスタンスを特定できない。

ラッチが守るのは装置ではなく性質

RFC 5387 の IPsec チャネルは、パケットフローの期間を通じて相手の同一性と保護品質が変わらないものとして説明される。connection latching は、その性質を上位接続へ結び付ける。

後の RFC 5660 は SPD と SAD の変化を監視する仕組みとして具体化した。保護の種類、トランスポートかトンネルか、暗号品質、ローカル ID、ピア ID などを保持し、開始時の条件と両立しない変化が起きたら、上位層へ同期的に知らせる。

SA は寿命によって再鍵交換される。新しい SA が成功しただけでは、古い判断を引き継げない。ラッチした性質が保存されたことを示せれば継続できる。相手や品質が変わったなら、チャネルを壊して新しい判断を求めるべきだ。

これは引き継ぎ一般にも当てはまる。新しい証明書、事業者、エージェントが同じ役割名を持っていても、前任者の権限を自動で受け取るわけではない。継続は名前ではなく、保存された不変条件で証明される。

失敗が遅ければ、その前に何かが起きる

通常の認証済み IKE なら、中間者は SA 作成時に排除されるはずだ。CBB では未認証の IKE が成功し、SA が先にできる。中間者が判明するのは、上位認証がチャネル結合を検査した時点である。

その失敗は最終承認を止めるが、時間を巻き戻さない。CPU とメモリは使われ、認証メッセージは送られた。パスワード由来の情報がオフライン攻撃に利用できるなら、後で拒否しても露出は残る。

したがって受入試験は、結合が失敗したかだけでなく、失敗までに何を割り当て、何バイトを送り、どの秘密を見せ、どの権限を与えたかを測る。SA 作成、結合確認、アプリケーション認可を一つの「安全」表示にまとめてはいけない。

遅い検出は無価値ではない。検出の責任範囲を正直に限定すれば有効である。問題は、検出を「被害は起きなかった」という別の主張へ拡張することだ。

三者構成で試す

まずクライアントとサーバーを直接結び、双方の結合値、上位セッション、ピア ID、保護品質、認証結果を保存する。同じ下位チャネルを見たことを二つの記録で確認する。

次に管理下のプロキシを置き、二つの強い SA を作らせ、上位交換をそのまま転送させる。暗号を弱めない。破損パケットも使わない。局所的には正常で、組合せだけが誤っている状態を作る。結合認証は値の不一致で失敗しなければならない。

サーバーのみ、クライアントのみ、双方、さらに層をまたいだ認証を順に試す。認証結果は方針に応じて変わるが、チャネル結合の両端検証は残る。

最後に長時間フローの途中で再鍵交換する。一回は全ラッチ属性を保ち、正当な継続を示す。もう一回はピア ID または保護品質を変え、追加データの受入前に上位へ破断を通知させる。どの端点が検出し、どの状態を消し、アプリケーションに何を返したかまで記録する。

結合点に独立した受領証を置く

局所制御は重要だが、全体の意味を所有しない。二つの署名が別の内容を指すことも、二つの台帳が同名の別物を指すことも、二つの暗号区間が中継者で終わることもある。

結合の受領証には、下位チャネルの正確な識別子、上位セッションと端点、各層の認証方向、両端の検証結果、ラッチ属性、遷移履歴を含める。値がない、異なる、未承認で変わった場合は閉じる。推測で補ってはならない。

記録者と権威を分ける視点もここにある。中継者は二つの優れた SA を運用できる。しかし、それを一つの合意済みチャネルと宣言する権限は持たない。端点間の事実は、端点が共有して検証できる証拠から生まれる。

出典