draft-ietf-ipsecme-ikev2-resumption-02.txt   draft-ietf-ipsecme-ikev2-resumption-03.txt 
Network Working Group Y. Sheffer Network Working Group Y. Sheffer
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: September 10, 2009 Nokia Siemens Networks Expires: November 2, 2009 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
March 9, 2009 May 1, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-02.txt draft-ietf-ipsecme-ikev2-resumption-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on November 2, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 7 skipping to change at page 3, line 7
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
The proposed approach requires passing opaque data from the IKEv2 The proposed approach requires passing opaque data from the IKEv2
responder to the IKEv2 initiator, which is later made available to responder to the IKEv2 initiator, which is later made available to
the IKEv2 responder for re-authentication. We use the term ticket to the IKEv2 responder for re-authentication. We use the term ticket to
refer to the opaque data that is created by the IKEv2 responder. refer to the opaque data that is created by the IKEv2 responder.
This document does not specify the format of the ticket but This document does not specify the format of the ticket but
recommendations are provided. recommendations are provided.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7
4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 8 4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9
4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 9
4.3.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 10 4.4. IKE_SESSION_RESUME Details . . . . . . . . . . . . . . . . 11
4.3.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10 4.5. Requesting a Ticket During Resumption . . . . . . . . . . 11
4.3.3. Requesting a Ticket during Resumption . . . . . . . . 11 4.6. IP Address Change and NAT . . . . . . . . . . . . . . . . 11
4.4. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 4.7. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11
4.5. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11 4.7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . 12
4.6. TICKET_OPAQUE' Notify Payload . . . . . . . . . . . . . . 12 4.7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12
4.7. Processing Guidelines for IKE SA Establishment . . . . . . 12 4.8. Computing the AUTH Payload . . . . . . . . . . . . . . . . 13
5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13 5. Processing Guidelines for IKE SA Establishment . . . . . . . . 13
5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13 6. The State After Resumption . . . . . . . . . . . . . . . . . . 14
5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 14 7. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 15 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
7.4. Key Management for Tickets By Value . . . . . . . . . . . 16 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 16 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18
7.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 16 9.4. Key Management for Tickets By Value . . . . . . . . . . . 19
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 16 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 17 9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
A.1. Recommended Ticket by Value Format . . . . . . . . . . . . 19 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 22
A.2. Recommended Ticket by Reference Format . . . . . . . . . . 19 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 23
B.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.6. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.7. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.8. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.7. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.8. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.9. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 B.10. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.11. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol has a certain The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved. of round-trips required and the cryptographic operations involved.
In particular the Extensible Authentication Protocol (EAP) is used In particular the Extensible Authentication Protocol (EAP) is used
for authentication in remote access cases, which increases latency. for authentication in remote access cases, which increases latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
skipping to change at page 4, line 43 skipping to change at page 5, line 43
by value and a ticket by reference format is proposed. by value and a ticket by reference format is proposed.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC5077] with the required adaptations for IKEv2, e.g., to [RFC5077] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed accommodate the two-phase protocol structure. We have borrowed
heavily from that specification. heavily from that specification.
The proposed solution should additionally meet the following goals: The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption. o Using only symmetric cryptography to minimize CPU consumption.
o Allowing a gateway to push state to clients.
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
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 a failover. 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], [RFC4306], and This document uses terminology defined in [RFC4301] and [RFC4306].
[RFC4555]. In addition, this document uses the following terms: In addition, this document uses the following terms:
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. 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 end points (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)
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
skipping to change at page 6, line 27 skipping to change at page 7, line 27
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! ! IKE_SESSION_RESUME ! ! ! ! IKE_SESSION_RESUME ! !
! Remote !<------------------------>! ! ! Remote !<------------------------>! !
! Access ! ! Access ! ! Access ! ! Access !
! 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 this scenario, an end host (an entity with a host implementation In the first use case above, an end host (an entity with a host
of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA
gateway in a remote network using IKEv2. The end host in this with a gateway in a remote network using IKEv2. The end host in this
scenario is sometimes referred to as a remote access client. At a scenario is sometimes referred to as a remote access client. At a
later stage when a client needs to re-establish the IKEv2 session it later stage when a client needs to re-establish the IKEv2 session it
may choose to establish IPsec SAs using a full IKEv2 exchange or the may choose to establish IPsec SAs using a full IKEv2 exchange or the
IKE_SESSION_RESUME exchange (shown in Figure 1). IKE_SESSION_RESUME exchange (shown in Figure 1).
In this scenario, the client needs to get an IP address from the
remote network so that traffic can be encapsulated by the remote
access gateway before reaching the client. In the initial exchange,
the gateway may acquire IP addresses from the address pool of a local
DHCP server. The session resumption exchange may need to support the
assignment of a new IP address.
The protocol defined in this document supports the re-allocation of
an IP address to the client, if this capability is provided by the
network. This capability is implicit in the use of the IKE
configuration mechanism, which allows the client to present its
existing IP address and receive the same address back, if allowed by
the gateway.
4. Protocol Details 4. Protocol Details
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket, see Section 4.1, and presenting a ticket, see requesting a ticket, see Section 4.1, and presenting a ticket, see
Section 4.3. Section 4.3.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
A client MAY request a ticket in the following exchanges: A client MAY request a ticket in the following exchanges:
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.
o In an Informational exchange, if the gateway previously replied o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only
with an N(TICKET_ACK) instead of providing a ticket. when this exchange is initiated by the client).
o In an Informational exchange, when the ticket lifetime is about to o In an Informational exchange at any time, e.g. if the gateway
expire. previously replied with an N(TICKET_ACK) instead of providing a
o In an IKE_SESSION_RESUME exchange, see Section 4.3.3. ticket, or when the ticket lifetime is about to expire. All such
Informational exchanges MUST be initiated by the client.
o While resuming an IKE session, i.e. in the IKE_AUTH exchange that
follows an IKE_SESSION_RESUME exchange, see Section 4.5.
Normally, a client requests a ticket in the third message of an IKEv2 Normally, a client requests a ticket in the third message of an IKEv2
exchange (the first of IKE_AUTH). Figure 2 shows the message exchange (the first of IKE_AUTH). Figure 2 shows the message
exchange for this typical case. exchange for this typical case.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
Figure 2: Example Message Exchange for Requesting a Ticket Figure 2: Example Message Exchange for Requesting a Ticket
The notification payloads are described in Section 4.4. The above is The notification payloads are described in Section 4.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.
A complete description of IKEv2 can be found in [RFC4718]. Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details
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_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
responder with respect to the IKE exchange, and the proper IKE
response (e.g. an IKE_AUTH response or an error notification) MUST be
sent.
4.2. Receiving a Ticket 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, as described in Section 4.1. The the IKEv2 exchange was successful. The ticket may be used later with
ticket may be used later with an IKEv2 responder that supports this an IKEv2 responder that supports this extension. Figure 3 shows how
extension. Figure 3 shows how the initiator receives the ticket. the initiator receives the ticket.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_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
N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH
request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST
only be returned in the final IKE_AUTH response.
4.3. Presenting a Ticket 4.3. Presenting a Ticket
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 ticket. Note that the client even if it is in possession of a valid ticket. Note that the client
can only judge validity in the sense of the ticket lifetime. A can only judge validity in the sense of the ticket lifetime. A
client MUST NOT present a ticket when it knows that the ticket's client MUST NOT present a ticket when it knows that the ticket's
lifetime has expired. lifetime has expired.
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 a communication with the IKEv2 responder is seen as interrupted and the
new exchange needs to be initiated and the session resumption session resumption procedure is to be initiated.
procedure to be initiated.
Tickets are intended for one-time use, i.e., a client MUST NOT reuse Tickets are intended for one-time use, i.e. a client MUST NOT reuse a
a ticket. A reused ticket SHOULD be rejected by a gateway. ticket. A reused ticket SHOULD be rejected by a gateway. Note that
a ticket is considered as used only when an IKE SA has been
established successfully with it.
This document specifies a new IKEv2 exchange type called This document specifies a new IKEv2 exchange type called
IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
somewhat similar to the IKE_AUTH exchange, and results in the equivalent to the IKE_SA_INIT exchange, and MUST be followed by an
creation of a Child SA. The client SHOULD NOT use this exchange type IKE_AUTH exchange. The client SHOULD NOT use this exchange type
unless it knows that the gateway supports it. unless it knows that the gateway supports it.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, Ni, N(TICKET_OPAQUE'), [N+,] HDR, Ni, N(TICKET_OPAQUE) [,N+] -->
SK { [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
Note: The initiator presents the TICKET_OPAQUE' payload to the
responder as the lifetime field attached to the ticket is not
relevant to the responder as it is included in the protected form
inside the ticket.
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The
initiator sets the SPIi value in the HDR to a new random value and initiator sets the SPIi value in the HDR to a new random value and
the SPIr value is set to 0. the SPIr value is set to 0.
See Section 4.3.1 for details on computing the protected (SK) When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
payload. payload it MUST perform one of the following steps if it supports the
extension defined in this document:
When the IKEv2 responder receives a ticket using the
N(TICKET_OPAQUE') payload it MUST perform one of the following steps
if it supports the extension defined in this document:
o If it is willing to accept the ticket, it responds as shown in o If it is willing to accept the ticket, it responds as shown in
Figure 4. Figure 4.
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.
o When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it, then the old SAs SHOULD be
silently deleted without sending a DELETE informational exchange.
Consequently, all the IPsec child SAs are deleted as well once the
old IKE SA is deleted.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK {Nr, SAr2, [TSi, TSr], <-- HDR, Nr [,N+]
[CP(CFG_REPLY)]}
Figure 4: IKEv2 Responder accepts the ticket Figure 4: 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
initiator sets the SPIi value in the HDR to a new random value and responder copies the SPIi value from the request, and the SPIr value
the SPIr value is set to 0. is set to a new random value .
The SK payload is protected using the cryptographic parameters
derived from the ticket, see Section 4.3.1 below.
At this point a new IKE SA is created by both parties, see
Section 4.7. This is followed by normal derivation of a child SA,
per Section 2.17 of [RFC4306].
4.3.1. Protection of the IKE_SESSION_RESUME Exchange
The two messages of this exchange are protected by a "subset" IKE SA.
The key material is derived from the ticket, as follows:
{SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)
where SK_d_old is the SK_d value of the original IKE SA, as retrieved
from the ticket. Ni guarantees freshness of the key material. SK_d2
is used later to derive the new IKE SA, see Section 4.7.
See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket.
4.3.2. Presenting a Ticket: The DoS Case
When receiving the first message of the IKE_SESSION_RESUME exchange,
the gateway may decide that it is under a denial-of-service attack.
In such a case, the gateway SHOULD defer the establishment of session
state until it has verified the identity of the client. We use a
variation of the IKEv2 Cookie mechanism, whereby the cookie is
protected.
In the two messages that follow, the gateway responds that it is
unwilling to resume the session until the client is verified, and the
client resubmits its first message, this time with the cookie:
Initiator Responder At this point the client MUST initiate an IKE_AUTH exchange, as per
----------- ----------- [RFC4306]. See Section 4.8 for guidelines on computing the AUTH
<-- HDR, SK{N(COOKIE)} payloads. The IDi value sent in this exchange MUST be identical to
the value included in the ticket. Following this exchange, a new IKE
SA is created by both parties, see Section 5, and a child SA is
derived, per Section 2.17 of [RFC4306].
HDR, Ni, N(TICKET_OPAQUE), [N+,] When the responder receives a ticket for an IKE SA that is still
SK {N(COOKIE), [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> active and if the responder accepts it, then the old SA SHOULD be
silently deleted without sending a DELETE informational exchange.
Consequently, all the dependent IPsec child SAs are also deleted.
This happens after both peers have been authenticated.
Assuming the cookie is correct, the gateway now replies normally. 4.4. IKE_SESSION_RESUME Details
This now becomes a 4-message exchange. The entire exchange is The IKE_SESSION_RESUME exchange behaves like the IKE_SA_INIT exchange
protected as defined in Section 4.3.1. in most respects. Specifically:
See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance o The first message may be rejected in denial of service situations,
regarding the usage and syntax of the cookie. Note that the cookie with the initiator instructed to send a cookie.
is completely independent of the IKEv2 ticket. o Notifications normally associated with IKE_SA_INIT can be sent.
In particular, NAT detection payloads.
o The SPI values and Message ID fields behave similarly to
IKE_SA_INIT.
4.3.3. Requesting a Ticket during Resumption 4.5. Requesting a Ticket During Resumption
When resuming a session, a client will typically request a new ticket When resuming a session, a client will typically request a new ticket
immediately, so it is able to resume the session again in the case of immediately, so it is able to resume the session again in the case of
a second failure. Therefore, the N(TICKET_REQUEST) and a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE)
N(TICKET_OPAQUE) notifications may be piggybacked as protected notifications will be included in the IKE_AUTH exchange that follows
payloads to the IKE_SESSION_RESUME exchange. the IKE_SESSION_RESUME exchange, with similar behavior to a ticket
request during a regular IKE exchange, Section 4.1.
The returned ticket (if any) will correspond to the IKE SA created The returned ticket (if any) will correspond to the IKE SA created
per the rules described in Section 4.7. per the rules described in Section 5.
4.4. IKE Notifications 4.6. IP Address Change and NAT
The client MAY resume the IKE exchange from an IP address different
from its original address. The gateway MAY reject the resumed
exchange if its policy depends on the client's address (although this
rarely makes sense).
The client's NAT traversal status SHOULD be determined anew upon
session resumption, by using the appropriate notifications. This
status is explicitly not part of the session resumption state.
4.7. IKE Notifications
This document defines a number of notifications. The notification This document defines a number of notifications. The notification
numbers are TBA by IANA. numbers are TBA by IANA.
+-------------------+--------+-----------------+ +-------------------+--------+-------------------+
| Notification Name | Number | Data | | Notification Name | Number | Data |
+-------------------+--------+-----------------+ +-------------------+--------+-------------------+
| TICKET_OPAQUE | TBA1 | See Section 4.5 | | TICKET_LT_OPAQUE | TBA1 | See Section 4.7.1 |
| TICKET_REQUEST | TBA2 | None | | TICKET_REQUEST | TBA2 | None |
| TICKET_ACK | TBA3 | None | | TICKET_ACK | TBA3 | None |
| TICKET_NACK | TBA4 | None | | TICKET_NACK | TBA4 | None |
| TICKET_OPAQUE' | TBA5 | See Section 4.6 | | TICKET_OPAQUE | TBA5 | See Section 4.7.2 |
+-------------------+--------+-----------------+ +-------------------+--------+-------------------+
4.5. TICKET_OPAQUE Notify Payload For all these notifications, the Protocol ID and the SPI Size fields
MUST both be sent as 0.
The data for the TICKET_OPAQUE Notify payload consists of the Notify 4.7.1. TICKET_LT_OPAQUE Notify Payload
message header, a lifetime field and the ticket itself. The four
octet lifetime field contains the number of seconds until the ticket The data for the TICKET_LT_OPAQUE Notify payload consists of the
expires (encoded as an unsigned integer). Notify message header, a Lifetime field and the ticket itself. The
four octet Lifetime field contains a relative time value, the number
of seconds until the ticket expires (encoded as an unsigned integer).
0 1 2 3 0 1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Lifetime ! ! Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Ticket ~ ~ Ticket ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TICKET_OPAQUE Notify Payload Figure 5: TICKET_LT_OPAQUE Notify Payload
4.6. TICKET_OPAQUE' Notify Payload 4.7.2. TICKET_OPAQUE Notify Payload
The data for the TICKET_OPAQUE' Notify payload consists of the Notify The data for the TICKET_OPAQUE Notify payload consists of the Notify
message header, and the ticket itself. Unlike the TICKET_OPAQUE message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE
payload no lifetime value is included in the TICKET_OPAQUE' Notify payload no lifetime value is included in the TICKET_OPAQUE Notify
payload. payload.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 6: TICKET_OPAQUE' Notify Payload Figure 6: TICKET_OPAQUE Notify Payload
4.7. Processing Guidelines for IKE SA Establishment 4.8. Computing the AUTH Payload
The value of the AUTH payload is derived in a manner similar to the
usage of IKEv2 pre-shared secret authentication, as shown below:
AUTH = prf(SK_px, <msg octets>)
Each of the initiator and responder uses its own SK_p value, taken
from the newly generated IKE SA, Section 5.
The exact material to be signed is defined in Section 2.15 of
[RFC4306]. The notation "IDr'" in RFC 4306 should be applied to the
new IDr value included in the exchange, rather than the value in the
ticket.
5. Processing Guidelines for IKE SA Establishment
When a ticket is presented, the gateway needs to obtain the ticket When a ticket is presented, the gateway needs to obtain the ticket
per value. In case a ticket by reference was provided by the client state. In case a ticket by reference was provided by the client, the
the gateway needs to resolve the reference in order to obtain the gateway needs to resolve the reference in order to obtain this state.
ticket by value. In case the client has already provided the ticket In case the client has already provided a ticket per value, the
per value it can parses the ticket. In either case, the gateway gateway can parse the ticket to obtain the state directly. In either
needs to process the ticket by value in order to restore the state of case, the gateway needs to process the ticket state in order to
the old IKE SA, and the client retrieves this state from its local restore the state of the old IKE SA, and the client retrieves the
store. Both peers now create state for the new IKE SA as follows: same state from its local store. Both peers now create state for the
new IKE SA as follows:
o The SA value (transforms etc.) is taken directly from the ticket. o The SA value (transforms etc.) is taken directly from the ticket.
o The sequence numbers are reset to 0.
o The Message ID values are reset to 0 in IKE_SESSION_RESUME, and
subsequently incremented normally.
o The IDi value is obtained from the ticket. o The IDi value is obtained from the ticket.
o The IDr value is obtained from the new exchange. The gateway MAY o The IDr value is obtained from the new exchange. The gateway MAY
make policy decisions based on the IDr value encoded in the make policy decisions based on the IDr value encoded in the
ticket. ticket.
o The SPI values are created anew, similarly to a regular IKE o The SPI values are created anew during IKE_SESSION_RESUME,
exchange. SPI values from the ticket MUST NOT be reused. This similarly to a regular IKE_SA_INIT exchange. SPI values from the
restriction is to avoid problems caused by collisions with other ticket MUST NOT be reused, and they are sent merely to help the
SPI values used already by the initiator/responder. gateway to locate the old state. The restriction on SPI reuse is
to avoid problems caused by collisions with other SPI values used
already by the initiator/responder.
The cryptographic material is refreshed based on the ticket and the 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_d2, Ni | Nr) SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
where SK_d2 was computed earlier (Section 4.3.1). where SK_d_old is taken from the ticket. The literal string is
encoded as 10 ASCII characters, with no NULL terminator.
The keys are derived as follows, unchanged from IKEv2: The keys are derived as follows, unchanged from IKEv2:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
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.
5. Ticket Recommendations 6. The State After Resumption
5.1. Ticket Content The following table, compiled by Pasi Eronen, describes the IKE and
IPsec state of the peers after session resumption, and how it is
related to their state before the IKE SA was interrupted. When the
table mentions that a certain state item is taken "from the ticket",
this should be construed as:
o The client retrieves this item from its local store.
o In the case of ticket by value, the gateway encodes this
information in the ticket.
o In the case of ticket by reference, the gateway fetches this
information from the ticket store.
+-----------------------------------+-------------------------------+
| State Item | After Resumption |
+-----------------------------------+-------------------------------+
| IDi | From the ticket (but must |
| | also be exchanged in |
| | IKE_AUTH) |
| IDr | From the new exchange (but |
| | old value included in the |
| | ticket) |
| Authentication method | From the ticket |
| Certificates (when applicable) | Unspecified, see note 1 |
| Local IP address/port, peer IP | Selected by the client, see |
| address/port | note 2 |
| NAT detection status | From new exchange |
| SPIs | From new exchange |
| Which peer is the "original | Determined by the initiator |
| initiator"? | of IKE_SESSION_RESUME |
| IKE SA sequence numbers (Message | Start from 0 |
| ID) | |
| IKE SA algorithms (SAr) | From the ticket |
| IKE SA keys (SK_*) | SK_d from the ticket, others |
| | are refreshed |
| IKE SA window size | Reset to 1 |
| Child SAs (ESP/AH) | Created in new exchange, see |
| | note 5 |
| Internal IP address | Not resumed, but see note 3 |
| Other Configuration Payload | Not resumed |
| information | |
| Peer vendor IDs | Unspecified (needed in the |
| | ticket only if |
| | vendor-specific state is |
| | 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 |
| [I-D.ietf-ipsecme-ikev2-redirect] | |
+-----------------------------------+-------------------------------+
Note 1: Certificates don't need to be stored if the peer never uses
them for anything after the IKE SA is up (but would be
needed if exposed to applications via IPsec APIs).
Note 2: If the certificate has an iPAddress SubjectAltName, and the
implementation requires it to match the peer's source IP
address, the same check needs to be performed on session
resumption and the required information saved locally or in
the ticket.
Note 3: The client can request the address it was using earlier, and
if possible, the gateway SHOULD honor the request.
Note 4: IKEv2 features that affect only the IKE_AUTH exchange
(including HTTP_CERT_LOOKUP_SUPPORTED, multiple
authentication exchanges [RFC4739], ECDSA authentication
[RFC4754], and 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.
Note 5: Since information about CHILD SAs and configuration payloads
is not resumed, IKEv2 features related to CHILD SA
negotiation (such as IPCOMP_SUPPORTED,
ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration
aren't usually affected by session resumption.
Note 6: New IKEv2 features that are not covered by notes 4 and 5
should specify how they interact with session resumption.
7. Ticket Handling
7.1. Ticket Content
When passing a ticket by value to the client, the ticket content MUST When passing a ticket by value to the client, the ticket content MUST
be integrity protected and encrypted. A ticket by reference does not be integrity protected and encrypted.
need to be encrypted, as it does not contain any sensitive material,
such as keying material. However, access to the storage where that A ticket by reference does not need to be encrypted, as it does not
sensitive material is stored MUST be protected so that only contain any sensitive material, such as keying material. However,
unauthorized access is not allowed. We note that such a ticket is access to the storage where that sensitive material is stored MUST be
analogous to the concept of 'stub', as defined in protected so that only unauthorized access is not allowed. We note
[I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. that such a ticket is analogous to the concept of 'stub', as defined
in [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS.
Although not strictly required for cryptographic protection, it is
RECOMMENDED to integrity-protect the ticket by reference. Failing to
do so could result in various security vulnerabilities on the gateway
side, depending on the format of the reference. Potential
vulnerabilities include access by the gateway to unintended URLs
(similar to cross-site scripting) or SQL injection.
When the state is passed by value, the ticket MUST encode at least When the state is passed by value, the ticket MUST encode at least
the following state from an IKE SA. the following state from an IKE SA. The same state MUST be stored in
the ticket store, in the case of ticket by reference.
o IDi, IDr. o IDi, IDr.
o SPIi, SPIr. o SPIi, SPIr.
o SAr (the accepted proposal). o SAr (the accepted proposal).
o SK_d. o SK_d.
The ticket by value MUST include a key identity field, so that keys The ticket by value MUST include a key identity field, so that keys
for encryption and authentication can be changed, and when necessary, for encryption and authentication can be changed, and when necessary,
algorithms can be replaced. algorithms can be replaced.
In addition, the ticket by value and the ticket by reference MUST 7.2. Ticket Identity and Lifecycle
contain a protected ticket expiration value that is readable for the
client.
5.2. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted, the client MUST delete its stored ticket. A an IKE SA is deleted, the client MUST delete its stored ticket.
ticket is therefore associated with the tuple (IDi, IDr). Similarly, when credentials associated with the IKE SA are
invalidated (e.g. when a user logs out), the ticket MUST be deleted.
When the IKE SA is rekeyed the ticket is invalidated, and the client
SHOULD request a new ticket.
The lifetime of the ticket carried in the N(TICKET_OPAQUE) The lifetime of the ticket sent by the gateway SHOULD be the minimum
notification SHOULD be the minimum of the IKE SA lifetime (per the of the IKE SA lifetime (per the gateway's local policy) and its re-
gateway's local policy) and its re-authentication time, according to authentication time, according to [RFC4478]. Even if neither of
[RFC4478]. Even if neither of these are enforced by the gateway, a these are enforced by the gateway, a finite lifetime MUST be
finite lifetime MUST be specified for the ticket. specified for the ticket.
The gateway SHOULD set the expiration date for the ticket to a larger The key that is used to protect the ticket MUST have a lifetime that
value than the lifetime of the IKE SA. The key that is used to is significantly longer than the lifetime of an IKE SA.
protect the ticket MUST have a lifetime that is significantly longer
than the lifetime of an IKE SA.
6. IANA Considerations In normal operation, the client will request a ticket when
establishing the initial IKE SA, and then every time the SA is
rekeyed or re-established because of re-authentication.
8. IANA Considerations
This document requires a number of IKEv2 notification status types in This document requires a number of IKEv2 notification status types in
Section 4.4, to be registered by IANA. The corresponding registry Section 4.7, to be registered by IANA. The "IKEv2 Notify Message
was established by IANA. Types - Status Types" registry was established by IANA.
The document defines a new IKEv2 exchange in Section 4.3. The The document defines a new IKEv2 exchange in Section 4.3. The
corresponding registry was established by IANA. corresponding registry was established by IANA.
7. 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.
7.1. Stolen Tickets 9.1. Stolen Tickets
An man-in-the-middle may try to eavesdrop on an exchange to obtain a An man-in-the-middle may try to eavesdrop on an exchange to obtain a
ticket by value and use it to establish a session with the IKEv2 ticket by value and use it to establish a session with the IKEv2
responder. This can happen in different ways: by eavesdropping on responder. This can happen in different ways: by eavesdropping on
the initial communication and copying the ticket when it is granted the initial communication and copying the ticket when it is granted
and before it is used, or by listening in on a client's use of the and before it is used, or by listening in on a client's use of the
ticket to resume a session. However, since the ticket's contents is ticket to resume a session. However, since the ticket's contents is
encrypted and the attacker does not know the corresponding secret encrypted and the attacker does not know the corresponding secret
key, a stolen ticket cannot be used by an attacker to succesfully 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.
Since a ticket by reference does not need to be encrypted. When an A ticket by reference does not need to be encrypted. When an
adversary is able to eavesdrop on an exchange, as described in the adversary is able to eavesdrop on an exchange, as described in the
previous paragraph, then the ticket by reference may be obtained. previous paragraph, then the ticket by reference may be obtained. A
The adversary MUST NOT be able to resolve the ticket via the ticket by reference cannot be used by an attacker to successfully
reference, i.e., access control MUST be enforced to ensure disclosure resume a session, for the same reasons as for a ticket by value.
only to authorized entities. Moreover, the adversary MUST NOT be able to resolve the ticket via
the reference, i.e., access control MUST be enforced to ensure
disclosure only to authorized entities.
7.2. Forged Tickets 9.2. Forged Tickets
A malicious user could forge or alter a ticket by value in order to A malicious user could forge or alter a ticket by value in order to
resume a session, to extend its lifetime, to impersonate as another resume a session, to extend its lifetime, to impersonate as another
user, or to gain additional privileges. This attack is not possible user, or to gain additional privileges. This attack is not possible
if the content of the ticket by value is protected using a strong if the content of the ticket by value is protected using a strong
integrity protection algorithm. integrity protection algorithm.
In case of a ticket by reference an adversary may attempt to In case of a ticket by reference an adversary may attempt to
construct a faked 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. the IKEv2 SA. As noted in Section 7.1, it is often useful to
integrity-protect the ticket by reference, too.
7.3. Denial of Service Attacks 9.3. Denial of Service Attacks
An adversary could generate and send a large number of tickets by An adversary could generate and send a large number of tickets by
value to a gateway for verification. To minimize the possibility of value to a gateway for verification. To minimize the possibility of
such denial of service, ticket verification should be lightweight such denial of service, ticket verification should be lightweight
(e.g., using efficient symmetric key cryptographic algorithms). (e.g., using efficient symmetric key cryptographic algorithms).
When an adversary chooses to send a large number of tickets by value When an adversary chooses to send a large number of tickets by
then this may lead to an amplification attack as the IKEv2 is forced reference then this may lead to an amplification attack as the IKEv2
to resolve the reference to a ticket in order to determine that the responder is forced to resolve the reference to a ticket in order to
adversary is not in possession of the keying material corresponding determine that the adversary is not in possession of the keying
to the stored state or that the reference is void. To minimize this material corresponding to the stored state or that the reference is
attack the protocol to resolve the reference should be as lightweight void. To minimize this attack, the protocol to resolve the reference
as possible. and should not generate a large number of messages. should be as lightweight as possible. and should not generate a large
number of messages.
7.4. Key Management for Tickets By Value 9.4. 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.
7.5. Ticket Lifetime 9.5. 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
initiator, allowing it to manage its tickets. initiator, allowing it to manage its tickets.
7.6. Ticket by Value Format 9.6. Ticket by Value Format
Great care must be taken when defining a ticket format such that the Great care must be taken when defining a ticket format such that the
requirements outlined in Section 5.1 are met. In particular, if requirements outlined in Section 7.1 are met. In particular, if
confidential information, such as a secret key, is transferred to the confidential information, such as a secret key, is transferred to the
client it MUST be done using channel security to prevent attackers client it MUST be done using channel security to prevent attackers
from obtaining or modifying the ticket. Also, the ticket by value from obtaining or modifying the ticket. Also, the ticket by value
MUST have its integrity and confidentiality protected with strong MUST have its integrity and confidentiality protected with strong
cryptographic techniques to prevent a breach in the security of the cryptographic techniques to prevent a breach in the security of the
system. system.
7.7. Identity Privacy, Anonymity, and Unlinkability 9.7. Identity Privacy, Anonymity, and Unlinkability
Since opaque state information is passed around between the IKEv2 Since opaque state information is passed around between the IKEv2
initiator and the IKEv2 responder it is important that leakage of initiator and the IKEv2 responder it is important that leakage of
information, such as the identities of an IKEv2 initiator and a information, such as the identities of an IKEv2 initiator and a
responder, MUST be avoided (e.g., with the help of encryption. Thus, responder, MUST be avoided.
it prevents the disclosure of potentially sensitive information.
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 end points.
This document therefore envisions that the ticket is presented to the This document therefore requires that the ticket be presented to the
IKEv2 responder only once; multiple usage of the ticket is not IKEv2 responder only once; under normal circumstances (e.g. no active
provided. attacker), there should be no multiple use of the same ticket.
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange
A major design goal of this protocol extension has been the two-
message exchange for session resumption. There is a tradeoff between
this abbreviated exchange and replay protection. It is RECOMMENDED
that an IKEv2 responder should cache tickets, and reject replayed
ones. However, some gateways may not do that in order to reduce
state size. An adversary may attempt to replay a ticket. To
mitigate these risks a client may be required by the gateway to show
that it knows the ticket's secret, before any state is committed on
the gateway side. Note that this is a stronger guarantee than the
regular IKE cookie mechanism, which only shows IP return routability
of the client. This is enabled by including the cookie in the
protected portion of the message.
For performance reasons, the cookie mechanism is optional, and
invoked by the gateway only when it suspects that it is the subject
of a denial-of-service attack.
In any case, a ticket replayed by an adversary only causes partial
IKE state to be created on the gateway. The IKE exchange cannot be
completed and an IKE SA cannot be created unless the client knows the
ticket's secret values.
8. Acknowledgements 10. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ
Housely, Yoav Nir and Tero Kivinen for their comments. We would to Housely, Yoav Nir and Tero Kivinen for their comments. We would like
particularly thank Florian Tegeler and Stjepan Gros for their help to particularly thank Florian Tegeler and Stjepan Gros for their help
with their implementation efforts and Florian Tegeler for his formal with their implementation efforts and Florian Tegeler for his formal
verification using the CASPER tool set. verification using the CASPER tool set.
We would furthermore like to thank the authors of We would furthermore like to thank the authors of
[I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke
Xu) for their input on the stub concept. Xu) for their input on the stub concept.
We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad
Muhanna and Stephen Kent for their feedback regarding the ticket by Muhanna and Stephen Kent for their feedback regarding the ticket by
reference concept. reference concept.
9. References 11. References
9.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.
9.2. Informative References 11.2. Informative References
[I-D.ietf-ipsecme-ikev2-redirect]
Devarapalli, V. and K. Weniger, "Redirect Mechanism for
IKEv2", draft-ietf-ipsecme-ikev2-redirect-08 (work in
progress), April 2009.
[I-D.ietf-ipsecme-ikev2bis]
Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis-03 (work in progress),
April 2009.
[I-D.ietf-rohc-ikev2-extensions-hcoipsec]
Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and
C. Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec-08 (work in
progress), February 2009.
[I-D.rescorla-stateless-tokens] [I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-01 (work in Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007. progress), March 2007.
[I-D.xu-ike-sa-sync] [I-D.xu-ike-sa-sync]
Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA
Synchronization for session resumption", Synchronization for session resumption",
draft-xu-ike-sa-sync-01 (work in progress), October 2008. draft-xu-ike-sa-sync-01 (work in progress), October 2008.
skipping to change at page 18, line 43 skipping to change at page 21, line 43
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, November 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status
Protocol (OCSP) Extensions to IKEv2", RFC 4806,
February 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
Appendix A. Ticket Format Appendix A. Ticket Format
This document does not specify a mandatory-to-implement or a This document does not specify a mandatory-to-implement or a
mandatory-to-use ticket format. The format described in the sub- mandatory-to-use ticket format. The formats described in the
sections are RECOMMENDED. following sub-sections are provided as useful examples.
A.1. Recommended 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 19, line 38 skipping to change at page 23, line 5
} 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 [I-D.rescorla-stateless-tokens] that
recommends a similar (but not identical) ticket format, and discusses recommends a similar (but not identical) ticket format, and discusses
related security considerations in depth. related security considerations in depth.
A.2. Recommended 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 RECOMMEND 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
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 Appendix B. Change Log
B.1. -02 B.1. -03
Added a new TICKET_OPAQUE' payload that does not have a lifetime Changed the protocol from one to two round trips, to simplify the
field included. 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.2. -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 Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE') when presenting the ticket to the (utilizing the TICKET_OPAQUE) when presenting the ticket to the
gateway. gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange. Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec child SAs would be deleted once the old IKE SA Clarified that IPsec child SAs would be deleted once the old IKE SA
gets deleted as well. gets deleted as well.
Clarified the behavior of SPI and sequence number usage. Clarified the behavior of SPI and sequence number usage.
B.2. -01 B.3. -01
Addressed issue#75, see Addressed issue#75, see
http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included
changes throughout the document to ensure that the ticket may contain changes throughout the document to ensure that the ticket may contain
a reference or a value. a reference or a value.
B.3. -00 B.4. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.4. -01 B.5. -01
Added reference to [I-D.xu-ike-sa-sync] Added reference to [I-D.xu-ike-sa-sync]
Included recommended ticket format into the appendix Included recommended ticket format into the appendix
Various editorial improvements within the document Various editorial improvements within the document
B.5. -00 B.6. -00
Issued a -00 version for the IPSECME working group. Reflected Issued a -00 version for the IPSECME working group. Reflected
discussions at IETF#72 regarding the strict focus on session discussions at IETF#72 regarding the strict focus on session
resumption. Consequently, text about failover was removed. resumption. Consequently, text about failover was removed.
B.6. -04 B.7. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.7. -03 B.8. -03
Removed counter mechanism. Added an optional anti-DoS mechanism, Removed counter mechanism. Added an optional anti-DoS mechanism,
based on IKEv2 cookies (removed previous discussion of cookies). based on IKEv2 cookies (removed previous discussion of cookies).
Clarified that gateways may support reallocation of same IP address, Clarified that gateways may support reallocation of same IP address,
if provided by network. Proposed a solution outline to the problem if provided by network. Proposed a solution outline to the problem
of key exchange for the keys that protect tickets. Added fields to of key exchange for the keys that protect tickets. Added fields to
the ticket to enable interoperability. Removed incorrect MOBIKE the ticket to enable interoperability. Removed incorrect MOBIKE
notification. notification.
B.8. -02 B.9. -02
Clarifications on generation of SPI values, on the ticket's lifetime Clarifications on generation of SPI values, on the ticket's lifetime
and on the integrity protection of the anti-replay counter. and on the integrity protection of the anti-replay counter.
Eliminated redundant SPIs from the notification payloads. Eliminated redundant SPIs from the notification payloads.
B.9. -01 B.10. -01
Editorial review. Removed 24-hour limitation on ticket lifetime, Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy. lifetime is up to local policy.
B.10. -00 B.11. -00
Initial version. This draft is a selective merge of Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00. draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
 End of changes. 104 change blocks. 
303 lines changed or deleted 427 lines changed or added

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