Network Working Group                                         Y. Sheffer
Internet-Draft                                               Check Point
Intended status: Standards Track                           H. Tschofenig
Expires: November 16, December 18, 2009                        Nokia Siemens Networks
                                                              L. Dondeti
                                                            V. Narayanan
                                                          QUALCOMM, Inc.
                                                            May 15,
                                                           June 16, 2009

                        IKEv2 Session Resumption
               draft-ietf-ipsecme-ikev2-resumption-04.txt
               draft-ietf-ipsecme-ikev2-resumption-05.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 November 16, December 18, 2009.

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 requires passing encodes partial IKE state into an opaque data from the IKEv2
   responder to the IKEv2 initiator,
   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. 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
   recommendations examples are provided.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Details Sequences . . . . . . . . . . . . . . . . . . . . . . .  7  8
     4.1.  Requesting a Ticket  . . . . . . . . . . . . . . . . . . .  7  8
     4.2.  Receiving a Ticket . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Presenting a Ticket  . . . . . . . . . . . . . . . . . . .  9
     4.4.  IKE_SESSION_RESUME Details . . . . . . . . . 10
       4.3.1.  Prologue . . . . . . . 11
     4.5.  Requesting a Ticket During Resumption . . . . . . . . . . 11
     4.6.  IP Address Change and NAT . . . . . . 10
       4.3.2.  IKE_SESSION_RESUME Exchange  . . . . . . . . . . 11
     4.7.  IKE Notifications . . . 10
       4.3.3.  IKE_AUTH Exchange  . . . . . . . . . . . . . . . . . 11
       4.7.1.  TICKET_LT_OPAQUE Notify Payload . 12
       4.3.4.  Epilogue . . . . . . . . . . 12
       4.7.2.  TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12
     4.8.  Computing the AUTH Payload . . .
   5.  IKE and IPsec State After Resumption . . . . . . . . . . . . . 13
   5.  Processing Guidelines
     5.1.  Generating Cryptographic Material for the Resumed IKE
           SA Establishment . . . . . . . . 13
   6.  The State After Resumption . . . . . . . . . . . . . . . . . . 14
   7. . . 15
   6.  Ticket Handling  . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.
     6.1.  Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.
     6.2.  Ticket Identity and Lifecycle  . . . . . . . . . . . . . . 17
   8.  IANA Considerations
   7.  IKE Notifications  . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations
     7.1.  TICKET_LT_OPAQUE Notify Payload  . . . . . . . . . . . . . 17
     7.2.  TICKET_OPAQUE Notify Payload . . . . . . 18
     9.1.  Stolen Tickets . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . 18
     9.2.  Forged Tickets . . . . . . . . 18
   9.  Security Considerations  . . . . . . . . . . . . . . 18
     9.3.  Denial of Service Attacks . . . . . 19
     9.1.  Stolen Tickets . . . . . . . . . . . 18
     9.4.  Key Management for Tickets By Value . . . . . . . . . . . 19
     9.5.  Ticket Lifetime  . . . .
     9.2.  Forged Tickets . . . . . . . . . . . . . . . . . 19
     9.6.  Ticket by Value Format . . . . . 19
     9.3.  Denial of Service Attacks  . . . . . . . . . . . . . 19 . . . 20
     9.4.  Key Management for Tickets By Value  . . . . . . . . . . . 20
     9.5.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 20
     9.6.  Ticket by Value Format . . . . . . . . . . . . . . . . . . 20
     9.7.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 20 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 21
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 21
     11.2. Informative References . . . . . . . . . . . . . . . . . . 21 22
   Appendix A.  Ticket Format . . . . . . . . . . . . . . . . . . . . 22 23
     A.1.  Example Ticket by Value Format . . . . . . . . . . . . . . 22 23
     A.2.  Example Ticket by Reference Format . . . . . . . . . . . . 23 24
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 24 25
     B.1.  -04  -05  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 25
     B.2.  -03  -04  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 25
     B.3.  -02  -03  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     B.4.  -01  -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26
     B.5.  -00  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26
     B.6.  -01  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26
     B.7.  -00  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 27
     B.8.  -04  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
     B.9.  -03  -04  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
     B.10. -02 -03  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
     B.11. -01 -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
     B.12. -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     B.13. -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 28

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.

   A client can reconnect to a gateway from which it was disconnected.
   One way to ensure that the IKEv2 responder is able to recreate the
   state information is by maintaining IKEv2 state (or a reference into
   a state store) in a "ticket", an opaque data structure.  This ticket
   is created by the server gateway and forwarded to the client, or
   alternatively, is stored centrally and a reference to it is forwarded
   to the client.  The IKEv2 protocol is extended to allow a client to
   request and present a ticket.  This document does not mandate the
   format of the ticket
   structure but a recommendation is provided. structure.  In Appendix A a ticket by value and
   a ticket by reference format is proposed.

   This approach is similar to the one taken by TLS session resumption
   [RFC5077] 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:

   o  Using only symmetric cryptography to minimize CPU consumption.
   o  Providing cryptographic agility.
   o  Having no negative impact on IKEv2 security features.

   The following are non-goals of this solution:
   o  Failover from one gateway to another.  This use case may be added
      in a future specification.

   o  Providing load balancing among gateways.
   o  Specifying how a client detects the need for resumption.

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

   This document uses terminology defined in [RFC4301] and [RFC4306].
   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.

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], 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]) 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).

