KEM-based authentication IKEv2 post-quantum: is it ready?

KEM-based authentication in IKEv2 is a proposed post-quantum method in which VPN peers prove their identity with a key encapsulation mechanism such as ML-KEM instead of a digital signature. Each peer holds a long-term KEM key pair. If it can recover a secret encapsulated to its public key, it has proven possession of the private key. No signature is needed for that step.

Organisations that run operational technology (OT) and critical infrastructure often have site-to-site tunnels over constrained links: cellular backhaul, radio, satellite or ageing MPLS. On those links, every extra kilobyte in the handshake matters. This article explains what the IETF has specified, what is still a draft, and how to plan around it.

Can ML-KEM be used for authentication in IKEv2, not just key exchange?

Yes, but so far only in a proposal. The individual Internet-Draft draft-wang-ipsecme-kem-auth-ikev2 defines a new IKEv2 authentication method based on ML-KEM. Standardised post-quantum key exchange with ML-KEM is a separate, more mature document.

The base protocol, RFC 7296, authenticates peers with signatures or pre-shared keys in the IKE_AUTH exchange. The draft specifies how to realise KEM based authentication for IKEv2 [RFC7296] by defining a new authentication method, called KEM based Authentication.

The idea is simple. A responder publishes an ML-KEM encapsulation key in a certificate. The initiator encapsulates a fresh secret to that key, and only the real responder can decapsulate it and fold the result into the authentication payload. The same can happen in the other direction. For the transport, the IKE_INTERMEDIATE exchange may be used to facilitate the hybrid key exchange in IKEv2 as specified in RFC 9370, and to transfer PQ certificates between the responder and the initiator for completing KEM based authentication.

One consequence is easy to overlook. A peer must know the other side’s KEM public key before it can encapsulate, so certificates move earlier in the exchange than in classic signature-based IKE_AUTH. Engineers who troubleshoot IKEv2 from packet captures should expect a different message flow.

How does KEM-based authentication compare to ML-DSA signatures for VPN peers?

ML-KEM keys and ciphertexts are significantly smaller than ML-DSA public keys and signatures, and the KEM operations are faster. The trade-offs are a newer, less widely reviewed protocol design and a separate key type to manage in your PKI.

The main alternative uses signatures: draft-ietf-ipsecme-ikev2-pqc-auth, which covers ML-DSA and SLH-DSA in IKEv2. Both approaches rest on NIST’s 2024 standards. In NIST’s words, “These standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers”. The authors of the KEM draft compare the two families directly:

Source for the sizes: the signature size of ML-DSA is about 3 times the ciphertext size of ML-KEM, and when ML-KEM replaces ML-DSA for authentication, the saved communication overhead is 2,164, 2,989, and 4,083 bytes, respectively (draft-wang-ipsecme-kem-auth-ikev2-04, July 2026). Source for the speed figures: the slides presented at IETF 125, which state KeyGen 4 times faster, encap 7 times faster than sign, and decap 3 times faster than verify (2026). Draft author Guilin Wang summarised the point: “Those savings are helpful to improve the performance of IKEv2.”

What the comparison does not show

The KEM key still arrives in an X.509 certificate, and a certificate authority has to sign that certificate. The CA chain therefore keeps its signatures. The draft itself notes that besides the KEM certificate, additional intermediate signing certificates may be sent. The saving applies to the end-entity proof, not to the whole chain. If you run a deep PKI hierarchy across many substations or plants, flattening the chain may save as many bytes as changing the authentication method.

Does KEM-based authentication reduce IKEv2 message size and fragmentation?

It reduces the size of the authentication messages by roughly 2 to 4 KB per handshake, depending on the security level. That lowers the number of IKE fragments, but on a standard 1500-byte MTU path it rarely removes fragmentation altogether, because certificates remain large.

