TOC 
Network Working GroupY. Sheffer
Internet-DraftCheck Point
Intended status: Standards TrackH. Tschofenig
Expires: March 25, 2010Nokia Siemens Networks
 September 21, 2009


IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-08.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 March 25, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.

To re-establish security associations (SAs) 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 order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an 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. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided.



Table of Contents

1.  Introduction
2.  Terminology
3.  Usage Scenario
4.  Protocol Sequences
    4.1.  Requesting a Ticket
    4.2.  Receiving a Ticket
    4.3.  Presenting a Ticket
        4.3.1.  Prologue
        4.3.2.  IKE_SESSION_RESUME Exchange
        4.3.3.  IKE_AUTH Exchange
        4.3.4.  Epilogue
5.  IKE and IPsec State After Resumption
    5.1.  Generating Cryptographic Material for the Resumed IKE SA
6.  Ticket Handling
    6.1.  Ticket Content
    6.2.  Ticket Identity and Lifecycle
7.  IKE Notifications
    7.1.  TICKET_LT_OPAQUE Notify Payload
    7.2.  TICKET_OPAQUE Notify Payload
8.  IANA Considerations
9.  Security Considerations
    9.1.  Stolen Tickets
    9.2.  Forged Tickets
    9.3.  Denial of Service Attacks
    9.4.  Detecting the Need for Resumption
    9.5.  Key Management for Tickets By Value
    9.6.  Ticket Lifetime
    9.7.  Ticket Revocation
    9.8.  Ticket by Value Format
    9.9.  Identity Privacy, Anonymity, and Unlinkability
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  Ticket Format
    A.1.  Example Ticket by Value Format
    A.2.  Example Ticket by Reference Format
Appendix B.  Change Log
    B.1.  -08
    B.2.  -07
    B.3.  -06
    B.4.  -05
    B.5.  -04
    B.6.  -03
    B.7.  -02
    B.8.  -01
    B.9.  -00
    B.10.  -01
    B.11.  -00
    B.12.  -04
    B.13.  -03
    B.14.  -02
    B.15.  -01
    B.16.  -00
§  Authors' Addresses




 TOC 

1.  Introduction

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In particular the Extensible Authentication Protocol (EAP) 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 responder. Usability is also affected when the re-establishment of an IKE SA involves user interaction for reauthentication.

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.

The client (IKEv2 initiator) stores the state about the previous IKE SA locally. The gateway (IKEv2 responder) has two options for maintaining the IKEv2 state about the previous IKE SA:

Note that the client behaves identically in both cases, and in general does not know which approach the gateway is using. Since the ticket (or reference) is only interpreted by the same party that created it, this document does not specify the exact format for it. However, Appendix A contains examples for both "ticket by reference" and "ticket by value" formats.

This approach is similar to the one taken by TLS session resumption [RFC5077] (Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” January 2008.) with the required adaptations for IKEv2, e.g., to accommodate the two-phase protocol structure. We have borrowed heavily from that specification.

The proposed solution should additionally meet the following 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.) and [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). In addition, this document uses the following terms:

Ticket:
An IKEv2 ticket is a data structure that contains all the necessary information that allows an IKEv2 responder to re-establish an IKEv2 security association.

In this document we use the term "ticket" and thereby refer to an opaque data structure that may either contain IKEv2 state as described above or a reference pointing to such state.



 TOC 

3.  Usage Scenario

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 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. This scenario is further discussed below.

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.




 (a)

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


 (b)

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


 Figure 1: Resuming a Session with a Remote Access Gateway 

In the first use case above, 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. At a later stage when a client needs to re-establish the IKEv2 session it may choose to establish IPsec SAs using a full IKEv2 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1 (Resuming a Session with a Remote Access Gateway)).

For either of the above use cases, there are multiple possible situations where the mechanism specified in this document could be useful. These include the following (note that this list is not meant to be exhaustive, and any particular deployment may not care about all of these):



 TOC 

4.  Protocol Sequences

