Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security
Extracted elements (26)
By performing PPK exchange in a separate IKE_INTERMEDIATE round trip before IKE_AUTH, the initiator can propose multiple PPK IDs and the responder can pick one. This is not possible when PPK is exchanged within IKE_AUTH (RFC 8784), and simplifies PPK rollover scenarios.
RFC 8784 protects IPsec traffic but not the initial IKE SA, leaving peer identities and sensitive IKE-level data exposed to a future CRQC. This specification fills that gap by mixing a PPK in the IKE_INTERMEDIATE exchange before IKE_AUTH, so the initial IKE SA is fully quantum-secure from the start.
RFC 8784 treats PPKs as static and provides no mechanism to use a fresh PPK on an active IKE SA; the only recourse is tearing down and recreating the SA. This specification adds PPK support to the CREATE_CHILD_SA exchange so fresh PPKs from sources like QKD can be consumed without that overhead.
The main disadvantage of this approach versus RFC 8784 is the mandatory additional round trip of the IKE_INTERMEDIATE exchange. However, if IKE_INTERMEDIATE is already required for another purpose (e.g., RFC 9370 additional key exchanges), PPK payloads can be piggybacked at no extra cost.
If the responder agrees to a PPK during IKE_INTERMEDIATE but later, during IKE_AUTH, finds that the selected PPK is not associated with the initiator's identity per local policy, it SHOULD abort with AUTHENTICATION_FAILED but MAY continue if local policy permits the mismatch.
Negotiation of USE_PPK_INT is independent from negotiation of USE_PPK (RFC 8784). An initiator supporting both MAY include both notifications; a responder supporting both MUST choose exactly one to return. The two mechanisms cannot be used simultaneously for the same SA.
PPK use in CREATE_CHILD_SA applies regardless of how the current IKE SA was established — whether via IKE_AUTH (RFC 8784), IKE_INTERMEDIATE (this spec), CREATE_CHILD_SA (this spec), or without any PPK. The fresh PPK does not require a specific prior SA history.
If a series of IKE_INTERMEDIATE exchanges takes place, the PPK_IDENTITY_KEY notification(s) MUST be sent in the last one — the IKE_INTERMEDIATE exchange immediately preceding IKE_AUTH.
If no matching PPK can be negotiated and the initiator requires quantum-computer resistance, the initiator MUST abort creating the IKE SA; otherwise it MAY continue with standard IKEv2.
If the initiator did not include USE_PPK_INT in its IKE_SA_INIT request and the responder's policy mandates protecting the initial IKE SA with a PPK, the responder MUST return the NO_PROPOSAL_CHOSEN notification.
If the responder cannot match any proposed PPK (or finds mismatched PPK values) and PPK use is mandatory, the responder MUST return an AUTHENTICATION_FAILED notification and abort IKE SA creation.
If the responder returns a PPK identity in PPK_IDENTITY that was not proposed by the initiator, the initiator MUST treat this as a fatal error and abort IKE SA establishment.
If the responder supports both RFC 8784 (USE_PPK) and this specification (USE_PPK_INT) and is configured to use PPKs, it MUST return either a USE_PPK_INT or a USE_PPK notification in the IKE_SA_INIT response, but not both.
If using PPKs in CREATE_CHILD_SA is mandatory for the responder and the initiator includes no PPK_IDENTITY_KEY notifications, or if no matching/valid PPK is found, the responder MUST return the NO_PROPOSAL_CHOSEN notification.
Implementations MUST ignore any data in the USE_PPK_INT notification that they do not understand, to allow future extensions to add notification data without breaking existing implementations.
When multiple operations recalculate IKE SA keys within the same IKE_INTERMEDIATE exchange (e.g., RFC 9370 additional key exchanges), applying the PPK MUST be done last so that PPK-based key recalculation is the final step before keys are used in the next exchange.
For CREATE_CHILD_SA, the PPK is mixed with the current SK_d to produce SK_d' = prf+(PPK, SK_d). This SK_d' replaces SK_d in all child SA key derivation formulas (RFC 7296 Sections 2.17/2.18 and RFC 9370 Section 2.2.4). The IKE SA's own SK_d is not modified.
IKE SA key derivation with PPK computes SKEYSEED' = prf+(PPK, SK_d), then derives all SK_* keys via prf+(SKEYSEED', Ni | Nr | SPIi | SPIr). Unlike RFC 8784, SK_d, SK_pi, and SK_pr are not individually recalculated with PPK.
PPK use in CREATE_CHILD_SA is negotiated by including one or more PPK_IDENTITY_KEY notifications in the CREATE_CHILD_SA request; the PPK Confirmation in this context uses prf(PPK, Ni | SPIi | SPIr) where Ni is the nonce from the CREATE_CHILD_SA request and SPIi/SPIr are the current IKE SA SPIs.
The USE_PPK_INT notification (Notify Message Type 16445) is a Status Type IKEv2 notification with Protocol ID 0 and SPI Size 0. It is included in IKE_SA_INIT by both initiator and responder to negotiate PPK use in the IKE_INTERMEDIATE exchange. Notification Data is empty; implementations MUST ignore unrecognized data.
IANA has added two entries to the 'IKEv2 Notify Message Status Types' registry: 16445 for USE_PPK_INT and 16446 for PPK_IDENTITY_KEY.
Symmetric key cryptographic primitives used for PPK-derived keys are believed to be unaffected by a CRQC, per the analysis in RFC 9370 Section 4. The PPK mechanism's security therefore does not depend on the classical DH or signature algorithms also used in IKEv2.
The specification relies on the IKE_INTERMEDIATE exchange; implementors should refer to RFC 9242 for discussion of security issues specific to that exchange, including key confirmation and integrity protection of intermediate messages.
Unlike RFC 8784, this specification protects the IKE_AUTH exchange itself — ID payloads and other sensitive content are encrypted under keys already mixed with the PPK, providing quantum resistance even against an active attacker. This also protects the initial IKE SA from the moment it is created.
Table 1 defines the responder's decision logic across five states keyed on: whether USE_PPK_INT was received, whether the responder supports the extension, whether a matching PPK is available, and whether PPK is mandatory. Outcomes are: proceed with this extension, fall back to RFC 8784 or plain IKEv2, send NO_PROPOSAL_CHOSEN, or abort with AUTHENTICATION_FAILED.
The PPK_IDENTITY_KEY notification (Notify Message Type 16446) carries a variable-length PPK_ID field followed by an 8-octet PPK Confirmation field. The PPK Confirmation is the first 8 octets of prf(PPK, Ni | Nr | SPIi | SPIr) for IKE_INTERMEDIATE, or prf(PPK, Ni | SPIi | SPIr) for CREATE_CHILD_SA.