State of PQC

Protocol · IKEv2 / IPsec

IPsec

IPsec protects site-to-site and remote-access VPNs, mobile backhaul, inter-datacentre links and much government and telecom traffic. ESP carries the packets; the Internet Key Exchange, IKEv2, agrees the keys and authenticates the peers. This page explains how IKEv2 derives keys, which documents carry the post-quantum changes, why the ordinary IKEv2 pre-shared key does not protect traffic from a quantum attacker and a post-quantum pre-shared key does, how a connection can be pushed back to weaker algorithms, and what to check in an implementation. Each claim names the document and section it comes from. The companion page covers TLS 1.3.

The protocol and its standards

IKEv2 is defined by RFC 7296. The post-quantum work adds to it through three published extensions, one each for additional key exchanges, a pre-shared key mixed into the keys, and an intermediate exchange that carries large payloads, and through two drafts that register ML-KEM and the post-quantum signatures.

An IPsec connection has two layers. IKEv2 runs over UDP port 500 or 4500, or over TCP, and establishes an IKE SA: a protected control channel between the two peers. Over that channel it negotiates one or more Child SAs, each a pair of ESP (or AH) security associations with their own keys, and it rekeys both kinds of SA for as long as the connection lives. The post-quantum migration changes the key exchanges inside IKEv2 and the way the peers authenticate; ESP's symmetric algorithms, AES-GCM and the rest, are not affected beyond the advice to use 256-bit keys (RFC 9370 §4, RFC 8784 §6).

Three things are negotiated in IKEv2's first exchange, IKE_SA_INIT: the cryptographic suite, as transforms of several types in the SA payload; a key exchange, as a KE payload carrying a public value for one of the proposed key exchange methods; and a set of notifications that announce extensions. RFC 9370 renamed Transform Type 4 from "Diffie-Hellman Group" to "Key Exchange Method" so that a KEM fits where a group used to, and added Transform Types 6 to 12 for up to seven additional key exchanges performed after IKE_SA_INIT.

DocumentWhat it doesStatus
RFC 7296IKEv2. The exchanges (§1.2, §1.3), key derivation (§2.14), authentication including the pre-shared key method (§2.15), and Child SA and IKE SA rekeying (§2.17, §2.18).Internet Standard (STD 79).
RFC 9370Multiple key exchanges: up to seven additional key exchanges in IKE_INTERMEDIATE and CREATE_CHILD_SA, each mixed into the keys, so a post-quantum KEM can be added beside (EC)DH.Standards Track. Updates RFC 7296.
RFC 9242The IKE_INTERMEDIATE exchange: encrypted messages between IKE_SA_INIT and IKE_AUTH that can be fragmented, for payloads too large for IKE_SA_INIT.Standards Track.
RFC 8784Post-quantum pre-shared keys (PPK): a key mixed into SK_d, SK_pi and SK_pr during IKE_AUTH, so Child SA keys and rekeyed IKE SAs do not depend on the (EC)DH secret.Standards Track.
RFC 9867PPK in IKE_INTERMEDIATE and CREATE_CHILD_SA: the PPK is mixed into all IKE SA keys before IKE_AUTH, and a fresh PPK can be applied at each rekey. Written with QKD-refreshed keys in mind.Standards Track.
draft-ietf-ipsecme-ikev2-mlkemML-KEM-512, 768 and 1024 as Key Exchange Methods 35, 36 and 37, for use as additional key exchanges or, with limits, in IKE_SA_INIT.RFC Editor queue.
draft-ietf-ipsecme-ikev2-pqc-authML-DSA and SLH-DSA as IKE_AUTH signature algorithms, through the Digital Signature authentication method of RFC 7427.RFC Editor queue.
RFC 7427The Digital Signature authentication method: the AUTH payload carries an ASN.1 AlgorithmIdentifier, so new signature algorithms need no new method number.Standards Track.
RFC 7383IKEv2 fragmentation. Only encrypted messages can be fragmented; IKE_SA_INIT cannot, which is why large key exchanges go in IKE_INTERMEDIATE.Standards Track.
RFC 9329IKEv2 and ESP over TCP, which removes the datagram size limit at the cost of running ESP over TCP as well.Standards Track. Obsoletes RFC 8229.
draft-ietf-ipsecme-ikev2-reliable-transportIKEv2 over TCP with ESP still over UDP, so large post-quantum payloads travel reliably without moving the data plane.Working group draft.
draft-ietf-ipsecme-big-payloadPayloads larger than the 64 kB that IKEv2's two-byte length field allows, for the largest post-quantum keys and signatures.Working group draft.