4.  Protocol Details

   This section provides protocol details and contains

   For either of the normative
   parts.  This document defines two protocol exchanges, namely
   requesting a ticket, see Section 4.1, and presenting a ticket, see
   Section 4.3.

4.1.  Requesting a Ticket

   A client MAY request a ticket above use cases, there are multiple possible
   situations where the mechanism specified in this document could be
   useful.  These include the following exchanges:

   o  In (note that this list is not
   meant to be exhaustive, and any particular deployment may not care
   about all of these):

   o  If a client temporarily loses network connectivity (and the IKE SA
      times out through the livensss test facility, a.k.a. "dead peer
      detection"), this mechanism could be used to re-establish the SA
      with less overhead (network, CPU, authentication infrastructure)
      and without requiring user interaction for authentication.
   o  If the connectivity problems affect a large number of clients
      (e.g., a large remote access VPN gateway), when the connectivity
      is restored, all the clients might reconnect almost
      simultaneously.  This mechanism could be used to reduce the load
      spike for cryptographic operations and authentication
      infrastructure.
   o  Losing connectivity can also be predictable and planned; for
      example, putting a laptop to "stand-by" mode before travelling.
      This mechanism could be used to re-establish the SA when the
      laptop is switched back on (again, with less overhead and without
      requiring user interaction for authentication).  However such
      user-level "resumption" may often be disallowed by policy.

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, and presenting a ticket, see
   Section 4.3.

4.1.  Requesting a Ticket

   A client MAY request a ticket in the following exchanges:

   o  In an IKE_AUTH exchange, as shown in the example message exchange
      in Figure 2 below.
   o  In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only
      when this exchange is initiated by the client).
   o  In an Informational exchange at any time, e.g. if the gateway
      previously replied with an N(TICKET_ACK) instead of providing a
      ticket, or when the ticket lifetime is about to expire. expire, or
      following a gateway-initiated IKE rekey.  All such Informational
      exchanges MUST be initiated by the client.
   o  While resuming an IKE session, i.e. in the IKE_AUTH exchange that
      follows an IKE_SESSION_RESUME exchange, see Section 4.5. 4.3.3.

   Normally, a client requests a ticket in the third message of an IKEv2
   exchange (the first of IKE_AUTH).  Figure 2 shows the message
   exchange for this typical case.

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

                        <--    HDR, SAr1, KEr, Nr, [CERTREQ] 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 4.7. 7.  The above is
   an example, and IKEv2 allows a number of variants on these messages.
   Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] 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:
   o  it creates a ticket and returns it with the N(TICKET_LT_OPAQUE)
      payload in a subsequent message towards the IKEv2 initiator.  This
      is shown in Figure 3.
   o  it returns an N(TICKET_NACK) payload, if it refuses to grant a
      ticket for some reason.
   o  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.
   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.

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