This section provides protocol details and contains the normative parts. This document defines two protocol exchanges, namely requesting a ticket, see Section 4.1 (Requesting a Ticket), and presenting a ticket, see Section 4.3 (Presenting 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 2 (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 2: Example Message Exchange for Requesting a Ticket 

The notification payloads are described in Section 7 (IKE Notifications). The above is an example, and IKEv2 allows a number of variants on these messages. Refer to [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) and [I‑D.ietf‑ipsecme‑ikev2bis] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” April 2010.) for more details on IKEv2.

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:

Regardless of this choice, there is no change to the behavior of the responder with respect to the IKE exchange, and the proper IKE response (e.g. an IKE_AUTH response or an error notification) MUST be sent.



 TOC 

4.2.  Receiving a Ticket

The IKEv2 initiator receives the ticket and may accept it, provided the IKEv2 exchange was successful. The ticket may be used later with an IKEv2 responder that supports this extension. Figure 3 (Receiving a Ticket) shows how the initiator receives the ticket.




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

 Figure 3: Receiving a Ticket 

When a multi-round-trip IKE_AUTH exchange is used, the N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST only be returned in the final IKE_AUTH response.

When the client accepts the ticket, it stores it in its local storage for later use, along with the IKE SA that the ticket refers to. Since the ticket itself is opaque to the client, the local storage MUST also include all items marked as "from the ticket" in the table of Section 5 (IKE and IPsec State After Resumption).



 TOC 

4.3.  Presenting a Ticket

When the client wishes to recover from an interrupted session, it presents the ticket to resume the session. This section describes the resumption process, consisting of some preparations, an IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization.



 TOC 

4.3.1.  Prologue

It is up to the client's local policy to decide when the communication with the IKEv2 responder is seen as interrupted and the session resumption procedure is to be initiated.

A client MAY initiate a regular (non-ticket-based) IKEv2 exchange even if it is in possession of a valid, unexpired ticket. A client MUST NOT present a ticket when it knows that the ticket's lifetime has expired.

Tickets are intended for one-time use, i.e. a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. Note that a ticket is considered as used only when an IKE SA has been established successfully with it.



 TOC 

4.3.2.  IKE_SESSION_RESUME Exchange

This document specifies a new IKEv2 exchange type called IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is equivalent to the IKE_SA_INIT exchange, and MUST be followed by an IKE_AUTH exchange. The client SHOULD NOT use this exchange type unless it knows that the gateway supports it (this condition is trivially true in the context of the current document, since the client always resumes into the same gateway that generated the ticket).




  Initiator                Responder
 -----------              -----------
 HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+]   -->

 Figure 4: IKEv2 Initiator wishes to resume an IKE SA 

The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The initiator sets the SPIi value in the HDR to a new, unique value and the SPIr value is set to 0.

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, Nr [,N+]

 Figure 5: IKEv2 Responder accepts the ticket 

Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The responder copies the SPIi value from the request, and the SPIr value is set to a new, unique value.

Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves exactly like the IKE_SA_INIT exchange. Specifically:

Although the IKE SA is not fully valid until the completion of the IKE_AUTH exchange, the peers must create much of the SA state (Section 5 (IKE and IPsec State After Resumption)) now. Specifically, the SK_xx values are required to protect the IKE_AUTH payloads.



 TOC 

4.3.3.  IKE_AUTH Exchange

Following the IKE_SESSION_RESUME exchange, the client MUST initiate an IKE_AUTH exchange, which is largely as specified in [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). This section lists the differences and constraints compared to the base document.

The value of the AUTH payload is derived in a manner similar to the usage of IKEv2 pre-shared secret authentication:


         AUTH = prf(SK_px, <message octets>)

Each of the initiator and responder uses its own SK_p value, taken from the newly generated IKE SA, Section 5.1 (Generating Cryptographic Material for the Resumed IKE SA).

The exact material to be signed is defined in Section 2.15 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.).

The IDi value sent in the IKE_AUTH exchange MUST be identical to the value included in the ticket. A CERT payload MUST NOT be included in this exchange, and therefore a new IDr value cannot be negotiated (since it would not be authenticated). As a result, the IDr value sent (by the gateway, and optionally by the client) in this exchange MUST also be identical to the value included in the ticket.

When resuming a session, a client will typically request a new ticket immediately, so that it is able to resume the session again in the case of a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH exchange that follows the IKE_SESSION_RESUME exchange, with similar behavior to a ticket request during a regular IKE exchange, Section 4.1 (Requesting a Ticket). The returned ticket (if any) will correspond to the IKE SA created per the rules described in Section 5 (IKE and IPsec State After Resumption).



 TOC 

4.3.4.  Epilogue

