Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (23)
Authentication of IKE_INTERMEDIATE messages is performed over pre-encryption plaintext (rather than on-wire bytes) because IKE fragmentation allows the same logical message to arrive in different forms (fragmented vs. unfragmented, different fragment sizes). Authenticating the on-wire form would make AUTH payload computation non-deterministic across peers.
TCP encapsulation of IKE (RFC 8229) was considered as an alternative to handle large messages but was rejected as it has significant drawbacks and is intended only as a last resort when UDP is completely blocked. IKE_INTERMEDIATE over UDP with IKE fragmentation is the preferred approach.
The IKE_INTERMEDIATE exchange is defined without being tied to any specific use case (e.g., post-quantum key exchange) so that separate specifications can define its application. The data transferred is expected to be tens to a few hundred kilobytes in most cases, not bulk transfer.
Because window size is initially 1, all IKE_INTERMEDIATE exchanges MUST be sequential and MUST all complete before IKE_AUTH is initiated. The IKE SA MUST NOT be considered established until IKE_AUTH successfully completes.
Error handling in IKE_INTERMEDIATE follows RFC 7296 Sections 2.21.1 and 2.21.2 (initial exchange error handling), with the qualification that not all error notifications apply (e.g., authentication errors are generally only applicable to IKE_AUTH).
If NAT is detected in IKE_SA_INIT via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP, peers switch to port 4500 in the first IKE_INTERMEDIATE exchange and use it for all subsequent exchanges.
IKE_INTERMEDIATE exchanges MAY be used during IKEv2 Session Resumption between IKE_SESSION_RESUME and IKE_AUTH. Peers MUST negotiate support by including INTERMEDIATE_EXCHANGE_SUPPORTED in IKE_SESSION_RESUME messages; support status is not stored in the resumption ticket.
Message IDs for IKE_INTERMEDIATE exchanges MUST follow the standard IKEv2 rule: 1 for the first exchange, 2 for the next, etc. Implementations MUST verify received Message IDs follow this rule. The first IKE_AUTH pair uses a Message ID one greater than the last IKE_INTERMEDIATE exchange.
PRF calculations for IntAuth MUST be applied to whole messages only, before possible IKE fragmentation. If a message was received fragmented, it MUST be reconstructed before PRF computation; the RESERVED field in the reconstructed Encrypted payload header MUST be set to the value from the first fragment.
The Encrypted payload MUST be present in IKE_INTERMEDIATE messages, and payloads containing large amounts of data MUST be placed inside it to allow IKE fragmentation to take place.
The initiator indicates support for Intermediate Exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request; the responder includes it in the response if it also supports the exchange. Both peers must signal support before the initiator may use IKE_INTERMEDIATE.
Each IKE_INTERMEDIATE exchange uses its own SK_p[i/r]* key generation for IntAuth computation, matched to the same generation as the SK_e[i/r] and SK_a[i/r] keys protecting that exchange. The first exchange uses keys from IKE_SA_INIT; updated keys carry forward if a new key exchange occurred.
IKE_AUTH_MID, part of IntAuth, is the four-octet Message ID from the IKE Header of the first round of IKE_AUTH, represented in network byte order exactly as it appears on the wire.
IKE_INTERMEDIATE exchanges are authenticated in IKE_AUTH via an IntAuth chunk appended to the signed/MACed octets. IntAuth = IntAuth_iN | IntAuth_rN | IKE_AUTH_MID, where IntAuth_[i/r]N is the cumulative PRF chain over all IKE_INTERMEDIATE messages from initiator and responder respectively.
IKE_INTERMEDIATE is a new IKEv2 exchange type (value 43) that may occur one or more times after IKE_SA_INIT and before IKE_AUTH, enabling transfer of large data (e.g., post-quantum key material) without IP fragmentation by leveraging IKE fragmentation.
INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification with Notify Message Type 16438. Both Protocol ID and SPI Size fields are set to 0; Notification Data is empty but implementations MUST ignore non-empty data they do not understand.
Keys SK_e[i/r] and SK_a[i/r] protecting IKE_INTERMEDIATE messages are computed per RFC 7296 Section 2.14. Each exchange uses the most recently calculated keys; updated keys from a prior IKE_INTERMEDIATE exchange (e.g., after additional key exchange) carry forward to the next exchange.
A new entry is added to the 'IKEv2 Notify Message Types - Status Types' registry: value 16438 assigned to INTERMEDIATE_EXCHANGE_SUPPORTED.
Data in IKE_INTERMEDIATE exchanges is not authenticated until IKE_AUTH completes. If placed in the Encrypted payload it is protected from eavesdropping; peers can verify message origin by checking Integrity Checksum Data. A malicious initiator may exploit this to mount DoS attacks by driving expensive IKE_INTERMEDIATE exchanges and then aborting before IKE_AUTH.
If an attacker breaks the key exchange in real time (e.g., quantum computer), it can read and forge Encrypted payload content; forgery becomes evident in IKE_AUTH unless the attacker also breaks authentication. Additionally, if the negotiated PRF is not secure against second preimage attacks with known key, the attacker could forge IKE_INTERMEDIATE messages undetected through IKE_AUTH.
Specifications utilizing IKE_INTERMEDIATE MUST NOT allow an unlimited number of exchanges at the initiator's discretion. It is recommended that both peers know the exact number of IKE_INTERMEDIATE exchanges after IKE_SA_INIT; if optional use is defined, a hard cap on the maximum number MUST be specified by the corresponding specification.
For PRF calculation, the IKE Header Length field (Adjusted Length) is set to the sum of IntAuth_[i/r]*A and IntAuth_[i/r]*P lengths; the Encrypted payload Payload Length field (Adjusted Payload Length) is set to IntAuth_[i/r]*P length plus the four-octet Encrypted payload header size.
IntAuth_[i/r]*A covers from the first octet of the IKE Header through the last octet of the Encrypted payload generic header (scope identical to AEAD Associated Data per RFC 5282 Section 5.1). IntAuth_[i/r]*P covers the inner plaintext payloads of the Encrypted payload, excluding IV, Padding, Pad Length, and Integrity Checksum Data.