4.3.  Presenting a Ticket

   A client MAY initiate a regular (non-ticket-based) IKEv2 exchange
   even if it is in possession of a valid ticket.  Note that

   When the client
   can only judge validity accepts the ticket, it stores it in its local storage
   for later use, along with the sense of IKE SA that the ticket lifetime.  A
   client MUST NOT present a ticket when it knows that refers to.

   Since the ticket's
   lifetime has expired.

   It ticket itself is up to the client's local policy opaque to decide when the
   communication with client, the IKEv2 responder is seen local storage
   MUST also include all items marked as interrupted and "from the
   session resumption procedure ticket" in the table
   of Section 5.

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.

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.

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.

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

   o  If it is willing to accept the ticket, it responds as shown in
      Figure 4. 5.
   o  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.

     Initiator                Responder
    -----------              -----------
                    <--  HDR, Nr [,N+]

               Figure 4: 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 random value .

   At this point the client MUST initiate an IKE_AUTH exchange, as per
   [RFC4306].  See Section 4.8 for guidelines on computing the AUTH
   payloads.  The IDi value sent in this exchange MUST be identical to
   the value included in the ticket.  Following this exchange, a new IKE
   SA is created by both parties, see Section 5, and a child SA is
   derived, per Section 2.17 of [RFC4306].

   When the responder receives a ticket for an IKE SA that is still
   active and if the responder accepts it, then the old SA SHOULD be
   silently deleted without sending a DELETE informational exchange.
   Consequently, all the dependent IPsec child SAs are also deleted.
   This happens after both peers have been authenticated.

4.4.  IKE_SESSION_RESUME Details

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

   o  The first message may be rejected in denial of service situations,
      with the initiator instructed to send a cookie.
   o  Notifications normally associated with IKE_SA_INIT can be sent.
      In particular, NAT detection payloads.
   o  The SPI values and Message ID fields behave similarly to
      IKE_SA_INIT.
   o  NAT may be detected during the IKE_SESSION_RESUME exchange, in
      which case the initiator switches to UDP encapsulation to port
      4500, as per [RFC4306], Sec. 2.23.

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

   The returned ticket (if any) will correspond to the IKE SA created
   per the rules described in Section 5.

4.6.  IP Address Change and NAT

   The client MAY resume client MAY resume the IKE exchange from an any IP address different
   from and
      port, regardless of its original address.  The gateway MAY reject
      the resumed exchange if its policy depends on the client's address
      (although this rarely makes sense).
   o  The first message may be rejected in denial of service situations,
      with the initiator instructed to send a cookie.
   o  Notifications normally associated with IKE_SA_INIT can be sent.
      In particular, NAT detection payloads.
   o  The client's NAT traversal status SHOULD be determined anew upon
   session resumption, by using in
      IKE_SESSION_RESUME.  If NAT is detected, the appropriate notifications.  This initiator switches to
      UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23.  NAT
      status is explicitly not part of the session resumption state.

   See also Section 4.4 for related details.

4.7.
   o  The SPI values and Message ID fields behave similarly to
      IKE_SA_INIT.

   Although the IKE Notifications

   This document defines a number SA is not fully valid until the completion of notifications.  The notification
   numbers the
   IKE_AUTH exchange, the peers must create much of the SA state
   (Section 5) now.  Specifically, the SK_xx values are TBA by IANA.

            +-------------------+--------+-------------------+
            | Notification Name | Number | Data              |
            +-------------------+--------+-------------------+
            | TICKET_LT_OPAQUE  | TBA1   | See Section 4.7.1 |
            | TICKET_REQUEST    | TBA2   | None              |
            | TICKET_ACK        | TBA3   | None              |
            | TICKET_NACK       | TBA4   | None              |
            | TICKET_OPAQUE     | TBA5   | See Section 4.7.2 |
            +-------------------+--------+-------------------+

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

4.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 5: TICKET_LT_OPAQUE Notify Payload

4.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 6: TICKET_OPAQUE Notify Payload

4.8.  Computing required to
   protect the AUTH Payload IKE_AUTH payloads.

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].
   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, as shown below: authentication:

            AUTH = prf(SK_px, <msg <message octets>)

   Each of the initiator and responder uses its own SK_p value, taken
   from the newly generated IKE SA, Section 5. 5.1.

   The exact material to be signed is defined in Section 2.15 of
   [RFC4306].

   The notation "IDr'" IDi value sent in RFC 4306 should the IKE_AUTH exchange MUST be applied identical to the
   new IDr
   value included in the ticket.  A CERT payload MUST NOT be included in
   this exchange, rather than the and therefore a new IDr value in the
   ticket.

