TOC 
Network Working GroupY. Sheffer
Internet-DraftCheck Point
Intended status: ExperimentalH. Tschofenig
Expires: May 18, 2008Nokia Siemens Networks
 L. Dondeti
 V. Narayanan
 QUALCOMM, Inc.
 November 15, 2007


IPsec Gateway Failover Protocol
draft-sheffer-ipsec-failover-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 18, 2008.

Abstract

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 additional 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. An encrypted ticket cannot be decrypted by a VPN client but allows a VPN gateway to restore state for faster session state setup.



Table of Contents

1.  Introduction
    1.1.  Goals
    1.2.  Non-Goals
2.  Terminology
3.  Usage Scenarios
    3.1.  Recovering from a Remote Access Gateway Failover
    3.2.  Recovering from an Application Server Failover
4.  Protocol Details
    4.1.  Requesting a Ticket
    4.2.  Presenting a Ticket
        4.2.1.  Protection of the IKE_SESSION_RESUME Exchange
        4.2.2.  Requesting a ticket during resumption
    4.3.  IKE Notifications
    4.4.  Gateway List
    4.5.  Processing Guidelines for IKE SA Establishment
5.  The IKE Ticket
    5.1.  Ticket Contents
    5.2.  Ticket Format
    5.3.  Ticket Identity and Lifecycle
6.  IANA Considerations
7.  Security Considerations
    7.1.  Stolen Tickets
    7.2.  Forged Tickets
    7.3.  Denial of Service Attacks
    7.4.  Ticket Protection Key Management
    7.5.  Ticket Lifetime
    7.6.  Alternate Ticket Formats and Distribution Schemes
    7.7.  Identity Privacy, Anonymity, and Unlinkability
    7.8.  Usage of IKE Cookies
    7.9.  Replay protection in the IKE_SESSION_RESUME EXCHANGE
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Related Work
Appendix B.  Change Log
    B.1.  -01
    B.2.  -00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

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 adds additional 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 an 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 needs to be 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 [RFC4507] (Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” May 2006.) with the required adaptations for IKEv2, e.g., to accommodate the two-phase protocol structure. We have borrowed heavily from that specification.



 TOC 

1.1.  Goals

The high-level goal of this extension is to provide an IPsec failover solution, according to the requirements defined in [I‑D.vidya‑ipsec‑failover‑ps] (Narayanan, V., “IPsec Gateway Failover and Redundancy - Problem Statement and Goals,” December 2007.).

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:

The proposed solution should additionally meet the following goals:



 TOC 

1.2.  Non-Goals

The following are non-goals of this solution:



 TOC 

2.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document uses terminology defined in [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.), [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), and [RFC4555] (Eronen, P., “IKEv2 Mobility and Multihoming Protocol (MOBIKE),” June 2006.). In addition, this document uses the following terms:

Secure domain:
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 the gateways in the secure domain are expected to share a security association - either with each other or through a trusted third party - so that they can verify the validity of the ticket and can extract the IKEv2 policy and session key material from the ticket.
IKEv2 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.
Stateless failover:
When the IKEv2 session state is stored at the client, the infrastructure 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.
Stateful failover:
When the infrastructure maintains IKEv2 session state, we refer to the process of IKEv2 SA re-establishment as stateful session resumption. Note that even in this case, a small amount of information (the "handle") needs to be stored on the client.



 TOC 

3.  Usage Scenarios

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 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), where IPsec tunnel mode is 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 is somewhat different from any of the use cases defined in the IKEv2 specification: at the IP layer, two endpoints use transport (or tunnel) mode to communicate between themselves. The two endpoints have a client-server relationship with respect to a protocol that runs using the protections afforded by the IPsec SA.



 TOC 

