要約

  • RFC 9867は、IKE_INTERMEDIATEとCREATE_CHILD_SAでPPKをIKEv2に混入し、新しいPPKを使ってChild SAやIKE SAを作成・リキーする方法を定める。
  • CREATE_CHILD_SAの応答にPPKアイデンティティがなくても、通常のIKEv2処理で新しいSAは作成され得る。強制ポリシーに反するなら、イニシエータは直後にそのSAを削除できる。
  • SAごとに、選択、確認、認可、作成、受容、利用、削除を分けるPPK混入レシートが必要だ。これはDaniel Kadeの編集上の提案であり、RFCやIETFの義務ではない。

「SAが作成された」というイベントには、結論らしい見た目がある。相手から応答があり、鍵素材が導出され、SPIが状態表に入り、運用システムは成功を一件増やせる。後日の移行報告は、その記録をPPKによる強化が完了した証拠として扱うかもしれない。

RFC 9867が示すのは、その推論に欠けた段階である。レスポンダが拡張を実装していない、設定していない、提示されたPPKアイデンティティに一致がない、または同じ名前に異なる値を持つ場合でも、任意ポリシーなら交換は先へ進み、SAは成立し得る。プロトコルの成功とPPK保護の証拠は同一ではない。

一つの接続に複数の鍵系譜がある

IKEv2は一個の不変なトンネルを作る仕組みではない。IKE SAを確立し、ピアを認証し、Child SAを作成し、双方を別々にリキーする。「このトンネルはPPKを使う」という表現には、どのSAか、どの交換か、どの鍵導出かという限定がない。

RFC 8784は、事前共有鍵をIKEv2のセッション鍵に混入する先行方式を定めた。初期確立時の利用を想定する一方、そのPPKで初期IKE SA自体を保護するものではない。RFC 9867はこの方式を置き換えず、二つの経路を追加する。

第一は、RFC 9242が定める認証前のIKE_INTERMEDIATEである。イニシエータはPPKアイデンティティを提示し、レスポンダは一つを選んで確認値を返せる。混入はIKE_AUTHより前なので、初期IKE SAと認証交換の保護に寄与する。他の中間鍵交換も再計算を行う場合、PPK処理は次の交換に進む前の最後の鍵再計算でなければならない。順序そのものが証拠になる。

第二はCREATE_CHILD_SAである。既存のIKE関係全体を壊さず、新しいPPKをChild SAの作成・リキー、またはIKE SAのリキーに用いられる。これは鍵の更新を現実的にするが、一つの論理的関係の下に異なる系譜を生む。古いIKE SA、継続するChild SA、新しいChild SA、リキー後のIKE SAに同じ保護ラベルを一括付与することはできない。

RFC 9370の複数鍵交換や、RFC 9838の耐量子ハイブリッド方式の用語は背景として重要である。しかしアルゴリズム一覧は能力を、交換ログは出来事を示すにすぎず、特定の寄与が特定SAの鍵に入ったことまでは証明しない。

一致と認可は別の判断である

RFC 9867は、USE_PPK_INT（通知値16445）とPPK_IDENTITY_KEY（通知値16446）を使う。IANAの登録簿で正式な割当を確認できる。これらは観測可能なプロトコル要素だが、秘密のPPKではない。観測の必要性は、秘密をログに残す理由にならない。

確認値は、定義された文脈に対する合意済み擬似乱数関数の出力から最初の8オクテットを取る。同名のPPKアイデンティティを選んだ二者が実際には異なる値を持つ状況を検出できる。設定名の一致より強い証拠だが、後に認証されたピアへそのPPKを使う権限までは与えない。

IKE_INTERMEDIATEでは、レスポンダがイニシエータの認証済みアイデンティティを知る前にPPKを選ぶ場合がある。認証後、その鍵が当該ピアには不適切だとローカルポリシーで分かるかもしれない。RFCは原則として中止すべきだとしつつ、ローカルポリシーが許せば継続を認める。鍵を見つけること、値を確認すること、相手を知ること、組合せを許可することは四つの状態である。