5.  Processing Guidelines for IKE SA Establishment

   When cannot be negotiated
   (since it would not be authenticated).  As a ticket is presented, result, the gateway needs to obtain IDr value
   sent (by the ticket
   state.  In case a ticket by reference was provided gateway, and optionally by the client, the
   gateway needs client) in this exchange
   MUST also be identical to resolve the reference value included in order to obtain this state.
   In case the ticket.

   When resuming a session, a client has already provided will typically request a new ticket per value, the
   gateway can parse the ticket to obtain the state directly.  In either
   case, the gateway needs
   immediately, so that it is able to process resume the ticket state session again in order to
   restore the state
   case of the old IKE SA, a second failure.  The N(TICKET_REQUEST) and
   N(TICKET_LT_OPAQUE) notifications will be included in the client retrieves the
   same state from its local store.  Both peers now create state for the
   new IKE SA as follows:

   o  The SA value (transforms etc.) is taken directly from IKE_AUTH
   exchange that follows the ticket.

   o  The Message ID values are reset IKE_SESSION_RESUME exchange, with similar
   behavior to 0 in IKE_SESSION_RESUME, and
      subsequently incremented normally.
   o  The IDi value is obtained from the ticket.
   o a ticket request during a regular IKE exchange,
   Section 4.1.  The IDr value is obtained from returned ticket (if any) will correspond to the new exchange.  The gateway MAY
      make policy decisions based on IKE
   SA created per the IDr value encoded rules described in Section 5.

4.3.4.  Epilogue

   Following the
      ticket.
   o  The SPI values are IKE_AUTH exchange, a new IKE SA is created anew during IKE_SESSION_RESUME,
      similarly to by both
   parties, see Section 5, and a regular IKE_SA_INIT exchange.  SPI values from child SA is derived, per Section 2.17
   of [RFC4306].

   When the responder receives a ticket MUST NOT be reused, for an IKE SA that is still
   active and they are sent merely to help if the
      gateway to locate responder accepts it (i.e. following successful
   completion of the old state.  The restriction on SPI reuse is
      to avoid problems caused by collisions with other SPI values used
      already by IKE_AUTH exchange), the initiator/responder.

   The cryptographic material is refreshed based on old SA SHOULD be silently
   deleted without sending a DELETE informational exchange.
   Consequently, all the ticket dependent IPsec child SAs are also deleted.

5.  IKE and IPsec State After Resumption

   During the
   nonce values, Ni, resumption process, both peers create IKE and Nr, from IPsec state
   for 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 resumed IKE SA.  Although the ticket.  The literal string SA 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 only completed following
   a successful IKE_AUTH exchange, many of its components are the SPI values created
   earlier, notably the SA's crypto material (Section 5.1).

   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 new IKE exchange.

   See [RFC4306] for client has already provided a ticket by value, the notation. "prf" is determined from
   gateway can parse the SA value ticket to obtain the state directly.  In either
   case, the gateway needs to process the ticket state in order to
   restore the ticket.