Following the IKE_AUTH exchange, a new IKE SA is created by both parties, see Section 5 (IKE and IPsec State After Resumption), and a Child SA is derived, per Section 2.17 of [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.).

When the responder receives a ticket for an IKE SA that is still active and if the responder accepts it (i.e. following successful completion of the IKE_AUTH exchange), the old SA SHOULD be silently deleted without sending a DELETE informational exchange. Consequently, all the dependent IPsec Child SAs are also deleted.



 TOC 

5.  IKE and IPsec State After Resumption

During the resumption process, both peers create IKE and IPsec state for the resumed IKE SA. Although the SA is only completed following a successful IKE_AUTH exchange, many of its components are created earlier, notably the SA's crypto material (Section 5.1 (Generating Cryptographic Material for the Resumed IKE SA)).

When a ticket is presented, the gateway needs to obtain the ticket state. In case a ticket by reference was provided by the client, the gateway needs to resolve the reference in order to obtain this state. In case the client has already provided a ticket by value, the gateway can parse the ticket to obtain the state directly. In either case, the gateway needs to process the ticket state in order to restore the state of the old IKE SA, and the client retrieves the same state from its local store.

The following table describes the IKE and IPsec state of the peers after session resumption, and how it is related to their state before the IKE SA was interrupted. When the table mentions that a certain state item is taken "from the ticket", this should be construed as:

State ItemAfter Resumption
IDi From the ticket (but must also be exchanged in IKE_AUTH). See also Note 1
IDr From the ticket (but must also be exchanged in IKE_AUTH)
Authentication method (PKI, pre-shared secret, EAP, PKI-less EAP [I‑D.eronen‑ipsec‑ikev2‑eap‑auth] (Eronen, P., Tschofenig, H., and Y. Sheffer, “An Extension for EAP-Only Authentication in IKEv2,” October 2009.) etc.) From the ticket
Certificates (when applicable) From the ticket, see Note 2
Local IP address/port, peer IP address/port Selected by the client, see Note 3
NAT detection status From new exchange
SPIs From new exchange, see Note 4
Which peer is the "original initiator"? Determined by the initiator of IKE_SESSION_RESUME
IKE SA sequence numbers (Message ID) Reset to 0 in IKE_SESSION_RESUME, and subsequently incremented normally
IKE SA algorithms (SAr) From the ticket
IKE SA keys (SK_*) The old SK_d is obtained from the ticket and all keys are refreshed, see Section 5.1 (Generating Cryptographic Material for the Resumed IKE SA)
IKE SA window size Reset to 1
Child SAs (ESP/AH) Created in new exchange, see Note 6
Internal IP address Not resumed, but see Note 5
Other Configuration Payload information Not resumed
Peer Vendor IDs Not resumed, resent in new exchange if required
Peer supports MOBIKE [RFC4555] (Eronen, P., “IKEv2 Mobility and Multihoming Protocol (MOBIKE),” June 2006.) From new exchange
MOBIKE additional addresses Not resumed, should be resent by client if necessary
Time until re-authentication [RFC4478] (Nir, Y., “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol,” April 2006.) From new exchange (but ticket lifetime is bounded by this duration)
Peer supports redirects [I‑D.ietf‑ipsecme‑ikev2‑redirect] (Devarapalli, V. and K. Weniger, “Redirect Mechanism for IKEv2,” August 2009.) From new exchange

Note 1:
The authenticated peer identity used for policy lookups may not be the same as the IDi payload (see Sec. 3.5 of [RFC4718] (Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” October 2006.)), and if so, MUST be included in the ticket. Note that the client may not have access to this value.
Note 2:
Certificates don't need to be stored if the peer never uses them for anything after the IKE SA is up; however if they are needed, e.g. if exposed to applications via IPsec APIs, they MUST be stored in the ticket.
Note 3:
If the certificate has an iPAddress SubjectAltName, and the implementation requires it to match the peer's source IP address, the same check needs to be performed on session resumption and the required information saved locally or in the ticket.
Note 4:
SPI values of the old SA MAY be stored in the ticket, to help the gateway locate corresponding old IKE state. These values MUST NOT be used for the resumed SA.
Note 5:
The client can request the address it was using earlier, and if possible, the gateway SHOULD honor the request.
Note 6:
Since information about Child SAs and configuration payloads is not resumed, IKEv2 features related to Child SA negotiation (such as IPCOMP_SUPPORTED, ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [I‑D.ietf‑rohc‑ikev2‑extensions‑hcoipsec] (Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, “IKEv2 Extensions to Support Robust Header Compression over IPsec,” February 2010.) and configuration) aren't usually affected by session resumption.

