doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc5723.txt b/doc/rfc/rfc5723.txt
new file mode 100644
index 0000000..46b9937
--- /dev/null
+++ b/doc/rfc/rfc5723.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        Y. Sheffer
+Request for Comments: 5723                                   Check Point
+Category: Standards Track                                  H. Tschofenig
+ISSN: 2070-1721                                   Nokia Siemens Networks
+                                                            January 2010
+
+
+           Internet Key Exchange Protocol Version 2 (IKEv2)
+                           Session Resumption
+
+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
+   endpoints.  A high number of concurrent sessions might cause
+   additional problems for an IPsec peer during SA re-establishment.
+
+   In order to avoid the need to re-run the key exchange protocol from
+   scratch, it would be useful to provide an efficient way to resume an
+   IKE/IPsec session.  This document proposes an extension to IKEv2 that
+   allows a client to re-establish an IKE SA with a gateway in a highly
+   efficient manner, utilizing a previously established IKE SA.
+
+   A client can reconnect to a gateway from which it was disconnected.
+   The proposed approach encodes partial IKE state into an opaque
+   ticket, which can be stored on the client or in a centralized store,
+   and is later made available to the IKEv2 responder for re-
+   authentication.  We use the term ticket to refer to the opaque data
+   that is created by the IKEv2 responder.  This document does not
+   specify the format of the ticket but examples are provided.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 1]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5723.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 2]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................5
+   3. Usage Scenario ..................................................5
+   4. Protocol Sequences ..............................................7
+      4.1. Requesting a Ticket ........................................7
+      4.2. Receiving a Ticket .........................................8
+      4.3. Presenting a Ticket ........................................9
+           4.3.1. Prologue ............................................9
+           4.3.2. IKE_SESSION_RESUME Exchange ........................10
+           4.3.3. IKE_AUTH Exchange ..................................11
+           4.3.4. Epilogue ...........................................12
+   5. IKE and IPsec State after Resumption ...........................12
+      5.1. Generating Cryptographic Material for the Resumed IKE SA ..15
+   6. Ticket Handling ................................................16
+      6.1. Ticket Content ............................................16
+      6.2. Ticket Identity and Lifecycle .............................16
+   7. IKE Notifications ..............................................17
+      7.1. TICKET_LT_OPAQUE Notify Payload ...........................17
+      7.2. TICKET_OPAQUE Notify Payload ..............................18
+   8. IANA Considerations ............................................18
+   9. Security Considerations ........................................19
+      9.1. Stolen Tickets ............................................19
+      9.2. Forged Tickets ............................................19
+      9.3. Denial-of-Service Attacks .................................20
+      9.4. Detecting the Need for Resumption .........................20
+      9.5. Key Management for "Tickets by Value" .....................20
+      9.6. Ticket Lifetime ...........................................21
+      9.7. Tickets and Identity ......................................21
+      9.8. Ticket Revocation .........................................21
+      9.9. Ticket by Value Format ....................................21
+      9.10. Identity Privacy, Anonymity, and Unlinkability ...........22
+   10. Acknowledgements ..............................................22
+   11. References ....................................................23
+      11.1. Normative References .....................................23
+      11.2. Informative References ...................................23
+   Appendix A.  Ticket Format ........................................25
+     A.1.  Example "Ticket by Value" Format ..........................25
+     A.2.  Example "Ticket by Reference" Format ......................25
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 3]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+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 (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
+   endpoints.  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 re-authentication.
+
+   In many failure cases, it would be useful to provide an efficient way
+   to resume an interrupted IKE/IPsec session.  This document proposes
+   an extension to IKEv2 that allows a client to re-establish an IKE SA
+   with a gateway in a highly efficient manner, utilizing a previously
+   established IKE SA.
+
+   The client (IKEv2 initiator) stores the state about the previous IKE
+   SA locally.  The gateway (IKEv2 responder) has two options for
+   maintaining the IKEv2 state about the previous IKE SA:
+
+   o  In the "ticket by reference" approach, the gateway stores the
+      state locally, and gives the client a protected and opaque
+      reference (e.g., an index to the gateway's table) that the gateway
+      can later use to find the state.  The client includes this opaque
+      reference when it resumes the session.
+
+   o  In the "ticket by value" approach, the gateway stores its state in
+      a ticket (data structure) that is encrypted and integrity-
+      protected by a key known only to the gateway.  The ticket is
+      passed to the client (who treats the ticket as an opaque string)
+      and sent back to the gateway when the session is resumed.  The
+      gateway can then decrypt the ticket and recover the state.
+
+   Note that the client behaves identically in both cases, and in
+   general does not know which approach the gateway is using.  Since the
+   ticket (or reference) is only interpreted by the same party that
+   created it, this document does not specify the exact format for it.
+   However, Appendix A contains examples for both "ticket by reference"
+   and "ticket by value" formats.
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 4]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   This approach is similar to the one taken by Transport Layer Security
+   (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 term:
+
+   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.
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 5]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   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 endpoints (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).
+
+   For either of the above use cases, there are multiple possible
+   situations where the mechanism specified in this document could be
+   useful.  These include the following (note that this list is not
+   meant to be exhaustive, and any particular deployment may not care
+   about all of these):
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 6]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   o  If a client temporarily loses network connectivity (and the IKE SA
+      times out through the liveness 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 traveling.
+      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.
+      Moreover, this document requires the client to destroy the ticket
+      when the user explicitly "logs out" (Section 6.2).
+
+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, 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.3.3.
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 7]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   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 7.  The above is
+   an example, and IKEv2 allows a number of variants on these messages.
+   Refer to [RFC4306] and [IKEV2-BIS] 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.
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 8]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+      Initiator                Responder
+     -----------              -----------
+            <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
+                        TSr, N(TICKET_LT_OPAQUE) }
+
+                       Figure 3: Receiving a Ticket
+
+   When a multi-round-trip IKE_AUTH exchange is used, the
+   N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH
+   request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST
+   only be returned in the final IKE_AUTH response.
+
+   When the client accepts the ticket, it stores it in its local storage
+   for later use, along with the IKE SA to which the ticket refers.
+   Since the ticket itself is opaque to the client, the local storage
+   MUST also include all items marked as "from the ticket" in the table
+   of Section 5.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                     [Page 9]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+4.3.2.  IKE_SESSION_RESUME Exchange
+
+   This document specifies a new IKEv2 exchange type called
+   IKE_SESSION_RESUME whose value is 38.  This exchange is equivalent to
+   the IKE_SA_INIT exchange, and MUST be followed by an IKE_AUTH
+   exchange.  The client SHOULD NOT use this exchange type unless it
+   knows that the gateway supports it (this condition is trivially true
+   in the context of the current document, since the client always
+   resumes into the same gateway that generated the ticket).
+
+     Initiator                Responder
+    -----------              -----------
+    HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+]   -->
+
+           Figure 4: IKEv2 Initiator Wishes to Resume an IKE SA
+
+   The exchange type in HDR is set to 'IKE_SESSION_RESUME'.  The
+   initiator sets the SPIi (Security Parameter Index, Initiator) value
+   in the HDR to a new, unique value and the SPIr value is set to 0.
+
+   When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
+   payload, it MUST perform one of the following steps if it supports
+   the extension defined in this document:
+
+   o  If it is willing to accept the ticket, it responds as shown in
+      Figure 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 5: IKEv2 Responder Accepts the Ticket
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 10]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.  The
+   responder copies the SPIi value from the request, and the SPIr value
+   is set to a new, unique value.
+
+   Where not specified otherwise, the IKE_SESSION_RESUME exchange
+   behaves exactly like the IKE_SA_INIT exchange.  Specifically:
+
+   o  The client MAY resume the IKE exchange from any IP address 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 (DoS)
+      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 in
+      IKE_SESSION_RESUME.  If NAT is detected, the initiator switches to
+      UDP encapsulation on port 4500, as per [RFC4306], Section 2.23.
+      NAT status is explicitly not part of the session resumption state.
+
+   o  The SPI values and Message ID fields behave similarly to
+      IKE_SA_INIT.
+
+   Although the IKE SA is not fully valid until the completion of the
+   IKE_AUTH exchange, the peers must create much of the SA state
+   (Section 5) now.  Specifically, the shared key values are required to
+   protect the IKE_AUTH payloads.  Their generation is described in
+   Section 5.1.
+
+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:
+
+            AUTH = prf(SK_px, <message octets>)
+
+   Each of the initiator and responder uses its own value for SK_px,
+   namely SK_pi for the initiator and SK_pr for the responder.  Both are
+   taken from the newly generated IKE SA (Section 5.1).
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 11]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   The exact material to be signed is defined in Section 2.15 of
+   [RFC4306].
+
+   The IDi value sent in the IKE_AUTH exchange MUST be identical to the
+   value included in the ticket.  A CERT payload MUST NOT be included in
+   this exchange, and therefore a new IDr value cannot be negotiated
+   (since it would not be authenticated).  As a result, the IDr value
+   sent (by the gateway, and optionally by the client) in this exchange
+   MUST also be identical to the value included in the ticket.
+
+   When resuming a session, a client will typically request a new ticket
+   immediately, so that it is able to resume the session again in the
+   case of a second failure.  The N(TICKET_REQUEST) and
+   N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH
+   exchange that follows the IKE_SESSION_RESUME exchange, with similar
+   behavior to a ticket request during a regular IKE exchange,
+   Section 4.1.  The returned ticket (if any) will correspond to the IKE
+   SA created per the rules described in Section 5.
+
+4.3.4.  Epilogue
+
+   Following the IKE_AUTH 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 (i.e., following successful
+   completion of the IKE_AUTH exchange), the old SA SHOULD be silently
+   deleted without sending a DELETE informational exchange.
+   Consequently, all the dependent IPsec Child SAs are also deleted.
+
+5.  IKE and IPsec State after Resumption
+
+   During the resumption process, both peers create IKE and IPsec state
+   for the resumed IKE SA.  Although the SA is only completed following
+   a successful IKE_AUTH exchange, many of its components are created
+   earlier, notably the SA's crypto material (Section 5.1).
+
+   When a ticket is presented, the gateway needs to obtain the ticket
+   state.  In case a "ticket by reference" was provided by the client,
+   the gateway needs to resolve the reference in order to obtain this
+   state.  In case the client has already provided a "ticket by value",
+   the gateway can parse the ticket to obtain the state directly.  In
+   either case, the gateway needs to process the ticket state in order
+   to restore the state of the old IKE SA, and the client retrieves the
+   same state from its local store.
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 12]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   The following table describes the IKE and IPsec state of the peers
+   after session resumption, and how it is related to their state before
+   the IKE SA was interrupted.  When the table mentions that a certain
+   state item is taken "from the ticket", this should be construed as:
+
+   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).  See  |
+   |                                | also Note 1.                     |
+   |                                |                                  |
+   | IDr                            | From the ticket (but must also   |
+   |                                | be exchanged in IKE_AUTH).       |
+   |                                |                                  |
+   | Authentication method (PKI,    | From the ticket.                 |
+   | pre-shared secret, EAP,        |                                  |
+   | PKI-less EAP [EAP-AUTH] etc.)  |                                  |
+   |                                |                                  |
+   | Certificates (when applicable) | From the ticket, see Note 2.     |
+   |                                |                                  |
+   | Local IP address/port, peer IP | Selected by the client, see Note |
+   | address/port                   | 3.                               |
+   |                                |                                  |
+   | NAT detection status           | From new exchange.               |
+   |                                |                                  |
+   | SPIs                           | From new exchange, see Note 4.   |
+   |                                |                                  |
+   | Which peer is the "original    | Determined by the initiator of   |
+   | initiator"?                    | IKE_SESSION_RESUME.              |
+   |                                |                                  |
+   | IKE SA sequence numbers        | Reset to 0 in                    |
+   | (Message ID)                   | IKE_SESSION_RESUME, and          |
+   |                                | subsequently incremented         |
+   |                                | normally.                        |
+   |                                |                                  |
+   | IKE SA algorithms (SAr)        | From the ticket.                 |
+   |                                |                                  |
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 13]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   | IKE SA keys (SK_*)             | The old SK_d is obtained from    |
+   |                                | the ticket and all keys are      |
+   |                                | refreshed, see Section 5.1.      |
+   |                                |                                  |
+   | IKE SA window size             | Reset to 1.                      |
+   |                                |                                  |
+   | Child SAs (ESP/AH)             | Created in new exchange, see     |
+   |                                | Note 6.                          |
+   |                                |                                  |
+   | Internal IP address            | Not resumed, but see Note 5.     |
+   |                                |                                  |
+   | Other Configuration Payload    | Not resumed.                     |
+   | information                    |                                  |
+   |                                |                                  |
+   | Peer Vendor IDs                | Not resumed, resent in new       |
+   |                                | exchange if 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 ticket    |
+   | [RFC4478]                      | lifetime is bounded by this      |
+   |                                | duration).                       |
+   |                                |                                  |
+   | Peer supports redirects        | From new exchange.               |
+   | [RFC5685]                      |                                  |
+   +--------------------------------+----------------------------------+
+
+   Note 1:  The authenticated peer identity used for policy lookups may
+            not be the same as the IDi payload.  This is possible when
+            using certain EAP methods, see Section 3.5 of [RFC4718].  If
+            these identities are indeed different, then the
+            authenticated client identity MUST be included in the
+            ticket.  Note that the client may not have access to this
+            value.
+
+   Note 2:  Certificates don't need to be stored if the peer never uses
+            them for anything after the IKE SA is up; however, if they
+            are needed, e.g., if exposed to applications via IPsec APIs,
+            they MUST be stored in the ticket.
+
+   Note 3:  If the certificate has an iPAddress SubjectAltName, and the
+            implementation requires it to match the peer's source IP
+            address, the same check needs to be performed on session
+            resumption and the required information saved locally or in
+            the ticket.
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 14]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   Note 4:  SPI values of the old SA MAY be stored in the ticket, to
+            help the gateway locate corresponding old IKE state.  These
+            values MUST NOT be used for the resumed SA.
+
+   Note 5:  The client can request the address it was using earlier, and
+            if possible, the gateway SHOULD honor the request.
+
+   Note 6:  Since information about Child SAs and configuration payloads
+            is not resumed, IKEv2 features related to Child SA
+            negotiation (such as IPCOMP_SUPPORTED,
+            ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec]
+            and configuration) aren't usually affected by session
+            resumption.
+
+   IKEv2 features that affect only the IKE_AUTH exchange (including
+   HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges
+   [RFC4739], Elliptic Curve Digital Signature Algorithm (ECDSA)
+   authentication [RFC4754], and the Online Certificate Status Protocol
+   (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.
+
+   New IKEv2 features that are not covered by Note 6 or by the previous
+   paragraph should specify how they interact with session resumption.
+
+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.
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 15]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+6.  Ticket Handling
+
+6.1.  Ticket Content
+
+   When passing a "ticket by value" to the client, the ticket content
+   MUST be integrity protected and encrypted.
+
+   A "ticket by reference" does not need to be encrypted, as it does not
+   contain any sensitive material, such as keying material.  However,
+   access to the storage where that sensitive material is stored MUST be
+   protected so that only authorized access is allowed.  We note that
+   such a ticket is analogous to the concept of 'stub', as defined in
+   [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 all state
+   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".
+
+   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.
+
+6.2.  Ticket Identity and Lifecycle
+
+   Each ticket is associated with a single IKE SA.  In particular, when
+   an IKE SA is deleted by the client or the gateway, the client MUST
+   delete its stored ticket.  Similarly, when credentials associated
+   with the IKE SA are invalidated (e.g., when a user logs out), the
+   ticket MUST be deleted.  When the IKE SA is rekeyed, the ticket is
+   invalidated, and the client SHOULD request a new ticket.  When a
+   client does not follow these rules, it might present an invalid
+   ticket to the gateway.  See Section 9.8 for more about this issue.
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 16]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   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 the SA is
+   rekeyed or re-established because of re-authentication.
+
+7.  IKE Notifications
+
+   This document defines a number of notifications.  The following
+   Notify Message types have been assigned by IANA.
+
+              +-------------------+-------+-----------------+
+              | Notification Name | Value | Data            |
+              +-------------------+-------+-----------------+
+              | TICKET_LT_OPAQUE  | 16409 | See Section 7.1 |
+              |                   |       |                 |
+              | TICKET_REQUEST    | 16410 | None            |
+              |                   |       |                 |
+              | TICKET_ACK        | 16411 | None            |
+              |                   |       |                 |
+              | TICKET_NACK       | 16412 | None            |
+              |                   |       |                 |
+              | TICKET_OPAQUE     | 16413 | 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,
+   in network byte order).
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 17]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+        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 ticket itself.  Unlike the TICKET_LT_OPAQUE
+   payload, no lifetime value is included in the TICKET_OPAQUE Notify
+   payload.
+
+        0                     1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | Next Payload  |C|  Reserved   |      Payload Length           |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | Protocol ID   | SPI Size = 0  |    Notify Message Type        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                                                               |
+       ~                        Ticket                                 ~
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 7: TICKET_OPAQUE Notify Payload
+
+8.  IANA Considerations
+
+   Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME,
+   whose value has been allocated from the "IKEv2 Exchange Types"
+   registry.
+
+   Section 7 defines several new IKEv2 notifications whose Message Type
+   values have been allocated from the "IKEv2 Notify Message Types -
+   Status Types" registry.
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 18]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+9.  Security Considerations
+
+   This section addresses security issues related to the usage of a
+   ticket.
+
+9.1.  Stolen Tickets
+
+   A man in the middle may try to eavesdrop on an exchange to obtain a
+   "ticket by value" and use it to establish a session with the IKEv2
+   responder.  Since all exchanges where the client obtains a ticket are
+   encrypted, this is only possible by listening in on a client's use of
+   the ticket to resume a session.  However, since the ticket's contents
+   are encrypted and the attacker does not know the corresponding secret
+   key, a stolen ticket cannot be used by an attacker to successfully
+   resume a session.  An IKEv2 responder MUST use strong encryption and
+   integrity protection of the ticket to prevent an attacker from
+   obtaining the ticket's contents, e.g., by using a brute force attack.
+
+   A "ticket by reference" does not need to be encrypted.  When an
+   adversary is able to eavesdrop on a resumption attempt, as described
+   in the previous paragraph, then the "ticket by reference" may be
+   obtained.  A "ticket by reference" cannot be used by an attacker to
+   successfully resume a session, for the same reasons as for a "ticket
+   by value", namely because the attacker would not be able to prove,
+   during IKE_AUTH, its knowledge of the secret part of the IKE state
+   embedded in the ticket.  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 the case of a "ticket by reference" an adversary may attempt to
+   construct a fake "ticket by reference" to point to state information
+   stored by the IKEv2 responder.  This attack will fail because the
+   adversary is not in possession of the keying material associated with
+   the IKEv2 SA.  As noted in Section 6.1, it is often useful to
+   integrity-protect the "ticket by reference", too.
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 19]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+9.3.  Denial-of-Service Attacks
+
+   An adversary could generate and send a large number of "tickets by
+   value" to a gateway for verification.  Such an attack could burden
+   the gateway's CPU, and/or exhaust its memory with half-open IKE
+   state.  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.
+
+   Note also that the regular IKEv2 cookie mechanism can be used to
+   handle state-overflow DoS situations.
+
+9.4.  Detecting the Need for Resumption
+
+   Detecting when an old IKE SA is no longer usable and needs to be
+   resumed is out of scope of the current document.  However, clients
+   are warned against implementing a more liberal policy than that used
+   to detect failed IKE SAs (Section 2.4 of RFC 4306).  In particular,
+   untrusted messages MUST NOT be relied upon to make this decision.
+
+9.5.  Key Management for "Tickets by Value"
+
+   A full description of the management of the keys used to protect the
+   "ticket by value" is beyond the scope of this document.  A list of
+   RECOMMENDED practices is given below.
+
+   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.
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 20]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+9.6.  Ticket Lifetime
+
+   An IKEv2 responder controls the validity period of the state
+   information by attaching a lifetime to a ticket.  The chosen lifetime
+   is based on the operational and security requirements of the
+   environment in which this IKEv2 extension is deployed.  The responder
+   provides information about the ticket lifetime to the IKEv2
+   initiator, allowing it to manage its tickets.
+
+9.7.  Tickets and Identity
+
+   A ticket is associated with a certain identity, and MUST be managed
+   securely on the client side.  Section 6.2 requires that a ticket be
+   deleted when the credentials associated with the ticket's identity
+   are no longer valid, e.g., when a user whose credentials were used to
+   create the SA logs out.
+
+9.8.  Ticket Revocation
+
+   A misbehaving client could present a ticket in its possession to the
+   gateway resulting in session resumption, even though the IKE SA
+   associated with this ticket had previously been deleted.  This is
+   disallowed by Section 6.2.  This issue is unique to "ticket by value"
+   cases, since a "ticket by reference" will have been deleted from the
+   ticket store.
+
+   To avoid this issue for "ticket by value", an Invalid Ticket List
+   (ITL) may be maintained by the gateway, see [TOKENS].  This can be a
+   simple blacklist of revoked tickets.  Alternatively, [TOKENS]
+   suggests to use Bloom Filters [Bloom70] to maintain the list in
+   constant space.  Management of such lists is outside the scope of the
+   current document.  Note that a policy that requires tickets to have
+   shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
+
+9.9.  Ticket by Value Format
+
+   The ticket's format is not defined by this document, since this is
+   not required for interoperability.  However, great care must be taken
+   when defining a ticket format such that the requirements outlined in
+   Section 6.1 are met.  The "ticket by value" MUST have its integrity
+   and confidentiality protected with strong cryptographic techniques to
+   prevent a breach in the security of the system.
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 21]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+9.10.  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 endpoints.
+
+   This document therefore requires that the ticket be presented to the
+   IKEv2 responder only once; under normal circumstances (e.g., no
+   active attacker), there should be no multiple use of the same ticket.
+
+   We are not aware of additional security issues associated with ticket
+   reuse: the protocol guarantees freshness of the generated crypto
+   material even in such cases.  As noted in Section 4.3.1, the gateway
+   SHOULD prevent multiple uses of the same ticket.  But this is only an
+   extra precaution, to ensure that clients do not implement reuse.  In
+   other words, the gateway is not expected to cache old tickets for
+   extended periods of time.
+
+10.  Acknowledgements
+
+   We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
+   Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ
+   Housely, Yoav Nir, Peny Yang, Sean Turner, and Tero Kivinen for their
+   comments.  We would like to particularly thank Florian Tegeler and
+   Stjepan Gros for their implementation efforts and Florian Tegeler for
+   a formal verification using the Casper tool set.
+
+   We would furthermore like to thank the authors of [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.
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 22]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+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
+
+   [Bloom70]     Bloom, B., "Space/time trade-offs in hash coding with
+                 allowable errors", Comm. ACM 13(7):422-6, July 1970.
+
+   [EAP-AUTH]    Eronen, P., Tschofenig, H., and Y. Sheffer, "An
+                 Extension for EAP-Only Authentication in IKEv2", Work
+                 in Progress, October 2009.
+
+   [IKEV2-BIS]   Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+                 "Internet Key Exchange Protocol: IKEv2", Work
+                 in Progress, October 2009.
+
+   [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.
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 23]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+   [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.
+
+   [RFC5685]     Devarapalli, V. and K. Weniger, "Redirect Mechanism for
+                 the Internet Key Exchange Protocol Version 2 (IKEv2)",
+                 RFC 5685, November 2009.
+
+   [ROHCoIPsec]  Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
+                 C. Bormann, "IKEv2 Extensions to Support Robust Header
+                 Compression over IPsec (ROHCoIPsec)", Work in Progress,
+                 December 2009.
+
+   [SA-SYNC]     Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2
+                 SA Synchronization for session resumption", Work
+                 in Progress, October 2008.
+
+   [TOKENS]      Rescorla, E., "How to Implement Secure (Mostly)
+                 Stateless Tokens", Work in Progress, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 24]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+Appendix A.  Ticket Format
+
+   This document does not specify a particular ticket format nor even
+   the suggested contents of a ticket: both are entirely up to the
+   implementer.  The formats described in the following sub-sections are
+   provided as useful examples, and implementers are free to adopt them
+   as-is or change them in any way necessary.
+
+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 [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:
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 25]
+
+RFC 5723                IKEv2 Session Resumption            January 2010
+
+
+  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;
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer & Tschofenig        Standards Track                    [Page 26]
+