6.  The State After Resumption state of the old IKE SA, and the client retrieves the
   same state from its local store.

   The following table, compiled by Pasi Eronen, 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:
   o  The client retrieves this item from its local store.
   o  In the case of ticket by value, the gateway encodes this
      information in the ticket.
   o  In the case of ticket by reference, the gateway fetches this
      information from the ticket store.

   +--------------------------------------+----------------------------+

   +------------------------------------+------------------------------+
   | State Item                         | After Resumption             |
   +--------------------------------------+----------------------------+
   +------------------------------------+------------------------------+
   | IDi                                | From the ticket (but must    |
   |                                    | also be exchanged in         |
   |                                    | IKE_AUTH) IKE_AUTH).  See also Note 1  |
   | IDr                                | From the new exchange ticket (but must    |
   |                                    | old value included also be exchanged in the         |
   |                                    | ticket) IKE_AUTH)                    |
   | Authentication method (PKI,        | From the ticket              |
   | pre-shared secret, EAP, PKI-less   |                              |
   | EAP                                |                              |
   | [I-D.eronen-ipsec-ikev2-eap-auth]  |                              |
   | etc.)                              |                              |
   | Certificates (when applicable)     | Unspecified, From the ticket, see note 1 Note 2  |
   | Local IP address/port, peer IP     | Selected by the client, see  |
   | address/port                       | see note 2 Note 3                       |
   | NAT detection status               | From new exchange            |
   | SPIs                               | From new exchange exchange, see Note  |
   |                                    | 4                            |
   | Which peer is the "original        | Determined by the initiator  |
   | initiator"?                        | initiator of               |
   |                                      | IKE_SESSION_RESUME        |
   | IKE SA sequence numbers (Message ID)   | Start from Reset to 0 in                |
   | ID)                                | 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, ticket and all keys |
   |                                    | others are refreshed refreshed, see           |
   |                                    | Section 5.1                  |
   | IKE SA window size                 | Reset to 1                   |
   | Child SAs (ESP/AH)                 | Created in new exchange, see |
   |                                    | see note 5 Note 7                       |
   | Internal IP address                | Not resumed, but see note  |
   |                                      | 3 Note 5  |
   | Other Configuration Payload        | Not resumed                  |
   | information                        |                              |
   | Peer vendor IDs                    | Unspecified (needed in the Implementation specific      |
   |                                    | (needed in the ticket only if   |
   |                                    | if vendor-specific state is  |
   |                                    | required)                    |
   | Peer supports MOBIKE [RFC4555]     | From new exchange            |
   | MOBIKE additional addresses        | Not resumed, should be       |
   |                                    | resent by client if          |
   |                                    | necessary                    |
   | Time until re-authentication       | From new exchange (but       |
   | [RFC4478]                          | ticket lifetime is bounded   |
   |                                    | by this duration)          |
   | Peer supports redirects              | From new exchange          |
   | [I-D.ietf-ipsecme-ikev2-redirect]    |                            |
   +--------------------------------------+----------------------------+ duration)            |
   | Peer supports redirects            | From new exchange            |
   | [I-D.ietf-ipsecme-ikev2-redirect]  |                              |
   +------------------------------------+------------------------------+

   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]), and if so, MUST be included in the ticket.  Note
            that the client may not have access to this value.
   Note 1: 2:  Certificates don't need to be stored if the peer never uses
            them for anything after the IKE SA is up (but would be
            needed up; however if they
            are needed, e.g. if exposed to applications via IPsec APIs). APIs,
            they MUST be stored in the ticket.
   Note 2: 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 3: 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 4: 6:  IKEv2 features that affect only the IKE_AUTH exchange
            (including HTTP_CERT_LOOKUP_SUPPORTED, multiple
            authentication exchanges [RFC4739], ECDSA authentication
            [RFC4754], and OCSP [RFC4806]) don't usually need any state
            in the IKE SA (after the IKE_AUTH exchanges are done), so
            resumption doesn't affect them.
   Note 5: 7:  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] and configuration
            aren't usually affected by session resumption.
   Note 6: 8:  New IKEv2 features that are not covered by notes 4 6 and 5 7
            should specify how they interact with session resumption.

7.

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] for the notation. "prf" is determined from the SA value
   in the ticket.

6.  Ticket Handling

7.1.

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 unauthorized access is not allowed.  We note
   that such a ticket is analogous to the concept of 'stub', as defined
   in [I-D.xu-ike-sa-sync], 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 at least
   the following all state from an IKE SA.
   information marked "from the ticket" in the table on Section 5.  The
   same state MUST be stored in the ticket store, in the case of ticket by reference.

   o  IDi, IDr.
   o  SPIi, SPIr.
   o  SAr (the accepted proposal).
   o  The authentication method used.
   o  SK_d. 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.

7.2.

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

   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].  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 then every time the SA is
   rekeyed or re-established because of re-authentication.

7.  IKE Notifications

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

             +-------------------+--------+-----------------+
             | Notification Name | Number | Data            |
             +-------------------+--------+-----------------+
             | TICKET_LT_OPAQUE  | TBA1   | See Section 7.1 |
             | TICKET_REQUEST    | TBA2   | None            |
             | TICKET_ACK        | TBA3   | None            |
             | TICKET_NACK       | TBA4   | None            |
             | TICKET_OPAQUE     | TBA5   | See Section 7.2 |
             +-------------------+--------+-----------------+

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

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

7.2.  TICKET_OPAQUE Notify Payload

   The data for the TICKET_OPAQUE Notify payload consists of the Notify
   message header, and the SA ticket itself.  Unlike the TICKET_LT_OPAQUE
   payload no lifetime value is
   rekeyed or re-established because of re-authentication. 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

8.  IANA Considerations

   This document requires a number of IKEv2 notification status types in
   Section 4.7, 7, to be registered by IANA.  The "IKEv2 Notify Message Types
   - Status Types" registry was established by IANA.

   The document defines a new IKEv2 exchange in Section 4.3.  The
   corresponding registry was established by IANA.

