Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
updates
- rfc-7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (30)
Additional key exchanges are carried in IKE_INTERMEDIATE exchanges (rather than IKE_SA_INIT) specifically to enable IKE fragmentation (RFC 7383) for large post-quantum KE payloads. IKE_SA_INIT has no inherent fragmentation support, while IKE_INTERMEDIATE messages are encrypted and can use the standard fragmentation protocol.
All key exchange algorithms—classical (EC)DH and post-quantum—are treated equivalently by the protocol and share a single Transform ID registry. This avoids categorizing algorithms as "post-quantum" or "classical" and ensures the extension remains usable if future algorithms with different properties emerge.
Negotiation via existing SA payload Transform Types (rather than new payload types or KE-payload-only approaches) was chosen to avoid backward-compatibility issues and to prevent downgrade attacks. A KE-payload-only approach was rejected because an on-path attacker could send INVALID_KE_PAYLOAD to force downgrade to a non-PQC fallback group.
The hybrid approach—requiring the final shared secret to depend on all component key exchanges—is chosen because no single post-quantum algorithm is yet trusted at the level of (EC)DH. The overall security is at least as strong as each individual primitive, hedging against the possibility that any one algorithm is broken.
Backward compatibility is preserved: if no ADDKE Transform Types appear in the SA payload, the proposal indicates standard IKEv2 per RFC 7296, and peers that do not support this extension will simply ignore the new transform types as unknown. The IKE SA resumption mechanism (RFC 5723) is compatible with IKE SAs created using this specification.
If the IKE_INTERMEDIATE exchange is not negotiated, peers MUST treat any ADDKE Transform Types in IKE_SA_INIT messages as unknown transform types and skip proposals containing them, falling back to NO_PROPOSAL_CHOSEN if no other proposals exist.
Additional key exchanges negotiated via ADDKE Transform Types MUST take place in a series of IKE_INTERMEDIATE exchanges in order of the Transform Type values, so that the key exchange negotiated using Additional Key Exchange i always precedes Additional Key Exchange i+1. Each MUST be fully completed before the next one is started.
For ADDKE Transform Types, the responder's chosen set MUST NOT contain duplicated algorithms (those with identical Transform ID and attributes), except for the Transform ID of NONE. If it cannot avoid duplicates, it MUST reject with NO_PROPOSAL_CHOSEN.
If a peer receives a CREATE_CHILD_SA request to rekey an SA that is already being rekeyed (i.e., IKE_FOLLOWUP_KE exchanges are in progress), a TEMPORARY_FAILURE notification MUST be sent in response.
If the initiator includes any ADDKE Transform Types in the SA payload in the IKE_SA_INIT exchange request, it MUST also negotiate the use of the IKE_INTERMEDIATE exchange by including an INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message.
If the initiator receives a response with one or more duplicated algorithm choices in the ADDKE Transform Types, it MUST treat the exchange as failed and MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges.
If the responder receives an IKE_FOLLOWUP_KE message for which it has no key exchange state, it MUST send the STATE_NOT_FOUND error notification. On receiving STATE_NOT_FOUND, the initiator MUST cancel the exchange and MUST treat the whole series from the CREATE_CHILD_SA as failed. After repeated STATE_NOT_FOUND notifications, the initiator MUST treat the situation as fatal and delete the IKE SA.
In simultaneous rekeying, if additional key exchanges are negotiated in the CREATE_CHILD_SA exchange in which the smallest nonce is used (the one to be abandoned per RFC 7296), the initiator MUST NOT initiate the IKE_FOLLOWUP_KE exchange.
The responder MUST handle the case where the initiator loses state and never sends remaining IKE_FOLLOWUP_KE exchanges by deleting the associated state after a reasonable timeout (typically 5–20 seconds).
The responder MUST include the ADDITIONAL_KEY_EXCHANGE notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message when a further IKE_FOLLOWUP_KE exchange is expected. The initiator MUST send this notification back intact in the next IKE_FOLLOWUP_KE request.
The responder MUST treat all omitted ADDKE Transform Types (not consecutive with those proposed by the initiator) as if they were proposed with Transform ID NONE.
IKE_FOLLOWUP_KE is a new IKEv2 exchange type (value 44) introduced to carry additional key exchange payloads following a CREATE_CHILD_SA exchange. It is used when rekeying an IKE SA or creating/rekeying Child SAs with multiple key exchanges.
Seven new Transform Types are defined for negotiating additional key exchanges: ADDKE1 (type 6) through ADDKE7 (type 12). They share the same Transform ID registry as Transform Type 4 and are used in the SA payload of IKE_SA_INIT or CREATE_CHILD_SA to negotiate key exchanges to be performed in subsequent IKE_INTERMEDIATE or IKE_FOLLOWUP_KE exchanges.
The ADDITIONAL_KEY_EXCHANGE notification (Status Type 16441, Protocol ID and SPI Size both 0) is used to link successive IKE_FOLLOWUP_KE exchanges to a corresponding CREATE_CHILD_SA exchange. The data is an opaque blob meaningful only to the responder.
The STATE_NOT_FOUND notification (Error Type 47, Protocol ID and SPI Size both 0, empty data) is sent by the responder when it receives an IKE_FOLLOWUP_KE message for which it has no key exchange state, typically due to a timeout deleting the associated state.
This document adds Exchange Type 44 (IKE_FOLLOWUP_KE) to the "IKEv2 Exchange Types" IANA registry.
This document adds Transform Types 6–12 (ADDKE1 through ADDKE7, each optional in IKE/AH/ESP) to the "Transform Type Values" IANA registry. All ADDKE types share the "Transform Type 4 - Key Exchange Method Transform IDs" subregistry for their Transform IDs.
This document registers ADDITIONAL_KEY_EXCHANGE (value 16441) in the "IKEv2 Notify Message Types - Status Types" registry and STATE_NOT_FOUND (value 47) in the "IKEv2 Notify Message Types - Error Types" registry.
This document renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renames the associated IANA registry from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs", also renaming the field in the KE payload from "Diffie-Hellman Group Num" to "Key Exchange Method".
Encryption, PRF, and integrity transform types (1–3) are not susceptible to Shor's algorithm but are susceptible to Grover's attack. Per NIST guidance, AES with a minimum 128-bit key remains acceptable for current applications, though longer keys should be considered for data requiring long-term secrecy.
Performing multiple key exchanges increases the responder's susceptibility to DoS attacks due to the additional resources required before the initiator is authenticated; this is especially true for post-quantum methods that are more memory/CPU intensive. Responders should consider RFC 8019 recommendations and may offer initial SA setup without additional key exchanges, deferring them to a subsequent CREATE_CHILD_SA rekey.
This extension focuses on preventing passive "harvest-and-decrypt" attacks (recording ciphertext today, decrypting with future quantum computers) via hybrid key exchange. Active attacks using quantum computers are not fully addressed because authentication remains classical; post-quantum digital signatures are needed to address that threat.
After each IKE_INTERMEDIATE additional key exchange, both sides compute SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr), where SK(n) is the shared secret from the n-th exchange and Ni/Nr are IKE_SA_INIT nonces. All SK_* values are then rederived: {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | SK_pr(n)} = prf+(SKEYSEED(n), Ni | Nr | SPIi | SPIr).
For Child SA creation or rekey with multiple key exchanges, KEYMAT = prf+(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)), using the same input construction as the IKE SA rekey formula.
For IKE SA rekey with multiple key exchanges, SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)), where SK_d is from the existing IKE SA, SK(0)/Ni/Nr are from the CREATE_CHILD_SA, and SK(1)...SK(n) are shared keys from the additional IKE_FOLLOWUP_KE exchanges.