3.1.  Recovering from a Remote Access Gateway Failover



 (a)

 +-+-+-+-+-+                          +-+-+-+-+-+
 !         !      IKEv2/IKEv2-EAP     !         !     Protected
 ! Remote  !<------------------------>! Remote  !     Subnet
 ! Access  !                          ! Access  !<--- and/or
 ! Client  !<------------------------>! Gateway !     Internet
 !         !      IPsec tunnel        !         !
 +-+-+-+-+-+                          +-+-+-+-+-+


 (b)

 +-+-+-+-+-+                          +-+-+-+-+-+
 !         !    IKE_SESSION_RESUME    !         !
 ! Remote  !<------------------------>! New/Old !
 ! Access  !                          ! Gateway !
 ! Client  !<------------------------>!         !
 !         !      IPsec tunnel        !         !
 +-+-+-+-+-+                          +-+-+-+-+-+


 Figure 1: Remote Access Gateway Failure 

In this scenario, an end-host (an entity with a host implementation of IPsec [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) ) 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 Figure 1 (Remote Access Gateway Failure)).

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.



 TOC 

3.2.  Recovering from an Application Server Failover



  (a)

 +-+-+-+-+-+                          +-+-+-+-+-+
 !   App.  !      IKEv2/IKEv2-EAP     !   App.  !
 !  Client !<------------------------>!  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    +-+-+-+-+-+

 Figure 2: Application Server Failover 

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 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). 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.



 TOC 

4.  Protocol Details

This section provides protocol details and contains the normative parts. This document defines two protocol exchanges, namely requesting a ticket and presenting a ticket. Section 4.1 (Requesting a Ticket) describes the procedure to request a ticket and Section 4.2 (Presenting a Ticket) illustrates how to present a ticket.



 TOC 

4.1.  Requesting a Ticket

A client MAY request a ticket in the following exchanges:

Normally, a client requests a ticket in the third message of an IKEv2 exchange (the first of IKE_AUTH). Figure 3 (Example Message Exchange for Requesting a Ticket) shows the message exchange for this typical case.




  Initiator                Responder
  -----------              -----------
 HDR, SAi1, KEi, Ni  -->

                     <--    HDR, SAr1, KEr, Nr, [CERTREQ]

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

 Figure 3: Example Message Exchange for Requesting a Ticket 

The notification payloads are described in Section 4.3 (IKE Notifications). The above is an example, and IKEv2 allows a number of variants on these messages. A complete description of IKEv2 can be found in [RFC4718] (Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” October 2006.).

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:

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. Figure 4 (Receiving a Ticket) shows how the initiator receives the ticket.




  Initiator                Responder
  -----------              -----------
         <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
                     TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}

 Figure 4: Receiving a Ticket 



 TOC 

4.2.  Presenting a 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 purely a local decision of the client when and based on what information to decide that a communication failure has happened and that a new exchange including the ticket is needed.

We specify 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 MUST NOT use this exchange unless it knows that the gateway supports failover, either through configuration, by out-of-band means or by using the Gateway List provision.


 Initiator                Responder
 -----------              -----------
 HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,]
      SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]
      [, N(UPDATE_SA_ADDRESSES)]} -->

The exchange type in HDR is set to 'IKE_SESSION_RESUME'.

See Section 4.2.1 (Protection of the IKE_SESSION_RESUME Exchange) for details on computing the protected (SK) payload.

The client MUST increment the counter value each time it uses this same ticket to resume the session. When the gateway receives a resumption request for a ticket it has seen in the past, it MUST reject the request unless the counter value is larger than its previous value.

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:




 Initiator                Responder
 -----------              -----------
                 <--  HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
                      [CP(CFG_REPLY)]}

 Figure 5: IKEv2 Responder accepts the ticket 

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 Section 4.2.1 (Protection of the IKE_SESSION_RESUME Exchange) below.

At this point a new IKE SA is created by both parties, see Section 4.5 (Processing Guidelines for IKE SA Establishment). This is followed by normal derivation of a child SA, per Sec. 2.17 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.).



 TOC 

4.2.1.  Protection of the IKE_SESSION_RESUME Exchange

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


     {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)

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 Section 4.5 (Processing Guidelines for IKE SA Establishment).

See [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) for the notation. "prf" is determined from the SA value in the ticket.



 TOC 

4.2.2.  Requesting a ticket during resumption

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 Section 4.5 (Processing Guidelines for IKE SA Establishment).



 TOC 

