]> Check Point Software Technologies Ltd.

5 Hasolelim St. Tel Aviv 67897 Israel yaronf@checkpoint.com

Nokia Siemens Networks

Otto-Hahn-Ring 6 Munich Bavaria 81739 Germany Hannes.Tschofenig@nsn.com http://www.tschofenig.priv.at

QUALCOMM, Inc.

5775 Morehouse Dr San Diego CA USA +1 858-845-1267 ldondeti@qualcomm.com

QUALCOMM, Inc.

5775 Morehouse Dr San Diego CA USA +1 858-845-2483 vidyan@qualcomm.com

The Internet Key Exchange version 2 (IKEv2) protocol has computational and communication overhead with respect to the number of round-trips required and cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol is used for authentication, which adds several more round trips and therefore latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. The encrypted ticket can only be decrypted by the VPN gateway in order to restore state for faster session setup.

The Internet Key Exchange version 2 (IKEv2) protocol has computational and communication overhead with respect to the number of round-trips required and cryptographic operations involved. In particular the Extensible Authentication Protocol is used for authentication in remote access cases, which increases latency. To re-establish security associations (SA) upon a failure recovery condition is time-consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. This document proposes to maintain IKEv2 state in a "ticket", an opaque data structure created and used by a server and stored by a client, which the client cannot understand or tamper with. The IKEv2 protocol is extended to allow a client to request and present a ticket. When two gateways mutually trust each other, one can accept a ticket generated by the other. This approach is similar to the one taken by TLS session resumption with the required adaptations for IKEv2, e.g., to accommodate the two-phase protocol structure. We have borrowed heavily from that specification.

The high-level goal of this extension is to provide an IPsec failover solution, according to the requirements defined in . Specifically, the proposed extension should allow IPsec sessions to be recovered from failures in remote access scenarios, in a more efficient manner than the basic IKE solution. This efficiency is primarily on the gateway side, since the gateway might have to deal with many thousands of concurrent requests. We should enable the following cases: Failover from one gateway to another, where the two gateways do not share state but do have mutual trust. For example, the gateways may be operated by the same provider and share the same keying materials to access an encrypted ticket. Recovery from an intermittent connectivity, where clients reconnect into the same gateway. In this case, the gateway would typically have detected the clients' absence and removed the state associated with them. Recovery from a gateway restart, where clients reconnect into the same gateway. The proposed solution should additionally meet the following goals: Using only symmetric cryptography to minimize CPU consumption. Allowing a gateway to push state to clients. Providing cryptographic agility. Having no negative impact on IKEv2 security features.

The following are non-goals of this solution: Providing load balancing among gateways. Specifying how a client detects the need for a failover.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . This document uses terminology defined in , , and . In addition, this document uses the following terms: A secure domain comprises a set of gateways that are able to resume an IKEv2 session that may have been established by any other gateway within the domain. All gateways in the secure domain are expected to share some secrets, so that they can generate an IKEv2 ticket, verify the validity of the ticket and extract the IKEv2 policy and session key material from the ticket. An IKEv2 ticket is a data structure that contains all the necessary information that allows any gateway within the same secure domain as the gateway that created the ticket to verify the validity of the ticket and extract IKEv2 policy and session keys to re-establish an IKEv2 session. When the IKEv2 session state is stored at the client, the IKEv2 responder is "stateless" until the client restores the SA with one of the gateways within the secure domain; thus, we refer to SA resumption with SA storage at the client as stateless session resumption. When the infrastructure maintains IKEv2 session state, we refer to the process of IKEv2 SA re-establishment as stateful session resumption.

This specification envisions two usage scenarios for efficient IKEv2 and IPsec SA session re-establishment. The first is similar to the use case specified in Section 1.1.3 of the IKEv2 specification , where the IPsec tunnel mode is used to establish a secure channel between a remote access client and a gateway; the traffic flow may be between the client and entities beyond the gateway. The second use case focuses on the usage of transport (or tunnel) mode to secure the communicate between two end points (e.g., two servers). The two endpoints have a client-server relationship with respect to a protocol that runs using the protections afforded by the IPsec SA.

! Remote ! Subnet ! Access ! ! Access !<--- and/or ! Client !<------------------------>! Gateway ! Internet ! ! IPsec tunnel ! ! +-+-+-+-+-+ +-+-+-+-+-+ (b) +-+-+-+-+-+ +-+-+-+-+-+ ! ! IKE_SESSION_RESUME ! ! ! Remote !<------------------------>! New/Old ! ! Access ! ! Gateway ! ! Client !<------------------------>! ! ! ! IPsec tunnel ! ! +-+-+-+-+-+ +-+-+-+-+-+ ]]>

