RFC 8784 post-quantum preshared key IKEv2: how it works

An RFC 8784 post-quantum preshared key (PPK) is a high-entropy symmetric secret that both IKEv2 peers hold in advance. It gets mixed into the key derivation of an IPsec tunnel, so the traffic keys stay secret even if a future quantum computer breaks the Diffie-Hellman exchange defined in RFC 7296. This matters most for OT links between sites, cloud networks and remote users, where data has to stay confidential for many years.

This article explains how the mechanism works and where it falls short. It also compares the PPK with RFC 9370 multiple key exchanges and covers the practical side: generating, distributing and rotating PPKs across a large estate of sites.

What is a post-quantum preshared key (PPK) in IKEv2?

A PPK is an extra shared secret that IKEv2 feeds into its key derivation function next to the Diffie-Hellman result. It is not used for authentication. Its job is to make the derived keys depend on something a quantum computer cannot work out from the recorded handshake.

The RFC’s model is simple: each IKE peer has a list of Post-quantum Preshared Keys (PPKs) along with their identifiers (PPK_ID), and any potential IKE initiator selects which PPK to use with any specific responder. In addition, implementations have a configurable flag that determines whether this PPK is mandatory. The design was deliberately conservative: the primary goal of this document is to augment the IKEv2 protocol to provide protection against quantum computers without requiring novel cryptographic algorithms.

How the negotiation works

In the IKE_SA_INIT exchange, the initiator sends a USE_PPK notification to signal support. In IKE_AUTH, it sends a PPK_IDENTITY notification that names the key it has chosen. It can also send a NO_PPK_AUTH payload, so that a responder without a PPK can still accept the connection when the PPK is not mandatory. Once both sides agree, PPKs are mixed into SK_d, SK_pi, and SK_pr (i.e., into the PRF/KDF inputs) per RFC 8784. Because every Child SA key is derived from SK_d, the IPsec traffic keys now depend on the PPK.

NIST SP 800-77 Rev. 1, the federal guide to IPsec VPNs, includes a section on Postquantum Preshared Keys (PPKs) in its IKE chapter. That shows the mechanism is part of mainstream IPsec practice, not an experimental add-on.

How does RFC 8784 protect IPsec tunnels against harvest now, decrypt later?

A PPK stops a recorded IKEv2 handshake from being enough to rebuild the traffic keys. Breaking the elliptic-curve or finite-field Diffie-Hellman exchange later, with a quantum computer, gives an adversary only part of the input. The secret PPK is still missing.

The RFC authors stated the threat directly when the RFC was published: “someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.” Their answer: assuming that the two end systems share a long secret key, then the resulting exchange is quantum secure.

The protection only holds if the PPK is strong enough:

• Entropy: The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy; this will provide 128 bits of post-quantum security (IETF RFC 8784, June 2020).
• No human-chosen values: Deriving a post-quantum preshared key from a password, name, or other low-entropy source is not secure.

What a PPK does not cover

The base specification has a known gap. An IETF follow-up draft notes that RFC 8784’s protection doesn’t cover an initial IKEv2 SA, which might be unacceptable in some scenarios. In practice, the IKE_AUTH messages, including the peer identities, are protected only by classical keys. User traffic in the Child SAs is protected by the PPK. For OT networks where device names and site identities are themselves sensitive, this is worth weighing.

What is the difference between RFC 8784 PPK and RFC 9370 multiple key exchanges?

RFC 8784 adds a pre-distributed symmetric secret. RFC 9370 adds one or more extra public-key exchanges, typically a post-quantum KEM such as ML-KEM, performed during the handshake. The first moves the problem to key logistics. The second moves it to algorithm trust and larger handshake messages.

RFC 9370 utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. Published in May 2023, it updates RFC 7296. The IETF working group treated the two as stages of one roadmap. One draft of RFC 9370 described the PPK route this way: “A short term solution to make IKEv2 key exchange quantum secure is to use post-quantum pre-shared keys”.

A separate IETF draft describes how ML-KEM can be used as the quantum-resistant KEM in IKEv2 by using one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange after an initial key exchange. NIST published ML-KEM as FIPS 203. It is one of the three PQC standards (as Federal Information Processing Standards, or FIPS) that NIST released in August 2024.

How should post-quantum preshared keys be generated, distributed and rotated across many sites?

Generate each PPK from an approved random bit generator, give every pair of peers its own key, move keys out of band, and use the PPK_ID field to roll new keys in before old ones are retired. Done this way, the PPK route stays manageable beyond a handful of sites.

Generation

