Internet Key Exchange (IKEv2) Protocol
obsoleted by
- rfc-5996 — Internet Key Exchange Protocol Version 2 (IKEv2)
obsoletes
- rfc-2407 — The Internet IP Security Domain of Interpretation for ISAKMP
- rfc-2408 — Internet Security Association and Key Management Protocol (ISAKMP)
- rfc-2409 — The Internet Key Exchange (IKE)
updated by
- rfc-5282 — Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
Extracted elements (30)
IKEv2 deliberately allows parallel CHILD_SAs with identical traffic selectors between common endpoints to support traffic QoS differentiation (per RFC 2474/2475/2983). This means the IKEv1 heuristic of deleting SAs based on duplicate traffic selectors SHOULD NOT be used in IKEv2 implementations.
Unlike IKEv1, IKEv2 does not negotiate SA lifetimes between peers. Each endpoint independently enforces its own lifetime policy and initiates rekeying as needed. This eliminates a class of lifetime-negotiation attacks and simplifies the protocol; the endpoint with the shorter lifetime will always be the rekeying initiator.
An active attacker can force two IKEv2-capable nodes to speak IKEv1 because IKEv1 has no mechanism for signaling ability to speak a higher version number. When a v2-capable node negotiates down to v1 due to an active attacker sending error messages, it SHOULD log that fact.
IKEv2 does not interoperate with IKEv1 but shares enough header format that both versions can run unambiguously on the same UDP port 500. If a node with a higher major version receives a message negotiating down, both sides will notice the other can support a higher version and MUST break the connection and reconnect at the higher version.
All IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, after which CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. Recipients of IKE_AUTH messages MUST verify that all signatures and MACs are computed correctly.
All IKEv2 implementations MUST be able to send, receive, and process IKE messages up to 1280 bytes long, and SHOULD be able to handle messages up to 3000 bytes long. Implementations SHOULD be aware of the maximum UDP message size supported and MAY shorten messages by omitting certificates or cryptographic suite proposals.
All RESERVED fields MUST be set to zero by a version 2.0 implementation and their content MUST be ignored on receipt. If the Critical flag is set on an unrecognized payload, the message MUST be rejected with UNSUPPORTED_CRITICAL_PAYLOAD; if the Critical flag is not set and the payload type is unrecognized, the payload MUST be ignored.
An endpoint MUST conclude the peer has failed only when repeated contact attempts have gone unanswered for a timeout period, or when a cryptographically protected INITIAL_CONTACT notification arrives on a different IKE_SA to the same authenticated identity. Endpoints MUST NOT conclude failure based on routing information (e.g., ICMP) or unprotected IKE messages.
An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted requests; when window size is N, the initiator must wait for responses to all requests through X-N before sending request X. The endpoint MUST keep copies of sent requests and a number of previous responses equal to its declared window size to support retransmission.
EAP authentication methods MUST be used in conjunction with public key signature-based authentication of the responder to the initiator. EAP methods that create a shared key MUST use that shared key (the MSK) to generate AUTH payloads in the final IKE_AUTH messages. EAP methods that do not establish a shared key SHOULD NOT be used due to susceptibility to MITM attacks.
ESP and AH SAs always exist in pairs (one in each direction); when an SA is closed, both members of the pair MUST be closed. When SAs are nested (IPComp, then ESP, then AH between the same endpoints), all SAs MUST be deleted together. Each endpoint MUST close its incoming SAs and allow the other endpoint to close the other SA in each pair.
Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated prf. If the IKE_SA Message ID grows too large for 32 bits, the IKE_SA MUST be closed; rekeying an IKE_SA resets sequence numbers.
Retransmission times MUST increase exponentially to avoid flooding the network and worsening congestion. Implementations MUST limit the rate at which they take actions based on unprotected messages. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all associated SAs.
The initiator is responsible for retransmission in the event of a timeout; the responder MUST never retransmit a response unless it receives a retransmission of the corresponding request. The initiator MUST remember each request until it receives the corresponding response; the responder MUST remember each response until it receives a request with a sufficiently larger sequence number.
To achieve perfect forward secrecy, when a connection is closed each endpoint MUST forget not only the session keys but also any information that could be used to recompute them, including the secrets used in the Diffie-Hellman calculation and any persistent state in a PRNG that could recompute DH secrets.
CHILD_SA keying material is KEYMAT = prf+(SK_d, Ni | Nr), or KEYMAT = prf+(SK_d, g^ir(new) | Ni | Nr) when the CREATE_CHILD_SA exchange includes a DH payload. Keys are assigned in order: initiator-to-responder encryption key, integrity key, then responder-to-initiator encryption key, integrity key.
IKEv2 defines four exchange types: IKE_SA_INIT (negotiates IKE_SA cryptographic parameters, exchanges nonces and DH values), IKE_AUTH (authenticates peers, exchanges identities and certificates, establishes first CHILD_SA), CREATE_CHILD_SA (creates or rekeys CHILD_SAs or the IKE_SA itself), and INFORMATIONAL (conveys control messages, deletions, and error notifications). All communications consist of request/response pairs.
IKEv2 key derivation begins with SKEYSEED = prf(Ni | Nr, g^ir). Seven keys are then derived as {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr). SK_d seeds CHILD_SA key derivation; SK_ai/SK_ar provide integrity protection; SK_ei/SK_er provide encryption; SK_pi/SK_pr generate AUTH payloads.
Pre-shared key AUTH is computed as AUTH = prf(prf(Shared Secret, "Key Pad for IKEv2"), <msg octets>), where the pad string is exactly 17 ASCII characters without null termination. The management interface MUST accept ASCII strings of at least 64 octets and MUST also accept HEX encoding of the shared secret; if the negotiated prf takes a fixed-size key, the shared secret MUST be of that size.
SA rekeying uses a CREATE_CHILD_SA exchange to establish a new SA before the old one expires, then deletes the old one. In IKEv2 (unlike IKEv1), SA lifetimes are not negotiated; each endpoint enforces its own lifetime policy. When both ends initiate rekeying simultaneously, the SA created with the lowest of the four nonces SHOULD be closed by the endpoint that created it.
The COOKIE anti-DoS mechanism allows a responder detecting many half-open IKE_SAs to require initiators to prove reachability before committing state. The recommended stateless cookie formula is: Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>), where <secret> is a frequently rotated server-only value. Initiators MUST retry IKE_SA_INIT with the COOKIE notify as the first payload.
The prf+ pseudo-random stream construction is defined as prf+(K,S) = T1 | T2 | T3 | ..., where T1 = prf(K, S|0x01), T2 = prf(K, T1|S|0x02), etc. Keys are taken from the output stream without regard to boundaries. The construction is not defined beyond 255 times the size of the prf output.
Traffic Selector (TS) payloads specify selection criteria (IPv4/IPv6 address range, port range, IP protocol ID) for packets to be forwarded over a CHILD_SA. TSi covers the initiator side and TSr the responder side. The responder may narrow the proposed traffic selectors but may not expand them; if it cannot accept the full set but can accept the first selectors, it MUST narrow to a subset including the initiator's first choices.
RFC 4306 creates and updates IANA registries for IKEv2 including: Exchange Types, Payload Types, Transform Types and IDs (encryption algorithms, PRF algorithms, integrity algorithms, DH groups), Notify Message Types, Authentication Methods, Traffic Selector Types, and Configuration Attribute Types. Most new assignments require Expert Review as defined in RFC 2434.
EAP methods that do not establish a shared key are subject to man-in-the-middle attacks when used in other protocols without a server-authenticated tunnel. If such methods are used, AUTH payloads in the final IKE_AUTH messages MUST be generated using SK_pi and SK_pr rather than an EAP-derived key.
Pre-shared keys derived solely from user-chosen passwords without additional randomness are typically insecure because user-chosen passwords lack sufficient unpredictability to resist dictionary attacks, and IKEv2's PSK authentication method does not prevent offline dictionary attacks. Applications requiring password-based bootstrapping should use the EAP authentication method instead.
The Encrypted Payload (payload type E) wraps all subsequent exchange payloads after IKE_SA_INIT with confidentiality and integrity protection using SK_e and SK_a. All messages following the initial exchange MUST include an Encrypted Payload, even if they are described as 'empty' (the encrypted portion may contain no payloads).
The Generic Payload Header is prepended to each IKE payload and contains: Next Payload type (1 octet), Critical flag and RESERVED bits (1 octet, Critical in the high-order bit), and Payload Length (2 octets) including the header. The Critical flag controls handling of unrecognized payload types.
The IKE fixed header contains: Initiator SPI (8 octets), Responder SPI (8 octets), Next Payload type (1 octet), Major/Minor Version (1 octet, 4 bits each), Exchange Type (1 octet), Flags including I(nitiator) and R(esponse) bits (1 octet), Message ID (4 octets), and Total Length (4 octets). An SPI value of zero in the Responder SPI field indicates the remote SPI is not yet known.
The SA payload uses a hierarchical Proposal/Protocol/Transform/Attribute structure. Each Proposal contains one or more Protocols; each Protocol contains one or more Transforms with a Transform Type field; each Transform contains zero or more Attributes. The responder MUST choose exactly one transform of each type included in the accepted proposal.