Fragmentation is already the normal case for IKE_AUTH. RFC 7383 notes that in most cases, IKE fragmentation will be used in the IKE_AUTH exchange, especially if certificates are employed. The signature-based post-quantum draft makes this explicit: “IKEv2 peers supporting the PQC authentication mechanism defined in this specification SHOULD implement IKEv2 message fragmentation”, according to the IPSECME working group in draft-ietf-ipsecme-ikev2-pqc-auth.

Key exchange adds its own volume. In draft-ietf-ipsecme-ikev2-mlkem, ML-KEM-768 carries 1,184 octets from the initiator and 1,088 from the responder (draft-04, 2026). ML-KEM-1024 carries 1568 / 1568 octets in each direction. An earlier version warned that ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP packet sizes larger than typical network MTUs (1500 bytes).

Why this matters more in OT networks

Industrial WAN links often have MTUs well below 1500 bytes because of tunnelling overhead, cellular encapsulation or legacy serial-to-IP converters. Some also have middleboxes that silently drop IP fragments. On those paths, every fragment you avoid reduces the chance that a rekey stalls. Before choosing an authentication method, do three things:

• Measure the effective path MTU on every OT link, not just the head-end.
• Confirm that RFC 7383 fragmentation is negotiated on both ends, so IKEv2 handles fragmentation itself instead of relying on IP fragments.
• Count the full certificate chain in bytes. Then decide whether a 2 to 3 KB saving changes the number of fragments on your worst link.

Which IETF drafts define KEM-based authentication for IKEv2?

The main document is draft-wang-ipsecme-kem-auth-ikev2 by Guilin Wang and Valery Smyslov. It builds on RFC 7296, RFC 9370 and the ML-KEM key exchange draft draft-ietf-ipsecme-ikev2-mlkem.

The ML-KEM key exchange draft explains its own scope: this specification is a profile of the Multiple Key Exchanges in IKEv2 specification [RFC9370] and registers new algorithm identifiers for ML-KEM key exchanges in IKEv2. The current version goes further and specifies how to use ML-KEM [FIPS203] as a key exchange in IKEv2, either by itself or alongside a traditional key exchange. FIPS 203 itself was published August 13, 2024.

The KEM authentication draft has evolved quickly. Version -02 added Valery Smyslov as co-author, and the current version is draft-wang-ipsecme-kem-auth-ikev2-04, dated July 2026 and set to expire on 4 January 2027. Related work by the same lead author includes a multi-authentication draft, and the IETF is discussing similar KEM-based authentication for TLS 1.3 and EDHOC.

Is KEM-based authentication ready for production site-to-site VPNs?

Not yet. It is an individual Internet-Draft with no final IANA codepoints for production use, and it can still change in ways that break interoperability. Production networks should deploy hybrid ML-KEM key exchange now and treat KEM authentication as something to test in a lab.

The priorities follow the threat. Recorded traffic that might be decrypted later (“harvest now, decrypt later”) is a confidentiality problem that only post-quantum key exchange solves. Authentication only needs to resist a quantum computer that exists at the moment of the handshake, so there is more time. That is why the IETF has advanced ML-KEM key exchange ahead of post-quantum authentication.

A practical sequence for OT and critical infrastructure

1. Now: enable hybrid key exchange (classical plus ML-KEM-768) on tunnels between control centres, plants and cloud environments. Keep classical certificate authentication in the meantime.
2. Next 12 to 24 months: inventory certificate chains, and test both ML-DSA and KEM-based authentication in a lab that copies your worst-MTU link.
3. When RFCs publish: choose the authentication method per link class. KEM authentication suits bandwidth-constrained remote sites. Signatures may be simpler where an existing PKI already issues ML-DSA certificates.

Crypto agility decides how painful step 3 will be. Field equipment in OT environments stays in service for a long time, so the encryption layer must be able to change algorithms without replacing hardware. Quantum Network’s QPN gateway, for example, combines a classical part and an ML-KEM (FIPS 203) part into one session key, renews both handshakes every two minutes, and allows the post-quantum algorithm to be changed if necessary.