In this scenario, an end-host (an entity with a host implementation of IPsec ) establishes a tunnel mode IPsec SA with a gateway in a remote network using IKEv2. The end-host in this scenario is sometimes referred to as a remote access client. When the remote gateway fails, all the clients associated with the gateway either need to re-establish IKEv2 sessions with another gateway within the same secure domain of the original gateway, or with the original gateway if the server is back online soon. The clients may choose to establish IPsec SAs using a full IKEv2 exchange or the IKE_SESSION_RESUME exchange (shown in ). In this scenario, the client needs to get an IP address from the remote network so that traffic can be encapsulated by the remote access gateway before reaching the client. In the initial exchange, the gateway may acquire IP addresses from the address pool of a local DHCP server. The new gateway that a client gets associated may not receive addresses from the same address pool. Thus, the session resumption protocol needs to support the assignment of a new IP address. The protocol defined in this document supports the re-allocation of an IP address to the client, if this capability is provided by the network. For example, if routing tables are modified so that traffic is rerouted through the new gateway. This capability is implicit in the use of the IKE Config mechanism, which allows the client to present its existing IP address and receive the same address back, if allowed by the gateway. The protocol defined here supports both stateful and stateless scenarios. In other words, tickets can be stored wholly on the client, or the ticket can be stored on the gateway (or in a database shared between multiple gateways), with the client only presenting a handle that identifies a particular ticket. In fact these scenarios are transparent to the protocols, with the only change being the non-mandatory ticket format.

! Server ! ! & ! ! & ! ! IPsec !<------------------------>! IPsec ! ! host ! IPsec transport/ ! host ! +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ (b) +-+-+-+-+-+ +-+-+-+-+-+ ! App. ! IKE_SESSION_RESUME ! New ! ! Client !<------------------------>! Server ! ! & ! ! & ! ! IPsec !<------------------------>! IPsec ! ! host ! IPsec transport/ ! host ! +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ ]]>

The second usage scenario is as follows: two entities with IPsec host implementations establish an IPsec transport or tunnel mode SA between themselves; this is similar to the model described in Section 1.1.2. of . At the application level, one of the entities is always the client and the other is a server. From that view point, the IKEv2 exchange is always initiated by the client. This allows the Initiator (the client) to authenticate itself using EAP, as long as the Responder (or the application server) allows it. If the application server fails, the client may find other servers within the same secure domain for service continuity. It may use a full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re-establish the IPsec SAs for secure communication required by the application layer signaling. The client-server relationship at the application layer ensures that one of the entities in this usage scenario is unambiguously always the Initiator and the other the Responder. This role determination also allows the Initiator to request an address in the Responder's network using the Configuration Payload mechanism of the IKEv2 protocol. If the client has thus received an address during the initial IKEv2 exchange, when it associates with a new server upon failure of the original server, it needs to request an address, specifying its assigned address. The server may allow the client to use the original address or if it is not permitted to use that address, assign a new address.

This section provides protocol details and contains the normative parts. This document defines two protocol exchanges, namely requesting a ticket and presenting a ticket. describes the procedure to request a ticket and illustrates how to present a ticket.

A client MAY request a ticket in the following exchanges: In an IKE_AUTH exchange, as shown in the example message exchange in below. In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. In an Informational exchange, if the gateway previously replied with an N(TICKET_ACK) instead of providing a ticket. In an Informational exchange, when the ticket lifetime is about to expire. In an IKE_SESSION_RESUME exchange, see . Normally, a client requests a ticket in the third message of an IKEv2 exchange (the first of IKE_AUTH). shows the message exchange for this typical case.

<-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> ]]>

The notification payloads are described in . The above is an example, and IKEv2 allows a number of variants on these messages. A complete description of IKEv2 can be found in . When an IKEv2 responder receives a request for a ticket using the N(TICKET_REQUEST) payload it MUST perform one of the following operations if it supports the extension defined in this document: it creates a ticket and returns it with the N(TICKET_OPAQUE) payload in a subsequent message towards the IKEv2 initiator. This is shown in . it returns an N(TICKET_NACK) payload, if it refuses to grant a ticket for some reason. it returns an N(TICKET_ACK), if it cannot grant a ticket immediately, e.g., due to packet size limitations. In this case the client MAY request a ticket later using an Informational exchange, at any time during the lifetime of the IKE SA. Provided the IKEv2 exchange was successful, the IKEv2 initiator can accept the requested ticket. The ticket may be used later with an IKEv2 responder which supports this extension. shows how the initiator receives the ticket.