Every IKEv2 and IPsec record in the catalog, with its stage, is on the roadmap. The CNSA 2.0 IPsec profile is on the guidance page.

The exchanges

IKE_SA_INIT agrees the suite and a first key exchange in the clear. IKE_INTERMEDIATE, when used, carries the additional key exchanges and the post-quantum pre-shared key under encryption. IKE_AUTH proves identities and creates the first Child SA. Step through the exchanges to see where ML-KEM, a PPK and a post-quantum signature enter. Use the buttons, the arrow keys, or play.

The IKEv2 exchanges with an ML-KEM additional key exchange, a post-quantum pre-shared key and a post-quantum signature Initiator Responder IKE_SA_INIT request SAi1: ENCR, PRF, INTEG, KE = X25519, ADDKE1 = ML-KEM-768 · KEi (X25519 public value), Ni N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(USE_PPK_INT)*, N(USE_PPK)* N(INVALID_KE_PAYLOAD) or N(COOKIE) the responder wants a different first key exchange, or a cookie; the initiator repeats IKE_SA_INIT with its full set of proposals IKE_SA_INIT response SAr1: the chosen transforms · KEr, Nr, [CERTREQ] · N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(USE_PPK_INT) or N(USE_PPK) SKEYSEED = prf(Ni | Nr, g^ir) and SK_* derived; later messages use SK_e, but a quantum attacker recovers g^ir IKE_INTERMEDIATE: SK{KEi(2) = ML-KEM-768 encapsulation key, 1184 B} → SK{KEr(2) = ML-KEM ciphertext, 1088 B} SKEYSEED(1) = prf(SK_d(0), SK(1) | Ni | Nr), all SK_* recomputed; the message is encrypted and may be fragmented IKE_INTERMEDIATE: SK{N(PPK_IDENTITY_KEY, PPK_ID, …)} → SK{N(PPK_IDENTITY_KEY, PPK_ID)} RFC 9867: SKEYSEED' = prf+(PPK, SK_d), all SK_* recomputed; the last change to the keys before IKE_AUTH IKE_AUTH request: SK{IDi, [CERT], [CERTREQ], [IDr], AUTH, SAi2, TSi, TSr, N(PPK_IDENTITY)*, N(NO_PPK_AUTH)*} AUTH = a MAC with the pre-shared key, or a Digital Signature (RFC 7427): ML-DSA-65 about 3.3 kB, ECDSA, RSA SK_pi is in the signed octets, so the AUTH payload binds every key derived so far IKE_AUTH response: SK{IDr, [CERT], AUTH, SAr2, TSi, TSr, N(PPK_IDENTITY)*} IKE SA authenticated; first Child SA: KEYMAT = prf+(SK_d, Ni | Nr); ESP traffic flows CREATE_CHILD_SA: SK{SA, Ni, [KEi], TSi, TSr, N(PPK_IDENTITY)*} → a new Child SA or a rekey further ADDKEs in IKE_FOLLOWUP_KE (RFC 9370 §2.2.4); with a fresh PPK, SK_d' = prf+(PPK, SK_d) (RFC 9867 §3.2.1)
  1. IKE_SA_INIT request. The initiator proposes its cryptographic suites as transforms in the SA payload, sends a public value for one key exchange method in KEi, and a nonce (RFC 7296 §1.2). A post-quantum proposal adds Additional Key Exchange transforms, types 6 to 12, naming ML-KEM (RFC 9370 §2.2.1; identifiers 35 to 37 from draft-ietf-ipsecme-ikev2-mlkem §2.1). Notifications announce the extensions: INTERMEDIATE_EXCHANGE_SUPPORTED for RFC 9242, USE_PPK for a PPK in IKE_AUTH (RFC 8784 §3), USE_PPK_INT for a PPK in IKE_INTERMEDIATE (RFC 9867 §3.1). An initiator may send both PPK notifications; the responder returns one.
  2. Retry. If the responder prefers a key exchange method the initiator did not send a share for, it answers INVALID_KE_PAYLOAD naming the method, and the initiator sends IKE_SA_INIT again with that share and its full set of proposals, so that a stripped proposal list is not a downgrade (RFC 7296 §1.2, §2.6.1). A responder under load answers with a COOKIE first. Both cost a round trip.
  3. IKE_SA_INIT response. The responder picks one proposal, returns its own key exchange value and nonce, and echoes the extensions it accepts. Both sides now compute SKEYSEED from the nonces and the (EC)DH secret and derive the seven SK_* keys (RFC 7296 §2.14). Everything after this point is encrypted with SK_ei and SK_er, which is what lets the next messages be fragmented. These keys depend only on the (EC)DH secret, which a quantum attacker recovers from the recording.
  4. IKE_INTERMEDIATE with an additional key exchange. One IKE_INTERMEDIATE exchange per additional key exchange. The initiator sends the ML-KEM-768 encapsulation key, 1184 bytes, and the responder returns the 1088-byte ciphertext (draft-ietf-ipsecme-ikev2-mlkem §2.1). The shared secret SK(1) is mixed into SKEYSEED(1) with the previous SK_d and the nonces, and all SK_* are recomputed, so the IKE SA keys now depend on ML-KEM as well as (EC)DH (RFC 9370 §2.2.2). The payload is encrypted and can be fragmented under RFC 7383.
  5. IKE_INTERMEDIATE with a PPK. If the responder returned USE_PPK_INT, the initiator sends the identities of PPKs it holds in PPK_IDENTITY_KEY notifications and the responder picks one it also holds (RFC 9867 §3.1). The PPK is mixed in as SKEYSEED' = prf+(PPK, SK_d), all SK_* are recomputed, and this is the last change to the keys before IKE_AUTH (§3.1.1). The PPK itself never crosses the wire. RFC 9867 names QKD as a source of frequently refreshed PPKs (§1).
  6. IKE_AUTH request. The initiator sends its identity, optionally a certificate, the AUTH payload, and the proposal and traffic selectors for the first Child SA (RFC 7296 §1.2). AUTH is either a MAC computed with the pre-shared key, or a signature over the initiator's first message, the responder's nonce and a MAC of IDi keyed with SK_pi (§2.15). Post-quantum signatures use the Digital Signature method of RFC 7427 with an ML-DSA or SLH-DSA AlgorithmIdentifier (draft-ietf-ipsecme-ikev2-pqc-auth §3.1, §4, §5). With RFC 8784 instead of RFC 9867, the PPK_IDENTITY notification goes here and the PPK is applied after this message is built.
  7. IKE_AUTH response and the first Child SA. The responder authenticates in the same way. Both sides derive the Child SA's keys from SK_d and the nonces: KEYMAT = prf+(SK_d, Ni | Nr), split into ESP keys for each direction (RFC 7296 §2.17). ESP traffic can now flow. When an RFC 8784 PPK was negotiated, SK_d has been replaced by prf+(PPK, SK_d') first (RFC 8784 §3).
  8. CREATE_CHILD_SA. New Child SAs and rekeys of either SA run over the IKE SA. A rekey may include a fresh key exchange, and with RFC 9370 further additional key exchanges in IKE_FOLLOWUP_KE exchanges, each mixed into KEYMAT (RFC 9370 §2.2.4). With RFC 9867 a PPK_IDENTITY notification selects a PPK, possibly a newer one, and SK_d' = prf+(PPK, SK_d) replaces SK_d in every formula for the new SA (RFC 9867 §3.2.1). This is the hook for a key stream that changes between rekeys.

