draft-ietf-ipsecme-ikev2-resumption-04.txt   draft-ietf-ipsecme-ikev2-resumption-05.txt 
Network Working Group Y. Sheffer Network Working Group Y. Sheffer
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: November 16, 2009 Nokia Siemens Networks Expires: December 18, 2009 Nokia Siemens Networks
L. Dondeti June 16, 2009
V. Narayanan
QUALCOMM, Inc.
May 15, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-04.txt draft-ietf-ipsecme-ikev2-resumption-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 16, 2009. This Internet-Draft will expire on December 18, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 33
end points. A high number of concurrent sessions might cause end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment. additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from 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 scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that 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 allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA. efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
The proposed approach requires passing opaque data from the IKEv2 The proposed approach encodes partial IKE state into an opaque
responder to the IKEv2 initiator, which is later made available to ticket, which can be stored on the client or in a centralized store,
the IKEv2 responder for re-authentication. We use the term ticket to and is later made available to the IKEv2 responder for re-
refer to the opaque data that is created by the IKEv2 responder. authentication. We use the term ticket to refer to the opaque data
This document does not specify the format of the ticket but that is created by the IKEv2 responder. This document does not
recommendations are provided. specify the format of the ticket but examples are provided.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 8
4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9 4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9
4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 9 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
4.4. IKE_SESSION_RESUME Details . . . . . . . . . . . . . . . . 11 4.3.1. Prologue . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Requesting a Ticket During Resumption . . . . . . . . . . 11 4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10
4.6. IP Address Change and NAT . . . . . . . . . . . . . . . . 11 4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12
4.7. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 12
4.7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . 12 5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13
4.7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12 5.1. Generating Cryptographic Material for the Resumed IKE
4.8. Computing the AUTH Payload . . . . . . . . . . . . . . . . 13 SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Processing Guidelines for IKE SA Establishment . . . . . . . . 13 6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16
6. The State After Resumption . . . . . . . . . . . . . . . . . . 14 6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
7. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.4. Key Management for Tickets By Value . . . . . . . . . . . 19 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20
9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19 9.4. Key Management for Tickets By Value . . . . . . . . . . . 20
9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 19 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20
9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20 9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 22 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 23
A.2. Example Ticket by Reference Format . . . . . . . . . . . . 23 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 23
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 24
B.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
B.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.8. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.10. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.9. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.10. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.11. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 B.12. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.13. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol has a certain The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved. of round-trips required and the cryptographic operations involved.
In particular the Extensible Authentication Protocol (EAP) is used In particular the Extensible Authentication Protocol (EAP) is used
for authentication in remote access cases, which increases latency. for authentication in remote access cases, which increases latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
condition is time-consuming, especially when an IPsec peer, such as a 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 VPN gateway, needs to re-establish a large number of SAs with various
end points. A high number of concurrent sessions might cause end points. A high number of concurrent sessions might cause
additional problems for an IPsec responder. additional problems for an IPsec responder. Usability is also
affected when the re-establishment of an IKE SA involves user
interaction for reauthentication.
In many failure cases it would be useful to provide an efficient way In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA 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 with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected. 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 One way to ensure that the IKEv2 responder is able to recreate the
state information is by maintaining IKEv2 state (or a reference into state information is by maintaining IKEv2 state (or a reference into
a state store) in a "ticket", an opaque data structure. This ticket a state store) in a "ticket", an opaque data structure. This ticket
is created by the server and forwarded to the client. The IKEv2 is created by the gateway and forwarded to the client, or
protocol is extended to allow a client to request and present a alternatively, is stored centrally and a reference to it is forwarded
ticket. This document does not mandate the format of the ticket to the client. The IKEv2 protocol is extended to allow a client to
structure but a recommendation is provided. In Appendix A a ticket request and present a ticket. This document does not mandate the
by value and a ticket by reference format is proposed. format of the ticket structure. In Appendix A a ticket by value and
a ticket by reference format is proposed.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC5077] with the required adaptations for IKEv2, e.g., to [RFC5077] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed accommodate the two-phase protocol structure. We have borrowed
heavily from that specification. heavily from that specification.
The proposed solution should additionally meet the following goals: The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption. o Using only symmetric cryptography to minimize CPU consumption.
o Providing cryptographic agility. o Providing cryptographic agility.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
Figure 1: Resuming a Session with a Remote Access Gateway Figure 1: Resuming a Session with a Remote Access Gateway
In the first use case above, an end host (an entity with a host In the first use case above, an end host (an entity with a host
implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA
with a gateway in a remote network using IKEv2. The end host in this 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 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 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 may choose to establish IPsec SAs using a full IKEv2 exchange or the
IKE_SESSION_RESUME exchange (shown in Figure 1). IKE_SESSION_RESUME exchange (shown in Figure 1).
4. Protocol Details 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):
o If a client temporarily loses network connectivity (and the IKE SA
times out through the livensss test facility, a.k.a. "dead peer
detection"), this mechanism could be used to re-establish the SA
with less overhead (network, CPU, authentication infrastructure)
and without requiring user interaction for authentication.
o If the connectivity problems affect a large number of clients
(e.g., a large remote access VPN gateway), when the connectivity
is restored, all the clients might reconnect almost
simultaneously. This mechanism could be used to reduce the load
spike for cryptographic operations and authentication
infrastructure.
o Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling.
This mechanism could be used to re-establish the SA when the
laptop is switched back on (again, with less overhead and without
requiring user interaction for authentication). However such
user-level "resumption" may often be disallowed by policy.
4. Protocol Sequences
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket, see Section 4.1, and presenting a ticket, see requesting a ticket, see Section 4.1, and presenting a ticket, see
Section 4.3. Section 4.3.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
A client MAY request a ticket in the following exchanges: A client MAY request a ticket in the following exchanges:
skipping to change at page 8, line 4 skipping to change at page 8, line 26
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket, see Section 4.1, and presenting a ticket, see requesting a ticket, see Section 4.1, and presenting a ticket, see
Section 4.3. Section 4.3.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
A client MAY request a ticket in the following exchanges: A client MAY request a ticket in the following exchanges:
o In an IKE_AUTH exchange, as shown in the example message exchange o In an IKE_AUTH exchange, as shown in the example message exchange
in Figure 2 below. in Figure 2 below.
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only
when this exchange is initiated by the client). when this exchange is initiated by the client).
o In an Informational exchange at any time, e.g. if the gateway o In an Informational exchange at any time, e.g. if the gateway
previously replied with an N(TICKET_ACK) instead of providing a previously replied with an N(TICKET_ACK) instead of providing a
ticket, or when the ticket lifetime is about to expire. All such ticket, or when the ticket lifetime is about to expire, or
Informational exchanges MUST be initiated by the client. 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 o While resuming an IKE session, i.e. in the IKE_AUTH exchange that
follows an IKE_SESSION_RESUME exchange, see Section 4.5. follows an IKE_SESSION_RESUME exchange, see Section 4.3.3.
Normally, a client requests a ticket in the third message of an IKEv2 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 (the first of IKE_AUTH). Figure 2 shows the message
exchange for this typical case. exchange for this typical case.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr [, CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
Figure 2: Example Message Exchange for Requesting a Ticket Figure 2: Example Message Exchange for Requesting a Ticket
The notification payloads are described in Section 4.7. The above is The notification payloads are described in Section 7. The above is
an example, and IKEv2 allows a number of variants on these messages. an example, and IKEv2 allows a number of variants on these messages.
Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details
on IKEv2. on IKEv2.
When an IKEv2 responder receives a request for a ticket using the When an IKEv2 responder receives a request for a ticket using the
N(TICKET_REQUEST) payload it MUST perform one of the following N(TICKET_REQUEST) payload it MUST perform one of the following
operations if it supports the extension defined in this document: operations if it supports the extension defined in this document:
o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE) o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE)
payload in a subsequent message towards the IKEv2 initiator. This payload in a subsequent message towards the IKEv2 initiator. This
is shown in Figure 3. is shown in Figure 3.
skipping to change at page 9, line 24 skipping to change at page 9, line 47
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_LT_OPAQUE) } TSr, N(TICKET_LT_OPAQUE) }
Figure 3: Receiving a Ticket Figure 3: Receiving a Ticket
When a multi-round-trip IKE_AUTH exchange is used, the When a multi-round-trip IKE_AUTH exchange is used, the
N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH
request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST
only be returned in the final IKE_AUTH response. only be returned in the final IKE_AUTH response.
When the client accepts the ticket, it stores it in its local storage
for later use, along with the IKE SA that the ticket refers to.
Since the ticket itself is opaque to the client, the local storage
MUST also include all items marked as "from the ticket" in the table
of Section 5.
4.3. Presenting a Ticket 4.3. Presenting a Ticket
A client MAY initiate a regular (non-ticket-based) IKEv2 exchange When the client wishes to recover from an interrupted session, it
even if it is in possession of a valid ticket. Note that the client presents the ticket to resume the session. This section describes
can only judge validity in the sense of the ticket lifetime. A the resumption process, consisting of some preparations, an
client MUST NOT present a ticket when it knows that the ticket's IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization.
lifetime has expired.
4.3.1. Prologue
It is up to the client's local policy to decide when the It is up to the client's local policy to decide when the
communication with the IKEv2 responder is seen as interrupted and the communication with the IKEv2 responder is seen as interrupted and the
session resumption procedure is to be initiated. 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 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 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 a ticket is considered as used only when an IKE SA has been
established successfully with it. established successfully with it.
4.3.2. IKE_SESSION_RESUME Exchange
This document specifies a new IKEv2 exchange type called This document specifies a new IKEv2 exchange type called
IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 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 equivalent to the IKE_SA_INIT exchange, and MUST be followed by an
IKE_AUTH exchange. The client SHOULD NOT use this exchange type IKE_AUTH exchange. The client SHOULD NOT use this exchange type
unless it knows that the gateway supports it. unless it knows that the gateway supports it.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, Ni, N(TICKET_OPAQUE) [,N+] --> 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 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The
initiator sets the SPIi value in the HDR to a new random value and initiator sets the SPIi value in the HDR to a random value and the
the SPIr value is set to 0. SPIr value is set to 0.
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 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 payload it MUST perform one of the following steps if it supports the
extension defined in this document: extension defined in this document:
o If it is willing to accept the ticket, it responds as shown in o If it is willing to accept the ticket, it responds as shown in
Figure 4. Figure 5.
o It responds with an unprotected N(TICKET_NACK) notification, if it o It responds with an unprotected N(TICKET_NACK) notification, if it
rejects the ticket for any reason. In that case, the initiator rejects the ticket for any reason. In that case, the initiator
should re-initiate a regular IKE exchange. One such case is when should re-initiate a regular IKE exchange. One such case is when
the responder receives a ticket for an IKE SA that has previously the responder receives a ticket for an IKE SA that has previously
been terminated on the responder itself, which may indicate been terminated on the responder itself, which may indicate
inconsistent state between the IKEv2 initiator and the responder. inconsistent state between the IKEv2 initiator and the responder.
However, a responder is not required to maintain the state for However, a responder is not required to maintain the state for
terminated sessions. terminated sessions.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, Nr [,N+] <-- HDR, Nr [,N+]
Figure 4: IKEv2 Responder accepts the ticket Figure 5: IKEv2 Responder accepts the ticket
Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 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 responder copies the SPIi value from the request, and the SPIr value
is set to a new random value . is set to a random value .
At this point the client MUST initiate an IKE_AUTH exchange, as per
[RFC4306]. See Section 4.8 for guidelines on computing the AUTH
payloads. The IDi value sent in this exchange MUST be identical to
the value included in the ticket. Following this exchange, a new IKE
SA is created by both parties, see Section 5, and a child SA is
derived, per Section 2.17 of [RFC4306].
When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it, then the old SA SHOULD be
silently deleted without sending a DELETE informational exchange.
Consequently, all the dependent IPsec child SAs are also deleted.
This happens after both peers have been authenticated.
4.4. IKE_SESSION_RESUME Details
Where not specified otherwise, the IKE_SESSION_RESUME exchange Where not specified otherwise, the IKE_SESSION_RESUME exchange
behaves exactly like the IKE_SA_INIT exchange. Specifically: 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 situations, o The first message may be rejected in denial of service situations,
with the initiator instructed to send a cookie. with the initiator instructed to send a cookie.
o Notifications normally associated with IKE_SA_INIT can be sent. o Notifications normally associated with IKE_SA_INIT can be sent.
In particular, NAT detection payloads. 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], Sec. 2.23. NAT
status is explicitly not part of the session resumption state.
o The SPI values and Message ID fields behave similarly to o The SPI values and Message ID fields behave similarly to
IKE_SA_INIT. IKE_SA_INIT.
o NAT may be detected during the IKE_SESSION_RESUME exchange, in
which case the initiator switches to UDP encapsulation to port
4500, as per [RFC4306], Sec. 2.23.
4.5. Requesting a Ticket During Resumption
When resuming a session, a client will typically request a new ticket Although the IKE SA is not fully valid until the completion of the
immediately, so it is able to resume the session again in the case of IKE_AUTH exchange, the peers must create much of the SA state
a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE) (Section 5) now. Specifically, the SK_xx values are required to
notifications will be included in the IKE_AUTH exchange that follows protect the IKE_AUTH payloads.
the IKE_SESSION_RESUME exchange, with similar behavior to a ticket
request during a regular IKE exchange, Section 4.1.
The returned ticket (if any) will correspond to the IKE SA created
per the rules described in Section 5.
4.6. IP Address Change and NAT
The client MAY resume the IKE exchange from an IP address different
from its original address. The gateway MAY reject the resumed
exchange if its policy depends on the client's address (although this
rarely makes sense).
The client's NAT traversal status SHOULD be determined anew upon
session resumption, by using the appropriate notifications. This
status is explicitly not part of the session resumption state.
See also Section 4.4 for related details.
4.7. IKE Notifications
This document defines a number of notifications. The notification
numbers are TBA by IANA.
+-------------------+--------+-------------------+
| Notification Name | Number | Data |
+-------------------+--------+-------------------+
| TICKET_LT_OPAQUE | TBA1 | See Section 4.7.1 |
| TICKET_REQUEST | TBA2 | None |
| TICKET_ACK | TBA3 | None |
| TICKET_NACK | TBA4 | None |
| TICKET_OPAQUE | TBA5 | See Section 4.7.2 |
+-------------------+--------+-------------------+
For all these notifications, the Protocol ID and the SPI Size fields
MUST both be sent as 0.
4.7.1. TICKET_LT_OPAQUE Notify Payload
The data for the TICKET_LT_OPAQUE Notify payload consists of the 4.3.3. IKE_AUTH Exchange
Notify message header, a Lifetime field and the ticket itself. The
four octet Lifetime field contains a relative time value, the number
of seconds until the ticket expires (encoded as an unsigned integer).
0 1 2 3 Following the IKE_SESSION_RESUME exchange, the client MUST initiate
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 an IKE_AUTH exchange, which is largely as specified in [RFC4306].
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This section lists the differences and constraints compared to the
! Next Payload !C! Reserved ! Payload Length ! base document.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ticket ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TICKET_LT_OPAQUE Notify Payload The value of the AUTH payload is derived in a manner similar to the
usage of IKEv2 pre-shared secret authentication:
4.7.2. TICKET_OPAQUE Notify Payload AUTH = prf(SK_px, <message octets>)
The data for the TICKET_OPAQUE Notify payload consists of the Notify Each of the initiator and responder uses its own SK_p value, taken
message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE from the newly generated IKE SA, Section 5.1.
payload no lifetime value is included in the TICKET_OPAQUE Notify
payload.
0 1 2 3 The exact material to be signed is defined in Section 2.15 of
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 [RFC4306].
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ticket ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TICKET_OPAQUE Notify Payload 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.
4.8. Computing the AUTH Payload 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.
The value of the AUTH payload is derived in a manner similar to the 4.3.4. Epilogue
usage of IKEv2 pre-shared secret authentication, as shown below:
AUTH = prf(SK_px, <msg octets>) 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].
Each of the initiator and responder uses its own SK_p value, taken When the responder receives a ticket for an IKE SA that is still
from the newly generated IKE SA, Section 5. 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.
The exact material to be signed is defined in Section 2.15 of 5. IKE and IPsec State After Resumption
[RFC4306]. The notation "IDr'" in RFC 4306 should be applied to the
new IDr value included in the exchange, rather than the value in the
ticket.
5. Processing Guidelines for IKE SA Establishment 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 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 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. gateway needs to resolve the reference in order to obtain this state.
In case the client has already provided a ticket per value, the In case the client has already provided a ticket by value, the
gateway can parse the ticket to obtain the state directly. In either gateway can parse the ticket to obtain the state directly. In either
case, the gateway needs to process the ticket state in order to 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 restore the state of the old IKE SA, and the client retrieves the
same state from its local store. Both peers now create state for the same state from its local store.
new IKE SA as follows:
o The SA value (transforms etc.) is taken directly from the ticket.
o The Message ID values are reset to 0 in IKE_SESSION_RESUME, and
subsequently incremented normally.
o The IDi value is obtained from the ticket.
o The IDr value is obtained from the new exchange. The gateway MAY
make policy decisions based on the IDr value encoded in the
ticket.
o The SPI values are created anew during IKE_SESSION_RESUME,
similarly to a regular IKE_SA_INIT exchange. SPI values from the
ticket MUST NOT be reused, and they are sent merely to help the
gateway to locate the old state. The restriction on SPI reuse is
to avoid problems caused by collisions with other SPI values used
already by the initiator/responder.
The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows:
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
where SK_d_old is taken from the ticket. The literal string is
encoded as 10 ASCII characters, with no NULL terminator.
The keys are derived as follows, unchanged from IKEv2:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
where SPIi, SPIr are the SPI values created in the new IKE exchange.
See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket.
6. The State After Resumption
The following table, compiled by Pasi Eronen, describes the IKE and The following table, compiled by Pasi Eronen, describes the IKE and
IPsec state of the peers after session resumption, and how it is IPsec state of the peers after session resumption, and how it is
related to their state before the IKE SA was interrupted. When the related to their state before the IKE SA was interrupted. When the
table mentions that a certain state item is taken "from the ticket", table mentions that a certain state item is taken "from the ticket",
this should be construed as: this should be construed as:
o The client retrieves this item from its local store. o The client retrieves this item from its local store.
o In the case of ticket by value, the gateway encodes this o In the case of ticket by value, the gateway encodes this
information in the ticket. information in the ticket.
o In the case of ticket by reference, the gateway fetches this o In the case of ticket by reference, the gateway fetches this
information from the ticket store. information from the ticket store.
+--------------------------------------+----------------------------+ +------------------------------------+------------------------------+
| State Item | After Resumption | | State Item | After Resumption |
+--------------------------------------+----------------------------+ +------------------------------------+------------------------------+
| IDi | From the ticket (but must | | IDi | From the ticket (but must |
| | also be exchanged in | | | also be exchanged in |
| | IKE_AUTH). See also Note 1 |
| IDr | From the ticket (but must |
| | also be exchanged in |
| | IKE_AUTH) | | | IKE_AUTH) |
| IDr | From the new exchange (but |
| | old value included in the |
| | ticket) |
| Authentication method (PKI, | From the ticket | | Authentication method (PKI, | From the ticket |
| pre-shared secret, EAP, PKI-less EAP | | | pre-shared secret, EAP, PKI-less | |
| EAP | |
| [I-D.eronen-ipsec-ikev2-eap-auth] | | | [I-D.eronen-ipsec-ikev2-eap-auth] | |
| etc.) | | | etc.) | |
| Certificates (when applicable) | Unspecified, see note 1 | | Certificates (when applicable) | From the ticket, see Note 2 |
| Local IP address/port, peer IP | Selected by the client, | | Local IP address/port, peer IP | Selected by the client, see |
| address/port | see note 2 | | address/port | Note 3 |
| NAT detection status | From new exchange | | NAT detection status | From new exchange |
| SPIs | From new exchange | | SPIs | From new exchange, see Note |
| Which peer is the "original | Determined by the | | | 4 |
| initiator"? | initiator of | | Which peer is the "original | Determined by the initiator |
| | IKE_SESSION_RESUME | | initiator"? | of IKE_SESSION_RESUME |
| IKE SA sequence numbers (Message ID) | Start from 0 | | IKE SA sequence numbers (Message | Reset to 0 in |
| ID) | IKE_SESSION_RESUME, and |
| | subsequently incremented |
| | normally |
| IKE SA algorithms (SAr) | From the ticket | | IKE SA algorithms (SAr) | From the ticket |
| IKE SA keys (SK_*) | SK_d from the ticket, | | IKE SA keys (SK_*) | The old SK_d is obtained |
| | others are refreshed | | | from the ticket and all keys |
| | are refreshed, see |
| | Section 5.1 |
| IKE SA window size | Reset to 1 | | IKE SA window size | Reset to 1 |
| Child SAs (ESP/AH) | Created in new exchange, | | Child SAs (ESP/AH) | Created in new exchange, see |
| | see note 5 | | | Note 7 |
| Internal IP address | Not resumed, but see note | | Internal IP address | Not resumed, but see Note 5 |
| | 3 |
| Other Configuration Payload | Not resumed | | Other Configuration Payload | Not resumed |
| information | | | information | |
| Peer vendor IDs | Unspecified (needed in the | | Peer vendor IDs | Implementation specific |
| | ticket only if | | | (needed in the ticket only |
| | vendor-specific state is | | | if vendor-specific state is |
| | required) | | | required) |
| Peer supports MOBIKE [RFC4555] | From new exchange | | Peer supports MOBIKE [RFC4555] | From new exchange |
| MOBIKE additional addresses | Not resumed, should be | | MOBIKE additional addresses | Not resumed, should be |
| | resent by client if | | | resent by client if |
| | necessary | | | necessary |
| Time until re-authentication | From new exchange (but | | Time until re-authentication | From new exchange (but |
| [RFC4478] | ticket lifetime is bounded | | [RFC4478] | ticket lifetime is bounded |
| | by this duration) | | | by this duration) |
| Peer supports redirects | From new exchange | | Peer supports redirects | From new exchange |
| [I-D.ietf-ipsecme-ikev2-redirect] | | | [I-D.ietf-ipsecme-ikev2-redirect] | |
+--------------------------------------+----------------------------+ +------------------------------------+------------------------------+
Note 1: Certificates don't need to be stored if the peer never uses Note 1: The authenticated peer identity used for policy lookups may
them for anything after the IKE SA is up (but would be not be the same as the IDi payload (see Sec. 3.5 of
needed if exposed to applications via IPsec APIs). [RFC4718]), and if so, MUST be included in the ticket. Note
Note 2: If the certificate has an iPAddress SubjectAltName, and the 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 implementation requires it to match the peer's source IP
address, the same check needs to be performed on session address, the same check needs to be performed on session
resumption and the required information saved locally or in resumption and the required information saved locally or in
the ticket. the ticket.
Note 3: The client can request the address it was using earlier, and 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. if possible, the gateway SHOULD honor the request.
Note 4: IKEv2 features that affect only the IKE_AUTH exchange Note 6: IKEv2 features that affect only the IKE_AUTH exchange
(including HTTP_CERT_LOOKUP_SUPPORTED, multiple (including HTTP_CERT_LOOKUP_SUPPORTED, multiple
authentication exchanges [RFC4739], ECDSA authentication authentication exchanges [RFC4739], ECDSA authentication
[RFC4754], and OCSP [RFC4806]) don't usually need any state [RFC4754], and OCSP [RFC4806]) don't usually need any state
in the IKE SA (after the IKE_AUTH exchanges are done), so in the IKE SA (after the IKE_AUTH exchanges are done), so
resumption doesn't affect them. resumption doesn't affect them.
Note 5: Since information about CHILD SAs and configuration payloads Note 7: Since information about CHILD SAs and configuration payloads
is not resumed, IKEv2 features related to CHILD SA is not resumed, IKEv2 features related to CHILD SA
negotiation (such as IPCOMP_SUPPORTED, negotiation (such as IPCOMP_SUPPORTED,
ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration [I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration
aren't usually affected by session resumption. aren't usually affected by session resumption.
Note 6: New IKEv2 features that are not covered by notes 4 and 5 Note 8: New IKEv2 features that are not covered by notes 6 and 7
should specify how they interact with session resumption. should specify how they interact with session resumption.
7. Ticket Handling 5.1. Generating Cryptographic Material for the Resumed IKE SA
7.1. Ticket Content The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows:
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
where SK_d_old is taken from the ticket. The literal string is
encoded as 10 ASCII characters, with no NULL terminator.
The keys are derived as follows, unchanged from IKEv2:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
where SPIi, SPIr are the SPI values created in the new IKE exchange.
See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket.
6. Ticket Handling
6.1. Ticket Content
When passing a ticket by value to the client, the ticket content MUST When passing a ticket by value to the client, the ticket content MUST
be integrity protected and encrypted. be integrity protected and encrypted.
A ticket by reference does not need to be encrypted, as it does not A ticket by reference does not need to be encrypted, as it does not
contain any sensitive material, such as keying material. However, contain any sensitive material, such as keying material. However,
access to the storage where that sensitive material is stored MUST be access to the storage where that sensitive material is stored MUST be
protected so that only unauthorized access is not allowed. We note protected so that only unauthorized access is not allowed. We note
that such a ticket is analogous to the concept of 'stub', as defined that such a ticket is analogous to the concept of 'stub', as defined
in [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. in [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS.
Although not strictly required for cryptographic protection, it is Although not strictly required for cryptographic protection, it is
RECOMMENDED to integrity-protect the ticket by reference. Failing to RECOMMENDED to integrity-protect the ticket by reference. Failing to
do so could result in various security vulnerabilities on the gateway do so could result in various security vulnerabilities on the gateway
side, depending on the format of the reference. Potential side, depending on the format of the reference. Potential
vulnerabilities include access by the gateway to unintended URLs vulnerabilities include access by the gateway to unintended URLs
(similar to cross-site scripting) or SQL injection. (similar to cross-site scripting) or SQL injection.
When the state is passed by value, the ticket MUST encode at least When the state is passed by value, the ticket MUST encode all state
the following state from an IKE SA. The same state MUST be stored in information marked "from the ticket" in the table on Section 5. The
the ticket store, in the case of ticket by reference. same state MUST be stored in the ticket store, in the case of ticket
by reference.
o IDi, IDr. A ticket by value MUST include a protected expiration time, which is
o SPIi, SPIr. an absolute time value and SHOULD correspond to the value included in
o SAr (the accepted proposal). the TICKET_LT_OPAQUE payload.
o The authentication method used.
o SK_d.
The ticket by value MUST include a key identity field, so that keys The ticket by value MUST additionally include a key identity field,
for encryption and authentication can be changed, and when necessary, so that keys for ticket encryption and authentication can be changed,
algorithms can be replaced. and when necessary, algorithms can be replaced.
7.2. Ticket Identity and Lifecycle 6.2. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted, the client MUST delete its stored ticket. an IKE SA is deleted, the client MUST delete its stored ticket.
Similarly, when credentials associated with the IKE SA are Similarly, when credentials associated with the IKE SA are
invalidated (e.g. when a user logs out), the ticket MUST be deleted. 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 When the IKE SA is rekeyed the ticket is invalidated, and the client
SHOULD request a new ticket. SHOULD request a new ticket.
The lifetime of the ticket sent by the gateway SHOULD be the minimum 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- of the IKE SA lifetime (per the gateway's local policy) and its re-
skipping to change at page 17, line 43 skipping to change at page 17, line 27
these are enforced by the gateway, a finite lifetime MUST be these are enforced by the gateway, a finite lifetime MUST be
specified for the ticket. specified for the ticket.
The key that is used to protect the ticket MUST have a lifetime that The key that is used to protect the ticket MUST have a lifetime that
is significantly longer than the lifetime of an IKE SA. is significantly longer than the lifetime of an IKE SA.
In normal operation, the client will request a ticket when In normal operation, the client will request a ticket when
establishing the initial IKE SA, and then every time the SA is establishing the initial IKE SA, and then every time the SA is
rekeyed or re-established because of re-authentication. rekeyed or re-established because of re-authentication.
7. IKE Notifications
This document defines a number of notifications. The notification
numbers are TBA by IANA.
+-------------------+--------+-----------------+
| Notification Name | Number | Data |
+-------------------+--------+-----------------+
| TICKET_LT_OPAQUE | TBA1 | See Section 7.1 |
| TICKET_REQUEST | TBA2 | None |
| TICKET_ACK | TBA3 | None |
| TICKET_NACK | TBA4 | None |
| TICKET_OPAQUE | TBA5 | See Section 7.2 |
+-------------------+--------+-----------------+
For all these notifications, the Protocol ID and the SPI Size fields
MUST both be sent as 0.
7.1. TICKET_LT_OPAQUE Notify Payload
The data for the TICKET_LT_OPAQUE Notify payload consists of the
Notify message header, a Lifetime field and the ticket itself. The
four octet Lifetime field contains a relative time value, the number
of seconds until the ticket expires (encoded as an unsigned integer).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ticket ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TICKET_LT_OPAQUE Notify Payload
7.2. TICKET_OPAQUE Notify Payload
The data for the TICKET_OPAQUE Notify payload consists of the Notify
message header, and the 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 8. IANA Considerations
This document requires a number of IKEv2 notification status types in This document requires a number of IKEv2 notification status types in
Section 4.7, to be registered by IANA. The "IKEv2 Notify Message Section 7, to be registered by IANA. The "IKEv2 Notify Message Types
Types - Status Types" registry was established by IANA. - Status Types" registry was established by IANA.
The document defines a new IKEv2 exchange in Section 4.3. The The document defines a new IKEv2 exchange in Section 4.3. The
corresponding registry was established by IANA. corresponding registry was established by IANA.
9. Security Considerations 9. Security Considerations
This section addresses security issues related to the usage of a This section addresses security issues related to the usage of a
ticket. ticket.
9.1. Stolen Tickets 9.1. Stolen Tickets
An man-in-the-middle may try to eavesdrop on an exchange to obtain a 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 ticket by value and use it to establish a session with the IKEv2
responder. This can happen in different ways: by eavesdropping on responder. Since all exchanges where the client obtains a ticket are
the initial communication and copying the ticket when it is granted encrypted, this is only possible by listening in on a client's use of
and before it is used, or by listening in on a client's use of the the ticket to resume a session. However, since the ticket's contents
ticket to resume a session. However, since the ticket's contents is are encrypted and the attacker does not know the corresponding secret
encrypted and the attacker does not know the corresponding secret
key, a stolen ticket cannot be used by an attacker to successfully key, a stolen ticket cannot be used by an attacker to successfully
resume a session. An IKEv2 responder MUST use strong encryption and resume a session. An IKEv2 responder MUST use strong encryption and
integrity protection of the ticket to prevent an attacker from integrity protection of the ticket to prevent an attacker from
obtaining the ticket's contents, e.g., by using a brute force attack. 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 A ticket by reference does not need to be encrypted. When an
adversary is able to eavesdrop on an exchange, as described in the adversary is able to eavesdrop on a resumption attempt, as described
previous paragraph, then the ticket by reference may be obtained. A in the previous paragraph, then the ticket by reference may be
ticket by reference cannot be used by an attacker to successfully obtained. A ticket by reference cannot be used by an attacker to
resume a session, for the same reasons as for a ticket by value. successfully resume a session, for the same reasons as for a ticket
Moreover, the adversary MUST NOT be able to resolve the ticket via by value. Moreover, the adversary MUST NOT be able to resolve the
the reference, i.e., access control MUST be enforced to ensure ticket via the reference, i.e., access control MUST be enforced to
disclosure only to authorized entities. ensure disclosure only to authorized entities.
9.2. Forged Tickets 9.2. Forged Tickets
A malicious user could forge or alter a ticket by value in order to 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 resume a session, to extend its lifetime, to impersonate as another
user, or to gain additional privileges. This attack is not possible user, or to gain additional privileges. This attack is not possible
if the content of the ticket by value is protected using a strong if the content of the ticket by value is protected using a strong
integrity protection algorithm. integrity protection algorithm.
In case of a ticket by reference an adversary may attempt to In case of a ticket by reference an adversary may attempt to
construct a fake ticket by reference to point to state information construct a fake ticket by reference to point to state information
stored by the IKEv2 responder. This attack will fail because the stored by the IKEv2 responder. This attack will fail because the
adversary is not in possession of the keying material associated with adversary is not in possession of the keying material associated with
the IKEv2 SA. As noted in Section 7.1, it is often useful to the IKEv2 SA. As noted in Section 6.1, it is often useful to
integrity-protect the ticket by reference, too. integrity-protect the ticket by reference, too.
9.3. Denial of Service Attacks 9.3. Denial of Service Attacks
An adversary could generate and send a large number of tickets by An adversary could generate and send a large number of tickets by
value to a gateway for verification. To minimize the possibility of value to a gateway for verification. To minimize the possibility of
such denial of service, ticket verification should be lightweight such denial of service, ticket verification should be lightweight
(e.g., using efficient symmetric key cryptographic algorithms). (e.g., using efficient symmetric key cryptographic algorithms).
When an adversary chooses to send a large number of tickets by When an adversary chooses to send a large number of tickets by
skipping to change at page 19, line 41 skipping to change at page 20, line 47
An IKEv2 responder controls the validity period of the state An IKEv2 responder controls the validity period of the state
information by attaching a lifetime to a ticket. The chosen lifetime information by attaching a lifetime to a ticket. The chosen lifetime
is based on the operational and security requirements of the is based on the operational and security requirements of the
environment in which this IKEv2 extension is deployed. The responder environment in which this IKEv2 extension is deployed. The responder
provides information about the ticket lifetime to the IKEv2 provides information about the ticket lifetime to the IKEv2
initiator, allowing it to manage its tickets. initiator, allowing it to manage its tickets.
9.6. Ticket by Value Format 9.6. Ticket by Value Format
Great care must be taken when defining a ticket format such that the The ticket's format is not defined by this document, since this is
requirements outlined in Section 7.1 are met. In particular, if not required for interoperability. However great care must be taken
confidential information, such as a secret key, is transferred to the when defining a ticket format such that the requirements outlined in
client it MUST be done using channel security to prevent attackers Section 6.1 are met. The ticket by value MUST have its integrity and
from obtaining or modifying the ticket. Also, the ticket by value confidentiality protected with strong cryptographic techniques to
MUST have its integrity and confidentiality protected with strong prevent a breach in the security of the system.
cryptographic techniques to prevent a breach in the security of the
system.
9.7. Identity Privacy, Anonymity, and Unlinkability 9.7. Identity Privacy, Anonymity, and Unlinkability
Since opaque state information is passed around between the IKEv2 Since opaque state information is passed around between the IKEv2
initiator and the IKEv2 responder it is important that leakage of initiator and the IKEv2 responder it is important that leakage of
information, such as the identities of an IKEv2 initiator and a information, such as the identities of an IKEv2 initiator and a
responder, MUST be avoided. responder, MUST be avoided.
When an IKEv2 initiator presents a ticket as part of the When an IKEv2 initiator presents a ticket as part of the
IKE_SESSION_RESUME exchange, confidentiality is not provided for the IKE_SESSION_RESUME exchange, confidentiality is not provided for the
skipping to change at page 20, line 28 skipping to change at page 21, line 28
This document therefore requires that the ticket be presented to the This document therefore requires that the ticket be presented to the
IKEv2 responder only once; under normal circumstances (e.g. no active IKEv2 responder only once; under normal circumstances (e.g. no active
attacker), there should be no multiple use of the same ticket. attacker), there should be no multiple use of the same ticket.
10. Acknowledgements 10. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ
Housely, Yoav Nir and Tero Kivinen for their comments. We would like Housely, Yoav Nir and Tero Kivinen for their comments. We would like
to particularly thank Florian Tegeler and Stjepan Gros for their help to particularly thank Florian Tegeler and Stjepan Gros for their
with their implementation efforts and Florian Tegeler for his formal implementation efforts and Florian Tegeler for a formal verification
verification using the CASPER tool set. using the Casper tool set.
We would furthermore like to thank the authors of We would furthermore like to thank the authors of
[I-D.xu-ike-sa-sync](Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke [I-D.xu-ike-sa-sync](Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke
Xu) for their input on the stub concept. Xu) for their input on the stub concept.
We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad
Muhanna and Stephen Kent for their feedback regarding the ticket by Muhanna and Stephen Kent for their feedback regarding the ticket by
reference concept. reference concept.
Vidya Narayanan and Lakshminath Dondeti coauthored several past
versions of this document, and we acknowledge their significant
contribution.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
11.2. Informative References 11.2. Informative References
[I-D.eronen-ipsec-ikev2-eap-auth] [I-D.eronen-ipsec-ikev2-eap-auth]
Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
for EAP-Only Authentication in IKEv2", for EAP-Only Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress), draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress),
April 2009. April 2009.
[I-D.ietf-ipsecme-ikev2-redirect] [I-D.ietf-ipsecme-ikev2-redirect]
Devarapalli, V. and K. Weniger, "Redirect Mechanism for Devarapalli, V. and K. Weniger, "Redirect Mechanism for
IKEv2", draft-ietf-ipsecme-ikev2-redirect-09 (work in IKEv2", draft-ietf-ipsecme-ikev2-redirect-10 (work in
progress), May 2009. progress), May 2009.
[I-D.ietf-ipsecme-ikev2bis] [I-D.ietf-ipsecme-ikev2bis]
Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol: IKEv2", "Internet Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis-03 (work in progress), draft-ietf-ipsecme-ikev2bis-03 (work in progress),
April 2009. April 2009.
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] [I-D.ietf-rohc-ikev2-extensions-hcoipsec]
Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and
skipping to change at page 24, line 23 skipping to change at page 25, line 23
int32 expiration; // an absolute time value, seconds int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970 // since Jan. 1, 1970
} ikev2_state_ref; } ikev2_state_ref;
} protected_part; } protected_part;
opaque MAC[0..255]; // the length depends opaque MAC[0..255]; // the length depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
Appendix B. Change Log Appendix B. Change Log
B.1. -04 Note to RFC Editor: remove this appendix before publication.
B.1. -05
Editorial changes: reordered and merged some sections.
Restated the use cases.
IDr is not negotiated during resumption, the gateway must use the
stored IDr.
Multiple small clarifications based on Pasi's LC review.
IPR: pre5378Trust200902.
B.2. -04
Closed issue #105, Non-PKI use of EAP, and resumption. Closed issue #105, Non-PKI use of EAP, and resumption.
Closed issue #106, Resumption and NAT detection and changing ports. Closed issue #106, Resumption and NAT detection and changing ports.
B.2. -03 B.3. -03
Changed the protocol from one to two round trips, to simplify the Changed the protocol from one to two round trips, to simplify the
security assumptions. Eliminated security considerations associated security assumptions. Eliminated security considerations associated
with the previous version. with the previous version.
Closed issue #69, Clarify behavior of SPI and sequence numbers. Closed issue #69, Clarify behavior of SPI and sequence numbers.
Closed issue #70, Ticket lifetime - explicit or not? (and ticket push Closed issue #70, Ticket lifetime - explicit or not? (and ticket push
from gateway). from gateway).
skipping to change at page 25, line 9 skipping to change at page 26, line 24
Closed issue #95, Minor nits for ikev2-resumption-02. Closed issue #95, Minor nits for ikev2-resumption-02.
Closed issue #97, Clarify what state comes from where. Closed issue #97, Clarify what state comes from where.
Closed issue #98, Replays in 1-RTT protocol. Closed issue #98, Replays in 1-RTT protocol.
Closed issue #100, NAT detection [and] IP address change. Closed issue #100, NAT detection [and] IP address change.
Closed issue #101, Assorted issues by Tero. Closed issue #101, Assorted issues by Tero.
B.3. -02 B.4. -02
Added a new TICKET_OPAQUE payload that does not have a lifetime field Added a new TICKET_OPAQUE payload that does not have a lifetime field
included. included.
Removed the lifetime usage from the IKE_SESSION_RESUME exchange Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE) when presenting the ticket to the (utilizing the TICKET_OPAQUE) when presenting the ticket to the
gateway. gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange. Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec child SAs would be deleted once the old IKE SA Clarified that IPsec child SAs would be deleted once the old IKE SA
gets deleted as well. gets deleted as well.
Clarified the behavior of SPI and sequence number usage. Clarified the behavior of SPI and sequence number usage.
B.4. -01 B.5. -01
Addressed issue#75, see Addressed issue#75, see
http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included
changes throughout the document to ensure that the ticket may contain changes throughout the document to ensure that the ticket may contain
a reference or a value. a reference or a value.
B.5. -00 B.6. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.6. -01 B.7. -01
Added reference to [I-D.xu-ike-sa-sync] Added reference to [I-D.xu-ike-sa-sync]
Included recommended ticket format into the appendix Included recommended ticket format into the appendix
Various editorial improvements within the document Various editorial improvements within the document
B.7. -00 B.8. -00
Issued a -00 version for the IPSECME working group. Reflected Issued a -00 version for the IPSECME working group. Reflected
discussions at IETF#72 regarding the strict focus on session discussions at IETF#72 regarding the strict focus on session
resumption. Consequently, text about failover was removed. resumption. Consequently, text about failover was removed.
B.8. -04 B.9. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.9. -03 B.10. -03
Removed counter mechanism. Added an optional anti-DoS mechanism, Removed counter mechanism. Added an optional anti-DoS mechanism,
based on IKEv2 cookies (removed previous discussion of cookies). based on IKEv2 cookies (removed previous discussion of cookies).
Clarified that gateways may support reallocation of same IP address, Clarified that gateways may support reallocation of same IP address,
if provided by network. Proposed a solution outline to the problem if provided by network. Proposed a solution outline to the problem
of key exchange for the keys that protect tickets. Added fields to of key exchange for the keys that protect tickets. Added fields to
the ticket to enable interoperability. Removed incorrect MOBIKE the ticket to enable interoperability. Removed incorrect MOBIKE
notification. notification.
B.10. -02 B.11. -02
Clarifications on generation of SPI values, on the ticket's lifetime Clarifications on generation of SPI values, on the ticket's lifetime
and on the integrity protection of the anti-replay counter. and on the integrity protection of the anti-replay counter.
Eliminated redundant SPIs from the notification payloads. Eliminated redundant SPIs from the notification payloads.
B.11. -01 B.12. -01
Editorial review. Removed 24-hour limitation on ticket lifetime, Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy. lifetime is up to local policy.
B.12. -00 B.13. -00
Initial version. This draft is a selective merge of Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00. draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
skipping to change at page 27, line 4 skipping to change at page 28, line 14
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
Tel Aviv 67897 Tel Aviv 67897
Israel Israel
Email: yaronf@checkpoint.com Email: yaronf@checkpoint.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
 End of changes. 91 change blocks. 
318 lines changed or deleted 388 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/