One document matched: draft-ietf-ipsecme-ikev2-resumption-06.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std" ipr="pre5378Trust200902"
docName="draft-ietf-ipsecme-ikev2-resumption-06.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="IKEv2 Session Resumption">IKEv2 Session
Resumption</title>
<author initials="Y." surname="Sheffer"
fullname="Yaron Sheffer">
<organization abbrev="Check Point">Check Point Software
Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim St.</street>
<city>Tel Aviv</city>
<code>67897</code>
<country>Israel</country>
</postal>
<email>yaronf@checkpoint.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig"
fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2009" />
<abstract>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- ************************************************************************************ -->
<section title="Introduction">
<t>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.</t>
<t>To re-establish security associations (SA) upon a failure
recovery condition is time-consuming, especially when an
IPsec peer, such as a VPN gateway, needs to re-establish a
large number of SAs with various end points. A high number of
concurrent sessions might cause additional problems for an
IPsec responder. Usability is also affected when the re-establishment
of an IKE SA involves user interaction for reauthentication.</t>
<t>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.</t>
<t>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 gateway and forwarded to the client, or alternatively, is stored centrally
and a reference to it is forwarded to the client. The IKEv2 protocol is
extended to allow a client to request and present a ticket.
This document does not mandate the format of the ticket
structure. In
<xref target="format" /> a ticket by value and a ticket by
reference format is proposed.</t>
<t>This approach is similar to the one taken by TLS session
resumption
<xref target="RFC5077" /> with the required adaptations for
IKEv2, e.g., to accommodate the two-phase protocol structure.
We have borrowed heavily from that specification.</t>
<t>The proposed solution should additionally meet the
following goals:</t>
<t>
<list style="symbols">
<t>Using only symmetric cryptography to minimize CPU
consumption.</t>
<t>Providing cryptographic agility.</t>
<t>Having no negative impact on IKEv2 security
features.</t>
</list>
</t>
<t>The following are non-goals of this solution:
<list style="symbols">
<t>Failover from one gateway to another. This use case may
be added in a future specification.</t>
<t>Providing load balancing among gateways.</t>
<t>Specifying how a client detects the need for
resumption.</t>
</list></t>
</section>
<!-- ************************************************************************************ -->
<section title="Terminology">
<t>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
<xref target="RFC2119" />.</t>
<t>This document uses terminology defined in
<xref target="RFC4301" /> and
<xref target="RFC4306" />.
In addition, this document uses the following terms:</t>
<t>
<list style="hanging">
<t hangText="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.
<vspace blankLines="1" /></t>
</list>
</t>
<t>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.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Usage Scenario" anchor="usage">
<t>This specification envisions two usage scenarios for
efficient IKEv2 and IPsec SA session re-establishment.</t>
<t>The first is similar to the use case specified in Section
1.1.3 of the IKEv2 specification
<xref target="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.</t>
<t>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.</t>
<t>
<figure title="Resuming a Session with a Remote Access Gateway"
anchor="Case1GWfig">
<artwork>
<![CDATA[
(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 ! !
+-+-+-+-+-+ +-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>In the first use case above,
an end host (an entity with a host
implementation of IPsec
<xref target="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
<xref target="Case1GWfig" />).</t>
<t>
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):
</t>
<t>
<list style="symbols">
<t> If a client temporarily loses network connectivity (and the IKE
SA times out through the livensss test facility, a.k.a. "dead peer detection"),
this mechanism could be used to re-establish the
SA with less overhead (network, CPU, authentication infrastructure)
and without requiring user interaction for authentication. </t>
<t> 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. </t>
<t> Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling.
This mechanism could be used to re-establish the SA when
the laptop is switched back on (again, with less overhead and
without requiring user interaction for authentication). However such user-level
"resumption" may often be disallowed by policy. Moreover, this document
requires the client to destroy the ticket when the user explicitly "logs out"
(<xref target="lifecycle"/>.</t>
</list>
</t>
</section>
<!-- ************************************************************************************ -->
<section title="Protocol Sequences">
<t>This section provides protocol details and contains the
normative parts. This document defines two protocol
exchanges, namely requesting a ticket, see
<xref target="request-ticket" />, and presenting a ticket,
see
<xref target="present-ticket" />.</t>
<section anchor="request-ticket" title="Requesting a Ticket">
<t>A client MAY request a ticket in the following
exchanges:</t>
<t>
<list style="symbols">
<t>In an IKE_AUTH exchange, as shown in the example
message exchange in
<xref target="request-ticket-example" /> below.</t>
<t>In a CREATE_CHILD_SA exchange, when an IKE SA is
rekeyed (and only when this exchange is initiated
by the client).</t>
<t>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.</t>
<t>While resuming an IKE session, i.e. in the IKE_AUTH exchange that follows
an IKE_SESSION_RESUME exchange, see
<xref target="ike-auth" />.</t>
</list>
</t>
<t>Normally, a client requests a ticket in the third
message of an IKEv2 exchange (the first of IKE_AUTH).
<xref target="request-ticket-example" /> shows the message
exchange for this typical case.</t>
<t>
<figure anchor="request-ticket-example"
title="Example Message Exchange for Requesting a Ticket">
<artwork>
<![CDATA[
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr [, CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
]]>
</artwork>
</figure>
</t>
<t>The notification payloads are described in
<xref target="notifications" />. The above is an example,
and IKEv2 allows a number of variants on these messages.
Refer to <xref target="RFC4306" /> and <xref target="I-D.ietf-ipsecme-ikev2bis"/>
for more details on IKEv2.</t>
<t>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:
<list style="symbols">
<t>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
<xref target="request-ticket-example2" />.</t>
<t>it returns an N(TICKET_NACK) payload, if it refuses to
grant a ticket for some reason.</t>
<t>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.</t>
</list>
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.
</t>
</section>
<section anchor="receive-ticket" title="Receiving a Ticket">
<t>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.
<xref target="request-ticket-example2" /> shows how the
initiator receives the ticket.</t>
<t>
<figure anchor="request-ticket-example2"
title="Receiving a Ticket">
<artwork>
<![CDATA[
Initiator Responder
----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_LT_OPAQUE) }
]]>
</artwork>
</figure>
</t>
<t>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.</t>
<t>When the client accepts the ticket, it stores it in its local storage for later use,
along with the IKE SA that the ticket refers to. Since the ticket itself is opaque to
the client,
the local storage MUST also include all items
marked as "from the ticket" in the table of <xref target="ike-sa"/>. </t>
</section>
<section anchor="present-ticket" title="Presenting a Ticket">
<t>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.</t>
<section title="Prologue">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="IKE_SESSION_RESUME Exchange">
<t>This document specifies a new IKEv2 exchange type called
IKE_SESSION_RESUME whose value is TBA by IANA. This
exchange is equivalent to the IKE_SA_INIT exchange, and
MUST be followed by an IKE_AUTH exchange. The client SHOULD
NOT use this exchange type unless it knows that the gateway
supports it.</t>
<t>
<figure anchor="resume-example" title="IKEv2 Initiator wishes to resume an IKE SA">
<artwork>
<![CDATA[
Initiator Responder
----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
]]>
</artwork>
</figure>
</t>
<t>The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
The initiator sets the SPIi value in the HDR to a
random value and the SPIr value is set to 0.</t>
<t>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:</t>
<t>
<list style="symbols">
<t>If it is willing to accept the ticket, it responds
as shown in
<xref target="ticket-present-success" />.</t>
<t>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.</t>
</list>
</t>
<t>
<figure anchor="ticket-present-success"
title="IKEv2 Responder accepts the ticket">
<artwork>
<![CDATA[
Initiator Responder
----------- -----------
<-- HDR, Nr [,N+]
]]>
</artwork>
</figure>
</t>
<t>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 random
value .</t>
<t>Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves
exactly like the
IKE_SA_INIT exchange. Specifically:</t>
<t>
<list style="symbols">
<t>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).</t>
<t>The first message may be rejected in denial of
service situations, with the initiator instructed to send
a cookie.</t>
<t>Notifications normally associated with IKE_SA_INIT
can be sent. In particular, NAT detection payloads.</t>
<t>
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
<xref target="RFC4306"/>, Sec. 2.23. NAT status is explicitly not part of the session
resumption state.
</t>
<t>The SPI values and Message ID fields behave
similarly to IKE_SA_INIT.</t>
</list>
</t>
<t>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 (<xref target="ike-sa"/>) now.
Specifically, the SK_xx values are required to protect the IKE_AUTH payloads.</t>
</section>
<section anchor="ike-auth" title="IKE_AUTH Exchange">
<t>Following the IKE_SESSION_RESUME exchange, the client MUST initiate an IKE_AUTH
exchange, which is largely as specified in
<xref target="RFC4306" />. This section lists the differences and constraints
compared to the base document.</t>
<t>The value of the AUTH payload is derived in a manner
similar to the usage of IKEv2 pre-shared secret
authentication:</t>
<figure>
<artwork>
<![CDATA[
AUTH = prf(SK_px, <message octets>)
]]>
</artwork>
</figure>
<t>Each of the initiator and responder uses its own SK_p
value, taken from the newly generated IKE SA, <xref target="crypto-resumed-sa" />.</t>
<t>The exact material to be signed is defined in Section
2.15 of
<xref target="RFC4306" />. </t>
<t>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.</t>
<t>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,
<xref target="request-ticket" />. The returned ticket (if any) will correspond to the IKE
SA created per the rules described in
<xref target="ike-sa" />.</t>
</section>
<section title="Epilogue">
<t>Following the IKE_AUTH exchange, a new IKE SA is
created by both parties, see
<xref target="ike-sa" />, and a child SA is derived, per Section 2.17 of
<xref target="RFC4306" />.</t>
<t>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.</t>
</section>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="IKE and IPsec State After Resumption"
anchor="ike-sa">
<t>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
(<xref target="crypto-resumed-sa"/>).
</t>
<t>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.
</t>
<t>
The following table, compiled by Pasi Eronen, describes the IKE and IPsec state of the
peers after session resumption, and how it is related to their state before the IKE SA was
interrupted. When the table mentions that a certain state item is taken "from the ticket",
this should be construed as:
<list style="symbols">
<t>The client retrieves this item from its local store.</t>
<t>In the case of ticket by value, the gateway encodes this information in the ticket.</t>
<t>In the case of ticket by reference, the gateway fetches this information from the
ticket store.</t>
</list>
</t>
<texttable>
<ttcol>State Item</ttcol>
<ttcol>After Resumption</ttcol>
<c>IDi</c>
<c>From the ticket (but must also be exchanged in IKE_AUTH).
See also Note <xref target="note-auth-id" format="counter"/></c>
<c>IDr</c>
<c>From the ticket (but must also be exchanged in IKE_AUTH)</c>
<c>Authentication method (PKI, pre-shared secret, EAP, PKI-less EAP <xref target="I-D.eronen-ipsec-ikev2-eap-auth"/> etc.)</c>
<c>From the ticket</c>
<c>Certificates (when applicable)</c>
<c>From the ticket, see Note <xref target="note-certs" format="counter"/></c>
<c>Local IP address/port, peer IP address/port</c>
<c>Selected by the client, see Note <xref target="note-cert-match" format="counter"/></c>
<c>NAT detection status</c>
<c>From new exchange</c>
<c>SPIs</c>
<c>From new exchange, see Note <xref target="note-SPIs" format="counter"/></c>
<c>Which peer is the "original initiator"?</c>
<c>Determined by the initiator of IKE_SESSION_RESUME</c>
<c>IKE SA sequence numbers (Message ID)</c>
<c>Reset to 0 in IKE_SESSION_RESUME, and subsequently incremented normally</c>
<c>IKE SA algorithms (SAr)</c>
<c>From the ticket</c>
<c>IKE SA keys (SK_*)</c>
<c>The old SK_d is obtained from the ticket and all keys are refreshed,
see <xref target="crypto-resumed-sa"/></c>
<c>IKE SA window size</c>
<c>Reset to 1</c>
<c>Child SAs (ESP/AH)</c>
<c>Created in new exchange, see Note
<xref target="note-Child-SA-fatures" format="counter"/></c>
<c>Internal IP address</c>
<c>Not resumed, but see Note <xref target="note-TIA" format="counter"/></c>
<c>Other Configuration Payload information</c>
<c>Not resumed</c>
<c>Peer vendor IDs</c>
<c>Implementation specific (needed in the ticket only if
vendor-specific state is required)</c>
<c>Peer supports MOBIKE <xref target="RFC4555" /></c>
<c>From new exchange</c>
<c>MOBIKE additional addresses</c>
<c>Not resumed, should be resent by client if necessary</c>
<c>Time until re-authentication <xref target="RFC4478" /></c>
<c>From new exchange (but ticket lifetime is bounded by this duration)</c>
<c>Peer supports redirects <xref target="I-D.ietf-ipsecme-ikev2-redirect" /></c>
<c>From new exchange</c>
</texttable>
<t>
<list style='format Note %d:' hangIndent='5'>
<t anchor="note-auth-id">The authenticated peer identity used for policy lookups may
not be the same as the IDi payload (see Sec. 3.5 of <xref target="RFC4718"/>),
and if so, MUST be included in the ticket. Note that the client may not have access
to this value.
</t>
<t anchor="note-certs">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.</t>
<t anchor="note-cert-match">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. </t>
<t anchor="note-SPIs">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.</t>
<t anchor="note-TIA">The client can request the address it was using earlier,
and if possible, the gateway SHOULD honor the request.</t>
<t anchor="note-AUTH-features">IKEv2 features that affect only the IKE_AUTH exchange (including
HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges
<xref target="RFC4739" />, ECDSA authentication <xref target="RFC4754" />,
and OCSP <xref target="RFC4806" />) don't usually need any state
in the IKE SA (after the IKE_AUTH exchanges are done),
so resumption doesn't affect them.</t>
<t anchor="note-Child-SA-fatures">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 <xref target="I-D.ietf-rohc-ikev2-extensions-hcoipsec" />
and configuration aren't usually affected by session resumption. </t>
<t anchor="note-new-features">New IKEv2 features that are not covered by notes
<xref target="note-AUTH-features" format="counter"/>
and
<xref target="note-Child-SA-fatures" format="counter"/>
should specify how they interact with session resumption. </t>
</list>
</t>
<section title="Generating Cryptographic Material for the Resumed IKE SA"
anchor="crypto-resumed-sa">
<t>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:</t>
<figure>
<artwork>
<![CDATA[
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
]]>
</artwork>
</figure>
<t>where SK_d_old is taken from the ticket. The literal
string is encoded as 10 ASCII characters, with no NULL
terminator.</t>
<t>The keys are derived as follows, unchanged from
IKEv2:</t>
<figure>
<artwork>
<![CDATA[
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
]]>
</artwork>
</figure>
<t>where SPIi, SPIr are the SPI values created in the new
IKE exchange.</t>
<t>See
<xref target="RFC4306" /> for the notation. "prf" is
determined from the SA value in the ticket.</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Ticket Handling">
<section anchor="content" title="Ticket Content">
<t>When passing a ticket by value to the client, the ticket
content MUST be integrity protected and encrypted.</t>
<t>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
<xref target="I-D.xu-ike-sa-sync" />, or the concept of a
Session ID from TLS.</t>
<t>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.
</t>
<t>When the state is passed by value, the ticket MUST
encode all state information marked "from the ticket" in the table on
<xref target="ike-sa"/>.
The same state MUST be stored in the ticket store,
in the case of ticket by reference.
</t>
<t>
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.
</t>
<t>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.</t>
</section>
<section title="Ticket Identity and Lifecycle"
anchor="lifecycle">
<t>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 <xref target="ticket-revocation"/>
for more about this issue.</t>
<t>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
<xref target="RFC4478" />. Even if neither of these are
enforced by the gateway, a finite lifetime MUST be
specified for the ticket.</t>
<t>
The key that is used to protect the ticket MUST have a
lifetime that is significantly longer than the lifetime of
an IKE SA.</t>
<t>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.
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="IKE Notifications" anchor="notifications">
<t>This document defines a number of notifications. The
notification numbers are TBA by IANA.</t>
<texttable>
<ttcol>Notification Name</ttcol>
<ttcol>Number</ttcol>
<ttcol>Data</ttcol>
<c>TICKET_LT_OPAQUE</c>
<c>TBA1</c>
<c>See
<xref target="ticket-encoding" /></c>
<c>TICKET_REQUEST</c>
<c>TBA2</c>
<c>None</c>
<c>TICKET_ACK</c>
<c>TBA3</c>
<c>None</c>
<c>TICKET_NACK</c>
<c>TBA4</c>
<c>None</c>
<c>TICKET_OPAQUE</c>
<c>TBA5</c>
<c>See
<xref target="ticket-encoding2" /></c>
</texttable>
<t>For all these notifications, the Protocol ID and the SPI
Size fields MUST both be sent as 0.</t>
<section title="TICKET_LT_OPAQUE Notify Payload"
anchor="ticket-encoding">
<t>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).</t>
<t>
<figure title="TICKET_LT_OPAQUE Notify Payload"
anchor="ticket">
<artwork>
<![CDATA[
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
</section>
<section title="TICKET_OPAQUE Notify Payload"
anchor="ticket-encoding2">
<t>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.</t>
<t>
<figure title="TICKET_OPAQUE Notify Payload"
anchor="ticket2">
<artwork>
<![CDATA[
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="IANA Considerations">
<t>This document requires a number of IKEv2 notification
status types in
<xref target="notifications" />, to be registered by IANA.
The "IKEv2 Notify Message Types - Status Types" registry was
established by IANA.</t>
<t>The document defines a new IKEv2 exchange in
<xref target="present-ticket" />. The corresponding registry
was established by IANA.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Security Considerations" anchor="security">
<t>This section addresses security issues related to the
usage of a ticket.</t>
<section title="Stolen Tickets">
<t>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.</t>
<t>A ticket by reference does not need to be encrypted.
When an adversary is able to eavesdrop on a resumption attempt, as
described in the previous paragraph, then the ticket by
reference may be obtained. A ticket by reference cannot be used by
an attacker to successfully resume a session, for the
same reasons as for a ticket by value.
Moreover, the adversary MUST NOT be able
to resolve the ticket via the reference, i.e., access
control MUST be enforced to ensure disclosure only to
authorized entities.</t>
</section>
<section title="Forged Tickets">
<t>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.</t>
<t>In case of a ticket by reference an adversary may
attempt to construct a fake ticket by reference to point to
state information stored by the IKEv2 responder. This
attack will fail because the adversary is not in possession
of the keying material associated with the IKEv2 SA. As noted in
<xref target="content"/>, it is often useful to integrity-protect
the ticket by reference, too.</t>
</section>
<section title="Denial of Service Attacks">
<t>An adversary could generate and send a large number of
tickets by value to a gateway for verification. To minimize
the possibility of such denial of service, ticket
verification should be lightweight (e.g., using efficient
symmetric key cryptographic algorithms).</t>
<t>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.</t>
</section>
<section title="Key Management for Tickets By Value ">
<t>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.
<list style="symbols">
<t>The keys should be generated securely following the
randomness recommendations in
<xref target="RFC4086" />.</t>
<t>The keys and cryptographic protection algorithms
should be at least 128 bits in strength.</t>
<t>The keys should not be used for any other purpose than
generating and verifying tickets.</t>
<t>The keys should be changed regularly.</t>
<t>The keys should be changed if the ticket format or
cryptographic protection algorithms change.</t>
</list></t>
</section>
<section title="Ticket Lifetime">
<t>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.</t>
</section>
<section anchor="ticket-revocation" title="Ticket Revocation">
<t>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 <xref target="lifecycle"/>.
This issue is unique to ticket by value cases, since a ticket by reference will have been
deleted from the ticket store.</t>
<t>To avoid this issue for ticket by value, an Invalid Ticket List (ITL)
may be maintained by the gateway, see
<xref target="I-D.rescorla-stateless-tokens" />. This can be a simple
blacklist of revoked tickets. Alternatively, <xref target="I-D.rescorla-stateless-tokens" />
suggests to use Bloom Filters <xref target="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.</t>
</section>
<section title="Ticket by Value Format">
<t>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
<xref target="content" /> are met. The ticket by value MUST have its
integrity and confidentiality protected with strong
cryptographic techniques to prevent a breach in the
security of the system.</t>
</section>
<section title="Identity Privacy, Anonymity, and Unlinkability">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<!-- <t>DOS resistance.</t>
<t>Authentication of identities.</t>
<t>Reuse of ticket from a terminated session.</t>
<t>Strength of the ticket protection stronger than the protected data.</t>
<t>Time synchronization between gateways.</t>
-->
</section>
<!-- ************************************************************************************ -->
<section title="Acknowledgements">
<t>We would like to thank Paul Hoffman, Pasi Eronen, Florian
Tegeler, Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros,
Dan Harkins, Russ Housely, Yoav Nir and Tero Kivinen for
their comments. We would like to particularly thank Florian
Tegeler and Stjepan Gros for their
implementation efforts and Florian Tegeler for a formal
verification using the Casper tool set.</t>
<t>We would furthermore like to thank the authors of
<xref target="I-D.xu-ike-sa-sync" /> (Yan Xu, Peny Yang,
Yuanchen Ma, Hui Deng and Ke Xu) for their input on the stub
concept.</t>
<t>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.</t>
<t>Vidya Narayanan and Lakshminath Dondeti coauthored several
past versions of this document, and we
acknowledge their significant contribution.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4306.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.4478.xml"?>
<?rfc include="reference.RFC.4086.xml"?>
<?rfc include="reference.RFC.4718.xml"?>
<?rfc include="reference.RFC.4739.xml"?>
<?rfc include="reference.RFC.4754.xml"?>
<?rfc include="reference.RFC.4806.xml"?>
<?rfc include="reference.RFC.5077.xml"?>
<?rfc include="reference.RFC.4555.xml"?>
<?rfc include="reference.I-D.xu-ike-sa-sync.xml"?>
<?rfc include="reference.I-D.ietf-ipsecme-ikev2-redirect.xml"?>
<?rfc include="reference.I-D.ietf-ipsecme-ikev2bis.xml"?>
<?rfc include="reference.I-D.ietf-rohc-ikev2-extensions-hcoipsec.xml"?>
<?rfc include="reference.I-D.eronen-ipsec-ikev2-eap-auth.xml"?>
<?rfc include="reference.I-D.rescorla-stateless-tokens.xml"?>
<reference anchor="Bloom70">
<front>
<title>Space/time trade-offs in hash coding with allowable errors</title>
<author initials="B. H." surname="Bloom" fullname="Burton H. Bloom">
<organization/>
</author>
<date month="July" year="1970"/>
</front>
<seriesInfo name="Comm. ACM " value="13(7):422-6"/>
<format type="PDF" target="http://gnunet.org/papers/p422-bloom.pdf"/>
</reference>
</references>
<section title="Ticket Format" anchor="format">
<t>This document does not specify a mandatory-to-implement or
a mandatory-to-use ticket format. The formats described in the
following sub-sections are provided as useful examples.</t>
<section title="Example Ticket by Value Format">
<t>
<figure>
<artwork>
<![CDATA[
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;
]]>
</artwork>
</figure>
</t>
<t>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.</t>
<t>The reader is referred to
<xref target="I-D.rescorla-stateless-tokens" /> that
recommends a similar (but not identical) ticket format, and
discusses related security considerations in depth.</t>
</section>
<section title="Example Ticket by Reference Format">
<t>For implementations that prefer to pass a reference to
IKE state in the ticket, rather than the state itself, we
suggest the following format:</t>
<t>
<figure>
<artwork>
<![CDATA[
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;
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Change Log">
<t>Note to RFC Editor: remove this appendix before publication.</t>
<section title="-06">
<t>Clients resuming propely closed sessions and how this can be avoided.</t>
</section>
<section title="-05">
<t>Editorial changes: reordered and merged some sections.</t>
<t>Restated the use cases.</t>
<t>IDr is not negotiated during resumption, the gateway must use the stored IDr.</t>
<t>Multiple small clarifications based on Pasi's LC review.</t>
<t>IPR: pre5378Trust200902.</t>
</section>
<section title="-04">
<t>Closed issue #105, Non-PKI use of EAP, and resumption.</t>
<t>Closed issue #106, Resumption and NAT detection and changing ports.</t>
</section>
<section title="-03">
<t>Changed the protocol from one to two round trips, to
simplify the security assumptions. Eliminated security
considerations associated with the previous version.</t>
<t>Closed issue #69, Clarify behavior of SPI and sequence
numbers.</t>
<t>Closed issue #70, Ticket lifetime - explicit or not?
(and ticket push from gateway).</t>
<t>Closed issue #99, Ticket example: downgrade.</t>
<t>Closed issue #76, IPsec child SAs during resumption.</t>
<t>Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption.</t>
<t>Closed issue #95, Minor nits for
ikev2-resumption-02.</t>
<t>Closed issue #97, Clarify what state comes from where.</t>
<t>Closed issue #98, Replays in 1-RTT protocol.</t>
<t>Closed issue #100, NAT detection [and] IP address change.</t>
<t>Closed issue #101, Assorted issues by Tero.</t>
</section>
<section title="-02">
<t>Added a new TICKET_OPAQUE payload that does not have a
lifetime field included.</t>
<t>Removed the lifetime usage from the IKE_SESSION_RESUME
exchange (utilizing the TICKET_OPAQUE) when presenting the
ticket to the gateway.</t>
<t>Removed IDi payloads from the IKE_SESSION_RESUME
exchange.</t>
<t>Clarified that IPsec child SAs would be deleted once the
old IKE SA gets deleted as well.</t>
<t>Clarified the behavior of SPI and sequence number
usage.</t>
</section>
<section title="-01">
<t>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.</t>
</section>
<section title="-00">
<t>Resubmitted document as a WG item.</t>
</section>
<section title="-01">
<t>Added reference to
<xref target="I-D.xu-ike-sa-sync" /></t>
<t>Included recommended ticket format into the appendix</t>
<t>Various editorial improvements within the document</t>
</section>
<section title="-00">
<t>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.</t>
</section>
<section title="-04">
<t>Editorial fixes; references cleaned up; updated author's
contact address</t>
</section>
<section title="-03">
<t>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.</t>
</section>
<section title="-02">
<t>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.</t>
</section>
<section title="-01">
<t>Editorial review. Removed 24-hour limitation on ticket
lifetime, lifetime is up to local policy.</t>
</section>
<section title="-00">
<t>Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:09:22 |