IKEv2 features that affect only the IKE_AUTH exchange (including HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges [RFC4739] (Eronen, P. and J. Korhonen, “Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol,” November 2006.), ECDSA authentication [RFC4754] (Fu, D. and J. Solinas, “IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA),” January 2007.), and OCSP [RFC4806] (Myers, M. and H. Tschofenig, “Online Certificate Status Protocol (OCSP) Extensions to IKEv2,” February 2007.)) don't usually need any state in the IKE SA (after the IKE_AUTH exchanges are done), so resumption doesn't affect them.

New IKEv2 features that are not covered by note 6 or by the previous paragraph should specify how they interact with session resumption.



 TOC 

5.1.  Generating Cryptographic Material for the Resumed IKE SA

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_d_old, "Resumption" | Ni | Nr)

where SK_d_old is taken from the ticket. The literal string is encoded as 10 ASCII characters, with no NULL terminator.

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 

6.  Ticket Handling



 TOC 

6.1.  Ticket Content

When passing a ticket by value to the client, the ticket content MUST be integrity protected and encrypted.

A ticket by reference does not need to be encrypted, as it does not contain any sensitive material, such as keying material. However, access to the storage where that sensitive material is stored MUST be protected so that only authorized access is allowed. We note that such a ticket is analogous to the concept of 'stub', as defined in [I‑D.xu‑ike‑sa‑sync] (Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, “IKEv2 SA Synchronization for session resumption,” October 2008.), or the concept of a Session ID from TLS.

Although not strictly required for cryptographic protection, it is RECOMMENDED to integrity-protect the ticket by reference. Failing to do so could result in various security vulnerabilities on the gateway side, depending on the format of the reference. Potential vulnerabilities include access by the gateway to unintended URLs (similar to cross-site scripting) or SQL injection.

When the state is passed by value, the ticket MUST encode all state information marked "from the ticket" in the table on Section 5 (IKE and IPsec State After Resumption). The same state MUST be stored in the ticket store, in the case of ticket by reference.

A ticket by value MUST include a protected expiration time, which is an absolute time value and SHOULD correspond to the value included in the TICKET_LT_OPAQUE payload.

The ticket by value MUST additionally include a key identity field, so that keys for ticket encryption and authentication can be changed, and when necessary, algorithms can be replaced.



 TOC 

6.2.  Ticket Identity and Lifecycle

Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g. when a user logs out), the ticket MUST be deleted. When the IKE SA is rekeyed the ticket is invalidated, and the client SHOULD request a new ticket. When a client does not follow these rules, it might present an invalid ticket to the gateway. See Section 9.7 (Ticket Revocation) for more about this issue.

The lifetime of the ticket sent by the gateway 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 are enforced by the gateway, a finite lifetime MUST be specified for the ticket.

The key that is used to protect the ticket MUST have a lifetime that is significantly longer than the lifetime of an IKE SA.

In normal operation, the client will request a ticket when establishing the initial IKE SA, and then every time the SA is rekeyed or re-established because of re-authentication.



 TOC 

7.  IKE Notifications

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

Notification NameNumberData
TICKET_LT_OPAQUE TBA1 See Section 7.1 (TICKET_LT_OPAQUE Notify Payload)
TICKET_REQUEST TBA2 None
TICKET_ACK TBA3 None
TICKET_NACK TBA4 None
TICKET_OPAQUE TBA5 See Section 7.2 (TICKET_OPAQUE Notify Payload)

For all these notifications, the Protocol ID and the SPI Size fields MUST both be sent as 0.



 TOC 

7.1.  TICKET_LT_OPAQUE Notify Payload

The data for the TICKET_LT_OPAQUE Notify payload consists of the Notify message header, a Lifetime field and the ticket itself. The four octet Lifetime field contains a relative time value, the number of seconds until the ticket expires (encoded as an unsigned integer).




       0                     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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Payload  !C!  Reserved   !      Payload Length           !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       Lifetime                                !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                        Ticket                                 ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 6: TICKET_LT_OPAQUE Notify Payload 



 TOC 

7.2.  TICKET_OPAQUE Notify Payload