Following a communication failure, a client re-initiates an IKE exchange to the same gateway or to a different one, and includes a ticket in the first message. A client MAY initiate a regular (non-ticket-based) IKEv2 exchange even if it is in possession of a valid ticket. A client MUST NOT present a ticket after the ticket's lifetime has expired. It is up to the client's local policy to decide when the communication with the IKEv2 responder is seen as interrupted and a new exchange needs to be initiated and the session resumption procedure to be initiated. Tickets are intended for one-time use: a client MUST NOT reuse a ticket, either with the same or with a different gateway. A gateway SHOULD reject a reused ticket. Note however that a gateway can elect not to retain a list of already-used tickets. Potential replay attacks on such gateways are mitigated by the cookie mechanism described in . This document specifies a new IKEv2 exchange type called IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is somewhat similar to the IKE_AUTH exchange, and results in the creation of a Child SA. The client SHOULD NOT use this exchange type unless it knows that the gateway supports it, either through configuration, by out-of-band means or by using the Gateway List provision.

]]>

The exchange type in HDR is set to 'IKE_SESSION_RESUME'. See for details on computing the protected (SK) payload. When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) payload it MUST perform one of the following steps if it supports the extension defined in this document: If it is willing to accept the ticket, it responds as shown in . It responds with an unprotected N(TICKET_NACK) notification, if it rejects the ticket for any reason. In that case, the initiator should re-initiate a regular IKE exchange. One such case is when the responder receives a ticket for an IKE SA that has previously been terminated on the responder itself, which may indicate inconsistent state between the IKEv2 initiator and the responder. However, a responder is not required to maintain the state for terminated sessions. When the responder receives a ticket for an IKE SA that is still active and if the responder accepts it, then the old SAs SHOULD be silently deleted without sending a DELETE informational exchange.

Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The SK payload is protected using the cryptographic parameters derived from the ticket, see below. At this point a new IKE SA is created by both parties, see . This is followed by normal derivation of a child SA, per Sec. 2.17 of .

The two messages of this exchange are protected by a "subset" IKE SA. The key material is derived from the ticket, as follows:

where SK_d_old is the SK_d value of the original IKE SA, as retrieved from the ticket. Ni guarantees freshness of the key material. SK_d2 is used later to derive the new IKE SA, see . See for the notation. "prf" is determined from the SA value in the ticket.

When receiving the first message of the IKE_SESSION_RESUME exchange, the gateway may decide that it is under a denial-of-service attack. In such a case, the gateway SHOULD defer the establishment of session state until it has verified the identity of the client. We use a variation of the IKEv2 Cookie mechanism, where the cookie is protected. In the two messages that follow, the gateway responds that it is unwilling to resume the session until the client is verified, and the client resubmits its first message, this time with the cookie:

]]>

Assuming the cookie is correct, the gateway now replies normally. This now becomes a 4-message exchange. The entire exchange is protected as defined in . See Sec. 2.6 and Sec. 3.10.1 of for more guidance regarding the usage and syntax of the cookie. Note that the cookie is completely independent of the IKEv2 ticket.

When resuming a session, a client will typically request a new ticket immediately, so it is able to resume the session again in the case of a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as protected payloads to the IKE_SESSION_RESUME exchange. The returned ticket (if any) will correspond to the IKE SA created per the rules described in .

This document defines a number of notifications. The notification numbers are TBA by IANA. Notification Name Number Data TICKET_OPAQUE TBA1 See TICKET_REQUEST TBA2 None TICKET_ACK TBA3 None TICKET_NACK TBA4 None TICKET_GATEWAY_LIST TBA5 See

The data for the TICKET_OPAQUE Notify payload consists of the Notify message header, a lifetime field and the ticket itself. The four octet lifetime field contains the number of seconds until the ticket expires as an unsigned integer. describes a possible ticket format, and offers further guidelines regarding the ticket's lifetime.

The TICKET_GATEWAY_LIST Notify payload contains the Notify payload header followed by a sequence of one or more gateway identifiers, each of the format depicted in .

