Quantum-powered Changes to IPsec

Quantum-powered Changes to IPsec

by Bruno Rijsman

This article focuses on the extensions to IPsec that enable Post Quantum Cryptography (PQC) and Quantum Key Distribution (QKD) for key exchange, ensuring that encrypted communications remain secure against quantum-enabled threats. However, this discussion covers only securing the IPsec key exchange process, it does not cover IPsec authentication.

PQC standards for IPsec authentication are still being refined at the time of this writing. This is a topic we will cover when the standards are more solidified. For now, we explore how PQC-based key exchange is being standardized and implemented within IPsec, helping organizations proactively defend their communications against sophisticated threats.

What is ML-KEM and how is it implemented for IPsec?

NIST published FIPS 203 in August of 2024. This is the standard for the first quantum-safe algorithm to replace quantum-vulnerable Diffie-Hellman. The name of the new algorithm is ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism..

At a high level, ML-KEM works as follows:

ML-KEM is based on the Module Learning with Errors problem. After rigorous examination, it is strongly believed to be computationally infeasible for an eavesdropper to reverse engineer the shared secrets from these publicly communicated values, even when using a quantum computer running Shor’s algorithm.

How IKEv2 PQC Key Exchange Works

We now describe how the IKEv2 exchange has been extended to support ML-KEM for Post-Quantum Cryptography. For details about the original process, please see the on-demand webinar Quantum-safe IPsec, where this is discussed at timestamp 07:42. The relevant RFCs for each step are listed here on the right side of the image below.

Change #1: Renaming the Diffie-Hellman Group payload. The first change, highlighted in red below, is that the Diffie-Hellman group payload has been generalized and renamed to Key Exchange Method.

This is a backwards compatible change; it's just renaming the element. When a Diffie-Hellman group is negotiated, the binary representation of the payload doesn't change at all. IPsec still performs a Diffie-Hellman key exchange, as highlighted in green above, even when PQC is enabled. This is because many current security standards and regulations still mandate the use of classical quantum-vulnerable algorithms like Diffie-Hellman and RSA. This hybrid approach is a practical solution during the transition to fully quantum-safe cryptographic standards, balancing enhanced security with compliance and interoperability considerations.

Functionally, this hybrid method means additional rounds of PQC key exchanges are performed alongside the Diffie-Hellman exchange, leading to change #2.

Change #2: New transform types for the additional rounds of key agreements. In the example below, there is an additional key exchange protocol being negotiated: ML-KEM 256, highlighted in blue. There is no corresponding PQC key exchange payload in the IKE_SA_INIT message.

There is only a key exchange payload for the traditional Diffie-Hellman exchange, highlighted in purple in the example. The reason additional PQC key exchange payloads are not in the IKE_SA_INIT message is PQC public keys are so large they do not fit in UDP packets without fragmentation. IPsec has its own fragmentation mechanism, but IPsec does not allow the first IKE_SA_INIT message to be fragmented. Therefore, the key exchange payloads for the additional PQC keys are moved from this message to a separate, follow up message.

Two new IPsec RFCs have been introduced to allow for these additional rounds of PQC exchanges. RFC9242 introduces a new message type, IKE Intermediate, pictured below. RFC9470 describes how this new message type can be used to do multiple rounds of hybrid key exchange.

In this example, there is one additional IKE Intermediate exchange for the extra single round of PQC key exchange using ML-KEM. The key exchange payload in this extra intermediate message is used to carry Alice's public key and Bob's clear text. Since this public key is too large to fit in a single UDP packet, this IKE Intermediate message is IKEv2 fragmented. The IKE_SA_INIT message contains notifications to negotiate the use of this new intermediate key exchange feature and of the existing fragmentation feature, both of which are needed to make this work.

How is QKD used with IPsec?

The image below shows how IPsec is deployed in combination with Quantum Key Distribution (QKD).

There are two IPsec gateways with an IPsec tunnel in between. There are also two QKD devices, one on each side, which are responsible for producing the quantum-safe keys. The QKD devices use the quantum properties of individual photons to exchange keys with each other over dedicated fibers, as shown in purple in the image above.

How are QKD-generated keys delivered?

Once the QKD devices have produced a key, they pass them to the IPsec gateway through a special interface.

There are two main protocols for handling this delivery:

ETSI QKD 014. Standardized by the European Telecommunication Standardization Institute (ETSI).

SKIP. The Secure Key Integration Protocol, or SKIP, defined by Cisco and recently documented in a public draft-cisco-skip-00.

Most QKD devices support both ETSI QKD 014 and SKIP. Most IPsec encryptors use ETSI QKD, except for Cisco encryptors which typically use SKIP. Both protocols are similar in how they operate. Both protocols are mechanisms for handing the produced key to the encryptor, regardless of the QKD protocol used to generate the key. Below is an example of a pair of QKD devices delivering a pair of symmetric encryption keys to a pair of IPsec firewalls.

This particular example is using ETSI QKD 014, but an example using SKIP would look very similar. Both ETSI QKD 014 and SKIP are REST interfaces that run over HTTPS. The flow of messages is as follows:

The IPsec gateways then each have the same symmetric shared key and can begin encrypting traffic in the IPsec tunnel.

Integrating QKD Keys into IPsec with IKEv2 Extensions

Once a QKD-generated key ID is delivered to an IPsec gateway, it still needs to be securely incorporated into the IPsec key exchange process. This is where IKEv2 comes in.

The IKEv2 protocol has been extended with RFC8784, which defines a new payload called the Post-quantum Preshared Key or PPK. The term “post-quantum preshared” might seem confusing; it's called “preshared” because RFC8784 was originally envisioned to use manually configured shared quantum-safe keys. It was only later that RFC8784 was generalized to be used for quantum keys dynamically produced by QKD devices.

The protocol is simple: in the IKE_SA_INIT exchange there is a USE_PPK notification to negotiate the use of this extension. Then, in the IKE_AUTH exchange, the key identifier is transferred using the PPK_IDENTITY notification. RFC8784 describes how to mix this QKD produced key with the rest of the key material, as shown in the gray box in the image above.

Below is an end-to-end example of how all the various protocols work together to use QKD in the context of IPsec.

The sequence of events is as follows:

The IPsec gateways typically mix this QKD key with a traditional Diffie-Hellman key, and sometimes also with one or more PQC keys. A final resulting mixed key is used to encrypt the ESP data plane.

As quantum-safe IPsec becomes more accessible in real-world deployments, understanding how quantum-secure keys are delivered and integrated into existing protocols is essential. The pieces are already in place for organizations to start scaling quantum-safe architectures. PQC and QKD can be implemented now in readily available popular network management products. (To see how PQC and QKD are implemented step-by-step using real-world network management tools see the blog post Real-world Implementation of Quantum-safe IPsec.)

The tools are available. Now is the time to integrate and plan ahead for your organizations quantum-powered future.

A full report on this topic can be found in the white paper Quantum-safe IPsec.

Bruno Rijsman