Key establishment

IKEv2 keys come from one or more key exchanges and, optionally, a pre-shared key mixed in afterwards. The post-quantum options are ML-KEM as an additional key exchange, ML-KEM as the only key exchange, and a PPK.

ML-KEM as an additional key exchange, RFC 9370

The usual deployment keeps (EC)DH in IKE_SA_INIT and runs ML-KEM in an IKE_INTERMEDIATE exchange. The two secrets are not concatenated; each is folded into the running SKEYSEED in turn, so the final keys depend on all of them and are secure if any one of them is (RFC 9370 §1.2, §4). Up to seven additional exchanges can be chained, which the RFC describes as a hedge against a new algorithm being broken. The CNSA 2.0 IPsec profile requires exactly one, ML-KEM-1024, with P-384 in IKE_SA_INIT. A proposal is matched transform by transform, and a responder that does not support RFC 9370 ignores the additional transform types and accepts a classical-only proposal; both sides have to want the extension.

MethodTransform IDInitiator KE (encapsulation key)Responder KE (ciphertext)Shared secret
ML-KEM-51235800 B, payload 808 B768 B, payload 776 B32 B
ML-KEM-768361184 B, payload 1192 B1088 B, payload 1096 B32 B
ML-KEM-1024371568 B, payload 1576 B1568 B, payload 1576 B32 B

