Post-quantum IKEv2 ML-KEM: how does it work?

Post-quantum IKEv2 with ML-KEM means using the lattice-based key encapsulation mechanism standardised in NIST FIPS 203 as a key exchange method inside the Internet Key Exchange Protocol Version 2 (RFC 7296). The IKE and IPsec keys are then derived from a secret that a future quantum computer cannot recover from recorded handshakes.

For organisations running operational technology (OT) and critical infrastructure, this matters most on long-lived links: substation-to-control-centre tunnels, plant-to-cloud historian feeds and remote engineering access. Traffic on these links can stay sensitive for decades. This article explains how the mechanism works at the protocol level, which RFCs and drafts define it, and what to check before you rely on it.

How does ML-KEM work inside an IKEv2 key exchange?

In IKEv2, ML-KEM replaces or supplements Diffie-Hellman. The initiator sends an ML-KEM encapsulation key, the responder answers with a ciphertext, and both sides get a shared secret that goes into the IKEv2 key derivation.

Diffie-Hellman is symmetric: both peers send a public value. A KEM is asymmetric. The initiator generates a fresh key pair and puts the encapsulation (public) key in its Key Exchange payload. The responder runs Encaps against that key, keeps the shared secret it gets, and returns the ciphertext in its own KE payload. The initiator runs Decaps to recover the same secret. The security of ML-KEM is related to the computational difficulty of the Module Learning with Errors problem.

One detail matters for anyone troubleshooting failed handshakes. ML-KEM’s Decaps routine uses implicit rejection and will not return a distinguished error value. If the ciphertext was tampered with, the initiator gets a wrong secret instead of an error. The mismatch only shows up when IKE_AUTH fails to verify. In logs, a manipulated or corrupted ML-KEM exchange therefore looks like an authentication failure, not a key exchange failure.

NIST is cautious about the algorithm’s strength: “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” That wording is the main reason the IETF also supports hybrid modes.

• Statistic: FIPS 203 specifies 3 parameter sets: in order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024 (NIST, FIPS 203, 13 August 2024).
• Statistic: ML-KEM-768 requires 1,184 bytes for public key and 1,088 bytes for ciphertext while RSA-2048 uses 256 bytes for both (arXiv 2607.17573, 2026).

These sizes explain why the place where ML-KEM runs inside IKEv2 matters, as the next sections show.

What is RFC 9370 and how does it allow multiple key exchanges in IKEv2?

RFC 9370 is the IETF Standards Track extension that lets IKEv2 run several key exchanges in a row and fold all their secrets into the final keys. That is the basis for hybrid ECDH plus ML-KEM tunnels.

RFC 9370 was published in May 2023 by the IETF IPSECME Working Group. Its stated purpose is 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. It also generalises the base protocol: it updates RFC 7296 by renaming a Transform Type 4 from “Diffie-Hellman Group (D-H)” to “Key Exchange Method (KE)”, so a KEM can now be negotiated where a DH group used to sit.

Negotiation uses new “additional key exchange” transforms (ADDKE1 to ADDKE7) in the IKE_SA_INIT SA payload. After each extra exchange, the IKE SK_* values are updated, so the final IKE SA keys depend on all the key exchanges. In practice, each new shared secret is mixed with the previous SK_d and the nonces to form a fresh SKEYSEED.

• Statistic: ML-KEM in IKEv2 can be hybridized with up to 7 other key exchanges using RFC 9370 (ENISA, Hybridization Standardisation Status, 30 April 2026).

The authors of RFC 9370 explain why chaining matters while confidence in new algorithms is still building: combining post-quantum and classical algorithms works since the overall security is at least as strong as each individual primitive.

What is the difference between IKE_INTERMEDIATE and IKE_FOLLOWUP_KE?

IKE_INTERMEDIATE carries extra key exchanges while the IKE SA is first being set up. IKE_FOLLOWUP_KE carries them later, when the IKE SA is rekeyed or a Child SA is created or rekeyed.

IKE_INTERMEDIATE was defined in RFC 9242, and RFC 9370 reuses it. IKE_FOLLOWUP_KE is new in RFC 9370: it is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.

The fragmentation row is the practical one. IKE_SA_INIT is sent unencrypted, so IKE fragmentation cannot be used there. As the IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation protocol [RFC7383] can be used. The ML-KEM draft draws the same conclusion: if a PQ KEM does not fit inside IKE_SA_INIT without causing IP fragmentation, then it should be used after IKE_SA_INIT as an additional key establishment algorithm.

Can ML-KEM be used by itself in IKEv2 or only alongside ECDH?

Both are allowed. Later revisions of the IETF draft explicitly allow ML-KEM on its own as well as in a hybrid with (EC)DH.

The early working group versions were hybrid-only: draft -00 described how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. That changed during working group review. The current text describes how ML-KEM can be used by itself or combined with a traditional (EC)DH key exchange in IKEv2 for key establishment and registers three new algorithm identifiers for IKEv2.

