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:
- Alice, shown on the left in the image above, performs a KeyGen operation. This generates a public key (pk) and a secret key (sk).
- Alice then sends the public key to Bob and keeps the secret key.
- Bob performs an Encaps operation, consuming the public key that was received from Alice and generating a clear text (ct) and a shared secret (ss).
- Bob keeps the shared secret (ss) and sends the clear text (ct) back to Alice.
- Lastly, Alice uses the secret key (the one Alice kept) and the clear text (received from Bob) to perform a Decaps operation, and generate the same shared secret (ss) as Bob.
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 gateway, pictured on the left in the image above, first requests the key from the co-located QKD device using what's known as a Get Key request.
- The Get Key request returns the actual key value, which is secret, and a key identifier, which is public.
- IPsec transfers this public key ID to the remote IPsec gateway using an IKEv2 message. (Details of this process are discussed below.)
- The IPsec gateway on the right requests the same key from its co-located QKD device using a Get Key with Key IDs request.
- The encryptor provides the key ID in the request and receives the key value.
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 purple arrows represent the quantum and classical post-processing protocols between the QKD devices. There are no standards for this yet, so these purple arrows are currently typically proprietary protocols from the QKD vendor.
- The blue arrows represent the IKEv2 control plane messages for the IPsec tunnel.
- The green arrows represent the ETSI QKD 014 or the SKIP key delivery protocol between the QKD device and the IPsec gateway.
- The yellow arrows represent the ESP data plane protocol for the IPsec tunnel that is encrypted using the QKD data.
The sequence of events is as follows:
- The QKD devices are constantly producing key material.
- At some point in time the two IPsec gateways decide that they want to establish an IPsec tunnel.
- In the initial IKE_SA_INIT exchange they negotiate the use of PPK (Post-quantum Preshared Keys) and this roughly translates into requesting to use QKD.
- The initiator IPsec gateway requests the key from its co-located QKD device using a Get Key API call.
- Behind the scenes, the two QKD devices collaborate with each other to assign QKD material to the requested key and to assign a key identifier to it.
- Then the key value and the key identifier are returned to the initial IPsec gateway in the response to the Get Key request.
- The initiator IPsec Gateway transfers this key ID to the responder IPsec gateway into PPK identity notification, which is in the IKE_AUTH message.
- The IPsec gateway on the responder side then invokes the Get Key with Key IDs API call on its co-located QKD device, providing the public key ID that it received in the IKE_AUTH message. It gets back the secret key value.
- At this point, both IPsec gateways have the same shared secret encryption key that was produced by QKD.
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.
