要約

  • RFC 2410はNULLを恒等関数として定義し、鍵長とIV長をゼロビットに固定した。暗号化しないことは、欠落や実装依存ではなく、ESPの中で交渉できる明示的な選択になった。
  • NULL自体に安全性はないが、ESPは別の強い完全性・認証アルゴリズムを組み合わせられた。一方、通常のESPパケットは、その選択を中間装置へ決定的に知らせる表示を持たなかった。

暗号アルゴリズムのテストベクトルは普通、入力と出力が違うことを確認する。RFC 2410では違う。入力したデータが、そのまま正しい出力になる。変換式は NULL(b) = I(b) = b で完結する。

ローマ時代に由来するという文章はユーモアだが、相互運用条件は冗談ではない。IKEが扱う鍵長はゼロビット、IV長もゼロビット。状態を持たず、ブロック長は一オクテット。独立した実装が「何もしない」の表現だけで食い違わないようにした。

何もしない処理に名前を与える理由は、欠落と選択を分けるためだった。暗号変換が書かれていない状態は、未設定、エラー、既定値、意図的な無効化のどれとも読める。NULLという変換を交渉すれば、端点はESPを使いつつ機密性だけを選ばないと合意できる。

ここで「暗号変換」という分類を字面通りに読んではいけない。NULLは暗号変換のスロットに置かれたが、機密性を提供しない。RFC 2410は、NULL単独では他の安全サービスも提供しないと明記している。

それでもESP_NULLは無保護のIPパケットと同じではない。別の認証アルゴリズムを選べば、データ起源認証と完全性を提供できる。内容は見えるが、改変の検出と鍵に結び付いた送信元の主張は残る。

RFC 2410はAHとの類似を述べながら、境界も示した。ESP_NULLの認証計算は、AHが対象にするIPヘッダー部分を含めない。同じ認証アルゴリズムなら機密性がないことだけで暗号学的に劣るとは限らないが、保護範囲、NATとの関係、パケット形式まで同一になるわけではない。

RFC 2406は、ESP SAが強い暗号化または認証アルゴリズムの少なくとも一方を指定するよう求めた。RFC 4303でも、機密性と完全性は条件により別々にNULLにできるが、同時にNULLにはできない。この不変条件が、ESPという外形だけ残った無保護モードを拒んだ。

したがって、監査ログにENCR_NULLだけを残しても意味は足りない。完全性アルゴリズム、鍵の由来、ポリシー、リプレイ設定、受信方向と送信方向のSA、設置結果を結び付けなければ、実際のサービスは分からない。

NULLが見えたからといって、直ちにダウングレードとも言えない。完全性のみを認めるポリシーなら正当な選択である。機密性を必須としたポリシーがNULLを受け入れたなら、設定不整合や不正なダウングレードを疑える。同じ番号の意味を分けるのは、変換名ではなく当時のポリシーと交渉記録だ。

IKEv1のIPsec DOIレジストリはESP_NULLに11を割り当てた。現在のIKEv2変換レジストリも、ESP向けENCR_NULLを11として掲載し、IKEv2自体の保護には使用不可としている。番号は表、変換種別、利用プロトコルと一緒でなければ安全性の主張にならない。

レジストリは語彙を共有する仕組みであり、稼働証明ではない。値の読み方を定めても、あるSAで提案、選択、設置された事実までは記録しない。RFC 9395はIKEv1を歴史的状態へ移し旧レジストリを閉鎖したが、ENCR_NULLを廃止対象の暗号アルゴリズムには含めなかった。

RFC 8221は、認証のみのESPを実現するためENCR_NULLを実装必須として残した。NAT環境ではAHよりESPが扱いやすいという理由もあった。実装必須は選択肢を共通化する規則であって、あらゆるSAで使う命令ではない。

端点にとっての明示性は、中間装置にとっての可視性と一致しなかった。端点はSAを参照して選択済み変換を知る。途中の装置はESPヘッダーとSPIを見るが、そのSPIを解釈する信頼できるSA状態を持たないことがある。

通常のESPパケットには、「暗号化あり」「NULL使用」と万人に示す公開フラグがない。暗号文が偶然に内部プロトコルらしい並びを持つことも、平文がカプセル化やパディングで識別しにくいこともある。単なる外形観察は確定的な分類にならない。

この問題は、企業内の検査装置に現れた。完全性だけのトラフィックなら、マルウェア検査やアクセス制御のために内容を解析したい場合がある。暗号文を平文と誤認すれば解析は壊れ、平文を暗号文と誤認すれば検査回避が生まれる。

RFC 5840のWESPは、この曖昧さに明示的な表示を追加した。通常のESPだけでは中間装置が暗号化と完全性のみを決定的に区別できないため、ラッパーと交渉機構を設けた。WESPの存在は観測面の不足を示すが、普及率を証明しない。

RFC 5879は、既存端点を変えられない環境向けにヒューリスティックを文書化した。内部プロトコルらしい構造、長さ、検証関係を試してESP-NULLを推定する。実務上使える推論でも、端点の認証済みSA状態とは証拠の種類が違う。

さらに、その利用場面は管理された同一組織内を想定していた。端点が真の暗号化を選んで検査を回避しないよう、組織のポリシーが必要だった。観測アルゴリズムだけでは、相手に可視性を強制する権限を作れない。

決定的に識別できても、検査権限までは生まれない。WESPは機密性の有無を伝えられるが、誰が、何の目的で、どれだけ保存し、どの手続で読むかは決めない。読めるという技術的状態と、読んでよいという制度的判断は別である。

受信後の事実も分ける必要がある。入方向SAと出方向SAは別物だ。交渉成功は両方の設置を証明しない。完全性検証成功はリプレイ窓の受理を証明しない。IPsec処理成功は内側のファイアウォールやアプリケーションの受理を証明しない。

そのため運用記録は、対向ID、ポリシー版、提案と選択、方向別SPI、暗号・完全性アルゴリズム、鍵由来、設置応答、シーケンス状態、パケット計数、観測者の分類方法、検査権限、アプリケーション結果を別々に持つべきだ。

Lu Hengの現実レイヤーで見ると、レジストリは象徴、交渉は合意、SAは実行状態、パケットは観測対象、ヒューリスティックは推論、検査ポリシーは権限、アプリケーションは結果に属する。上流の一つの成功が、下流すべての代弁者にはならない。

最小初期仕様の考え方もよく表れている。共通層は、相互運用に必要な恒等変換とゼロ長パラメータだけを厳密に定めた。完全性のみを採用するか、可視化方式を追加するか、検査を許可するかは、結果を負う参加者に残された。

RFC 2410は「何もしない」を曖昧さなく標準化した。後のWESPとヒューリスティックの歴史は、その明示的な合意さえ、観測位置が変われば推測に戻ることを示している。

出典