Network Working Group                                         Y. Sheffer
Internet-Draft                                               Check Point
Intended status: Standards Track                           H. Tschofenig
Expires: July 28, 2009                            Nokia Siemens Networks
                                                              L. Dondeti
                                                            V. Narayanan
                                                          QUALCOMM, Inc.
                                                        January 24, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on July 28, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.




Sheffer, et al.           Expires July 28, 2009                 [Page 1]


Internet-Draft          IKEv2 Session Resumption            January 2009


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 opaque data from the IKEv2
   responder to the IKEv2 initiator, which 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
   recommendations are provided.























Sheffer, et al.           Expires July 28, 2009                 [Page 2]


Internet-Draft          IKEv2 Session Resumption            January 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Requesting a Ticket  . . . . . . . . . . . . . . . . . . .  7
     4.2.  Presenting a Ticket  . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  Protection of the IKE_SESSION_RESUME Exchange  . . . . 10
       4.2.2.  Presenting a Ticket: The DoS Case  . . . . . . . . . . 10
       4.2.3.  Requesting a ticket during resumption  . . . . . . . . 11
     4.3.  IKE Notifications  . . . . . . . . . . . . . . . . . . . . 11
     4.4.  TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11
     4.5.  Processing Guidelines for IKE SA Establishment . . . . . . 12
   5.  Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Ticket Identity and Lifecycle  . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     7.1.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14
     7.3.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 14
     7.4.  Key Management for Tickets By Value  . . . . . . . . . . . 15
     7.5.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 15
     7.6.  Ticket by Value Format . . . . . . . . . . . . . . . . . . 15
     7.7.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 16
     7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Ticket Format . . . . . . . . . . . . . . . . . . . . 18
     A.1.  Recommended Ticket by Value Format . . . . . . . . . . . . 18
     A.2.  Recommended Ticket by Reference Format . . . . . . . . . . 19
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 19
     B.1.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     B.2.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     B.3.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     B.4.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.5.  -04  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.6.  -03  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.7.  -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.8.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.9.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20






Sheffer, et al.           Expires July 28, 2009                 [Page 3]


Internet-Draft          IKEv2 Session Resumption            January 2009


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.

   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 and 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.  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  Allowing a gateway to push state to clients.
   o  Providing cryptographic agility.
   o  Having no negative impact on IKEv2 security features.

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






Sheffer, et al.           Expires July 28, 2009                 [Page 4]


Internet-Draft          IKEv2 Session Resumption            January 2009


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], [RFC4306], and
   [RFC4555].  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.

   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.
















Sheffer, et al.           Expires July 28, 2009                 [Page 5]


Internet-Draft          IKEv2 Session Resumption            January 2009


    (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 this scenario, 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).

   In this scenario, the client needs to get an IP address from the
   remote network so that traffic can be encapsulated by the remote
   access gateway before reaching the client.  In the initial exchange,
   the gateway may acquire IP addresses from the address pool of a local
   DHCP server.  The session resumption exchange may need to support the
   assignment of a new IP address.

   The protocol defined in this document supports the re-allocation of
   an IP address to the client, if this capability is provided by the
   network.  This capability is implicit in the use of the IKE
   configuration mechanism, which allows the client to present its
   existing IP address and receive the same address back, if allowed by
   the gateway.





Sheffer, et al.           Expires July 28, 2009                 [Page 6]


Internet-Draft          IKEv2 Session Resumption            January 2009


4.  Protocol Details

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

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.
   o  In an Informational exchange, if the gateway previously replied
      with an N(TICKET_ACK) instead of providing a ticket.
   o  In an Informational exchange, when the ticket lifetime is about to
      expire.
   o  In an IKE_SESSION_RESUME exchange, see Section 4.2.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]

    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.3.  The above is
   an example, and IKEv2 allows a number of variants on these messages.
   A complete description of IKEv2 can be found in [RFC4718].

   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_OPAQUE)
      payload in a subsequent message towards the IKEv2 initiator.  This
      is shown in Figure 3.




Sheffer, et al.           Expires July 28, 2009                 [Page 7]


Internet-Draft          IKEv2 Session Resumption            January 2009


   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.

   Provided the IKEv2 exchange was successful, the IKEv2 initiator can
   accept the requested ticket.  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_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}


                       Figure 3: Receiving a Ticket

4.2.  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 the client
   can only judge validity in the sense of the ticket lifetime.  A
   client MUST NOT present a ticket when it knows that the ticket's
   lifetime has expired.

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

   Tickets are intended for one-time use: a client MUST NOT reuse a
   ticket, either with the same or with a different gateway.  A gateway
   SHOULD reject a reused ticket.

   This document specifies a new IKEv2 exchange type called
   IKE_SESSION_RESUME whose value is TBA by IANA.  This exchange is
   somewhat similar to the IKE_AUTH exchange, and results in the
   creation of a Child SA.  The client SHOULD NOT use this exchange type
   unless it knows that the gateway supports it.







Sheffer, et al.           Expires July 28, 2009                 [Page 8]