The ID Type contains a restricted set of the IKEv2 ID payloads (see , Section 3.5). Allowed ID types are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN and the various reserved values. This field must be sent as 0 and must be ignored when received. The length field indicates the total size of the Identification data. The Identification Data field is of variable length and depends on the ID type. The length is not necessarily a multiple of 4.

When a ticket is presented, the gateway parses the ticket to retrieve the state of the old IKE SA, and the client retrieves this state from its local store. Both peers now create state for the new IKE SA as follows: The SA value (transforms etc.) is taken directly from the ticket. The sequence numbers are reset to 0. The IDi value is obtained from the ticket. The IDr value is obtained from the new exchange. The gateway MAY make policy decisions based on the IDr value encoded in the ticket. The SPI values are created anew, similarly to a regular IKE exchange. SPI values from the ticket SHOULD NOT be reused. This restriction is to avoid problems caused by collisions with other SPI values used already by the initiator/responder. The SPI value should only be reused if collision avoidance can be ensured through other means. The cryptographic material is refreshed based on the ticket and the nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED value is derived as follows:

where SK_d2 was computed earlier (). The keys are derived as follows, unchanged from IKEv2:

where SPIi, SPIr are the SPI values created in the new IKE exchange. See for the notation. "prf" is determined from the SA value in the ticket.

This section lists the required contents of the ticket, and recommends a non-normative format. This is followed by a discussion of the ticket's lifecycle.

The ticket MUST encode at least the following state from an IKE SA. These values MUST be encrypted and authenticated. IDi, IDr. SPIi, SPIr. SAr (the accepted proposal). SK_d. In addition, the ticket MUST encode a protected ticket expiration value.

This document does not specify a mandatory-to-implement or a mandatory-to-use ticket format. The following format is RECOMMENDED, if interoperability between gateways is desired.