Generate PPKs on a hardened system with a deterministic random bit generator that follows NIST SP 800-90A, and request at least 32 bytes of output. Do not derive PPKs from passphrases, site codes or asset tags. Keep the PPK separate from any preshared key used for IKEv2 authentication: if one leaks, the other should not leak with it.

Distribution in OT and air-gapped networks

A PPK cannot be sent over the tunnel it is meant to protect. NIST’s IPsec guidance makes the general point that out-of-band means a separate mechanism, because the VPN cannot be used to exchange the keys securely because the keys are required to provide the necessary protection. For substations, pumping stations and other remote OT sites, this usually means encrypted removable media carried by authorised staff, dual control during loading, and a logged chain of custody. In air-gapped segments, physical transfer is the only option anyway, so PPKs fit existing procedures well.

Some deployments use externally supplied key material. A patent filing describes how PPKs can either be configured manually, referred to as manual PPK, or may be dynamically generated using a secure key integration protocol that imports key material from synchronized external key sources. That approach adds extra infrastructure, and the source of the key material needs its own trust assessment.

Rotation without downtime

RFC 8784 treats PPKs as long-lived. The qr-alt draft notes that the RFC assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch. A practical rotation sequence:

1. Load the new PPK under a new PPK_ID on the responder, alongside the current one.
2. Load it on the initiator and switch its selected PPK_ID.
3. Re-establish the IKE SA in a maintenance window, so that a brief renegotiation does not disrupt control traffic.
4. Confirm the new PPK_ID is in use, then delete the old key from both peers and record its destruction.

Scaling by topology

Pairwise keys grow with the number of links. A full mesh of n sites needs n(n-1)/2 PPKs (45 for ten sites), while hub-and-spoke needs one per spoke. Many critical infrastructure operators already route OT traffic through control-centre hubs, and that limits the key count. Cloud gateways and remote-user clients add peers that are harder to reach physically, which is one reason a KEM-based exchange often suits those connections better.

When should you combine a PPK with ML-KEM hybrid key exchange?

Combine them when a link carries data that must stay confidential for longer than you can confidently predict the security of any single algorithm, and when you can manage pairwise secrets for that link. For other connections, an RFC 9370 hybrid with ML-KEM is usually enough by itself.

NIST IR 8547 gives a way to decide which links need the most care: if “X” represents the number of years that data must be kept secure, and “Y” is the estimated time needed to complete the transition, then organizations must start transitioning to post-quantum algorithms before X + Y exceeds the expected time Z. Engineering drawings, grid topology and safety-system configurations often have a large X.

Situations where a layered setup (classical DH, ML-KEM and a PPK) is worth the extra effort:

• Hedging algorithm risk: if a weakness is found in ML-KEM, the PPK still protects the traffic keys. If the PPK leaks, ML-KEM still does.
• Closing the initial IKE SA gap: the ML-KEM exchange protects the IKE_AUTH messages, which a PPK alone leaves classical.
• Fixed, high-value links: point-to-point connections between control centres and backup sites rarely change peers, so the cost of distributing keys stays bounded.

For cloud networks and remote users, peers change more often and physical key delivery is impractical, so a hybrid KEM exchange is the more realistic default. Gateway products follow the same hybrid logic outside IKEv2. Quantum Network’s QPN gateway, for example, combines a classical part and an ML-KEM part into one session key and renews both handshakes every two minutes.

National agencies also support hybrid approaches. According to a European Commission Joint Research Centre review, the Dutch NCSC also advocate for the usage of hybrid solutions, while the UK NCSC underline that hybrid systems can be envisaged as a temporary solution only. Whatever you deploy should therefore let you change the algorithm later.

How urgent is post-quantum protection for site, cloud and remote-user tunnels?

Urgent enough to start now. Confidentiality protection for recorded traffic has to be in place before a quantum computer exists, and large migrations take years.

• Transition dates: NIST IR 8547 proposes that quantum-vulnerable algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035. (NIST, initial public draft, 12 November 2024)
• Standards available: NIST released three PQC FIPS standards, including FIPS 203, in August 2024 (NIST NCCoE, 2024).
• Migration duration: It took more than five years to migrate from SHA-1 to SHA-256 even though the specifications and implementations were already available. (NCSC-NL, 2023)

NIST’s own guidance is direct: “Organizations should begin applying these standards now to migrate their systems to quantum-resistant cryptography.” For IPsec estates, a practical order is: list every tunnel and the data it carries, enable mandatory PPKs on the longest-lived OT links, and move to RFC 9370 hybrid exchanges as soon as both ends support them.