4.3.  IKE Notifications

This document defines a number of notifications. The notification numbers are TBA by IANA.

Notification NameNumberData
TICKET_OPAQUE TBA1 See below
TICKET_REQUEST TBA2 None
TICKET_ACK TBA3 None
TICKET_NACK TBA4 None
TICKET_COUNTER TBA5 See below
TICKET_GATEWAY_LIST TBA6 See Section 4.4 (Gateway List)

The data for the TICKET_OPAQUE notification consists of a lifetime duration in seconds (4 octets, denoting the time until the ticket expires), followed by the ticket content. See Section 5.2 (Ticket Format) for a recommended ticket format, and Section 5.3 (Ticket Identity and Lifecycle) for further guidelines regarding the ticket's lifetime.

The data for TICKET_COUNTER consists of a single octet, treated as an unsigned integer.



 TOC 

4.4.  Gateway List

The gateway list is a sequence of zero or more gateway identifiers, each of the following format:



                             1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !    ID Type    !   Reserved    !             Length            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       Identifier Value                        !
      !                                                               !
      !                              ...                              !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 6: Gateway Identifier Syntax 

ID Type - see allowed values below.

Reserved - must be sent as 0, ignored when received.

Length - the length in octets of the identifier value.

Identifier Value - variable length. The actual length depends on the ID type. The length is not necessarily a multiple of 4.

The values and semantics of identifiers follow those of IKEv2 ID payloads ([RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), Sec. 3.5). Allowed ID types are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN and the various reserved values.



 TOC 

4.5.  Processing Guidelines for IKE SA Establishment

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 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:


     SKEYSEED = prf(SK_d2, Ni | Nr)

where SK_d2 was computed earlier (Section 4.2.1 (Protection of the IKE_SESSION_RESUME Exchange)).

The keys are derived as follows, unchanged from IKEv2:


     {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
                                 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

where SPIi, SPIr are the SPI values created in the new IKE exchange.

See [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) for the notation. "prf" is determined from the SA value in the ticket.



 TOC 

5.  The IKE 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.



 TOC 

5.1.  Ticket Contents

The ticket MUST encode at least the following state from an IKE SA. These values MUST be encrypted and authenticated.

In addition, the ticket MUST encode a protected ticket expiration value.



 TOC 

5.2.  Ticket Format

This document does not specify a ticket format. The following format (this entire current section) is a RECOMMENDED implementation. The client SHOULD NOT attempt to decode the ticket.


struct {
    opaque key_name[16];     // ASCII, null-terminated
    opaque IV[0..255];       // the length (possibly 0) depends
                             // on the encryption algorithm

    [encrypted] struct {
        opaque IDi, IDr;     // the full payloads
        opaque SPIi, SPIr;
        opaque SA;           // the full payload, returned as SAr
        opaque SK_d;
        opaque expiration;   // an absolute time value
    } ikev2_state;           // encrypted and authenticated
    opaque MAC[0..255];      // the length (possibly 0) depends
                             // on the integrity algorithm
} ticket;

Note that the key defined by "key_name" 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 [I‑D.rescorla‑stateless‑tokens] (Rescorla, E., “How to Implement Secure (Mostly) Stateless Tokens,” March 2007.) that recommends a similar (but not identical) ticket format, and discusses related security considerations in depth.



 TOC 

5.3.  Ticket Identity and Lifecycle

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 included with the ticket 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 [RFC4478] (Nir, Y., “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol,” April 2006.). Even if neither of these is enforced by the gateway, a finite lifetime MUST be specified for the ticket.



 TOC 

6.  IANA Considerations

This document requires a number of IKEv2 notification status types in Section 4.3 (IKE Notifications), to be registered by IANA. The corresponding registry was established by IANA.

The document defines a new IKEv2 exchange in Section 4.2 (Presenting a Ticket). The corresponding registry was established by IANA.



 TOC 

7.  Security Considerations

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



 TOC 

7.1.  Stolen Tickets

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.



 TOC 

7.2.  Forged Tickets

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.



 TOC 

7.3.  Denial of Service Attacks

The key_name 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). See also Section 7.8 (Usage of IKE Cookies).



 TOC 