Note that the key defined by "key_id" determines the encryption and authentication algorithms used for this ticket. Those algorithms are unrelated to the transforms defined by the SA payload. The reader is referred to a recent draft that recommends a similar (but not identical) ticket format, and discusses related security considerations in depth.

Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted, the client MUST delete its stored ticket. A ticket is therefore associated with the tuple (IDi, IDr). The client MAY however use a ticket to approach other gateways that are willing to accept it. How a client discovers such gateways is outside the scope of this document. The lifetime of the ticket carried in the N(TICKET_OPAQUE) notification should be the minimum of the IKE SA lifetime (per the gateway's local policy) and its re-authentication time, according to . Even if neither of these are enforced by the gateway, a finite lifetime MUST be specified for the ticket.

This document does not define an interoperable mechanism for the generation and distribution of the keys that protect IKE keys. Such a mechanism can be developed, based on the GDOI group key exchange protocol . There is on-going work to enable the generation of non-IPsec keys by means of GDOI, e.g. to provide RSVP router groups with a single key . This work can be generalized for our purposes. We note that there are no significant performance requirements on such a protocol, as key rollover can be at a daily or even more leisurely rate.

This document requires a number of IKEv2 notification status types in , to be registered by IANA. The corresponding registry was established by IANA. The document defines a new IKEv2 exchange in . The corresponding registry was established by IANA.

This section addresses security issues related to the usage of a ticket.

An eavesdropper or man-in-the-middle may try to obtain a ticket and use it to establish a session with the IKEv2 responder. This can happen in different ways: by eavesdropping on the initial communication and copying the ticket when it is granted and before it is used, or by listening in on a client's use of the ticket to resume a session. However, since the ticket's contents is encrypted and the attacker does not know the corresponding secret key (specifically, SK_d), a stolen ticket cannot be used by an attacker to resume a session. An IKEv2 responder MUST use strong encryption and integrity protection of the ticket to prevent an attacker from obtaining the ticket's contents, e.g., by using a brute force attack.

A malicious user could forge or alter a ticket in order to resume a session, to extend its lifetime, to impersonate as another user, or to gain additional privileges. This attack is not possible if the ticket is protected using a strong integrity protection algorithm.

The key_id field defined in the recommended ticket format helps the server efficiently reject tickets that it did not issue. However, an adversary could generate and send a large number of tickets to a gateway for verification. To minimize the possibility of such denial of service, ticket verification should be lightweight (e.g., using efficient symmetric key cryptographic algorithms).

A full description of the management of the keys used to protect the ticket is beyond the scope of this document. A list of RECOMMENDED practices is given below. The keys should be generated securely following the randomness recommendations in . The keys and cryptographic protection algorithms should be at least 128 bits in strength. The keys should not be used for any other purpose than generating and verifying tickets. The keys should be changed regularly. The keys should be changed if the ticket format or cryptographic protection algorithms change.

An IKEv2 responder controls the lifetime of a ticket, based on the operational and security requirements of the environment in which it is deployed. The responder provides information about the ticket lifetime to the IKEv2 initiator, allowing it to manage its tickets. An IKEv2 client may present a ticket in its possession to a gateway, even if the IKE SA associated with this ticket had previously been terminated by another gateway (the gateway that originally provided the ticket). Where such usage is against the local security policy, an Invalid Ticket List (ITL) may be used, see . Management of such lists is outside the scope of the current document. Note that a policy that requires tickets to have shorter lifetimes (e.g., 1 hour) significantly mitigates this risk.

If the ticket format or distribution scheme defined in this document is not used, then great care must be taken in analyzing the security of the solution. In particular, if confidential information, such as a secret key, is transferred to the client, it MUST be done using secure communication to prevent attackers from obtaining or modifying the key. Also, the ticket MUST have its integrity and confidentiality protected with strong cryptographic techniques to prevent a breach in the security of the system.

This document mandates that the content of the ticket MUST be encrypted in order to avoid leakage of information, such as the identities of an IKEv2 initiator and a responder. Thus, it prevents the disclosure of potentially sensitive information carried within the ticket. When an IKEv2 initiator presents the ticket as part of the IKE_SESSION_RESUME exchange, confidentiality is not provided for the exchange. Although the ticket itself is encrypted there might still be a possibility for an on-path adversary to observe multiple exchange handshakes where the same ticket is used and therefore to conclude that they belong to the same communication end points. Administrators that use the ticket mechanism described in this document should be aware that unlinkability may not be provided by this mechanism. Note, however, that IKEv2 does not provide active user identity confidentiality for the IKEv2 initiator either.

A major design goal of this protocol extension has been the two-message exchange for session resumption. There is a tradeoff between this abbreviated exchange and replay protection. It is RECOMMENDED that the gateway should cache tickets, and reject replayed ones. However some gateways may not do that in order to reduce state size. In addition, an adversary may replay a ticket last presented to gateway A, into gateway B. Our cookie-based mechanism () mitigates both scenarios by ensuring that the client presenting the ticket is indeed its "owner": the client can be required by the gateway to prove that it knows the ticket's secret, before any state is committed on the gateway. Note that this is a stronger guarantee than the regular IKE cookie mechanism, which only proves IP return routability of the client. This is enabled by including the cookie in the protected portion of the message. For performance reasons, the cookie mechanism is optional, and invoked by the gateway only when it suspects that it is the subject of a denial-of-service attack. In any case, a ticket replayed by an adversary only causes partial IKE state to be created on the gateway. The IKE exchange cannot be completed and an IKE SA cannot be created unless the client knows the ticket's secret values.

We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, Yoav Nir and Tero Kivinen for their many helpful comments.

&rfc2119; &rfc4306; &rfc3547; &rfc4301; &rfc4478; &rfc4086; &rfc4507; &rfc4555; &rfc4718; &draft-friedman-ike-short-term-certs; &draft-vidya-ipsec-failover-ps; &draft-rescorla-stateless-tokens; &draft-weis-gdoi-for-rsvp;

is on-going work that discusses the use of short-term certificates for client re-authentication. It is similar to the ticket approach described in this document in that they both require enhancements to IKEv2 to allow information request, e.g., for a certificate or a ticket. However, the changes required by the former are fewer since an obtained certificate is valid for any IKE responder that is able to verify them. On the other hand, short-term certificates, while eliminating the usability issues of user re-authentication, do not reduce the amount of effort performed by the gateway in failover situations.

Removed counter mechanism. Added an optional anti-DoS mechanism, based on IKEv2 cookies (removed previous discussion of cookies). Clarified that gateways may support reallocation of same IP address, if provided by network. Proposed a solution outline to the problem of key exchange for the keys that protect tickets. Added fields to the ticket to enable interoperability. Removed incorrect MOBIKE notification.

Clarifications on generation of SPI values, on the ticket's lifetime and on the integrity protection of the anti-replay counter. Eliminated redundant SPIs from the notification payloads.

Editorial review. Removed 24-hour limitation on ticket lifetime, lifetime is up to local policy.

Initial version. This draft is a selective merge of draft-sheffer-ike-session-resumption-00 and draft-dondeti-ipsec-failover-sol-00.