9.  Security Considerations

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

9.1.  Stolen Tickets

   An

   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.  This can happen in different ways: by eavesdropping on
   the initial communication and copying  Since all exchanges where the client obtains a ticket when it is granted
   and before it are
   encrypted, this is used, or only possible by listening in on a client's use of
   the ticket to resume a session.  However, since the ticket's contents is
   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 an exchange, 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.

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 7.1, 6.1, it is often useful to
   integrity-protect the ticket by reference, too.

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.

9.4.  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.
   o  The keys should be generated securely following the randomness
      recommendations in [RFC4086].
   o  The keys and cryptographic protection algorithms should be at
      least 128 bits in strength.
   o  The keys should not be used for any other purpose than generating
      and verifying tickets.
   o  The keys should be changed regularly.
   o  The keys should be changed if the ticket format or cryptographic
      protection algorithms change.

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

9.6.  Ticket by Value Format

   Great

   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 7.1 6.1 are met.  In particular, if
   confidential information, such as a secret key, is transferred to the
   client it MUST be done using channel security to prevent attackers
   from obtaining or modifying the ticket.  Also, the  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.

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

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 and Tero Kivinen for their comments.  We would like
   to particularly thank Florian Tegeler and Stjepan Gros for their help
   with their
   implementation efforts and Florian Tegeler for his a formal verification
   using the CASPER Casper tool set.

   We would furthermore like to thank the authors of
   [I-D.xu-ike-sa-sync](Yan
   [I-D.xu-ike-sa-sync] (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.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

11.2.  Informative References

   [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-06 (work in progress),
              April 2009.

   [I-D.ietf-ipsecme-ikev2-redirect]
              Devarapalli, V. and K. Weniger, "Redirect Mechanism for
              IKEv2", draft-ietf-ipsecme-ikev2-redirect-09 draft-ietf-ipsecme-ikev2-redirect-10 (work in
              progress), May 2009.

   [I-D.ietf-ipsecme-ikev2bis]
              Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol: IKEv2",
              draft-ietf-ipsecme-ikev2bis-03 (work in progress),
              April 2009.

   [I-D.ietf-rohc-ikev2-extensions-hcoipsec]
              Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and
              C. Bormann, "IKEv2 Extensions to Support Robust Header
              Compression over IPsec  (ROHCoIPsec)",
              draft-ietf-rohc-ikev2-extensions-hcoipsec-08 (work in
              progress), February 2009.

   [I-D.rescorla-stateless-tokens]
              Rescorla, E., "How to Implement Secure (Mostly) Stateless
              Tokens", draft-rescorla-stateless-tokens-01 (work in
              progress), March 2007.

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

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4478]  Nir, Y., "Repeated Authentication in Internet Key Exchange
              (IKEv2) Protocol", RFC 4478, April 2006.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
              Implementation Guidelines", RFC 4718, October 2006.

   [RFC4739]  Eronen, P. and J. Korhonen, "Multiple Authentication
              Exchanges in the Internet Key Exchange (IKEv2) Protocol",
              RFC 4739, November 2006.

   [RFC4754]  Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
              the Elliptic Curve Digital Signature Algorithm (ECDSA)",
              RFC 4754, January 2007.

   [RFC4806]  Myers, M. and H. Tschofenig, "Online Certificate Status
              Protocol (OCSP) Extensions to IKEv2", RFC 4806,
              February 2007.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

Appendix A.  Ticket Format

   This document does not specify a mandatory-to-implement or a
   mandatory-to-use ticket format.  The formats described in the
   following sub-sections are provided as useful examples.

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] that
   recommends a similar (but not identical) ticket format, and discusses
   related security considerations in depth.

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;

Appendix B.  Change Log

   Note to RFC Editor: remove this appendix before publication.

B.1.  -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.

B.2.  -04

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

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

B.2.

B.3.  -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.

B.3.

B.4.  -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.

B.4.

B.5.  -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.

B.5.

B.6.  -00

   Resubmitted document as a WG item.

B.6.

B.7.  -01

   Added reference to [I-D.xu-ike-sa-sync]

   Included recommended ticket format into the appendix

   Various editorial improvements within the document

B.7.

B.8.  -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.

B.8.

B.9.  -04

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

B.9.

B.10.  -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.

B.10.

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

B.11.

B.12.  -01

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

B.12.

B.13.  -00

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

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

   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