The data for the TICKET_OPAQUE Notify payload consists of the Notify message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE payload, no lifetime value is included in the TICKET_OPAQUE Notify payload.




       0                     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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Payload  !C!  Reserved   !      Payload Length           !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                        Ticket                                 ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 7: TICKET_OPAQUE Notify Payload 



 TOC 

8.  IANA Considerations

Section 4.3.2 (IKE_SESSION_RESUME Exchange) defines a new IKEv2 exchange type, IKE_SESSION_RESUME, whose value is to be allocated (has been allocated) from the "IKEv2 Exchange Types" registry.

Section 7 (IKE Notifications) defines several new IKEv2 notifications whose values are to be allocated (have been allocated) from the "IKEv2 Notify Message Types - Status Types" registry.



 TOC 

9.  Security Considerations

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



 TOC 

9.1.  Stolen Tickets

A man-in-the-middle may try to eavesdrop on an exchange to obtain a ticket by value and use it to establish a session with the IKEv2 responder. Since all exchanges where the client obtains a ticket are encrypted, this is only possible by listening in on a client's use of the ticket to resume a session. However, since the ticket's contents are encrypted and the attacker does not know the corresponding secret key, a stolen ticket cannot be used by an attacker to successfully 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 ticket by reference does not need to be encrypted. When an adversary is able to eavesdrop on a resumption attempt, as described in the previous paragraph, then the ticket by reference may be obtained. A ticket by reference cannot be used by an attacker to successfully resume a session, for the same reasons as for a ticket by value. Moreover, the adversary MUST NOT be able to resolve the ticket via the reference, i.e., access control MUST be enforced to ensure disclosure only to authorized entities.



 TOC 

9.2.  Forged Tickets

A malicious user could forge or alter a ticket by value 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 content of the ticket by value is protected using a strong integrity protection algorithm.

In case of a ticket by reference an adversary may attempt to construct a fake ticket by reference to point to state information stored by the IKEv2 responder. This attack will fail because the adversary is not in possession of the keying material associated with the IKEv2 SA. As noted in Section 6.1 (Ticket Content), it is often useful to integrity-protect the ticket by reference, too.



 TOC 

9.3.  Denial of Service Attacks

An adversary could generate and send a large number of tickets by value 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).

When an adversary chooses to send a large number of tickets by reference then this may lead to an amplification attack as the IKEv2 responder is forced to resolve the reference to a ticket in order to determine that the adversary is not in possession of the keying material corresponding to the stored state or that the reference is void. To minimize this attack, the protocol to resolve the reference should be as lightweight as possible and should not generate a large number of messages.



 TOC 

9.4.  Detecting the Need for Resumption

Detecting when an old IKE SA is no longer usable and needs to be resumed is out of scope of the current document. However, clients are warned against implementing a more liberal policy than that used to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular, untrusted messages MUST NOT be relied upon to make this decision.



 TOC 

9.5.  Key Management for Tickets By Value

A full description of the management of the keys used to protect the ticket by value is beyond the scope of this document. A list of RECOMMENDED practices is given below.



 TOC 

9.6.  Ticket Lifetime

An IKEv2 responder controls the validity period of the state information by attaching a lifetime to a ticket. The chosen lifetime is based on the operational and security requirements of the environment in which this IKEv2 extension is deployed. The responder provides information about the ticket lifetime to the IKEv2 initiator, allowing it to manage its tickets.



 TOC 

9.7.  Ticket Revocation

A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had previously been deleted. This is disallowed by Section 6.2 (Ticket Identity and Lifecycle). This issue is unique to ticket by value cases, since a ticket by reference will have been deleted from the ticket store.

To avoid this issue for ticket by value, an Invalid Ticket List (ITL) may be maintained by the gateway, see [I‑D.rescorla‑stateless‑tokens] (Rescorla, E., “How to Implement Secure (Mostly) Stateless Tokens,” March 2007.). This can be a simple blacklist of revoked tickets. Alternatively, [I‑D.rescorla‑stateless‑tokens] (Rescorla, E., “How to Implement Secure (Mostly) Stateless Tokens,” March 2007.) suggests to use Bloom Filters [Bloom70] (Bloom, B., “Space/time trade-offs in hash coding with allowable errors,” July 1970.) to maintain the list in constant space. 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 issue.



 TOC 

9.8.  Ticket by Value Format

