要約

  • IESGは2026年8月24日、draft-ietf-ipsecme-ikev2-pqc-auth-12をProposed Standardとして承認した。8月27日の資料確定時点では、番号付きRFCではなく、RFC Editorの処理待ちにある現役のInternet-Draftだった。
  • 文書は、既存のIKEv2 Digital Signature方式で純粋モードのML-DSAとSLH-DSAを使う方法を定める。特定の装置がそれを選び、大きな認証メッセージを実経路で届け、AUTHを検証し、IKE SAと許可済みChild SAを成立させたことまでは示さない。

同じ表示でも、認証結果は同じではない

移行レビューに二台のVPNゲートウェイが並ぶ。どちらも資産画面では「耐量子対応」。ML-DSAの資格情報が登録され、ソフトウェアもアルゴリズムを認識する。構成表だけなら差はない。

しかし、一方の実通信ではローカル方針に従ってECDSAへフォールバックし、AUTHにも従来署名が記録される。もう一方は大きな耐量子認証データを分割して送り始めるものの、実経路上で再構成が完了しない。どちらのIKE SAもML-DSAでは認証されていない。

これは特定製品の障害報告ではなく、証拠境界を示すための分析例である。今回のニュースによって共通の実装経路は前進した。だが「このトンネルは耐量子署名で認証された」と言う権限は、標準化の進捗ではなく、接続ごとの記録から生まれる。

承認された文書の現在地

8月24日のIESG発表は、IP Security Maintenance and Extensionsワーキンググループが作成した第12版をProposed Standardとして承認した。中核となるIKEv2を置き換えるのではなく、既存の汎用署名認証の枠に耐量子方式を組み込み、ML-DSAとSLH-DSAを具体化している。

手続き上の状態もニュースの一部だ。8月27日、DatatrackerはIESG状態を「RFC Ed Queue」、RFC Editor状態を参照確認と整形待ちとしていた。文書の日付は8月21日、失効予定日は2027年2月22日で、まだ編集過程にある。現時点で「RFCが発行された」と書けば、確認可能な差を失う。

また、この草案はIANAに新しい割り当てを求めていない。既存のIKEv2登録値を組み合わせる。Digital Signatureは認証方式14、IKEV2_FRAGMENTATION_SUPPORTEDは通知16430、SIGNATURE_HASH_ALGORITHMSは16431、SUPPORTED_AUTH_METHODSは16443、Identityハッシュは値5である。登録値は共通語彙を提供するが、個々の装置がその値を送信した証拠ではない。

選ばれた署名はAUTHで確認する

IKE_SA_INITでは暗号パラメーター、nonce、鍵交換値を扱う。続くIKE_AUTHでは識別子と認証証拠を送り、通常は最初のChild SAも交渉する。鍵確立と署名認証は連続していても同一ではない。

RFC 7427のDigital Signature方式では、Authentication Dataの先頭にDER形式のAlgorithmIdentifierを置き、その後に署名値を続ける。実際のAUTHに現れたこの識別子が、ML-DSA-44などの方式とパラメーターを示す。

新草案はML-DSAとSLH-DSAの純粋モードを使う。セッション固有の署名対象を外部で事前ハッシュせず、署名方式へ渡すため、両者はSIGNATURE_HASH_ALGORITHMSでIdentityハッシュ5を通知しなければならない。相手が5を通知しなければ、それを必要とする方式は使えない。

ただしIdentity 5は署名方式の名前ではない。入力をそのまま扱うという条件である。両方向に5が見えても、最終選択はAUTHのAlgorithmIdentifier、提示された証明書、検証結果で確認する必要がある。

対応方式の通知は選択結果ではない

草案は、互換性のある鍵種別を見つける手段としてCertificate RequestとRFC 9593のSUPPORTED_AUTH_METHODSを挙げる。後者は、利用できる認証方式や署名方式を優先順で知らせる。

RFC 9593では、通知することも、その情報を使うことも任意である。複数資格情報がある場合の無駄な試行は減らせるが、後続AUTHの選択を約束しない。ML-DSAを通知した装置が方針によりECDSAを選ぶ場合も、証明書チェーンが受理されない場合もある。

NIST FIPS 204はML-DSA、FIPS 205はSLH-DSAを規定する。RFC 9881とRFC 9909はPKIX用のOID、符号化、鍵用途を定める。これらは相互運用に必要だが、秘密鍵の配備、証明書発行、トラストアンカー、暗号モジュールの能力、製品間の接続成功を保証しない。

したがって運用台帳には、鍵識別子、証明書フィンガープリント、発行チェーン、key usage、暗号プロバイダー、ソフトウェアビルド、適用する接続方針をひとまとまりで残すべきだ。

署名サイズが経路を検証対象にする

草案が示すサイズは小さくない。ML-DSA-44の公開鍵は1,312バイト、署名は2,420バイト。最小のSLH-DSA署名でも約7,856バイトで、さらに証明書チェーンが加わる。

このため、機構を実装するピアはIKEv2メッセージ分割に対応しなければならない。RFC 7383ではIKE_SA_INIT中にIKEV2_FRAGMENTATION_SUPPORTEDを通知し、その後のEncrypted payloadを含むメッセージを分割できる。IKE_SA_INIT自体はこの方式で分割できない。

対応通知は配送完了を証明しない。ゲートウェイが正しく分割しても、ファイアウォール、NAT、ロードバランサー、損失の多い経路で再構成に失敗し得る。信頼できるトランスポートや既知の十分なPMTUなら分割しない場合もある。必要な記録は、通知の有無、暗号化フラグメント数とサイズ、再送、再構成、最後の応答である。

耐量子鍵交換と耐量子認証を分ける

「耐量子VPN」という一語では、共有秘密を作る鍵交換と、資格情報で相手を証明する署名が混ざる。RFC 9370はIKEv2の複数鍵交換を定義し、緊急の焦点は機密性であって認証は扱わないと明記する。RFC 8784は追加の事前共有鍵を混ぜるが、既存の認証検査を置き換えない。

したがって、鍵確立に耐量子またはハイブリッド要素があっても、AUTHはECDSAやRSAという接続が成立する。逆にML-DSAでAUTHを検証しても、どの鍵交換グループを使ったかは分からない。二つの軸を別々に報告しなければならない。

AUTHの成功後にも認可が残る

署名検証が成功すれば、受理した資格情報の下で、そのセッション固有の署名対象が正しいと分かる。すべてのサブネット、Traffic Selector、利用者、アプリケーションを許可するわけではない。IKE SAが成立しても、最初のChild SAが失敗することはある。

完全な証拠列は、実装した文書版、ソフトウェアと暗号プロバイダー、鍵と証明書チェーン、両方向の通知、AUTHのAlgorithmIdentifier、分割と再構成、署名検証とIKE SAの相手識別、フォールバック、Child SAのセレクターと方針、実際の保護トラフィックまで続く。この列を通過して初めて「耐量子認証済み」が実行結果になる。

出典