RFC 9370 already left room for a single post-quantum exchange. It allows IKE peers to perform a single post-quantum key exchange in the IKE_SA_INIT without additional key exchanges, provided that the IP fragmentation is not an issue and that hybrid key exchange is not needed.

For critical infrastructure, hybrid is the conservative default: if either component holds, the session keys stay protected. Dedicated encryption gateways follow the same principle. Quantum Network’s QPN gateway, for example, combines a classical and an ML-KEM key agreement into one session key and renews both handshakes every two minutes.

Are IPsec Child SAs quantum-safe after rekeying with ML-KEM?

They are if ML-KEM went into the keying material those Child SAs are derived from. Data protected before the first ML-KEM exchange does not become quantum-safe after the fact.

Child SA keys (KEYMAT) are derived from the IKE SA’s SK_d plus nonces, and optionally a fresh key exchange. RFC 9370 notes that when creating or rekeying Child SAs, the peers may optionally perform a key exchange to add a fresh entropy into the session keys. In the case of an IKE SA rekey, the key exchange is mandatory. Three scenarios follow from this:

• IKE SA established with ML-KEM: SK_d already depends on a post-quantum secret, so Child SAs derived from it, including rekeys without a new key exchange, inherit that protection.
• Child SA rekeyed with ML-KEM: After the additional ML-KEM key exchange KE(1) has taken place in the IKE_FOLLOWUP_KE exchange, the IKE or Child SA are rekeyed by stirring the new ML-KEM shared secret SK(1) in SKEYSEED and KEYMAT. That adds fresh post-quantum entropy and forward secrecy.
• IKE SA established classically, ML-KEM added later: traffic sent before the ML-KEM rekey stays exposed to harvest-now-decrypt-later.

For the third case, the draft’s security considerations offer a remedy: the peers can enforce a policy to not encrypt any data until an ML_KEM exchange has taken place. [RFC9370] supports Childless IKE SAs which can be followed by a new Child SA after doing more key exchanges. Even then, the identities, configuration parameters and traffic selectors exchanged before the ML-KEM step remain classically protected.

How far is the IETF ML-KEM for IKEv2 draft from becoming an RFC?

It is at the last stage. The IESG approved draft-ietf-ipsecme-ikev2-mlkem as a Proposed Standard in July 2026, and the document is now with the RFC Editor.

The work started as an individual submission and was adopted by the IETF IPSECME Working Group as draft-ietf-ipsecme-ikev2-mlkem-00 on 29 April 2025. Over the following year, author Panos Kampanakis revised it through several versions, adding the standalone mode along the way. He sums up the goal plainly: “By integrating ML-KEM into IKEv2, IKEv2/IPsec tunnels become resistant to harvest-now-decrypt-later attacks.”

• Statistic: IESG has approved the document draft-ietf-ipsecme-ikev2-mlkem (Proposed Standard), dated 7 July 2026 (IETF Datatracker, IESG review decisions).

According to the Datatracker, revision -09 is in IESG state RFC Ed Queue, and the working group’s status update confirms that IKEv2 MLKEM and downgrade prevention drafts are in the RFC editor queue. The companion downgrade-prevention draft was approved one day earlier. ENISA’s April 2026 tracker describes the RFC Editor stage as “final editorial changes” on a document that is technically stable.

What remains is editorial work, final IANA code point assignment and publication under an RFC number. Before production rollout on critical links, check that your IKEv2 implementations use the final IANA-registered ML-KEM transform IDs, not early experimental values. Mismatched code points are a common reason why peers from different implementation lines fail to agree on a post-quantum transform.

What should OT and critical infrastructure operators check first?

Start with the links where data must stay confidential longest, and verify how ML-KEM is negotiated on them, not just whether it is supported.

• Placement: confirm whether ML-KEM runs in IKE_SA_INIT, IKE_INTERMEDIATE or IKE_FOLLOWUP_KE, and test the handshake across the real WAN path, including its MTU.
• Enforcement: make the additional key exchange mandatory on critical tunnels so a misconfigured peer cannot fall back to a classical-only SA unnoticed.
• Child SA policy: where peers are upgraded gradually, use childless IKE SAs or a “no data before ML-KEM” policy.
• Scope: remember that ML-KEM protects key establishment. Authentication in IKE_AUTH is a separate post-quantum migration topic in the IETF IPSECME Working Group.

Where routers or controllers on an OT segment cannot be upgraded to a post-quantum IKEv2 stack, an encryption gateway at each end of the link is an alternative architecture. Quantum Network’s QPN, for instance, encrypts at Layer 3 alongside existing firewalls and routers, without installing software on the equipment behind it. Whichever route you choose, the protocol questions above about placement, enforcement and rekeying still decide whether a link is actually quantum-safe.