Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
Extracted elements (29)
The design is modeled closely on TLS session resumption (RFC 5077) with adaptations for IKEv2's two-phase exchange structure. Only symmetric cryptography is used to minimize CPU consumption.
The ticket format is intentionally left unspecified because format interoperability is not required — the same gateway that issues the ticket is always the one that interprets it. Appendix A provides example 'ticket by value' and 'ticket by reference' formats as non-normative guidance.
Two approaches are defined for gateway state storage: 'ticket by value' (state encrypted into the ticket itself) and 'ticket by reference' (an opaque index into gateway storage). The client behaves identically in both cases and cannot distinguish which is in use, so the ticket format is intentionally unspecified.
Child SAs, internal IP addresses, other Configuration Payload information, MOBIKE additional addresses, and peer Vendor IDs are not resumed; they must be re-established in the new exchange. New IKEv2 extensions not covered by the state table SHOULD specify how they interact with session resumption.
NAT traversal status is explicitly not part of session resumption state; it MUST be re-detected in IKE_SESSION_RESUME. If NAT is detected, the initiator switches to UDP encapsulation on port 4500 as per normal IKEv2 procedures.
When a multi-round-trip IKE_AUTH exchange is used, N(TICKET_REQUEST) MUST be included in the first IKE_AUTH request and N(TICKET_LT_OPAQUE)/TICKET_NACK/TICKET_ACK MUST only appear in the final IKE_AUTH response.
A finite lifetime MUST be specified for every ticket. The ticket lifetime SHOULD be the minimum of the IKE SA lifetime and re-authentication time per RFC 4478. The key protecting the ticket MUST have a lifetime significantly longer than the IKE SA lifetime.
A 'ticket by value' MUST have its content integrity protected and encrypted. A 'ticket by reference' does not need encryption but access to its backing store MUST be protected so only authorized entities can resolve it.
A 'ticket by value' MUST include a protected expiration time (absolute value) and MUST include a key identity field so that ticket encryption/authentication keys can be rotated and algorithms replaced.
IKE_SESSION_RESUME MUST be followed by an IKE_AUTH exchange. The client SHOULD NOT use IKE_SESSION_RESUME unless it knows the gateway supports it.
Leakage of identity information (IKEv2 initiator and responder identities) from the opaque ticket state MUST be avoided. The ticket MUST be presented to the responder only once to prevent linkability.
The IDi value sent in the IKE_AUTH exchange following IKE_SESSION_RESUME MUST be identical to the value included in the ticket. A CERT payload MUST NOT be included in this exchange, and IDr MUST also match the ticket.
Tickets are for one-time use only; a client MUST NOT reuse a ticket. A ticket is considered used only when an IKE SA has been successfully established with it, and a reused ticket SHOULD be rejected by the gateway.
Untrusted messages MUST NOT be relied upon to detect the need for session resumption; clients should not use a more liberal detection policy than the standard IKE SA liveness test (Section 2.4 of RFC 4306).
When an IKE SA is deleted by either party, the client MUST delete its stored ticket. When credentials associated with the IKE SA are invalidated (e.g., user logout), the ticket MUST also be deleted.
When the client accepts a ticket, its local storage MUST also include all state items marked 'from the ticket' in Section 5's state table, since the ticket itself is opaque to the client.
A new IKEv2 exchange type IKE_SESSION_RESUME (value 38) is defined, equivalent to IKE_SA_INIT but carrying the client's ticket in an N(TICKET_OPAQUE) payload. It must be followed by an IKE_AUTH exchange before the IKE SA is valid.
A Ticket is an opaque data structure created by the IKEv2 responder that encodes all necessary state to re-establish an IKE SA, either by value (encrypted state) or by reference (pointer to gateway-side storage).
Key material for the resumed IKE SA is derived as SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr), where SK_d_old is retrieved from the ticket and the literal string 'Resumption' is exactly 10 ASCII characters with no NULL terminator.
IKEv2 Exchange Types registry updated with IKE_SESSION_RESUME = 38.
IKEv2 Notify Message Types - Status Types registry updated with five new values: TICKET_LT_OPAQUE (16409), TICKET_REQUEST (16410), TICKET_ACK (16411), TICKET_NACK (16412), TICKET_OPAQUE (16413).
A stolen 'ticket by value' cannot be used by an attacker to resume a session because the ticket contents are encrypted and the attacker cannot prove knowledge of the secret IKE state during IKE_AUTH. The responder MUST use strong encryption and integrity protection on the ticket.
An adversary flooding a gateway with forged tickets (by value) burdens CPU and memory. For tickets by reference, this creates an amplification attack as the gateway resolves each reference. The regular IKEv2 cookie mechanism can mitigate state-overflow DoS; ticket verification should use efficient symmetric algorithms.
Forged or altered 'ticket by value' attacks are defeated by strong integrity protection. For 'ticket by reference', forging a fake reference fails because the adversary lacks the keying material; it is recommended to integrity-protect the reference to also prevent SQL injection and SSRF-style attacks.
Keys used to protect 'tickets by value' SHOULD be at least 128 bits, generated per RFC 4086, used only for ticket generation/verification, changed regularly and whenever the ticket format or algorithms change.
Ticket revocation for 'ticket by value' is a known problem since a misbehaving client can present a ticket for an already-deleted IKE SA. Mitigations include an Invalid Ticket List (ITL) or Bloom Filter on the gateway, and short ticket lifetimes (e.g., 1 hour).
Session resumption proceeds through three states: (1) IKE_SESSION_RESUME exchange where the client presents the ticket and both peers derive crypto material; (2) IKE_AUTH exchange where peers authenticate using prf(SK_px, message octets) and IDi/IDr are verified against the ticket; (3) completion where a new IKE SA and Child SA are established.
The TICKET_LT_OPAQUE Notify payload (type 16409) carries a 4-octet unsigned integer Lifetime field (seconds until expiry, network byte order) followed by a variable-length opaque Ticket field. Protocol ID and SPI Size MUST both be 0.
The TICKET_OPAQUE Notify payload (type 16413) carries only the variable-length opaque Ticket field with no lifetime value. Protocol ID and SPI Size MUST both be 0.