Internet-Draft          IKEv2 Session Resumption            January 2009


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

   The exchange type in HDR is set to 'IKE_SESSION_RESUME'.  The value
   of the Lifetime field in the TICKET_OPAQUE payload is set to the
   value that was received when requesting the ticket.

   See Section 4.2.1 for details on computing the protected (SK)
   payload.

   When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
   payload it MUST perform one of the following steps if it supports the
   extension defined in this document:
   o  If it is willing to accept the ticket, it responds as shown in
      Figure 4.
   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.
   o  When the responder receives a ticket for an IKE SA that is still
      active and if the responder accepts it, then the old SAs SHOULD be
      silently deleted without sending a DELETE informational exchange.



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

               Figure 4: IKEv2 Responder accepts the ticket

   Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.

   The SK payload is protected using the cryptographic parameters
   derived from the ticket, see Section 4.2.1 below.

   At this point a new IKE SA is created by both parties, see
   Section 4.5.  This is followed by normal derivation of a child SA,
   per Section 2.17 of [RFC4306].





Sheffer, et al.           Expires July 28, 2009                 [Page 9]


Internet-Draft          IKEv2 Session Resumption            January 2009


4.2.1.  Protection of the IKE_SESSION_RESUME Exchange

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


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

   where SK_d_old is the SK_d value of the original IKE SA, as retrieved
   from the ticket.  Ni guarantees freshness of the key material.  SK_d2
   is used later to derive the new IKE SA, see Section 4.5.

   See [RFC4306] for the notation. "prf" is determined from the SA value
   in the ticket.

4.2.2.  Presenting a Ticket: The DoS Case

   When receiving the first message of the IKE_SESSION_RESUME exchange,
   the gateway may decide that it is under a denial-of-service attack.
   In such a case, the gateway SHOULD defer the establishment of session
   state until it has verified the identity of the client.  We use a
   variation of the IKEv2 Cookie mechanism, whereby the cookie is
   protected.

   In the two messages that follow, the gateway responds that it is
   unwilling to resume the session until the client is verified, and the
   client resubmits its first message, this time with the cookie:



  Initiator                Responder
  -----------              -----------
                  <-- HDR, SK{N(COOKIE)}

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

   Assuming the cookie is correct, the gateway now replies normally.

   This now becomes a 4-message exchange.  The entire exchange is
   protected as defined in Section 4.2.1.

   See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance
   regarding the usage and syntax of the cookie.  Note that the cookie
   is completely independent of the IKEv2 ticket.






Sheffer, et al.           Expires July 28, 2009                [Page 10]


Internet-Draft          IKEv2 Session Resumption            January 2009


4.2.3.  Requesting a ticket during resumption

   When resuming a session, a client will typically request a new ticket
   immediately, so it is able to resume the session again in the case of
   a second failure.  Therefore, the N(TICKET_REQUEST) and
   N(TICKET_OPAQUE) notifications may be piggybacked as protected
   payloads to the IKE_SESSION_RESUME exchange.

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

4.3.  IKE Notifications

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

             +-------------------+--------+-----------------+
             | Notification Name | Number | Data            |
             +-------------------+--------+-----------------+
             | TICKET_OPAQUE     | TBA1   | See Section 4.4 |
             | TICKET_REQUEST    | TBA2   | None            |
             | TICKET_ACK        | TBA3   | None            |
             | TICKET_NACK       | TBA4   | None            |
             +-------------------+--------+-----------------+

