Post-quantum key exchange in IPsec and IKEv2 (RFC 9370)

Short answer: RFC 9370 describes how to extend IKEv2, the key exchange protocol used with IPsec, so that multiple key exchanges take place while a shared secret is computed during Security Association setup. It says one or more post-quantum key exchanges should be performed together with an (EC)DH exchange, so the resulting key is resistant to quantum-computer attacks. The RFC is a protocol specification. It does not say which networks use it.

What the RFC describes

The abstract says the document 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. It uses the IKE_INTERMEDIATE exchange, in which multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.

Why combine classical and post-quantum exchanges

The RFC says it is essential to be able 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. It gives the reason: there is currently no post-quantum key exchange as well-studied as (EC)DH. Performing multiple exchanges, with different post-quantum algorithms alongside the well-established classical ones, addresses this concern because, in its words, the overall security is at least as strong as each individual primitive.

Using more than one post-quantum algorithm

The RFC says the method allows PQC to be integrated in IKEv2 while maintaining backward compatibility, to derive a set of IKE keys that is resistant to quantum-computer attacks. It allows negotiation of one or more PQC algorithms in addition to the existing (EC)DH exchange. It says it is believed that using more than one post-quantum algorithm is important, since many of these algorithms are relatively new and there may be a need to hedge the security risk with key exchange data from several distinct PQC algorithms.

Large payloads

The RFC notes that some post-quantum key exchange payloads may be larger than the standard maximum transmission unit, which could cause fragmentation issues at the IP layer. To allow larger payloads, the mechanism relies on the IKE_INTERMEDIATE exchange specified in RFC 9242. The key exchange starts with a smaller, possibly classical primitive such as (EC)DH. Then, before the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges are carried out, each containing an additional key exchange. The RFC says the IKE_INTERMEDIATE exchange is encrypted, which relates to how fragmentation is handled; the part of the text we reviewed breaks off there, so we do not describe the rest.

What this does not tell you

This article summarises the RFC's abstract and selected sections. It does not say which algorithms to pick, does not list the algorithm identifiers, and does not report any deployment. Implementers should read the full RFC.

FAQ

What does RFC 9370 add to IKEv2?

Support for multiple key exchanges while computing a shared secret during SA setup, using the IKE_INTERMEDIATE and IKE_FOLLOWUP_KE exchanges.

Why keep (EC)DH?

The RFC says no post-quantum key exchange is yet as well-studied as (EC)DH, so combining them means the overall security is at least as strong as each individual primitive.

Why allow several post-quantum algorithms?

Many are relatively new, so the RFC says it may be necessary to hedge the security risk with data from several distinct algorithms.

How does it handle large payloads?

By starting with a smaller exchange, then carrying out one or more IKE_INTERMEDIATE exchanges before IKE_AUTH, each with an additional key exchange.

Is it backward compatible?

The RFC says the method maintains backward compatibility.