Post-Quantum IPsec / IKEv2

IPsec VPNs negotiate their keys with IKEv2. Post-quantum migration typically involves three layers of mechanism: RFC 8784 provides a post-quantum preshared key (PPK) path; RFC 9242 provides the Intermediate Exchange to carry larger PQC payloads; and RFC 9370 provides a framework for multiple key exchanges. The concrete binding of ML-KEM as an additional IKEv2 key exchange is defined by draft-ietf-ipsecme-ikev2-mlkem, which is still an Internet-Draft.

RFC 8784 — Post-quantum preshared keys (PPK)

RFC 8784 ("Mixing Preshared Keys in IKEv2 for Post-quantum Security") takes the simplest possible path to quantum resistance: it mixes an additional preshared key (PPK) into the IKEv2 key derivation. Because the PPK is a high-entropy secret distributed out of band, an attacker who later breaks the classical Diffie-Hellman exchange still cannot derive the session keys without also knowing the PPK.

No new public-key algorithm is required — it works on existing IKEv2 stacks plus the PPK extension.
Strong protection against Harvest Now, Decrypt Later for recorded VPN traffic.
The operational cost is distributing and rotating PPKs securely across peers — a key-management problem, not a cryptographic one.

RFC 9370 — Multiple key exchanges in IKEv2

RFC 9370 ("Multiple Key Exchanges in IKEv2") generalizes IKEv2 so a single negotiation can chain several key exchanges whose results are combined. This is the IKEv2 equivalent of TLS hybrid groups: negotiate a classical group (for example a standard ECDH/MODP group) and then layer one or more ML-KEM exchanges on top, so the final keys are safe unless every exchange is broken.

Introduces additional key-exchange transforms (beyond the single classical group of base IKEv2).
Together with the current ML-KEM IKEv2 draft and supporting implementations, it lets operators add ML-KEM-768 / ML-KEM-1024 as additional key exchanges alongside the classical group.
Supported or being integrated in major IPsec stacks such as strongSwan and libreswan; verify the exact version, plugin, and algorithm naming.

RFC 8784 vs RFC 9370

	RFC 8784 (PPK)	RFC 9370 (multiple KE)
Mechanism	Mix in a preshared key	Chain extra key exchanges (e.g. ML-KEM)
New crypto?	No public-key change needed	Adds PQC KEM transforms
Main cost	Distributing/rotating PPKs	Larger handshakes, more compute
Best for	Quick HNDL mitigation on existing kit	Forward-looking hybrid PQC VPNs

The two are not mutually exclusive — a deployment can use a PPK and negotiate an additional ML-KEM exchange for defense in depth.

Example: strongSwan-style configuration

A swanctl connection that negotiates a classical group first and then layers ML-KEM as an additional key exchange looks roughly like this (algorithm names vary by stack version):

connections {
    pq-tunnel {
        proposals = aes256gcm16-prfsha384-x25519-ke1_mlkem768
        # x25519 = classical group; ke1_mlkem768 = additional ML-KEM-768 exchange (an additional key exchange mechanism per RFC 9370; the exact algorithm name varies by strongSwan version).
        ...
    }
}

Note

RFC 8784 (PPK) is the fastest way to get HNDL protection onto existing IPsec deployments because it needs no new public-key math. Use RFC 9370 with ML-KEM where you want a standards-based hybrid that does not depend on out-of-band shared secrets.

Standards & references

RFC 9370 — a framework for multiple key exchanges in IKEv2, usable for hybrid post-quantum IKEv2.
RFC 9242 — the IKEv2 Intermediate Exchange, used to carry larger PQC payloads.
RFC 8784 — post-quantum preshared keys mixed into IKEv2.
draft-ietf-ipsecme-ikev2-mlkem — the ML-KEM additional key exchange binding in IKEv2.
Resources — full standards register

后量子 IPsec / IKEv2