ML-KEM in IKE_SA_INIT

ML-KEM may also be the first key exchange, in IKE_SA_INIT, as the only one. The draft allows ML-KEM-512 there without reservation and says implementations over UDP without path MTU discovery SHOULD NOT use ML-KEM-768 or 1024 in IKE_SA_INIT on networks where the MTU is unknown, because IKE_SA_INIT cannot be fragmented by IKEv2 (draft-ietf-ipsecme-ikev2-mlkem §2.1, RFC 7383). Over TCP (RFC 9329 or draft-ietf-ipsecme-ikev2-reliable-transport) any parameter set may be used. A keypair and ciphertext MUST be fresh for each exchange, and the ML-KEM and (EC)DH keys MUST NOT come from the same seed (§3).

Post-quantum pre-shared keys, RFC 8784 and RFC 9867

A PPK is a symmetric key both peers already hold, identified by a PPK_ID. The RFCs ask for at least 256 bits of entropy, so that Grover's algorithm leaves 128, and warn that a PPK derived from a password is not secure (RFC 8784 §6). How the PPK gets to both ends is "a local matter"; the RFC points to the RFC 6030 key container format and RFC 9867 names QKD as one source (RFC 8784 §5.2.1, RFC 9867 §1). A group PPK shared by more than two peers is NOT RECOMMENDED, because any member can impersonate any other (RFC 8784 §5.2.2). Where the PPK enters the keys differs between the two RFCs, and the key schedule below shows why it matters.

Authentication

Each peer proves its identity once, in IKE_AUTH, with an AUTH payload. The method is per peer and per direction, which is both IKEv2's flexibility and its downgrade weakness.

Signatures

RFC 7296 defines RSA and DSS signature methods with fixed numbers. RFC 7427 added the Digital Signature method, in which the AUTH payload starts with a DER-encoded AlgorithmIdentifier, so a new algorithm needs only an OID. draft-ietf-ipsecme-ikev2-pqc-auth uses this to bring in ML-DSA-44, 65 and 87 and the twelve SLH-DSA parameter sets, with the identifiers listed in its Appendix B (§3.1, §4, §5). The signature covers the peer's own IKE_SA_INIT message, the other side's nonce and a MAC of the identity keyed with SK_p (RFC 7296 §2.15), so the signed data includes the proposals and the key exchange. Peers can learn each other's algorithms from the Certificate Request payload or from the SUPPORTED_AUTH_METHODS notification of RFC 9593 (§3.3). An ML-DSA-65 signature is about 3.3 kB and a certificate chain several times that; IKE_AUTH is encrypted and can be fragmented, and draft-ietf-ipsecme-big-payload exists for the cases where a single payload passes 64 kB.

The pre-shared key method

With a shared secret, AUTH is a MAC: prf(prf(Shared Secret, "Key Pad for IKEv2"), SignedOctets) (RFC 7296 §2.15). The secret proves the peer's identity and nothing else. It does not enter SKEYSEED or any SK_* key, and RFC 8784 §2 says so in as many words: the PPK is independent of the authentication PSK "because the preshared key in IKEv2 is not used for any key derivation and thus doesn't protect against quantum computers". A quantum attacker reading a recorded session is not trying to authenticate, so a PSK of any length does not help confidentiality. This is the opposite of TLS 1.3, where the PSK is the first input to the key schedule.