7.4.  Ticket Protection Key Management

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.



 TOC 

7.5.  Ticket Lifetime

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 [I‑D.rescorla‑stateless‑tokens] (Rescorla, E., “How to Implement Secure (Mostly) Stateless Tokens,” March 2007.). 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.



 TOC 

7.6.  Alternate Ticket Formats and Distribution Schemes

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.



 TOC 

7.7.  Identity Privacy, Anonymity, and Unlinkability

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.



 TOC 

7.8.  Usage of IKE Cookies

The extension specified in this document eliminates most potential denial-of-service attacks that the cookie mechanism aims to solve. However, memory exhaustion remains possible. Therefore the cookie mechanism described in Section 2.6 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) MAY be invoked by the gateway for the IKE_SESSION_RESUME exchange described in Section 4.2 (Presenting a Ticket).



 TOC 

7.9.  Replay protection in the IKE_SESSION_RESUME EXCHANGE

A major design goal of the current protocol has been the two-message exchange for session resumption. There is a tradeoff between this abbreviated exchange and replay protection. Using our counter-based solution, an attacker cannot replay a ticket to a gateway that had seen this same ticket before. However the attacker can attempt to replay a ticket to another gateway, and create intermittent IKE state (but no successful establishment of an IKE SA). The standard Cookie mechanism can be used to mitigate this risk.



 TOC 

8.  Acknowledgements

We would like to thank Paul Hoffman, Pasi Eronen and Yoav Nir for their review of earlier drafts.



 TOC 

9.  References



 TOC 

9.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4306] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT).


 TOC 

9.2. Informative References

[I-D.friedman-ike-short-term-certs] Friedman, A., “Short-Term Certificates,” draft-friedman-ike-short-term-certs-02 (work in progress), June 2007 (TXT).
[I-D.rescorla-stateless-tokens] Rescorla, E., “How to Implement Secure (Mostly) Stateless Tokens,” draft-rescorla-stateless-tokens-01 (work in progress), March 2007 (TXT).
[I-D.vidya-ipsec-failover-ps] Narayanan, V., “IPsec Gateway Failover and Redundancy - Problem Statement and Goals,” draft-vidya-ipsec-failover-ps-02 (work in progress), December 2007 (TXT).
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” BCP 106, RFC 4086, June 2005 (TXT).
[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT).
[RFC4478] Nir, Y., “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol,” RFC 4478, April 2006 (TXT).
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” RFC 4507, May 2006 (TXT).
[RFC4555] Eronen, P., “IKEv2 Mobility and Multihoming Protocol (MOBIKE),” RFC 4555, June 2006 (TXT).
[RFC4718] Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” RFC 4718, October 2006 (TXT).


 TOC 

Appendix A.  Related Work

[I‑D.friedman‑ike‑short‑term‑certs] (Friedman, A., “Short-Term Certificates,” June 2007.) 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.



 TOC 

Appendix B.  Change Log



 TOC 

B.1.  -01

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



 TOC 

B.2.  -00

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



 TOC 

Authors' Addresses

  Yaron Sheffer
  Check Point Software Technologies Ltd.
  5 Hasolelim St.
  Tel Aviv 67897
  Israel
Email:  yaronf@checkpoint.com
  
  Hannes Tschofenig
  Nokia Siemens Networks
  Otto-Hahn-Ring 6
  Munich, Bavaria 81739
  Germany
Email:  Hannes.Tschofenig@nsn.com
URI:  http://www.tschofenig.com
  
  Lakshminath Dondeti
  QUALCOMM, Inc.
  5775 Morehouse Dr
  San Diego, CA
  USA
Phone:  +1 858-845-1267
Email:  ldondeti@qualcomm.com
  
  Vidya Narayanan
  QUALCOMM, Inc.
  5775 Morehouse Dr
  San Diego, CA
  USA
Phone:  +1 858-845-2483
Email:  vidyan@qualcomm.com


 TOC 

Full Copyright Statement

Intellectual Property