要約

  • RFC 5386 は、ピア自身が提示した公開鍵に対する IKEv2 署名を検証しても、その鍵を外部の人物・組織・名前・アドレスに結び付けたとは扱わない。
  • 非BTNSのPADエントリーが先に評価され、既知の身元に一致して認証に失敗したピアは拒否される。ワイルドカードへ落としてはならない。
  • BTNSのChild SA識別範囲は既知関係と重複できず、トラフィックはBTNS_OKを明示したSPDエントリーだけに入れる。

入場券と代理権を分ける

IKE SA の成立は、ピアとの制御関係を作る。Child SA のセレクターは、その関係がどのトラフィックを扱えるかを決める。両者を一つの「接続成功」にまとめると、匿名の入場券が他者のアドレスを代理する権利に変わり得る。

RFC 5386 の例では、セキュリティゲートウェイが既知の相手と BTNS 対応の未知ピアを同時に扱う。未知ピアが自分の公開鍵を提示し、対応する秘密鍵で署名できても、既知ホストのアドレスを名乗る権限までは得ない。

仕様は PAD を二つの場面で使う。最初は IKE ピアの認証方式を選ぶ。次は BTNS ピアが提案する Child SA の識別範囲が、非BTNSエントリーの範囲に衝突しないかを確認する。単一パス実装でもよいが、意味は保存しなければならない。

この二回目の確認がなければ、最初の認証分離は形式だけになる。攻撃者は匿名として入った後、既知のネットワークをセレクターに書くだけで、強い関係のトラフィックを受け取れるからだ。

既知の失敗は未知ではない

PAD は順序付きリストである。通常のエントリーを先に検索し、ピアが主張した ID に一致する関係を探す。該当する相手が必要な認証を通過できなければ、IKE SA は拒否される。

ここで検索を続け、最後の匿名エントリーに一致させることは許されない。「この身元を知らない」と「この身元を知っているが証明が失敗した」は違う。後者を前者に変換すれば、認証失敗が弱いモードを呼び出す合図になる。

通常エントリーが一つも一致しない場合だけ、実装はローカルな ID を PUBLICKEY に変換できる。値はピアの公開鍵で、ネットワーク上に新しい ID が送られるわけではない。その後に BTNS エントリーを検索する。

全BTNSエントリーは論理的に通常エントリーの後ろに置かれ、ワイルドカードは一つだけ、しかも最後でなければならない。この配置は検索効率ではなく、拒否権の所有者を定める。

署名が示したのは秘密鍵の保持

BTNS は IKEv2 AUTH の署名を捨てていない。ピアは裸の公開鍵を CERT payload に入れ、その秘密鍵で交換を署名する。検証できれば、交換を行った主体が秘密鍵を保持したという証拠になる。

ただし、公開鍵に名前を与えたのも同じピアである。CA、事前登録、DNSSEC などの外部根拠がなければ、署名は会社名やホスト名、アドレス所有者を証明しない。RFC 5386 が限定的な意味で「authenticated」と呼ぶ対象は、鍵そのものに近い。

RFC 5387 はこれを association の継続性として説明する。一つの SA の寿命では同じ未認証ソースとの通信を保てる。最初の確立が中間者に奪われていなければ、IPsec の完全性、機密性、アンチリプレイは実際に働く。

それでも別の SA へ自動的に同じ身元が続くわけではない。rekey は新しい窓を開く。公開鍵が変わっても各 SA 内部だけを見れば正しく見える場合がある。

BTNS_OK は匿名モードの適用範囲を固定した

RFC 5386 は SPD エントリーに BTNS_OK を加えた。BTNS ピアのトラフィックは、そのフラグを持つルールだけに一致できる。実装が BTNS を搭載していることは、全サービスで受け入れる判断ではない。

たとえば公開 NFSv4 サービスだけを匿名保護に開き、管理系や既知ゲートウェイ間の通信は従来認証に残せる。匿名モードの権限はピア全体ではなく、ローカルのトラフィック分類に付く。

監査では、鍵指紋だけでなく、どの PAD エントリー、どの SPD エントリー、どのセレクターが結合したかを残す必要がある。SA がインストールされた事実だけでは、対象パケットがその SA を通ったことも、アプリケーションが処理を許可したことも分からない。

RFC 7619 の NULL Authentication も、未認証ピアを受け入れる SPD ルールに明示フラグを求める。また、認証可能な同一セレクター範囲で未認証モードを優先すべきでないとする。弱い証明は局所的な opt-in でなければならない。

上位認証は後から中間者を見つける

Stand-Alone BTNS はネットワーク層の身元認証を行わない。最初の交換に能動的中間者が入れば、攻撃者は両端と別々の SA を作れる。作成後の暗号が正しいことは、作成者が正しいことを保証しない。

Channel-Bound BTNS は、上位プロトコルの認証を IPsec チャネルに結び付ける。channel binding 値が異なれば、二つの SA を中継した攻撃を上位認証が検出できる。connection latching は上位のフローを連続する SA に結び付ける。

しかし検出時刻は IKE 成功後である。SA と状態はすでに作られている。上位認証が再利用可能なパスワード材料を送る設計なら、失敗を検出しても露出は取り消せない。RFC 5387 はその組み合わせを避けるよう警告する。

証拠も時間順に残すべきだ。IKE 結果、SA 対、latch、channel binding、上位主体、アプリケーション許可は別のレコードである。最後の成功で前の未認証状態を書き換えてはならない。

平文へのフォールバックは仕様外だった

RFC 5386 は、相手が IKEv2 を使えない場合に未保護 IP へ落ちる opportunistic モードを定義していない。leap of faith と connection latching も本文では完成させていない。

RFC 5387 は BTNS を「より強い安全」の代替ではなく、「保護なし」の代替として位置付ける。証明書が失敗したら匿名鍵、それも失敗したら平文、という階段を作れば別のシステムである。

拒否ログが重要になる。既知ピアの認証失敗後に処理が止まった記録は、降格が起きなかったことを示す。成功 SA だけを保存するダッシュボードは、最も重要な veto を消してしまう。

証拠の限界

公式資料が示すのは標準の設計、履歴、想定脅威であり、現在の製品実装、導入率、実際の攻撃ではない。RFC 4306 の raw RSA 文脈は RFC 7296 と RFC 7670 で変化した。現行環境について述べるには、実装版、設定、トレースとパケット観測が必要だ。

Lu Heng の枠組みで見れば、主張 ID、鍵保持、PAD 判断、セレクター権限、SPD 判断、SA 状態、パケット処理、上位主体、業務結果は別々の現実層にある。匿名鍵を扱うこと自体が誤りではない。誤りは、その鍵が既知関係の失敗や識別範囲を引き継げるようにすることである。