up:: In the Protocols MOC
PQC in IPsec and IKEv2
Post-quantum IPsec is the work of making VPN tunnels and site-to-site links resist a quantum computer, and it happens in the key exchange that IKEv2 runs to set up each tunnel. The bulk encryption of the traffic is durable, so the exposed piece is the (EC)DH key exchange inside IKE, whose recorded output a future quantum computer could unwind to recover the session keys. The IETF standardized two complementary answers. RFC 9370 lets IKEv2 run multiple key exchanges in one negotiation, so a classical (EC)DH and a post-quantum ML-KEM exchange combine into a single shared secret, a hybrid. RFC 8784 mixes a post-quantum preshared key into the key derivation, so breaking the (EC)DH alone leaves the keys out of reach. Both rely on the IKE_INTERMEDIATE exchange to carry their extra payloads, and both close the harvest-now-decrypt-later window on recorded VPN traffic.
Source: CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov, “Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9370, May 2023, rfc-editor.org/rfc/rfc9370.
The short version:
- IPsec’s quantum problem is narrow. The traffic encryption survives, and the exposed piece is the (EC)DH key exchange inside IKEv2, which is the harvest-now-decrypt-later half.
- RFC 9370 adds multiple key exchanges to IKEv2. A classical (EC)DH runs first, then up to 7 additional exchanges (one of them an ML-KEM KEM) fold into the same derived secret, so the tunnel holds if any component survives.
- RFC 8784 takes a different route: a post-quantum preshared key is mixed into the IKEv2 key derivation, so an attacker who solves the (EC)DH still cannot recover the keys without also holding the preshared key.
- Both use the IKE_INTERMEDIATE exchange from RFC 9242 to carry the larger payloads, because a post-quantum KEM key does not fit the assumptions the original IKEv2 messages were built around.
- The two are complementary. RFC 9370 is the general hybrid-KEM answer for any deployment, and RFC 8784 is a lighter option for closed networks where both gateways can be pre-configured with a shared secret out of band.
Picture two embassies running a private diplomatic line between them, agreeing on the day’s cipher key by each contributing a number over an open channel and combining the two. For decades that combination used only elliptic-curve math, which a future quantum computer could reconstruct from a recording of the exchange. RFC 9370 has each side contribute a second, quantum-resistant number in the same setup and mixes it into the combination, so unwinding the elliptic-curve half leaves the key intact. RFC 8784 does something simpler: it requires that both embassies already share a secret passphrase, delivered by courier ahead of time, and blends that passphrase into every key, so intercepting and later breaking the open exchange is not enough. Different tools, same goal: make a recording captured today useless to a quantum computer tomorrow.
What is quantum-vulnerable in IPsec?
IPsec builds each tunnel with the Internet Key Exchange, IKEv2, and only one part of that process faces the quantum threat. IKEv2 does three jobs: it authenticates the peer gateway, it negotiates fresh session keys through a Diffie-Hellman exchange, and it hands those keys to ESP, which encrypts the actual packets. The packet encryption is symmetric and durable, so it is a strengthen-in-place item rather than a replacement. The exposed piece is the (EC)DH key exchange, because it rests on the discrete-logarithm math that Shor’s algorithm solves.
That places IPsec’s quantum exposure squarely in the harvest-now-decrypt-later category. An adversary who records the IKE exchange and the encrypted tunnel today can store it, wait for a capable quantum computer, solve the recorded (EC)DH, recover the session keys, and decrypt the whole captured tunnel retroactively. For VPN traffic carrying data that must stay confidential for years, that window is open now. The fix is to keep IPsec and ESP as they are and make the IKEv2 key exchange quantum-safe, which is exactly what the two RFCs below do.
Source: CJ. Tjhai et al., RFC 9370, §1.2, May 2023, rfc-editor.org/rfc/rfc9370.
How does RFC 9370 add post-quantum key exchange to IKEv2?
RFC 9370 extends IKEv2 to perform several key exchanges in sequence during one Security Association setup, so a classical exchange and a post-quantum one both contribute to the final key. Its abstract states the mechanism directly: it describes “how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.” The design goal in §1.2 is explicit about why: “It is essential to have the ability to perform one or more post-quantum key exchanges in conjunction with an (EC)DH key exchange so that the resulting shared key is resistant to quantum-computer attacks.”
The construction runs in a defined order:
- The first exchange is the classical one. The initial IKE_SA_INIT still carries a standard (EC)DH exchange, so a peer that does not understand the extension still completes a normal handshake.
- Additional exchanges follow in intermediate messages. RFC 9370 defines 7 additional key-exchange transform types, from ADDKE1 through ADDKE7, and one of them carries a post-quantum KEM such as ML-KEM. These run in IKE_INTERMEDIATE messages after IKE_SA_INIT.
- Every secret folds into the key derivation. RFC 9370 §2.2.2 chains each exchange’s shared secret into the keying material, so the final SKEYSEED depends on all of them. The tunnel key is therefore secure as long as any one component exchange remains unbroken, which is the hybrid property.
Source: CJ. Tjhai et al., RFC 9370, abstract, §1.2, §2.2.1, and §2.2.2, May 2023, rfc-editor.org/rfc/rfc9370.
Why does IKEv2 need the intermediate exchange?
The intermediate exchange exists because a post-quantum KEM key is too large for the message where IKEv2 originally carried key-exchange data, and that size problem echoes the oversized-handshake trouble in TLS. The original IKE_SA_INIT exchange was not built to fragment cleanly, and a post-quantum encapsulation key can be well over a kilobyte, so stuffing it into IKE_SA_INIT would run into the same packet-size and fragmentation limits that trip up other protocols. RFC 9242 defined a new exchange, IKE_INTERMEDIATE, that runs after IKE_SA_INIT and before IKE_AUTH and can be fragmented by the standard IKEv2 machinery.
RFC 9370 leans on that exchange for exactly this reason. Its §2.1.2 states that the additional key exchanges “are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange,” and that this is “to allow the standard IKE fragmentation mechanisms … to be available for the potentially large Key Exchange payloads with post-quantum algorithm data.” So the intermediate exchange is the carrier that makes room for the extra kilobyte of KEM material without breaking the initial handshake, and it is the enabling piece that the multiple-key-exchange design is built on.
Source: CJ. Tjhai et al., RFC 9370, §2.1.2, May 2023, rfc-editor.org/rfc/rfc9370.
What does RFC 8784 do differently with preshared keys?
RFC 8784 makes IPsec quantum-resistant without adding a post-quantum key exchange at all, by mixing a Post-quantum Preshared Key into the IKEv2 key derivation. Its title names the approach, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” and it is a Standards Track RFC from June 2020 that predates the ML-KEM standard. The idea is that if a strong shared secret is blended into every derived key, then solving the (EC)DH is not sufficient to recover those keys.
RFC 8784 §3 mixes the preshared key into the three main derived keys, computing each as a pseudorandom function of the PPK and the classically derived value, so that, per Appendix A, “even if the (EC)DH can be trivially solved, the attacker still can’t recover any key material” without the preshared key. That directly addresses harvest-now-decrypt-later: the abstract frames the threat as “someone storing VPN communications today could decrypt them at a later time when a quantum computer is available,” and the PPK dependency closes it. Two constraints shape where RFC 8784 fits:
- The preshared key is distributed out of band. RFC 8784 §5.2.1 assumes fixed PPKs “are configured within the IKE device in an out-of-band fashion,” so both gateways must be provisioned with the shared secret manually, which suits closed networks between known endpoints more than open, many-party deployments.
- It complements rather than replaces the (EC)DH. RFC 8784 §1.4 states it “does not replace the authentication checks that the protocol does; instead, they are strengthened by using an additional secret key,” and the (EC)DH exchange remains mandatory alongside the PPK.
Source: S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” RFC 8784, June 2020, rfc-editor.org/rfc/rfc8784.
Which approach should a VPN deployment use?
The two RFCs are complementary, and the choice comes down to whether a deployment can pre-provision a shared secret and whether it wants a full post-quantum key exchange. RFC 9370 is the general answer that scales to open and dynamic peerings, and RFC 8784 is the lighter answer for controlled point-to-point links.
| RFC 9370 (multiple key exchanges) | RFC 8784 (post-quantum preshared keys) | |
|---|---|---|
| Mechanism | Adds an ML-KEM key exchange alongside classical (EC)DH | Mixes a preshared key into the IKEv2 key derivation |
| Provisioning | Negotiated in the handshake, no shared secret needed in advance | Preshared key distributed out of band to both gateways |
| Best fit | Open, many-party, and dynamically peered tunnels | Closed networks between a fixed set of known endpoints |
| Carries the extra data via | IKE_INTERMEDIATE (RFC 9242) | The existing key-derivation step, no large payloads |
| Standard | RFC 9370, May 2023 | RFC 8784, June 2020 |
For most enterprise VPN estates, RFC 9370’s hybrid key exchange is the direction that matches the wider transition, because it uses the standardized ML-KEM and needs no manual key distribution. RFC 8784 is valuable where a manageable set of gateways can be pre-keyed and an organization wants quantum resistance without waiting on full KEM support in its stack. The catch that applies to both, unique to IPsec, is that a tunnel has two endpoints usually owned by different organizations, so a quantum-safe IPsec rollout requires both gateways to upgrade in lockstep, per the rule in the applied-PQC hub that a protocol is only as quantum-safe as its weakest deployed endpoint.
Source: CJ. Tjhai et al., RFC 9370, May 2023, rfc-editor.org/rfc/rfc9370; S. Fluhrer et al., RFC 8784, June 2020, rfc-editor.org/rfc/rfc8784.
Common misconceptions
- “Making a VPN quantum-safe means replacing IPsec.” The traffic encryption in ESP is durable. The quantum work is confined to the IKEv2 key exchange, so you keep IPsec and make the key setup quantum-safe.
- “RFC 9370 and RFC 8784 are competing standards.” They are complementary. RFC 9370 adds a post-quantum key exchange in the handshake, and RFC 8784 mixes in a pre-provisioned secret; a deployment picks based on whether it can distribute a preshared key out of band.
- “RFC 8784’s preshared key replaces the Diffie-Hellman exchange.” It complements it. The (EC)DH still runs, and the preshared key is mixed into the derivation on top, so an attacker has to defeat both.
- “You can just put the ML-KEM key in the first IKEv2 message.” The post-quantum key is too large for IKE_SA_INIT to carry and fragment cleanly, which is why RFC 9370 uses the IKE_INTERMEDIATE exchange to carry the additional key-exchange payloads.
- “If one VPN gateway is upgraded, the tunnel is protected.” A tunnel has two endpoints, usually owned by different organizations, and both have to negotiate the quantum-safe exchange. One un-upgraded gateway keeps the whole tunnel classical.
Questions people ask
Is IPsec quantum-safe? Not by default. The ESP traffic encryption is durable, but the IKEv2 (EC)DH key exchange is broken by Shor’s algorithm, so recorded tunnel traffic is exposed to a future quantum computer until the key exchange is upgraded.
How do I make my VPN quantum-safe? Use RFC 9370 to add a post-quantum ML-KEM key exchange alongside the classical (EC)DH in IKEv2, or RFC 8784 to mix a post-quantum preshared key into the key derivation, and upgrade both tunnel endpoints together.
What does RFC 9370 do? It extends IKEv2 to run multiple key exchanges in one setup, so a classical (EC)DH and up to 7 additional exchanges, including a post-quantum KEM, all fold into the final shared secret, making the tunnel key a hybrid that holds if any component survives.
What does RFC 8784 do? It mixes a post-quantum preshared key into the IKEv2 key derivation so that an attacker who solves the (EC)DH still cannot recover the session keys without also holding the preshared key, which must be distributed to both gateways out of band.
Why does IKEv2 use the intermediate exchange for this? Because a post-quantum KEM key is too large for the original IKE_SA_INIT message to carry and fragment, so RFC 9370 uses the IKE_INTERMEDIATE exchange from RFC 9242, which the standard IKEv2 fragmentation can handle.
Which one should I deploy? RFC 9370 for open or dynamically peered tunnels, since it needs no pre-shared secret and uses standardized ML-KEM. RFC 8784 for closed networks between fixed endpoints that can be pre-provisioned with a shared key.
Everything here is the map, given freely. When your team needs its own VPN gateways, tunnel endpoints, and IKE configurations assessed for a quantum-safe rollout, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.