The PSK method is quantum-safe as authentication, provided the key has enough entropy, and RFC 9370 §4 notes that the PSK option "provided the key is long enough, is post-quantum secure" while signatures are not. RFC 8784 §5.2.3 goes further and allows authentication by PPK alone, with the NULL authentication method of RFC 7619 for AUTH and the PPK made mandatory. Combining that with a group PPK is NOT RECOMMENDED.

Key derivation, and where a pre-shared key enters

RFC 7296 §2.14 derives every IKE SA key from SKEYSEED, which depends on the nonces and the (EC)DH secret alone. The extensions each splice a new input into this chain at a different point. Step through the derivation, then through what a quantum attacker can and cannot recover under each option.

IKEv2 key derivation showing the (EC)DH secret, an ML-KEM additional key exchange, the two PPK methods, the authentication pre-shared key and the Child SA keys g^ir: the (EC)DH shared secret X25519 or P-256 from IKE_SA_INIT, plus Ni | Nr SKEYSEED = prf(Ni|Nr, g^ir) quantum attacker recovers g^ir prf+(SKEYSEED, Ni|Nr|SPIi|SPIr) SK_d → Child SA keys and rekeys SK_ai, SK_ar → IKE message integrity SK_ei, SK_er → IKE message encryption SK_pi, SK_pr → the AUTH payload SK(1): ML-KEM-768 shared secret, 32 B additional key exchange in IKE_INTERMEDIATE SKEYSEED(1)=prf(SK_d, SK(1)|Ni|Nr) all SK_* recomputed (RFC 9370 §2.2.2) PPK in IKE_INTERMEDIATE (RFC 9867) provisioned or QKD-delivered, ≥ 256 bits SKEYSEED' = prf+(PPK, SK_d) all SK_* recomputed, before IKE_AUTH PPK in IKE_AUTH (RFC 8784) applied after the IKE_AUTH request is built SK_d = prf+(PPK, SK_d') SK_pi, SK_pr likewise SK_ei, SK_er, SK_ai, SK_ar unchanged IKEv2 pre-shared key (RFC 7296 §2.15) the shared secret used for authentication prf(PSK, "Key Pad for IKEv2") = KAUTH = prf(K, SignedOctets) proves identity only (RFC 7296 §2.15) not an input to SKEYSEED or any SK_* × no path KEYMAT = prf+(SK_d, Ni|Nr) ESP keys for each Child SA (§2.17) IKE SA rekey: prf(SK_d, g^ir(new)|Ni|Nr) RFC 9867: SK_d' = prf+(PPK, SK_d) first every later key hangs off SK_d; a rekey prepends SK(new) (EC)DH only, PSK authentication: g^ir is recovered, then SKEYSEED, every SK_*, every Child SA key and every rekey. The PSK never entered a key, so it changes nothing. An ML-KEM additional key exchange makes SKEYSEED(1) unknown and stops this. PPK in IKE_AUTH (RFC 8784): SK_d, SK_pi and SK_pr depend on the PPK, so every Child SA key and every rekey is safe (§6). SK_e and SK_a are not: the initial IKE SA is readable, with identities, configuration and traffic selectors, but no ESP key. PPK in IKE_INTERMEDIATE (RFC 9867): all SK_* depend on the PPK before IKE_AUTH, so the initial IKE SA is safe too (§4). A PPK with 256 bits of entropy is sufficient on its own. An ML-KEM additional key exchange gives the same result without one.
  1. SKEYSEED = prf(Ni | Nr, g^ir). The root of every IKEv2 key is a pseudorandom function keyed by the two nonces and applied to the (EC)DH shared secret from IKE_SA_INIT (RFC 7296 §2.14). Nothing else goes in. The nonces are sent in the clear, so SKEYSEED is exactly as secret as g^ir.
  2. Seven keys from one prf+. SKEYSEED is expanded with the nonces and SPIs into SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi and SK_pr, in that order (§2.14). SK_e and SK_a encrypt and authenticate IKE messages, SK_p keys the identity MAC inside the AUTH computation, and SK_d seeds every Child SA and every rekey. Which of these an extension replaces decides what it protects.
  3. An additional key exchange, RFC 9370. Each IKE_INTERMEDIATE key exchange produces a secret SK(n). SKEYSEED(n) is prf(SK_d(n-1), SK(n) | Ni | Nr), and all seven keys are recomputed from it (§2.2.2). An ML-KEM secret here makes the IKE SA keys depend on ML-KEM; the RFC's security section says the final keys are secure if any one of the exchanges is (§4). Authentication is untouched.
  4. A PPK in IKE_INTERMEDIATE, RFC 9867. After the key exchanges, SKEYSEED' = prf+(PPK, SK_d), and all seven keys are recomputed once more. The RFC requires this to be the last change before IKE_AUTH, after any RFC 9370 recomputation (§3.1.1). From here on every IKE message, including the identities and certificates in IKE_AUTH, is encrypted under keys that depend on the PPK.
  5. A PPK in IKE_AUTH, RFC 8784. The original method applies the PPK later and to less. After the IKE_AUTH request is formed, SK_d, SK_pi and SK_pr are replaced by prf+(PPK, ·) of their old values; SK_e and SK_a are left as they were (§3). The RFC calls this a compromise that lets the responder find the right PPK quickly, and it limits what the PPK protects (§6).
  6. The authentication pre-shared key has no path into the keys. With the shared-key method, AUTH is prf(prf(Shared Secret, "Key Pad for IKEv2"), SignedOctets) (RFC 7296 §2.15). The secret appears only there. It is not an input to SKEYSEED, to any SK_* or to KEYMAT. RFC 8784 §2 states the consequence: it "is not used for any key derivation and thus doesn't protect against quantum computers". An IKEv2 PSK and a PPK can be the same bytes only by accident; the protocol treats them as different things.
  7. Child SA keys and rekeys hang off SK_d. KEYMAT = prf+(SK_d, Ni | Nr) for a Child SA created in IKE_AUTH, with the new key exchange secrets prepended in CREATE_CHILD_SA (RFC 7296 §2.17, RFC 9370 §2.2.4). A rekeyed IKE SA takes SKEYSEED = prf(SK_d(old), g^ir(new) | Ni | Nr) (§2.18). With RFC 9867, SK_d' = prf+(PPK, SK_d) replaces SK_d in every one of these formulas, and the PPK may be a different one each time (§3.2.1). ESP keys inherit whatever SK_d had.
  8. A quantum attacker recovers g^ir. Assume a recording and a computer that solves the discrete logarithm. With (EC)DH alone, SKEYSEED is computable, then all seven keys, every Child SA key and every rekey, however the peers authenticated. A pre-shared key used only for authentication changes nothing, because it never entered a key. With ML-KEM as an additional key exchange, SK(1) stays unknown and the chain stops at SKEYSEED(1).
  9. A PPK in IKE_AUTH is sufficient for traffic, not for the control channel. With RFC 8784, SK_d depends on a 256-bit PPK, so every Child SA key and every rekeyed IKE SA is beyond a quantum attacker (§6). The initial IKE SA's SK_e does not depend on it, so the attacker reads what crossed the initial IKE SA: identities, configuration, traffic selectors, and anything else sent before a rekey. The RFC says to rekey before sending sensitive data and suggests a childless initial IKE SA (RFC 6023) so that no Child SA parameters are exposed.
  10. A PPK in IKE_INTERMEDIATE is sufficient. With RFC 9867 all seven keys depend on the PPK before IKE_AUTH, so the initial IKE SA, the Child SAs and the rekeys are all beyond the attacker (§4). A QKD-delivered key used as the PPK gives the same result, and a new PPK can be applied at each CREATE_CHILD_SA. ML-KEM in an additional key exchange protects the same keys without a pre-shared key, and the two combine.
