draft-ietf-ipsecme-ikev2-resumption-09.txt   rfc5723.txt 
Network Working Group Y. Sheffer Internet Engineering Task Force (IETF) Y. Sheffer
Internet-Draft Check Point Request for Comments: 5723 Check Point
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: April 24, 2010 Nokia Siemens Networks ISSN: 2070-1721 Nokia Siemens Networks
October 21, 2009 January 2010
IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-09.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Internet Key Exchange Protocol Version 2 (IKEv2)
Provisions Relating to IETF Documents in effect on the date of Session Resumption
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
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 remote access situations, the Extensible Authentication Protocol In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips (EAP) is used for authentication, which adds several more round trips
and consequently latency. and consequently latency.
To re-establish security associations (SAs) upon a failure recovery To re-establish security associations (SAs) 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 endpoints. 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 encodes partial IKE state into an opaque The proposed approach encodes partial IKE state into an opaque
ticket, which can be stored on the client or in a centralized store, ticket, which can be stored on the client or in a centralized store,
and is later made available to the IKEv2 responder for re- and is later made available to the IKEv2 responder for re-
authentication. We use the term ticket to refer to the opaque data authentication. We use the term ticket to refer to the opaque data
that is created by the IKEv2 responder. This document does not that is created by the IKEv2 responder. This document does not
specify the format of the ticket but examples are provided. specify the format of the ticket but examples are provided.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5723.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................5
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenario ..................................................5
4. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Sequences ..............................................7
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 8 4.1. Requesting a Ticket ........................................7
4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9 4.2. Receiving a Ticket .........................................8
4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 4.3. Presenting a Ticket ........................................9
4.3.1. Prologue . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Prologue ............................................9
4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10 4.3.2. IKE_SESSION_RESUME Exchange ........................10
4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 4.3.3. IKE_AUTH Exchange ..................................11
4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Epilogue ...........................................12
5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13 5. IKE and IPsec State after Resumption ...........................12
5.1. Generating Cryptographic Material for the Resumed IKE 5.1. Generating Cryptographic Material for the Resumed IKE SA ..15
SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Ticket Handling ................................................16
6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Ticket Content ............................................16
6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Ticket Identity and Lifecycle .............................16
6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 7. IKE Notifications ..............................................17
7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17 7.1. TICKET_LT_OPAQUE Notify Payload ...........................17
7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18 7.2. TICKET_OPAQUE Notify Payload ..............................18
7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 8. IANA Considerations ............................................18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations ........................................19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. Stolen Tickets ............................................19
9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Forged Tickets ............................................19
9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Denial-of-Service Attacks .................................20
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20 9.4. Detecting the Need for Resumption .........................20
9.4. Detecting the Need for Resumption . . . . . . . . . . . . 20 9.5. Key Management for "Tickets by Value" .....................20
9.5. Key Management for Tickets By Value . . . . . . . . . . . 20 9.6. Ticket Lifetime ...........................................21
9.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 21 9.7. Tickets and Identity ......................................21
9.7. Tickets and Identity . . . . . . . . . . . . . . . . . . . 21 9.8. Ticket Revocation .........................................21
9.8. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21 9.9. Ticket by Value Format ....................................21
9.9. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21 9.10. Identity Privacy, Anonymity, and Unlinkability ...........22
9.10. Identity Privacy, Anonymity, and Unlinkability . . . . . . 22 10. Acknowledgements ..............................................22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. References ....................................................23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References .....................................23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References ...................................23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Ticket Format ........................................25
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24 A.1. Example "Ticket by Value" Format ..........................25
A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 25 A.2. Example "Ticket by Reference" Format ......................25
A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
B.1. -09 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. -08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.3. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.7. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.13. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.14. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.15. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.16. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.17. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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 (SAs) 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 endpoints. A high number of concurrent sessions might cause
additional problems for an IPsec responder. Usability is also additional problems for an IPsec responder. Usability is also
affected when the re-establishment of an IKE SA involves user affected when the re-establishment of an IKE SA involves user
interaction for reauthentication. interaction for re-authentication.
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.
The client (IKEv2 initiator) stores the state about the previous IKE The client (IKEv2 initiator) stores the state about the previous IKE
SA locally. The gateway (IKEv2 responder) has two options for SA locally. The gateway (IKEv2 responder) has two options for
maintaining the IKEv2 state about the previous IKE SA: maintaining the IKEv2 state about the previous IKE SA:
o In the "ticket by reference" approach, the gateway stores the o In the "ticket by reference" approach, the gateway stores the
skipping to change at page 5, line 36 skipping to change at page 4, line 36
The client (IKEv2 initiator) stores the state about the previous IKE The client (IKEv2 initiator) stores the state about the previous IKE
SA locally. The gateway (IKEv2 responder) has two options for SA locally. The gateway (IKEv2 responder) has two options for
maintaining the IKEv2 state about the previous IKE SA: maintaining the IKEv2 state about the previous IKE SA:
o In the "ticket by reference" approach, the gateway stores the o In the "ticket by reference" approach, the gateway stores the
state locally, and gives the client a protected and opaque state locally, and gives the client a protected and opaque
reference (e.g., an index to the gateway's table) that the gateway reference (e.g., an index to the gateway's table) that the gateway
can later use to find the state. The client includes this opaque can later use to find the state. The client includes this opaque
reference when it resumes the session. reference when it resumes the session.
o In the "ticket by value" approach, the gateway stores its state in o In the "ticket by value" approach, the gateway stores its state in
a ticket (data structure) that is encrypted and integrity- a ticket (data structure) that is encrypted and integrity-
protected by a key known only to the gateway. The ticket is protected by a key known only to the gateway. The ticket is
passed to the client (who treats the ticket as an opaque string), passed to the client (who treats the ticket as an opaque string)
and sent back to the gateway when the session is resumed. The and sent back to the gateway when the session is resumed. The
gateway can then decrypt the ticket and recover the state. gateway can then decrypt the ticket and recover the state.
Note that the client behaves identically in both cases, and in Note that the client behaves identically in both cases, and in
general does not know which approach the gateway is using. Since the general does not know which approach the gateway is using. Since the
ticket (or reference) is only interpreted by the same party that ticket (or reference) is only interpreted by the same party that
created it, this document does not specify the exact format for it. created it, this document does not specify the exact format for it.
However, Appendix A contains examples for both "ticket by reference" However, Appendix A contains examples for both "ticket by reference"
and "ticket by value" formats. and "ticket by value" formats.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by Transport Layer Security
[RFC5077] with the required adaptations for IKEv2, e.g., to (TLS) session resumption [RFC5077] with the required adaptations for
accommodate the two-phase protocol structure. We have borrowed IKEv2, e.g., to accommodate the two-phase protocol structure. We
heavily from that specification. have borrowed 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.
o Having no negative impact on IKEv2 security features. o Having no negative impact on IKEv2 security features.
The following are non-goals of this solution: The following are non-goals of this solution:
o Failover from one gateway to another. This use case may be added o Failover from one gateway to another. This use case may be added
in a future specification. in a future specification.
o Providing load balancing among gateways. o Providing load balancing among gateways.
o Specifying how a client detects the need for resumption. o Specifying how a client detects the need for resumption.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terminology defined in [RFC4301] and [RFC4306]. This document uses terminology defined in [RFC4301] and [RFC4306].
In addition, this document uses the following terms: In addition, this document uses the following term:
Ticket: An IKEv2 ticket is a data structure that contains all the Ticket: An IKEv2 ticket is a data structure that contains all the
necessary information that allows an IKEv2 responder to re- necessary information that allows an IKEv2 responder to re-
establish an IKEv2 security association. establish an IKEv2 security association.
In this document we use the term "ticket" and thereby refer to an In this document, we use the term "ticket" and thereby refer to an
opaque data structure that may either contain IKEv2 state as opaque data structure that may either contain IKEv2 state as
described above or a reference pointing to such state. described above or a reference pointing to such state.
3. Usage Scenario 3. Usage Scenario
This specification envisions two usage scenarios for efficient IKEv2 This specification envisions two usage scenarios for efficient IKEv2
and IPsec SA session re-establishment. and IPsec SA session re-establishment.
The first is similar to the use case specified in Section 1.1.3 of The first is similar to the use case specified in Section 1.1.3 of
the IKEv2 specification [RFC4306], where the IPsec tunnel mode is the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
used to establish a secure channel between a remote access client and used to establish a secure channel between a remote access client and
a gateway; the traffic flow may be between the client and entities a gateway; the traffic flow may be between the client and entities
beyond the gateway. This scenario is further discussed below. beyond the gateway. This scenario is further discussed below.
The second use case focuses on the usage of transport (or tunnel) The second use case focuses on the usage of transport (or tunnel)
mode to secure the communicate between two end points (e.g., two mode to secure the communicate between two endpoints (e.g., two
servers). The two endpoints have a client-server relationship with servers). The two endpoints have a client-server relationship with
respect to a protocol that runs using the protections afforded by the respect to a protocol that runs using the protections afforded by the
IPsec SA. IPsec SA.
(a) (a)
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IKEv2/IKEv2-EAP | | Protected | | IKEv2/IKEv2-EAP | | Protected
| Remote |<------------------------>| | Subnet | Remote |<------------------------>| | Subnet
| Access | | Access |<--- and/or | Access | | Access |<--- and/or
skipping to change at page 7, line 33 skipping to change at page 6, line 43
| Client |<------------------------>| Gateway | | Client |<------------------------>| Gateway |
| | IPsec tunnel | | | | IPsec tunnel | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
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,
may choose to establish IPsec SAs using a full IKEv2 exchange or the it may choose to establish IPsec SAs using a full IKEv2 exchange or
IKE_SESSION_RESUME exchange (shown in Figure 1). the IKE_SESSION_RESUME exchange (shown in Figure 1).
For either of the above use cases, there are multiple possible For either of the above use cases, there are multiple possible
situations where the mechanism specified in this document could be situations where the mechanism specified in this document could be
useful. These include the following (note that this list is not useful. These include the following (note that this list is not
meant to be exhaustive, and any particular deployment may not care meant to be exhaustive, and any particular deployment may not care
about all of these): about all of these):
o If a client temporarily loses network connectivity (and the IKE SA o If a client temporarily loses network connectivity (and the IKE SA
times out through the liveness test facility, a.k.a. "dead peer times out through the liveness test facility, a.k.a. "dead peer
detection"), this mechanism could be used to re-establish the SA detection"), this mechanism could be used to re-establish the SA
skipping to change at page 8, line 5 skipping to change at page 7, line 10
situations where the mechanism specified in this document could be situations where the mechanism specified in this document could be
useful. These include the following (note that this list is not useful. These include the following (note that this list is not
meant to be exhaustive, and any particular deployment may not care meant to be exhaustive, and any particular deployment may not care
about all of these): about all of these):
o If a client temporarily loses network connectivity (and the IKE SA o If a client temporarily loses network connectivity (and the IKE SA
times out through the liveness test facility, a.k.a. "dead peer times out through the liveness test facility, a.k.a. "dead peer
detection"), this mechanism could be used to re-establish the SA detection"), this mechanism could be used to re-establish the SA
with less overhead (network, CPU, authentication infrastructure) with less overhead (network, CPU, authentication infrastructure)
and without requiring user interaction for authentication. and without requiring user interaction for authentication.
o If the connectivity problems affect a large number of clients o If the connectivity problems affect a large number of clients
(e.g., a large remote access VPN gateway), when the connectivity (e.g., a large remote access VPN gateway), when the connectivity
is restored, all the clients might reconnect almost is restored, all the clients might reconnect almost
simultaneously. This mechanism could be used to reduce the load simultaneously. This mechanism could be used to reduce the load
spike for cryptographic operations and authentication spike for cryptographic operations and authentication
infrastructure. infrastructure.
o Losing connectivity can also be predictable and planned; for o Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling. example, putting a laptop to "stand-by" mode before traveling.
This mechanism could be used to re-establish the SA when the This mechanism could be used to re-establish the SA when the
laptop is switched back on (again, with less overhead and without laptop is switched back on (again, with less overhead and without
requiring user interaction for authentication). However such requiring user interaction for authentication). However, such
user-level "resumption" may often be disallowed by policy. user-level "resumption" may often be disallowed by policy.
Moreover, this document requires the client to destroy the ticket Moreover, this document requires the client to destroy the ticket
when the user explicitly "logs out" (Section 6.2). when the user explicitly "logs out" (Section 6.2).
4. Protocol Sequences 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.
skipping to change at page 8, line 33 skipping to change at page 7, line 40
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, or ticket, or when the ticket lifetime is about to expire, or
following a gateway-initiated IKE rekey. All such Informational following a gateway-initiated IKE rekey. All such Informational
exchanges MUST be initiated by the client. 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.3.3. 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 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 [IKEV2-BIS] 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.
o it returns an N(TICKET_NACK) payload, if it refuses to grant a o it returns an N(TICKET_NACK) payload, if it refuses to grant a
ticket for some reason. ticket for some reason.
o it returns an N(TICKET_ACK), if it cannot grant a ticket o it returns an N(TICKET_ACK), if it cannot grant a ticket
immediately, e.g., due to packet size limitations. In this case immediately, e.g., due to packet size limitations. In this case,
the client MAY request a ticket later using an Informational the client MAY request a ticket later using an Informational
exchange, at any time during the lifetime of the IKE SA. exchange, at any time during the lifetime of the IKE SA.
Regardless of this choice, there is no change to the behavior of the Regardless of this choice, there is no change to the behavior of the
responder with respect to the IKE exchange, and the proper IKE responder with respect to the IKE exchange, and the proper IKE
response (e.g. an IKE_AUTH response or an error notification) MUST be response (e.g., an IKE_AUTH response or an error notification) MUST
sent. be sent.
4.2. Receiving a Ticket 4.2. Receiving a Ticket
The IKEv2 initiator receives the ticket and may accept it, provided The IKEv2 initiator receives the ticket and may accept it, provided
the IKEv2 exchange was successful. The ticket may be used later with the IKEv2 exchange was successful. The ticket may be used later with
an IKEv2 responder that supports this extension. Figure 3 shows how an IKEv2 responder that supports this extension. Figure 3 shows how
the initiator receives the ticket. the initiator receives the ticket.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
skipping to change at page 10, line 13 skipping to change at page 9, line 18
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 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. for later use, along with the IKE SA to which the ticket refers.
Since the ticket itself is opaque to the client, the local storage 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 MUST also include all items marked as "from the ticket" in the table
of Section 5. of Section 5.
4.3. Presenting a Ticket 4.3. Presenting a Ticket
When the client wishes to recover from an interrupted session, it When the client wishes to recover from an interrupted session, it
presents the ticket to resume the session. This section describes presents the ticket to resume the session. This section describes
the resumption process, consisting of some preparations, an the resumption process, consisting of some preparations, an
IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization. IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization.
skipping to change at page 10, line 36 skipping to change at page 9, line 41
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 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange
even if it is in possession of a valid, unexpired ticket. A client 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 MUST NOT present a ticket when it knows that the ticket's lifetime
has expired. 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
ticket. A reused ticket SHOULD be rejected by a gateway. Note that a ticket. A reused ticket SHOULD be rejected by a gateway. Note
a ticket is considered as used only when an IKE SA has been that 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 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 38. This exchange is equivalent to
equivalent to the IKE_SA_INIT exchange, and MUST be followed by an the IKE_SA_INIT exchange, and MUST be followed by an IKE_AUTH
IKE_AUTH exchange. The client SHOULD NOT use this exchange type exchange. The client SHOULD NOT use this exchange type unless it
unless it knows that the gateway supports it (this condition is knows that the gateway supports it (this condition is trivially true
trivially true in the context of the current document, since the in the context of the current document, since the client always
client always resumes into the same gateway that generated the resumes into the same gateway that generated the ticket).
ticket).
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] --> HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
Figure 4: IKEv2 Initiator wishes to resume an IKE SA 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, unique value and initiator sets the SPIi (Security Parameter Index, Initiator) value
the SPIr value is set to 0. in the HDR to a new, unique value and the SPIr value is set to 0.
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 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
extension defined in this document: the 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 5. 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
skipping to change at page 11, line 34 skipping to change at page 10, line 45
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 5: 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, unique value. is set to a new, unique value.
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 o The client MAY resume the IKE exchange from any IP address and
port, regardless of its original address. The gateway MAY reject port, regardless of its original address. The gateway MAY reject
the resumed exchange if its policy depends on the client's address the resumed exchange if its policy depends on the client's address
(although this rarely makes sense). (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 (DoS)
with the initiator instructed to send a cookie. situations, 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 o The client's NAT traversal status SHOULD be determined anew in
IKE_SESSION_RESUME. If NAT is detected, the initiator switches to IKE_SESSION_RESUME. If NAT is detected, the initiator switches to
UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT UDP encapsulation on port 4500, as per [RFC4306], Section 2.23.
status is explicitly not part of the session resumption state. 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.
Although the IKE SA is not fully valid until the completion of the 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 IKE_AUTH exchange, the peers must create much of the SA state
(Section 5) now. Specifically, the shared key values are required to (Section 5) now. Specifically, the shared key values are required to
protect the IKE_AUTH payloads. Their generation is described in protect the IKE_AUTH payloads. Their generation is described in
Section 5.1. Section 5.1.
4.3.3. IKE_AUTH Exchange 4.3.3. IKE_AUTH Exchange
skipping to change at page 12, line 36 skipping to change at page 11, line 51
This section lists the differences and constraints compared to the This section lists the differences and constraints compared to the
base document. base document.
The value of the AUTH payload is derived in a manner similar to the The value of the AUTH payload is derived in a manner similar to the
usage of IKEv2 pre-shared secret authentication: usage of IKEv2 pre-shared secret authentication:
AUTH = prf(SK_px, <message octets>) AUTH = prf(SK_px, <message octets>)
Each of the initiator and responder uses its own value for SK_px, Each of the initiator and responder uses its own value for SK_px,
namely SK_pi for the initiator and SK_pr for the responder. Both are namely SK_pi for the initiator and SK_pr for the responder. Both are
taken from the newly generated IKE SA, Section 5.1. taken from the newly generated IKE SA (Section 5.1).
The exact material to be signed is defined in Section 2.15 of The exact material to be signed is defined in Section 2.15 of
[RFC4306]. [RFC4306].
The IDi value sent in the IKE_AUTH exchange MUST be identical to the 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 value included in the ticket. A CERT payload MUST NOT be included in
this exchange, and therefore a new IDr value cannot be negotiated this exchange, and therefore a new IDr value cannot be negotiated
(since it would not be authenticated). As a result, the IDr value (since it would not be authenticated). As a result, the IDr value
sent (by the gateway, and optionally by the client) in this exchange sent (by the gateway, and optionally by the client) in this exchange
MUST also be identical to the value included in the ticket. MUST also be identical to the value included in the ticket.
skipping to change at page 13, line 17 skipping to change at page 12, line 31
Section 4.1. The returned ticket (if any) will correspond to the IKE Section 4.1. The returned ticket (if any) will correspond to the IKE
SA created per the rules described in Section 5. SA created per the rules described in Section 5.
4.3.4. Epilogue 4.3.4. Epilogue
Following the IKE_AUTH exchange, a new IKE SA is created by both 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 parties, see Section 5, and a Child SA is derived, per Section 2.17
of [RFC4306]. of [RFC4306].
When the responder receives a ticket for an IKE SA that is still When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it (i.e. following successful active and if the responder accepts it (i.e., following successful
completion of the IKE_AUTH exchange), the old SA SHOULD be silently completion of the IKE_AUTH exchange), the old SA SHOULD be silently
deleted without sending a DELETE informational exchange. deleted without sending a DELETE informational exchange.
Consequently, all the dependent IPsec Child SAs are also deleted. Consequently, all the dependent IPsec Child SAs are also deleted.
5. IKE and IPsec State After Resumption 5. IKE and IPsec State after Resumption
During the resumption process, both peers create IKE and IPsec state During the resumption process, both peers create IKE and IPsec state
for the resumed IKE SA. Although the SA is only completed following for the resumed IKE SA. Although the SA is only completed following
a successful IKE_AUTH exchange, many of its components are created a successful IKE_AUTH exchange, many of its components are created
earlier, notably the SA's crypto material (Section 5.1). 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,
gateway needs to resolve the reference in order to obtain this state. the gateway needs to resolve the reference in order to obtain this
In case the client has already provided a ticket by value, the state. In case the client has already provided a "ticket by value",
gateway can parse the ticket to obtain the state directly. In either the gateway can parse the ticket to obtain the state directly. In
case, the gateway needs to process the ticket state in order to either case, the gateway needs to process the ticket state in order
restore the state of the old IKE SA, and the client retrieves the to restore the state of the old IKE SA, and the client retrieves the
same state from its local store. same state from its local store.
The following table describes the IKE and IPsec state of the peers The following table describes the IKE and IPsec state of the peers
after session resumption, and how it is related to their state before after session resumption, and how it is related to their state before
the IKE SA was interrupted. When the table mentions that a certain the IKE SA was interrupted. When the table mentions that a certain
state item is taken "from the ticket", this should be construed as: state item is taken "from the ticket", 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 |
| | also be exchanged in | | | be exchanged in IKE_AUTH). See |
| | IKE_AUTH). See also Note 1 | | | also Note 1. |
| IDr | From the ticket (but must | | | |
| | also be exchanged in | | IDr | From the ticket (but must also |
| | IKE_AUTH) | | | be exchanged in IKE_AUTH). |
| Authentication method (PKI, | From the ticket | | | |
| pre-shared secret, EAP, PKI-less | | | Authentication method (PKI, | From the ticket. |
| EAP | | | pre-shared secret, EAP, | |
| [I-D.eronen-ipsec-ikev2-eap-auth] | | | PKI-less EAP [EAP-AUTH] etc.) | |
| etc.) | | | | |
| Certificates (when applicable) | From the ticket, see Note 2 | | Certificates (when applicable) | From the ticket, see Note 2. |
| Local IP address/port, peer IP | Selected by the client, see | | | |
| address/port | Note 3 | | Local IP address/port, peer IP | Selected by the client, see Note |
| NAT detection status | From new exchange | | address/port | 3. |
| SPIs | From new exchange, see Note | | | |
| | 4 | | NAT detection status | From new exchange. |
| Which peer is the "original | Determined by the initiator | | | |
| initiator"? | of IKE_SESSION_RESUME | | SPIs | From new exchange, see Note 4. |
| IKE SA sequence numbers (Message | Reset to 0 in | | | |
| ID) | IKE_SESSION_RESUME, and | | Which peer is the "original | Determined by the initiator of |
| | subsequently incremented | | initiator"? | IKE_SESSION_RESUME. |
| | normally | | | |
| IKE SA algorithms (SAr) | From the ticket | | IKE SA sequence numbers | Reset to 0 in |
| IKE SA keys (SK_*) | The old SK_d is obtained | | (Message ID) | IKE_SESSION_RESUME, and |
| | from the ticket and all | | | subsequently incremented |
| | keys are refreshed, see | | | normally. |
| | Section 5.1 | | | |
| IKE SA window size | Reset to 1 | | IKE SA algorithms (SAr) | From the ticket. |
| Child SAs (ESP/AH) | Created in new exchange, | | | |
| | see Note 6 | | IKE SA keys (SK_*) | The old SK_d is obtained from |
| Internal IP address | Not resumed, but see Note 5 | | | the ticket and all keys are |
| Other Configuration Payload | Not resumed | | | refreshed, see Section 5.1. |
| information | | | | |
| Peer Vendor IDs | Not resumed, resent in new | | IKE SA window size | Reset to 1. |
| | exchange if required | | | |
| Peer supports MOBIKE [RFC4555] | From new exchange | | Child SAs (ESP/AH) | Created in new exchange, see |
| MOBIKE additional addresses | Not resumed, should be | | | Note 6. |
| | resent by client if | | | |
| | necessary | | Internal IP address | Not resumed, but see Note 5. |
| Time until re-authentication | From new exchange (but | | | |
| [RFC4478] | ticket lifetime is bounded | | Other Configuration Payload | Not resumed. |
| | by this duration) | | information | |
| Peer supports redirects | From new exchange | | | |
| [I-D.ietf-ipsecme-ikev2-redirect] | | | Peer Vendor IDs | Not resumed, resent in new |
+-------------------------------------+-----------------------------+ | | exchange if required. |
| | |
| Peer supports MOBIKE [RFC4555] | From new exchange. |
| | |
| MOBIKE additional addresses | Not resumed, should be resent by |
| | client if necessary. |
| | |
| Time until re-authentication | From new exchange (but ticket |
| [RFC4478] | lifetime is bounded by this |
| | duration). |
| | |
| Peer supports redirects | From new exchange. |
| [RFC5685] | |
+--------------------------------+----------------------------------+
Note 1: The authenticated peer identity used for policy lookups may Note 1: The authenticated peer identity used for policy lookups may
not be the same as the IDi payload. This is possible when not be the same as the IDi payload. This is possible when
using certain EAP methods, see Sec. 3.5 of [RFC4718]. If using certain EAP methods, see Section 3.5 of [RFC4718]. If
these identities are indeed different, then the these identities are indeed different, then the
authenticated client identity MUST be included in the authenticated client identity MUST be included in the
ticket. Note that the client may not have access to this ticket. Note that the client may not have access to this
value. value.
Note 2: Certificates don't need to be stored if the peer never uses 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 them for anything after the IKE SA is up; however, if they
are needed, e.g. if exposed to applications via IPsec APIs, are needed, e.g., if exposed to applications via IPsec APIs,
they MUST be stored in the ticket. they MUST be stored in the ticket.
Note 3: If the certificate has an iPAddress SubjectAltName, and the 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 4: SPI values of the old SA MAY be stored in the ticket, to Note 4: SPI values of the old SA MAY be stored in the ticket, to
help the gateway locate corresponding old IKE state. These help the gateway locate corresponding old IKE state. These
values MUST NOT be used for the resumed SA. values MUST NOT be used for the resumed SA.
Note 5: The client can request the address it was using earlier, and 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 6: Since information about Child SAs and configuration payloads Note 6: 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 [ROHCoIPsec]
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration) and configuration) aren't usually affected by session
aren't usually affected by session resumption. resumption.
IKEv2 features that affect only the IKE_AUTH exchange (including IKEv2 features that affect only the IKE_AUTH exchange (including
HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges
[RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't [RFC4739], Elliptic Curve Digital Signature Algorithm (ECDSA)
usually need any state in the IKE SA (after the IKE_AUTH exchanges authentication [RFC4754], and the Online Certificate Status Protocol
are done), so resumption doesn't affect them. (OCSP) [RFC4806]) don't usually need any state in the IKE SA (after
the IKE_AUTH exchanges are done), so resumption doesn't affect them.
New IKEv2 features that are not covered by note 6 or by the previous New IKEv2 features that are not covered by Note 6 or by the previous
paragraph should specify how they interact with session resumption. paragraph should specify how they interact with session resumption.
5.1. Generating Cryptographic Material for the Resumed IKE SA 5.1. Generating Cryptographic Material for the Resumed IKE SA
The cryptographic material is refreshed based on the ticket and the The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows: value is derived as follows:
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr) SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
skipping to change at page 16, line 24 skipping to change at page 16, line 9
where SPIi, SPIr are the SPI values created in the new IKE exchange. 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 See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket. in the ticket.
6. Ticket Handling 6. Ticket Handling
6.1. Ticket Content 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
be integrity protected and encrypted. MUST 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 authorized access is allowed. We note that protected so that only authorized access is allowed. We note that
such a ticket is analogous to the concept of 'stub', as defined in 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. [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
do so could result in various security vulnerabilities on the gateway to do so could result in various security vulnerabilities on the
side, depending on the format of the reference. Potential gateway 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 all state When the state is passed by value, the ticket MUST encode all state
information marked "from the ticket" in the table on Section 5. The information marked "from the ticket" in the table on Section 5. The
same state MUST be stored in the ticket store, in the case of ticket same state MUST be stored in the ticket store, in the case of "ticket
by reference. by reference".
A ticket by value MUST include a protected expiration time, which is A "ticket by value" MUST include a protected expiration time, which
an absolute time value and SHOULD correspond to the value included in is an absolute time value and SHOULD correspond to the value included
the TICKET_LT_OPAQUE payload. in the TICKET_LT_OPAQUE payload.
The ticket by value MUST additionally include a key identity field, The "ticket by value" MUST additionally include a key identity field,
so that keys for ticket encryption and authentication can be changed, so that keys for ticket encryption and authentication can be changed,
and when necessary, algorithms can be replaced. and when necessary, algorithms can be replaced.
6.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 by the client or the gateway, the client MUST an IKE SA is deleted by the client or the gateway, the client MUST
delete its stored ticket. Similarly, when credentials associated delete its stored ticket. Similarly, when credentials associated
with the IKE SA are invalidated (e.g. when a user logs out), the 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 ticket MUST be deleted. When the IKE SA is rekeyed, the ticket is
invalidated, and the client SHOULD request a new ticket. When a invalidated, and the client SHOULD request a new ticket. When a
client does not follow these rules, it might present an invalid client does not follow these rules, it might present an invalid
ticket to the gateway. See Section 9.8 for more about this issue. ticket to the gateway. See Section 9.8 for more about this issue.
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-
authentication time, according to [RFC4478]. Even if neither of authentication time, according to [RFC4478]. Even if neither of
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 7. IKE Notifications
This document defines a number of notifications. The Notify Message This document defines a number of notifications. The following
types are TBA by IANA. Notify Message types have been assigned by IANA.
+-------------------+-------+-----------------+ +-------------------+-------+-----------------+
| Notification Name | Value | Data | | Notification Name | Value | Data |
+-------------------+-------+-----------------+ +-------------------+-------+-----------------+
| TICKET_LT_OPAQUE | TBA1 | See Section 7.1 | | TICKET_LT_OPAQUE | 16409 | See Section 7.1 |
| TICKET_REQUEST | TBA2 | None | | | | |
| TICKET_ACK | TBA3 | None | | TICKET_REQUEST | 16410 | None |
| TICKET_NACK | TBA4 | None | | | | |
| TICKET_OPAQUE | TBA5 | See Section 7.2 | | TICKET_ACK | 16411 | None |
| | | |
| TICKET_NACK | 16412 | None |
| | | |
| TICKET_OPAQUE | 16413 | See Section 7.2 |
+-------------------+-------+-----------------+ +-------------------+-------+-----------------+
For all these notifications, the Protocol ID and the SPI Size fields For all these notifications, the Protocol ID and the SPI Size fields
MUST both be sent as 0. MUST both be sent as 0.
7.1. TICKET_LT_OPAQUE Notify Payload 7.1. TICKET_LT_OPAQUE Notify Payload
The data for the TICKET_LT_OPAQUE Notify payload consists of the The data for the TICKET_LT_OPAQUE Notify payload consists of the
Notify message header, a Lifetime field and the ticket itself. The Notify message header, a Lifetime field and the ticket itself. The
four octet Lifetime field contains a relative time value, the number four octet Lifetime field contains a relative time value, the number
skipping to change at page 19, line 4 skipping to change at page 18, line 39
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 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 | | Next Payload |C| Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size = 0 | Notify Message Type | | Protocol ID | SPI Size = 0 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Ticket ~ ~ Ticket ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TICKET_OPAQUE Notify Payload Figure 7: TICKET_OPAQUE Notify Payload
8. IANA Considerations 8. IANA Considerations
Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME, Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME,
whose value is to be allocated (has been allocated) from the "IKEv2 whose value has been allocated from the "IKEv2 Exchange Types"
Exchange Types" registry. registry.
Section 7 defines several new IKEv2 notifications whose Message Type Section 7 defines several new IKEv2 notifications whose Message Type
values are to be allocated (have been allocated) from the "IKEv2 values have been allocated from the "IKEv2 Notify Message Types -
Notify Message Types - Status Types" registry. Status Types" registry.
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
A 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. Since all exchanges where the client obtains a ticket are 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 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 the ticket to resume a session. However, since the ticket's contents
are encrypted and the attacker does not know the corresponding secret are 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 a resumption attempt, as described adversary is able to eavesdrop on a resumption attempt, as described
in the previous paragraph, then the ticket by reference may be in the previous paragraph, then the "ticket by reference" may be
obtained. A ticket by reference cannot be used by an attacker to obtained. A "ticket by reference" cannot be used by an attacker to
successfully resume a session, for the same reasons as for a ticket successfully resume a session, for the same reasons as for a "ticket
by value, namely because the attacker would not be able to prove, by value", namely because the attacker would not be able to prove,
during IKE_AUTH, its knowledge of the secret part of the IKE state during IKE_AUTH, its knowledge of the secret part of the IKE state
embedded in the ticket. Moreover, the adversary MUST NOT be able to embedded in the ticket. Moreover, the adversary MUST NOT be able to
resolve the ticket via the reference, i.e., access control MUST be resolve the ticket via the reference, i.e., access control MUST be
enforced to ensure disclosure only to authorized entities. enforced to 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 the 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 6.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. Such an attack could burden the value" to a gateway for verification. Such an attack could burden
gateway's CPU, and/or exhaust its memory with half-open IKE state. the gateway's CPU, and/or exhaust its memory with half-open IKE
To minimize the possibility of such denial of service, ticket state. To minimize the possibility of such denial of service, ticket
verification should be lightweight (e.g., using efficient symmetric verification should be lightweight (e.g., using efficient symmetric
key cryptographic algorithms). 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
reference then this may lead to an amplification attack as the IKEv2 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 responder is forced to resolve the reference to a ticket in order to
determine that the adversary is not in possession of the keying determine that the adversary is not in possession of the keying
material corresponding to the stored state or that the reference is material corresponding to the stored state or that the reference is
void. To minimize this attack, the protocol to resolve the reference void. To minimize this attack, the protocol to resolve the reference
should be as lightweight as possible and should not generate a large should be as lightweight as possible and should not generate a large
number of messages. number of messages.
Note also that the regular IKEv2 cookie mechanism can be used to Note also that the regular IKEv2 cookie mechanism can be used to
handle state-overflow DoS situations. handle state-overflow DoS situations.
9.4. Detecting the Need for Resumption 9.4. Detecting the Need for Resumption
Detecting when an old IKE SA is no longer usable and needs to be Detecting when an old IKE SA is no longer usable and needs to be
resumed is out of scope of the current document. However, clients resumed is out of scope of the current document. However, clients
are warned against implementing a more liberal policy than that used are warned against implementing a more liberal policy than that used
to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular, to detect failed IKE SAs (Section 2.4 of RFC 4306). In particular,
untrusted messages MUST NOT be relied upon to make this decision. untrusted messages MUST NOT be relied upon to make this decision.
9.5. Key Management for Tickets By Value 9.5. Key Management for "Tickets by Value"
A full description of the management of the keys used to protect the 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 "ticket by value" is beyond the scope of this document. A list of
RECOMMENDED practices is given below. RECOMMENDED practices is given below.
o The keys should be generated securely following the randomness o The keys should be generated securely following the randomness
recommendations in [RFC4086]. recommendations in [RFC4086].
o The keys and cryptographic protection algorithms should be at o The keys and cryptographic protection algorithms should be at
least 128 bits in strength. least 128 bits in strength.
o The keys should not be used for any other purpose than generating o The keys should not be used for any other purpose than generating
and verifying tickets. and verifying tickets.
o The keys should be changed regularly. o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic o The keys should be changed if the ticket format or cryptographic
protection algorithms change. protection algorithms change.
9.6. Ticket Lifetime 9.6. Ticket Lifetime
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
skipping to change at page 21, line 27 skipping to change at page 21, line 19
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.7. Tickets and Identity 9.7. Tickets and Identity
A ticket is associated with a certain identity, and MUST be managed A ticket is associated with a certain identity, and MUST be managed
securely on the client side. Section 6.2 requires that a ticket be securely on the client side. Section 6.2 requires that a ticket be
deleted when the credentials associated with the ticket's identity deleted when the credentials associated with the ticket's identity
are no longer valid, e.g. when a user whose credentials were used to are no longer valid, e.g., when a user whose credentials were used to
create the SA logs out. create the SA logs out.
9.8. Ticket Revocation 9.8. Ticket Revocation
A misbehaving client could present a ticket in its possession to the A misbehaving client could present a ticket in its possession to the
gateway resulting in session resumption, even though the IKE SA gateway resulting in session resumption, even though the IKE SA
associated with this ticket had previously been deleted. This is associated with this ticket had previously been deleted. This is
disallowed by Section 6.2. This issue is unique to ticket by value disallowed by Section 6.2. This issue is unique to "ticket by value"
cases, since a ticket by reference will have been deleted from the cases, since a "ticket by reference" will have been deleted from the
ticket store. ticket store.
To avoid this issue for ticket by value, an Invalid Ticket List (ITL) To avoid this issue for "ticket by value", an Invalid Ticket List
may be maintained by the gateway, see (ITL) may be maintained by the gateway, see [TOKENS]. This can be a
[I-D.rescorla-stateless-tokens]. This can be a simple blacklist of simple blacklist of revoked tickets. Alternatively, [TOKENS]
revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens]
suggests to use Bloom Filters [Bloom70] to maintain the list in suggests to use Bloom Filters [Bloom70] to maintain the list in
constant space. Management of such lists is outside the scope of the constant space. Management of such lists is outside the scope of the
current document. Note that a policy that requires tickets to have current document. Note that a policy that requires tickets to have
shorter lifetimes (e.g., 1 hour) significantly mitigates this issue. shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
9.9. Ticket by Value Format 9.9. Ticket by Value Format
The ticket's format is not defined by this document, since this is The ticket's format is not defined by this document, since this is
not required for interoperability. However great care must be taken not required for interoperability. However, great care must be taken
when defining a ticket format such that the requirements outlined in when defining a ticket format such that the requirements outlined in
Section 6.1 are met. The ticket by value MUST have its integrity and Section 6.1 are met. The "ticket by value" MUST have its integrity
confidentiality protected with strong cryptographic techniques to and confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system. prevent a breach in the security of the system.
9.10. Identity Privacy, Anonymity, and Unlinkability 9.10. 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
exchange. There is thereby the possibility for an on-path adversary exchange. There is thereby the possibility for an on-path adversary
to observe multiple exchange handshakes where the same state to observe multiple exchange handshakes where the same state
information is used and therefore to conclude that they belong to the information is used and therefore to conclude that they belong to the
same communication end points. same communication endpoints.
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
attacker), there should be no multiple use of the same ticket. active attacker), there should be no multiple use of the same ticket.
We are not aware of additional security issues associated with ticket We are not aware of additional security issues associated with ticket
reuse: the protocol guarantees freshness of the generated crypto reuse: the protocol guarantees freshness of the generated crypto
material even in such cases. As noted in Section 4.3.1, the gateway material even in such cases. As noted in Section 4.3.1, the gateway
SHOULD prevent multiple uses of the same ticket. But this is only an SHOULD prevent multiple uses of the same ticket. But this is only an
extra precaution, to ensure that clients do not implement reuse. In extra precaution, to ensure that clients do not implement reuse. In
other words, the gateway is not expected to cache old tickets for other words, the gateway is not expected to cache old tickets for
extended periods of time. extended periods of time.
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, Peny Yang, Sean Turner and Tero Kivinen for their Housely, Yoav Nir, Peny Yang, Sean Turner, and Tero Kivinen for their
comments. We would like to particularly thank Florian Tegeler and comments. We would like to particularly thank Florian Tegeler and
Stjepan Gros for their implementation efforts and Florian Tegeler for Stjepan Gros for their implementation efforts and Florian Tegeler for
a formal verification using the Casper tool set. a formal verification using the Casper tool set.
We would furthermore like to thank the authors of We would furthermore like to thank the authors of [SA-SYNC] (Yan Xu,
[I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke Peny Yang, Yuanchen Ma, Hui Deng, and Ke Xu) for their input on the
Xu) for their input on the stub concept. 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 Vidya Narayanan and Lakshminath Dondeti coauthored several past
versions of this document, and we acknowledge their significant versions of this document, and we acknowledge their significant
contribution. 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
[Bloom70] Bloom, B., "Space/time trade-offs in hash coding with [Bloom70] Bloom, B., "Space/time trade-offs in hash coding with
allowable errors", Comm. ACM 13(7):422-6, July 1970. allowable errors", Comm. ACM 13(7):422-6, July 1970.
[I-D.eronen-ipsec-ikev2-eap-auth] [EAP-AUTH] Eronen, P., Tschofenig, H., and Y. Sheffer, "An
Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension Extension for EAP-Only Authentication in IKEv2", Work
for EAP-Only Authentication in IKEv2", in Progress, October 2009.
draft-eronen-ipsec-ikev2-eap-auth-07 (work in progress),
October 2009.
[I-D.ietf-ipsecme-ikev2-redirect] [IKEV2-BIS] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Devarapalli, V. and K. Weniger, "Redirect Mechanism for "Internet Key Exchange Protocol: IKEv2", Work
IKEv2", draft-ietf-ipsecme-ikev2-redirect-13 (work in in Progress, October 2009.
progress), August 2009.
[I-D.ietf-ipsecme-ikev2bis] [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, Requirements for Security", BCP 106, RFC 4086,
"Internet Key Exchange Protocol: IKEv2", June 2005.
draft-ietf-ipsecme-ikev2bis-05 (work in progress),
October 2009.
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Internet Protocol", RFC 4301, December 2005.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec-09 (work in
progress), August 2009.
[I-D.rescorla-stateless-tokens] [RFC4478] Nir, Y., "Repeated Authentication in Internet Key
Rescorla, E., "How to Implement Secure (Mostly) Stateless Exchange (IKEv2) Protocol", RFC 4478, April 2006.
Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007.
[I-D.xu-ike-sa-sync] [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA (MOBIKE)", RFC 4555, June 2006.
Synchronization for session resumption",
draft-xu-ike-sa-sync-01 (work in progress), October 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Requirements for Security", BCP 106, RFC 4086, June 2005. Implementation Guidelines", RFC 4718, October 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Internet Protocol", RFC 4301, December 2005. Exchanges in the Internet Key Exchange (IKEv2)
Protocol", RFC 4739, November 2006.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
(IKEv2) Protocol", RFC 4478, April 2006. Using the Elliptic Curve Digital Signature Algorithm
(ECDSA)", RFC 4754, January 2007.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status
(MOBIKE)", RFC 4555, June 2006. Protocol (OCSP) Extensions to IKEv2", RFC 4806,
February 2007.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
Implementation Guidelines", RFC 4718, October 2006. "Transport Layer Security (TLS) Session Resumption
without Server-Side State", RFC 5077, January 2008.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
Exchanges in the Internet Key Exchange (IKEv2) Protocol", the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 4739, November 2006. RFC 5685, November 2009.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [ROHCoIPsec] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
the Elliptic Curve Digital Signature Algorithm (ECDSA)", C. Bormann, "IKEv2 Extensions to Support Robust Header
RFC 4754, January 2007. Compression over IPsec (ROHCoIPsec)", Work in Progress,
December 2009.
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status [SA-SYNC] Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2
Protocol (OCSP) Extensions to IKEv2", RFC 4806, SA Synchronization for session resumption", Work
February 2007. in Progress, October 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [TOKENS] Rescorla, E., "How to Implement Secure (Mostly)
"Transport Layer Security (TLS) Session Resumption without Stateless Tokens", Work in Progress, March 2007.
Server-Side State", RFC 5077, January 2008.
Appendix A. Ticket Format Appendix A. Ticket Format
This document does not specify a particular ticket format nor even This document does not specify a particular ticket format nor even
the suggested contents of a ticket: both are entirely up to the the suggested contents of a ticket: both are entirely up to the
implementer. The formats described in the following sub-sections are implementer. The formats described in the following sub-sections are
provided as useful examples, and implementers are free to adopt them provided as useful examples, and implementers are free to adopt them
as-is or change them in any way necessary. as-is or change them in any way necessary.
A.1. Example Ticket by Value Format A.1. Example "Ticket by Value" Format
struct { struct {
[authenticated] struct { [authenticated] struct {
octet format_version; // 1 for this version of the protocol octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver. octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string octet key_id[8]; // arbitrary byte string
opaque IV[0..255]; // actual length (possibly 0) depends opaque IV[0..255]; // actual length (possibly 0) depends
// on the encryption algorithm // on the encryption algorithm
[encrypted] struct { [encrypted] struct {
skipping to change at page 25, line 33 skipping to change at page 25, line 41
} ikev2_state; } ikev2_state;
} protected_part; } protected_part;
opaque MAC[0..255]; // the length (possibly 0) depends opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
Note that the key defined by "key_id" determines the encryption and Note that the key defined by "key_id" determines the encryption and
authentication algorithms used for this ticket. Those algorithms are authentication algorithms used for this ticket. Those algorithms are
unrelated to the transforms defined by the SA payload. unrelated to the transforms defined by the SA payload.
The reader is referred to [I-D.rescorla-stateless-tokens] that The reader is referred to [TOKENS] that recommends a similar (but not
recommends a similar (but not identical) ticket format, and discusses identical) ticket format, and discusses related security
related security considerations in depth. considerations in depth.
A.2. Example Ticket by Reference Format A.2. Example "Ticket by Reference" Format
For implementations that prefer to pass a reference to IKE state in For implementations that prefer to pass a reference to IKE state in
the ticket, rather than the state itself, we suggest the following the ticket, rather than the state itself, we suggest the following
format: format:
struct { struct {
[authenticated] struct { [authenticated] struct {
octet format_version; // 1 for this version of the protocol octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver. octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string octet key_id[8]; // arbitrary byte string
skipping to change at page 26, line 21 skipping to change at page 26, line 21
struct { struct {
opaque state_ref; // reference to IKE state opaque state_ref; // reference to IKE state
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
Note to RFC Editor: remove this appendix before publication.
B.1. -09
Implemented IESG and opsdir review comments.
B.2. -08
Implemented IETF LC, secdir and gen-art comments.
B.3. -07
Implemented AD Review comments, most of them editorial.
B.4. -06
Clients resuming propely closed sessions and how this can be avoided.
B.5. -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.6. -04
Closed issue #105, Non-PKI use of EAP, and resumption.
Closed issue #106, Resumption and NAT detection and changing ports.
B.7. -03
Changed the protocol from one to two round trips, to simplify the
security assumptions. Eliminated security considerations associated
with the previous version.
Closed issue #69, Clarify behavior of SPI and sequence numbers.
Closed issue #70, Ticket lifetime - explicit or not? (and ticket push
from gateway).
Closed issue #99, Ticket example: downgrade.
Closed issue #76, IPsec Child SAs during resumption.
Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption.
Closed issue #95, Minor nits for ikev2-resumption-02.
Closed issue #97, Clarify what state comes from where.
Closed issue #98, Replays in 1-RTT protocol.
Closed issue #100, NAT detection [and] IP address change.
Closed issue #101, Assorted issues by Tero.
B.8. -02
Added a new TICKET_OPAQUE payload that does not have a lifetime field
included.
Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE) when presenting the ticket to the
gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec Child SAs would be deleted once the old IKE SA
gets deleted as well.
Clarified the behavior of SPI and sequence number usage.
B.9. -01
Addressed issue#75, see
http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included
changes throughout the document to ensure that the ticket may contain
a reference or a value.
B.10. -00
Resubmitted document as a WG item.
B.11. -01
Added reference to [I-D.xu-ike-sa-sync]
Included recommended ticket format into the appendix
Various editorial improvements within the document
B.12. -00
Issued a -00 version for the IPSECME working group. Reflected
discussions at IETF#72 regarding the strict focus on session
resumption. Consequently, text about failover was removed.
B.13. -04
Editorial fixes; references cleaned up; updated author's contact
address
B.14. -03
Removed counter mechanism. Added an optional anti-DoS mechanism,
based on IKEv2 cookies (removed previous discussion of cookies).
Clarified that gateways may support reallocation of same IP address,
if provided by network. Proposed a solution outline to the problem
of key exchange for the keys that protect tickets. Added fields to
the ticket to enable interoperability. Removed incorrect MOBIKE
notification.
B.15. -02
Clarifications on generation of SPI values, on the ticket's lifetime
and on the integrity protection of the anti-replay counter.
Eliminated redundant SPIs from the notification payloads.
B.16. -01
Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy.
B.17. -00
Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses 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
 End of changes. 132 change blocks. 
499 lines changed or deleted 375 lines changed or added

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