The ticket's format is not defined by this document, since this is not required for interoperability. However great care must be taken when defining a ticket format such that the requirements outlined in Section 6.1 (Ticket Content) are met. The ticket by value MUST have its integrity and confidentiality protected with strong cryptographic techniques to prevent a breach in the security of the system.



 TOC 

9.9.  Identity Privacy, Anonymity, and Unlinkability

Since opaque state information is passed around between the IKEv2 initiator and the IKEv2 responder it is important that leakage of information, such as the identities of an IKEv2 initiator and a responder, MUST be avoided.

When an IKEv2 initiator presents a ticket as part of the IKE_SESSION_RESUME exchange, confidentiality is not provided for the exchange. There is thereby the possibility for an on-path adversary to observe multiple exchange handshakes where the same state information is used and therefore to conclude that they belong to the same communication end points.

This document therefore requires that the ticket be presented to the IKEv2 responder only once; under normal circumstances (e.g. no active attacker), there should be no multiple use of the same ticket.

We are not aware of additional security issues associated with ticket reuse: the protocol guarantees freshness of the generated crypto material even in such cases. As noted in Section 4.3.1 (Prologue), the gateway SHOULD prevent multiple uses of the same ticket. But this is only an extra precaution, to ensure that clients do not implement reuse. In other words, the gateway is not expected to cache old tickets for extended periods of time.



 TOC 

10.  Acknowledgements

We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ Housely, Yoav Nir, Peny Yang, Sean Turner and Tero Kivinen for their comments. We would like to particularly thank Florian Tegeler and Stjepan Gros for their implementation efforts and Florian Tegeler for a formal verification using the Casper tool set.

We would furthermore like to thank the authors of [I‑D.xu‑ike‑sa‑sync] (Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, “IKEv2 SA Synchronization for session resumption,” October 2008.) (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke Xu) for their input on the stub concept.

We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad Muhanna and Stephen Kent for their feedback regarding the ticket by reference concept.

Vidya Narayanan and Lakshminath Dondeti coauthored several past versions of this document, and we acknowledge their significant contribution.



 TOC 

11.  References



 TOC 

11.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 

11.2. Informative References

[Bloom70] Bloom, B., “Space/time trade-offs in hash coding with allowable errors,” Comm. ACM  13(7):422-6, July 1970.
[I-D.eronen-ipsec-ikev2-eap-auth] Eronen, P., Tschofenig, H., and Y. Sheffer, “An Extension for EAP-Only Authentication in IKEv2,” draft-eronen-ipsec-ikev2-eap-auth-07 (work in progress), October 2009 (TXT).
[I-D.ietf-ipsecme-ikev2-redirect] Devarapalli, V. and K. Weniger, “Redirect Mechanism for IKEv2,” draft-ietf-ipsecme-ikev2-redirect-13 (work in progress), August 2009 (TXT).
[I-D.ietf-ipsecme-ikev2bis] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” draft-ietf-ipsecme-ikev2bis-10 (work in progress), April 2010 (TXT).
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, “IKEv2 Extensions to Support Robust Header Compression over IPsec,” draft-ietf-rohc-ikev2-extensions-hcoipsec-12 (work in progress), February 2010 (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.xu-ike-sa-sync] Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, “IKEv2 SA Synchronization for session resumption,” draft-xu-ike-sa-sync-01 (work in progress), October 2008 (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).
[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).
[RFC4739] Eronen, P. and J. Korhonen, “Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol,” RFC 4739, November 2006 (TXT).
[RFC4754] Fu, D. and J. Solinas, “IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA),” RFC 4754, January 2007 (TXT).
[RFC4806] Myers, M. and H. Tschofenig, “Online Certificate Status Protocol (OCSP) Extensions to IKEv2,” RFC 4806, February 2007 (TXT).
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” RFC 5077, January 2008 (TXT).


 TOC 

Appendix A.  Ticket Format

This document does not specify a particular ticket format nor even the suggested contents of a ticket: both are entirely up to the implementer. The formats described in the following sub-sections are provided as useful examples, and implementers are free to adopt them as-is or change them in any way necessary.



 TOC 

A.1.  Example Ticket by Value Format