What a pre-shared key buys in IKEv2. Only a PPK, a key mixed into the derivation under RFC 8784 or RFC 9867, protects traffic from a quantum attacker. A PPK of 256 bits of entropy under RFC 9867 makes every key of the connection, including the initial IKE SA's, depend on a value the attacker cannot recover from the recording, whichever key exchange ran. Under RFC 8784 the same PPK protects every ESP key and every rekeyed IKE SA, but not the initial IKE SA. A QKD-delivered key used as the PPK gives the same result, and RFC 9867 lets each rekey take a fresh one. The CNSA 2.0 IPsec profile prefers RFC 9867 for this reason.
What it does not buy. The IKEv2 authentication pre-shared key of RFC 7296 §2.15 is not a PPK. It authenticates and enters no key, so a connection that uses it with classical (EC)DH is fully decryptable by a quantum attacker, however long the key. A PPK authenticates only as "a holder of this key" unless the peers also use certificates, and a group PPK lets any member impersonate any other (RFC 8784 §5.2.2). The PPK has to reach both ends by some other channel; the RFCs call that a local matter.

Downgrade

IKEv2 signs each peer's own IKE_SA_INIT message, not the other's, so it catches less tampering than TLS 1.3 does. Most of the protection against a downgrade is policy on both ends rather than a cryptographic check.

  • Authentication is one-directional. The AUTH payload covers the signer's own first message and the peer's nonce (RFC 7296 §2.15). Neither side signs the proposal the other side chose. draft-ietf-ipsecme-ikev2-mlkem §3 draws the consequence: if both peers support a classical-only sequence of key exchanges, an active attacker with a quantum computer can steer them to it, by breaking the (EC)DH in IKE_SA_INIT while the exchange is in flight and controlling the messages. The attack needs a quantum computer at the time of the connection, so it is not a harvest-now concern; draft-ietf-ipsecme-ikev2-downgrade-prevention is the long-term fix.
  • Policy, not negotiation. The draft's advice is to disable classical-only proposals wherever possible. A responder that knows its initiators support ML-KEM SHOULD reject any proposal without it, and an initiator that knows its responder supports ML-KEM SHOULD offer only proposals that include it, or abort if the responder chooses one without (§3). The CNSA 2.0 profile makes ML-KEM-1024 the single mandatory additional key exchange.
  • INVALID_KE_PAYLOAD. The responder can ask the initiator to restart with a different first key exchange method (RFC 7296 §1.2). An initiator MUST repeat its full proposal set when it does, so the retry carries the same ADDKE transforms. An initiator that answers a rejection by dropping ML-KEM from its proposals is a downgrade written into its own code.
  • Silent loss of RFC 9370. A responder without RFC 9370 does not understand Transform Types 6 to 12 and accepts the proposal without them. The initiator sees a valid IKE_SA_INIT response with no additional key exchange. Whether that is acceptable is policy; the protocol does not refuse it.
  • PPK is optional unless configured otherwise. If the responder does not return USE_PPK or USE_PPK_INT, the initiator continues without a PPK unless the PPK is marked mandatory for that peer, in which case it MUST abort (RFC 8784 §3, RFC 9867 §3.1). The same holds in IKE_AUTH: an initiator with an optional PPK sends NO_PPK_AUTH, an AUTH value computed without the PPK, so that a responder that does not have the PPK can still complete the handshake without it. The mandatory_or_not flag is the whole difference between a protected and an unprotected connection.
  • Post-quantum signatures are per policy. draft-ietf-ipsecme-ikev2-pqc-auth §8 and §9: when post-quantum authentication is mandatory, an implementation MUST NOT fall back to a traditional algorithm, and a deployment that must resist an active quantum attacker MUST require it. When it is optional, a quantum attacker who can forge a traditional signature can remove the SUPPORTED_AUTH_METHODS announcement and impersonate either side.
  • Rekeys. A Child SA rekey without a key exchange takes its keys from SK_d alone (RFC 7296 §2.17). That is safe if SK_d is, and not otherwise; a rekey does not add protection the IKE SA lacks, except through an RFC 9867 PPK or RFC 9370 additional exchange carried in CREATE_CHILD_SA.