自動化はこの境界を消しやすい。鍵ストアは「存在」を、確認は「同値」を、認証は「相手」を示す。最後にポリシーが「利用可」を決める。一つの成功フラグでは、判断の主体も順序も復元できない。

作成後に拒否され、削除されるSA

最も明瞭な例はCREATE_CHILD_SAにある。イニシエータが新しいPPKを要求しても、レスポンダが未対応、未設定、不一致、または値違いなら、応答はPPK_IDENTITY_KEYを含まない。それでも通常のIKEv2処理は新しいSAを作成し得る。

PPKが任意なら、イニシエータはSAを受け入れて利用できる。必須なら、同じSAはポリシーを満たさず、直ちに削除できる。双方が仕様どおりに動作していても、作成数だけを見る計器は、後者の一時的オブジェクトを強化成功と誤認する。

少なくとも、作成時刻、PPK証拠の欠如をポリシーが評価した時刻、受容または削除時刻を分ける必要がある。削除までにパケットが通ったか、フェイルオーバーがSAをインストールしたか、ローカル削除後も相手が有効だと考えたかも問われる。RFCは交換動作を定めるが、運用上の主張に必要な証拠は運用者が所有する。

「必須」にも範囲と決定者が要る。特定ピア、トラフィック、リキー、移行段階だけの規則かもしれない。製品がPPK対応だからといって必須とは限らない。任意フォールバックも正当な相互運用判断である。問題は、それを強い状態の証明として報告することだ。

鍵ではなく鍵遷移のレシート

ここで提案する PPK混入レシート は編集上の統制記録であり、RFC 9867のフィールドでも、新規プロトコルでも、秘密収集命令でもない。

新規またはリキーされたSAごとに、交換種別と親IKE SAの系譜を記す。RFC 8784か、RFC 9867のどちらの経路かを区別する。秘密でないアイデンティティまたはプライバシーに配慮した指紋、提示・選択状態、確認結果、認証済みアイデンティティが判明した時点を残す。観測可能な範囲で双方の必須・任意ポリシー、版、決定者、例外責任者も結び付ける。

次に導出順序を記録する。中間交換が複数あれば、PPK処理は要求どおり最後だったか。SPIやSA識別子はレシートを対象に結び付けるが、計算そのものの証明ではない。作成、インストール、受容、最初のパケット、最後のパケット、削除を別状態にし、フォールバック理由、削除理由、ロールバック、再審査日を付ける。

観測限界も不可欠である。パケットキャプチャは通知と通信を示せても、実装内部の秘密の鍵スケジュールまでは見えないことがある。実装は秘密を公開せず、寄与を適用したと証言できる。ベンダーをまたぐ主張は限定された信頼を必要とする。どの部品が何を観測し、何が推測かをレシートに明示すべきだ。

問うべきは「IKEは成功したか」ではない。このSA、この系譜、このポリシーについて、意図したPPKが正しい時点で正しい導出に入ったと何が示し、その後SAはどう扱われたか、である。

移行の主張はSA単位で閉じる

耐量子の動機にも境界がある。RFC 9867は、暗号学的に有意な量子計算機に対して、対称暗号プリミティブは議論対象の公開鍵方式と同じ影響を受けるとは現在考えられていないと説明する。強いPPKを認証前に混入することは保護経路を加える。しかし、該当する計算機が既に存在するとも、時期を予測するとも、製品を「量子安全」と認定するとも述べていない。

新しいPPKは実際に異なる必要がある。同じPPKを再利用するなら、新鮮な更新経路を使う意味がない。エントロピー、保管、配布、漏えい時の対応は運用責任であり、交換完了だけでは証明できない。

誠実な移行報告は、全体を一語で塗らず、SAごとの経路と結果を数える。RFC 8784、IKE_INTERMEDIATE、新しいPPKによるリキー、任意フォールバック、確認失敗、必須ポリシーによる作成直後の削除である。この差は消すべきノイズではなく、意思決定の実体だ。

プロトコルが能力差のある相手とも進めるのは、ネットワークが動き続ける必要があるからだ。ガバナンスは、どの状態で進んだかを保存する。RFC 9867は柔軟な移行を可能にしたが、「作成」を存在しない証拠へ書き換えてはいない。

出典