4.4.  TICKET_OPAQUE Notify Payload

   The data for the TICKET_OPAQUE Notify payload consists of the Notify
   message header, a lifetime field and the ticket itself.  The four
   octet lifetime field contains the number of seconds until the ticket
   expires (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                                 ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Sheffer, et al.           Expires July 28, 2009                [Page 11]


Internet-Draft          IKEv2 Session Resumption            January 2009


                  Figure 5: TICKET_OPAQUE Notify Payload

4.5.  Processing Guidelines for IKE SA Establishment

   When a ticket is presented, the gateway needs to obtain the ticket
   per value.  In case a ticket by reference was provided by the client
   the gateway needs to resolve the reference in order to obtain the
   ticket by value.  In case the client has already provided the ticket
   per value it can parses the ticket.  In either case, the gateway
   needs to process the ticket by value in order to restore the state of
   the old IKE SA, and the client retrieves this state from its local
   store.  Both peers now create state for the new IKE SA as follows:

   o  The SA value (transforms etc.) is taken directly from the ticket.
   o  The sequence numbers are reset to 0.
   o  The IDi value is obtained from the ticket.
   o  The IDr value is obtained from the new exchange.  The gateway MAY
      make policy decisions based on the IDr value encoded in the
      ticket.
   o  The SPI values are created anew, similarly to a regular IKE
      exchange.  SPI values from the ticket SHOULD NOT be reused.  This
      restriction is to avoid problems caused by collisions with other
      SPI values used already by the initiator/responder.  The SPI value
      should only be reused if collision avoidance can be ensured
      through other means.

   The cryptographic material is refreshed based on the ticket and the
   nonce values, Ni, and Nr, from the current exchange.  A new SKEYSEED
   value is derived as follows:


        SKEYSEED = prf(SK_d2, Ni | Nr)

   where SK_d2 was computed earlier (Section 4.2.1).

   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.






Sheffer, et al.           Expires July 28, 2009                [Page 12]


Internet-Draft          IKEv2 Session Resumption            January 2009


5.  Ticket Recommendations

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

   When the state is passed by value, the ticket MUST encode at least
   the following state from an IKE SA.

   o  IDi, IDr.
   o  SPIi, SPIr.
   o  SAr (the accepted proposal).
   o  SK_d.

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

   In addition, the ticket by value and the ticket by reference MUST
   contain a protected ticket expiration value that is readable for the
   client.

5.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.  A
   ticket is therefore associated with the tuple (IDi, IDr).

   The lifetime of the ticket carried in the N(TICKET_OPAQUE)
   notification SHOULD be the minimum of the IKE SA lifetime (per the
   gateway's local policy) and its re-authentication time, according to
   [RFC4478].  Even if neither of these are enforced by the gateway, a
   finite lifetime MUST be specified for the ticket.


6.  IANA Considerations

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




Sheffer, et al.           Expires July 28, 2009                [Page 13]


Internet-Draft          IKEv2 Session Resumption            January 2009


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


7.  Security Considerations

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

7.1.  Stolen Tickets

   An 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 the ticket when it is granted
   and before it is used, or by listening in on a client's use of the
   ticket to resume a session.  However, since the ticket's contents is
   encrypted and the attacker does not know the corresponding secret
   key, a stolen ticket cannot be used by an attacker to succesfully
   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.

   Since a ticket by reference does not need to be encrypted.  When an
   adversary is able to eavesdrop on an exchange, as described in the
   previous paragraph, then the ticket by reference may be obtained.
   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.

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

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



Sheffer, et al.           Expires July 28, 2009                [Page 14]


Internet-Draft          IKEv2 Session Resumption            January 2009


   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 value
   then this may lead to an amplification attack as the IKEv2 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.

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

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

7.6.  Ticket by Value Format

   Great care must be taken when defining a ticket format such that the
   requirements outlined in Section 5.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 ticket by value
   MUST have its integrity and confidentiality protected with strong
   cryptographic techniques to prevent a breach in the security of the
   system.






Sheffer, et al.           Expires July 28, 2009                [Page 15]


Internet-Draft          IKEv2 Session Resumption            January 2009


7.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 (e.g., with the help of encryption.  Thus,
   it prevents the disclosure of potentially sensitive information.

   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 envisions that the ticket is presented to the
   IKEv2 responder only once; multiple usage of the ticket is not
   provided.

7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange

   A major design goal of this protocol extension has been the two-
   message exchange for session resumption.  There is a tradeoff between
   this abbreviated exchange and replay protection.  It is RECOMMENDED
   that an IKEv2 responder should cache tickets, and reject replayed
   ones.  However, some gateways may not do that in order to reduce
   state size.  An adversary may attempt to replay a ticket.  To
   mitigate these risks a client may be required by the gateway to show
   that it knows the ticket's secret, before any state is committed on
   the gateway side.  Note that this is a stronger guarantee than the
   regular IKE cookie mechanism, which only shows IP return routability
   of the client.  This is enabled by including the cookie in the
   protected portion of the message.

   For performance reasons, the cookie mechanism is optional, and
   invoked by the gateway only when it suspects that it is the subject
   of a denial-of-service attack.

   In any case, a ticket replayed by an adversary only causes partial
   IKE state to be created on the gateway.  The IKE exchange cannot be
   completed and an IKE SA cannot be created unless the client knows the
   ticket's secret values.


8.  Acknowledgements

   We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
   Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ



Sheffer, et al.           Expires July 28, 2009                [Page 16]


Internet-Draft          IKEv2 Session Resumption            January 2009


   Housely, Yoav Nir and Tero Kivinen for their comments.  We would to
   particularly thank Florian Tegeler and Stjepan Gros for their help
   with their implementation efforts and Florian Tegeler for his formal
   verification using the CASPER tool set.

   We would furthermore like to thank the authors of
   [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.


9.  References

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

9.2.  Informative References

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




Sheffer, et al.           Expires July 28, 2009                [Page 17]


Internet-Draft          IKEv2 Session Resumption            January 2009


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

   [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 format described in the sub-
   sections are RECOMMENDED.

A.1.  Recommended 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
              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.





Sheffer, et al.           Expires July 28, 2009                [Page 18]


Internet-Draft          IKEv2 Session Resumption            January 2009


A.2.  Recommended Ticket by Reference Format

   For implementations that prefer to pass a reference to IKE state in
   the ticket, rather than the state itself, we RECOMMEND 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

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

   Resubmitted document as a WG item.

B.3.  -01

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

   Included recommended ticket format into the appendix

   Various editorial improvements within the document






Sheffer, et al.           Expires July 28, 2009                [Page 19]


Internet-Draft          IKEv2 Session Resumption            January 2009


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

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

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

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

B.9.  -00

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














Sheffer, et al.           Expires July 28, 2009                [Page 20]


Internet-Draft          IKEv2 Session Resumption            January 2009


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











Sheffer, et al.           Expires July 28, 2009                [Page 21]