What to test

IKE_SA_INIT is in the clear, so the proposals, the first key exchange method, the nonces and the notifications are visible in a packet capture. Everything after it needs the implementation's logs or key material. The transform IDs and notification types are the checkpoints.

  • Proposals. In the IKE_SA_INIT request, confirm the SA payload carries an Additional Key Exchange transform (type 6 to 12) with ML-KEM, ID 35 to 37, and the KE payload a classical method. Confirm the response selects it. A response with no ADDKE transform means the responder does not support RFC 9370 or chose not to; confirm the initiator's policy then aborts if post-quantum is required.
  • IKE_INTERMEDIATE. Confirm INTERMEDIATE_EXCHANGE_SUPPORTED in both IKE_SA_INIT messages and an IKE_INTERMEDIATE exchange per additional key exchange. The encapsulation key for ML-KEM-768 is 1184 bytes and the ciphertext 1088; the payloads are 8 bytes longer. Confirm fragmentation under RFC 7383 when the MTU is small.
  • Freshness. Capture two connections and confirm the ML-KEM encapsulation keys differ, and that the ML-KEM and (EC)DH keys are not derived from one seed (draft-ietf-ipsecme-ikev2-mlkem §3). Reuse is a forward-secrecy loss.
  • ML-KEM in IKE_SA_INIT. If used as the first method, confirm the parameter set and the path MTU behaviour. ML-KEM-768 or 1024 in IKE_SA_INIT over UDP with an unknown MTU is against the draft's advice (§2.1).
  • Which PPK method. Confirm the IKE_SA_INIT response carries USE_PPK_INT when RFC 9867 is expected, or USE_PPK for RFC 8784, and never both. Confirm PPK_IDENTITY_KEY in IKE_INTERMEDIATE or PPK_IDENTITY in IKE_AUTH. The PPK method determines whether the initial IKE SA is protected, so test which one was actually used, not which one was configured.
  • Mandatory PPK. Set the PPK mandatory and remove it from the responder. The initiator MUST abort, not continue. Set it optional and confirm NO_PPK_AUTH appears in IKE_AUTH; decide whether that is acceptable.
  • PPK entropy and distribution. Confirm the PPK is at least 256 bits from a random source, not a passphrase, and that it is not shared by more than two peers. With a QKD source, confirm the PPK_ID changes when the key does and that a CREATE_CHILD_SA rekey carries PPK_IDENTITY under RFC 9867.
  • Authentication method. Confirm the AUTH method in IKE_AUTH. The pre-shared key method is not a PPK: a configuration that has a PSK and no PPK gives no confidentiality against a quantum attacker. For signatures, confirm the Digital Signature method with an ML-DSA or SLH-DSA AlgorithmIdentifier and that the chain is post-quantum to the root if that is required.
  • Policy under rejection. Send INVALID_KE_PAYLOAD and confirm the retry still carries the ML-KEM ADDKE transform. Remove ML-KEM from the responder's proposals and confirm the initiator aborts if post-quantum key exchange is mandatory.
  • Signature fallback. Remove the post-quantum algorithm from the responder's SUPPORTED_AUTH_METHODS and confirm an initiator with mandatory post-quantum authentication refuses a traditional signature.
  • Symmetric algorithms. Confirm 256-bit keys for ENCR, PRF and INTEG in IKE and for ESP, and that PRF_AES128_XCBC is not used; RFC 8784 §6 lists what gives less than 128 bits of post-quantum security.
  • Transport. With IKE_AUTH carrying an ML-DSA chain, confirm fragmentation and reassembly over UDP, and the TCP fallback of RFC 9329 or draft-ietf-ipsecme-ikev2-reliable-transport where configured.

Sources

Section numbers in the text refer to these documents.

Published

  • RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2)STD 79
  • RFC 9370 Multiple Key Exchanges in IKEv2
  • RFC 9242 Intermediate Exchange in IKEv2
  • RFC 8784 Mixing Preshared Keys in IKEv2 for Post-quantum Security
  • RFC 9867 Mixing Preshared Keys in IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
  • RFC 7427 Signature Authentication in IKEv2
  • RFC 7383 IKEv2 Message Fragmentation
  • RFC 9329 TCP Encapsulation of IKE and IPsec Packetsobsoletes RFC 8229

In progress