IPsec VPN 通过 IKEv2 协商密钥。后量子迁移通常涉及三层机制：RFC 8784 提供后量子预共享密钥 PPK 路径；RFC 9242 提供 Intermediate Exchange，以承载更大的 PQC 负载；RFC 9370 提供多重密钥交换框架。ML-KEM 作为 IKEv2 附加密钥交换的具体绑定由 draft-ietf-ipsecme-ikev2-mlkem 定义，当前仍处于草案阶段。

RFC 8784 后量子预共享密钥 PPK

RFC 8784（"在 IKEv2 中混入预共享密钥以实现后量子安全"）走的是最简单的抗量子路径：把一个额外的预共享密钥（PPK）混入 IKEv2 密钥派生。由于 PPK 是带外分发的高熵秘密即便攻击者日后攻破了经典 Diffie-Hellman 交换只要不知道 PPK 仍然无法推导出会话密钥。

无需新的公钥算法——在现有 IKEv2 栈加上 PPK 扩展即可工作。
对已录制的 VPN 流量提供强有力的先收集、后解密防护。
运维成本在于跨对端安全分发并轮换 PPK——这是密钥管理问题而非密码学问题。

RFC 9370 IKEv2 多重密钥交换

RFC 9370（"IKEv2 中的多重密钥交换"）对 IKEv2 做了通用化使单次协商可串联多个密钥交换并将结果合并。这相当于 IKEv2 版的 TLS 混合分组：先协商一个经典分组（例如标准 ECDH/MODP 分组）再在其上叠加一次或多次 ML-KEM 交换这样除非每一次交换都被攻破否则最终密钥都是安全的。

引入额外的密钥交换变换（超出基础 IKEv2 仅有的单一经典分组）。
结合当前的 ML-KEM IKEv2 草案与支持它的实现，运营商可在经典分组之外加入 ML-KEM-768 / ML-KEM-1024 作为附加密钥交换。
已在 strongSwan、libreswan 等主流 IPsec 栈中支持或集成中；请核对具体版本、插件与算法命名。

RFC 8784 与 RFC 9370 对比

	RFC 8784（PPK）	RFC 9370（多重 KE）
机制	混入预共享密钥	串联额外密钥交换如 ML-KEM
是否新增密码	无需改动公钥算法	新增后量子 KEM 变换
主要成本	分发与轮换 PPK	握手更大算力更高
适用场景	在现有设备上快速缓解 HNDL	面向未来的混合后量子 VPN

两者并不互斥——一套部署可同时使用 PPK 并协商一次附加 ML-KEM 交换实现纵深防御。

示例 strongSwan 风格配置

一个先协商经典分组再叠加 ML-KEM 作为附加密钥交换的 swanctl 连接大致如下（算法名称随栈版本而异）：

connections {
    pq-tunnel {
        proposals = aes256gcm16-prfsha384-x25519-ke1_mlkem768
        # x25519 = 经典分组；ke1_mlkem768 = 附加 ML-KEM-768 交换（基于 RFC 9370 的 additional key exchange 机制，具体算法名随 strongSwan 版本而异）。
        ...
    }
}

提示

RFC 8784（PPK）是给现有 IPsec 部署快速加上 HNDL 防护的最快途径因为它无需任何新的公钥运算。若希望获得不依赖带外共享秘密的标准化混合方案请配合 ML-KEM 使用 RFC 9370。

标准与参考

RFC 9370 — IKEv2 多重密钥交换框架，可用于混合后量子 IKEv2。
RFC 9242 — IKEv2 Intermediate Exchange，用于承载更大的 PQC 负载。
RFC 8784 — 混入 IKEv2 的后量子预共享密钥。
draft-ietf-ipsecme-ikev2-mlkem — IKEv2 中 ML-KEM 附加密钥交换绑定。
资源链接 — 完整标准登记册

Previous上一页← SSHSSH Next下一页X.509 CertificatesX.509 证书 →