struct {
    [authenticated] struct {
        octet format_version;    // 1 for this version of the protocol
        octet reserved[3];       // sent as 0, ignored by receiver.
        octet key_id[8];         // arbitrary byte string
        opaque IV[0..255];       // actual length (possibly 0) depends
                                 // on the encryption algorithm

        [encrypted] struct {
            opaque IDi, IDr;     // the full payloads
            octet SPIi[8], SPIr[8];
            opaque SA;           // the full SAr payload
            octet SK_d[0..255];  // actual length depends on SA value
            enum ... authentication_method;
            int32 expiration;    // an absolute time value, seconds
                                 // since Jan. 1, 1970
        } ikev2_state;
    } protected_part;
    opaque MAC[0..255];          // the length (possibly 0) depends
                                 // on the integrity algorithm
} ticket;

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

A.2.  Example Ticket by Reference Format

For implementations that prefer to pass a reference to IKE state in the ticket, rather than the state itself, we suggest the following format:


struct {
      [authenticated] struct {
          octet format_version;  // 1 for this version of the protocol
          octet reserved[3];     // sent as 0, ignored by receiver.
          octet key_id[8];       // arbitrary byte string

          struct {
              opaque state_ref;  // reference to IKE state
              int32 expiration;  // an absolute time value, seconds
                                 // since Jan. 1, 1970
          } ikev2_state_ref;
      } protected_part;
      opaque MAC[0..255];        // the length depends
                                 // on the integrity algorithm
} ticket;



 TOC 

Appendix B.  Change Log

Note to RFC Editor: remove this appendix before publication.



 TOC 

B.1.  -08

Implemented IETF LC, secdir and gen-art comments.



 TOC 

B.2.  -07

Implemented AD Review comments, most of them editorial.



 TOC 

B.3.  -06

Clients resuming propely closed sessions and how this can be avoided.



 TOC 

B.4.  -05

Editorial changes: reordered and merged some sections.

Restated the use cases.

IDr is not negotiated during resumption, the gateway must use the stored IDr.

Multiple small clarifications based on Pasi's LC review.

IPR: pre5378Trust200902.



 TOC 

B.5.  -04

Closed issue #105, Non-PKI use of EAP, and resumption.

Closed issue #106, Resumption and NAT detection and changing ports.



 TOC 

B.6.  -03

Changed the protocol from one to two round trips, to simplify the security assumptions. Eliminated security considerations associated with the previous version.

Closed issue #69, Clarify behavior of SPI and sequence numbers.

Closed issue #70, Ticket lifetime - explicit or not? (and ticket push from gateway).

Closed issue #99, Ticket example: downgrade.

Closed issue #76, IPsec Child SAs during resumption.

Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption.

Closed issue #95, Minor nits for ikev2-resumption-02.

Closed issue #97, Clarify what state comes from where.

Closed issue #98, Replays in 1-RTT protocol.

Closed issue #100, NAT detection [and] IP address change.

Closed issue #101, Assorted issues by Tero.



 TOC 

B.7.  -02

Added a new TICKET_OPAQUE payload that does not have a lifetime field included.

Removed the lifetime usage from the IKE_SESSION_RESUME exchange (utilizing the TICKET_OPAQUE) when presenting the ticket to the gateway.

Removed IDi payloads from the IKE_SESSION_RESUME exchange.

Clarified that IPsec Child SAs would be deleted once the old IKE SA gets deleted as well.

Clarified the behavior of SPI and sequence number usage.



 TOC 

B.8.  -01

Addressed issue#75, see http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included changes throughout the document to ensure that the ticket may contain a reference or a value.



 TOC 

B.9.  -00

Resubmitted document as a WG item.



 TOC 

B.10.  -01

Added reference to [I‑D.xu‑ike‑sa‑sync] (Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, “IKEv2 SA Synchronization for session resumption,” October 2008.)

Included recommended ticket format into the appendix

Various editorial improvements within the document



 TOC 

B.11.  -00

Issued a -00 version for the IPSECME working group. Reflected discussions at IETF#72 regarding the strict focus on session resumption. Consequently, text about failover was removed.



 TOC 

B.12.  -04

Editorial fixes; references cleaned up; updated author's contact address



 TOC 

B.13.  -03

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.



 TOC 

B.14.  -02

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.



 TOC 

B.15.  -01

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



 TOC 

B.16.  -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
  Linnoitustie 6
  Espoo 02600
  Finland
Phone:  +358 (50) 4871445
Email:  Hannes.Tschofenig@gmx.net
URI:  http://www.tschofenig.priv.at