draft-ietf-ipsecme-ikev2-resumption-00.txt   draft-ietf-ipsecme-ikev2-resumption-01.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: May 21, 2009 Nokia Siemens Networks Expires: July 28, 2009 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
November 17, 2008 January 24, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-00.txt draft-ietf-ipsecme-ikev2-resumption-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2009. This Internet-Draft will expire on July 28, 2009.
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
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.
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 (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 end points. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment. additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that IKE/IPsec session. This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA. efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
The proposed approach uses a IKEv2 state (or a reference into a state The proposed approach requires passing opaque data from the IKEv2
store). to store state information that is later made available to responder to the IKEv2 initiator, which is later made available to
the IKEv2 responder for re-authentication. Restoring state the IKEv2 responder for re-authentication. We use the term ticket to
information by utilizing a ticket is one possible way. This document refer to the opaque data that is created by the IKEv2 responder.
does not specify the format of the ticket but recommendations are This document does not specify the format of the ticket but
provided. recommendations are provided.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7
4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8
4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 9 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 10
4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10
4.2.3. Requesting a ticket during resumption . . . . . . . . 10 4.2.3. Requesting a ticket during resumption . . . . . . . . 11
4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11
4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11
4.5. Processing Guidelines for IKE SA Establishment . . . . . . 11 4.5. Processing Guidelines for IKE SA Establishment . . . . . . 12
5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 12 5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13
5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 13 5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 14 7.4. Key Management for Tickets By Value . . . . . . . . . . . 15
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 14 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 15
7.6. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15 7.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 15
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 15 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 16
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 15 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 A.1. Recommended Ticket by Value Format . . . . . . . . . . . . 18
B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Recommended Ticket by Reference Format . . . . . . . . . . 19
B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.4. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.5. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.6. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.6. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 B.7. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 31 skipping to change at page 4, line 31
an extension to IKEv2 that allows a client to re-establish an IKE SA an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
One way to ensure that the IKEv2 responder is able to recreate the One way to ensure that the IKEv2 responder is able to recreate the
state information is by maintaining IKEv2 state (or a reference into state information is by maintaining IKEv2 state (or a reference into
a state store) in a "ticket", an opaque data structure. This ticket a state store) in a "ticket", an opaque data structure. This ticket
is created by the server and forwarded to the client. The IKEv2 is created by the server and forwarded to the client. The IKEv2
protocol is extended to allow a client to request and present a protocol is extended to allow a client to request and present a
ticket. ticket. This document does not mandate the format of the ticket
structure but a recommendation is provided. In Appendix A a ticket
by value and a ticket by reference format is proposed.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC4507] 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 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.
skipping to change at page 6, line 27 skipping to change at page 6, 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 this scenario, an end host (an entity with a host implementation
of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
gateway in a remote network using IKEv2. The end-host in this 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 In this scenario, the client needs to get an IP address from the
remote network so that traffic can be encapsulated by the remote remote network so that traffic can be encapsulated by the remote
access gateway before reaching the client. In the initial exchange, access gateway before reaching the client. In the initial exchange,
the gateway may acquire IP addresses from the address pool of a local the gateway may acquire IP addresses from the address pool of a local
DHCP server. The session resumption exchange may need to support the DHCP server. The session resumption exchange may need to support the
skipping to change at page 8, line 27 skipping to change at page 8, line 27
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
Figure 3: Receiving a Ticket Figure 3: Receiving a Ticket
4.2. Presenting a Ticket 4.2. 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. A client MUST NOT even if it is in possession of a valid ticket. Note that the client
present a ticket when it knows that the ticket's lifetime has can only judge validity in the sense of the ticket lifetime. A
expired. client MUST NOT present a ticket when it knows that the ticket's
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 a
new exchange needs to be initiated and the session resumption new exchange needs to be initiated and the session resumption
procedure to be initiated. procedure to be initiated.
Tickets are intended for one-time use: a client MUST NOT reuse a Tickets are intended for one-time use: a client MUST NOT reuse a
ticket, either with the same or with a different gateway. A gateway ticket, either with the same or with a different gateway. A gateway
SHOULD reject a reused ticket. SHOULD reject a reused ticket.
skipping to change at page 9, line 7 skipping to change at page 9, line 10
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 somewhat similar to the IKE_AUTH exchange, and results in the
creation of a Child SA. The client SHOULD NOT use this exchange type creation of a Child SA. 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 {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The value
of the Lifetime field in the TICKET_OPAQUE payload is set to the
value that was received when requesting the ticket.
See Section 4.2.1 for details on computing the protected (SK) See Section 4.2.1 for details on computing the protected (SK)
payload. payload.
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
payload it MUST perform one of the following steps if it supports the payload it MUST perform one of the following steps if it supports the
extension defined in this document: extension defined in this document:
o If it is willing to accept the ticket, it responds as shown in o If it is willing to accept the ticket, it responds as shown in
Figure 4. Figure 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
skipping to change at page 11, line 42 skipping to change at page 12, line 4
! 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_OPAQUE Notify Payload
4.5. Processing Guidelines for IKE SA Establishment 4.5. Processing Guidelines for IKE SA Establishment
When a ticket is presented, the gateway parses the ticket to retrieve When a ticket is presented, the gateway needs to obtain the ticket
the state of the old IKE SA, and the client retrieves this state from per value. In case a ticket by reference was provided by the client
its local store. Both peers now create state for the new IKE SA as the gateway needs to resolve the reference in order to obtain the
follows: ticket by value. In case the client has already provided the ticket
per value it can parses the ticket. In either case, the gateway
needs to process the ticket by value in order to restore the state of
the old IKE SA, and the client retrieves this 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 sequence numbers are reset to 0.
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, similarly to a regular IKE
exchange. SPI values from the ticket SHOULD NOT be reused. This exchange. SPI values from the ticket SHOULD NOT be reused. This
restriction is to avoid problems caused by collisions with other restriction is to avoid problems caused by collisions with other
skipping to change at page 12, line 40 skipping to change at page 13, 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.
5. Ticket Recommendations 5. Ticket Recommendations
5.1. Ticket Content 5.1. Ticket Content
As noted above, the ticket represents a partial IKEv2 state, either When passing a ticket by value to the client, the ticket content MUST
by reference or by value. When passing the state by value, the be integrity protected and encrypted. A ticket by reference does not
ticket MUST contain an integrity-protected reference to partial IKEv2 need to be encrypted, as it does not contain any sensitive material,
state, containing the state items described further in this section. such as keying material. However, access to the storage where that
We note that such a ticket is analogous to the concept of 'stub', as sensitive material is stored MUST be protected so that only
defined in [I-D.xu-ike-sa-sync], or the concept of a Session ID from unauthorized access is not allowed. We note that such a ticket is
TLS. analogous to the concept of 'stub', as defined in
[I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS.
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. These values MUST be encrypted the following state from an IKE SA.
and authenticated.
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.
In addition, the ticket MUST encode a protected ticket expiration The ticket by value MUST include a key identity field, so that
value. encryption and authentication can be changed, and when necessary,
algorithms can be replaced.
The ticket MUST include a key identity field, so that encryption and In addition, the ticket by value and the ticket by reference MUST
authentication can be changed, and when necessary, algorithms can be contain a protected ticket expiration value that is readable for the
replaced. client.
5.2. Ticket Identity and Lifecycle 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. A
ticket is therefore associated with the tuple (IDi, IDr). ticket is therefore associated with the tuple (IDi, IDr).
The lifetime of the ticket carried in the N(TICKET_OPAQUE) The lifetime of the ticket carried in the N(TICKET_OPAQUE)
notification SHOULD be the minimum of the IKE SA lifetime (per the notification SHOULD be the minimum of the IKE SA lifetime (per the
gateway's local policy) and its re-authentication time, according to gateway's local policy) and its re-authentication time, according to
skipping to change at page 13, line 42 skipping to change at page 14, line 11
This document requires a number of IKEv2 notification status types in This document requires a number of IKEv2 notification status types in
Section 4.3, to be registered by IANA. The corresponding registry Section 4.3, to be registered by IANA. The corresponding registry
was established by IANA. was established by IANA.
The document defines a new IKEv2 exchange in Section 4.2. The The document defines a new IKEv2 exchange in Section 4.2. The
corresponding registry was established by IANA. corresponding registry was established by IANA.
7. Security Considerations 7. 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. The text below assumes that the IKE state is contained ticket.
explicitly in the ticket ("passed by value"). In most cases, there
are similar risks when the state is passed by reference.
7.1. Stolen Tickets 7.1. Stolen Tickets
An eavesdropper or man-in-the-middle may try to obtain a ticket and An man-in-the-middle may try to eavesdrop on an exchange to obtain a
use it to establish a session with the IKEv2 responder. This can ticket by value and use it to establish a session with the IKEv2
happen in different ways: by eavesdropping on the initial responder. This can happen in different ways: by eavesdropping on
communication and copying the ticket when it is granted and before it the initial communication and copying the ticket when it is granted
is used, or by listening in on a client's use of the ticket to resume and before it is used, or by listening in on a client's use of the
a session. However, since the ticket's contents is encrypted and the ticket to resume a session. However, since the ticket's contents is
attacker does not know the corresponding secret key, a stolen ticket encrypted and the attacker does not know the corresponding secret
cannot be used by an attacker to succesfully resume a session. An key, a stolen ticket cannot be used by an attacker to succesfully
IKEv2 responder MUST use strong encryption and integrity protection resume a session. An IKEv2 responder MUST use strong encryption and
of the ticket to prevent an attacker from obtaining the ticket's integrity protection of the ticket to prevent an attacker from
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
adversary is able to eavesdrop on an exchange, as described in the
previous paragraph, then the ticket by reference may be obtained.
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 7.2. Forged Tickets
A malicious user could forge or alter a ticket in order to resume a A malicious user could forge or alter a ticket by value in order to
session, to extend its lifetime, to impersonate as another user, or resume a session, to extend its lifetime, to impersonate as another
to gain additional privileges. This attack is not possible if the user, or to gain additional privileges. This attack is not possible
ticket is protected using a strong integrity protection algorithm. if the content of the ticket by value is protected using a strong
integrity protection algorithm.
In case of a ticket by reference an adversary may attempt to
construct a faked ticket by reference to point to state information
stored by the IKEv2 responder. This attack will fail because the
adversary is not in possession of the keying material associated with
the IKEv2 SA.
7.3. Denial of Service Attacks 7.3. Denial of Service Attacks
An adversary could generate and send a large number of tickets to a An adversary could generate and send a large number of tickets by
gateway for verification. To minimize the possibility of such denial value to a gateway for verification. To minimize the possibility of
of service, ticket verification should be lightweight (e.g., using such denial of service, ticket verification should be lightweight
efficient symmetric key cryptographic algorithms). (e.g., using efficient symmetric key cryptographic algorithms).
7.4. Ticket Protection Key Management When an adversary chooses to send a large number of tickets by value
then this may lead to an amplification attack as the IKEv2 is forced
to resolve the reference to a ticket in order to determine that the
adversary is not in possession of the keying material corresponding
to the stored state or that the reference is void. To minimize this
attack the protocol to resolve the reference should be as lightweight
as possible. and should not generate a large number of messages.
7.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 is beyond the scope of this document. A list of RECOMMENDED ticket by value is beyond the scope of this document. A list of
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 7.5. Ticket Lifetime
An IKEv2 responder controls the lifetime of a ticket, based on the An IKEv2 responder controls the validity period of the state
operational and security requirements of the environment in which it information by attaching a lifetime to a ticket. The chosen lifetime
is deployed. The responder provides information about the ticket is based on the operational and security requirements of the
lifetime to the IKEv2 initiator, allowing it to manage its tickets. environment in which this IKEv2 extension is deployed. The responder
provides information about the ticket lifetime to the IKEv2
initiator, allowing it to manage its tickets.
7.6. Ticket Format 7.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 5.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 secure communication to prevent client it MUST be done using channel security to prevent attackers
attackers from obtaining or modifying the key. Also, the ticket MUST from obtaining or modifying the ticket. Also, the ticket by value
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 7.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 (e.g., with the help of encryption. Thus,
it prevents the disclosure of potentially sensitive information. it prevents the disclosure of potentially sensitive information.
skipping to change at page 16, line 23 skipping to change at page 17, line 13
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 to
particularly thank Florian Tegeler and Stjepan Gros for their help 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
Muhanna and Stephen Kent for their feedback regarding the ticket by
reference concept.
9. References 9. References
9.1. Normative References 9.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.
skipping to change at page 17, line 8 skipping to change at page 17, line 48
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 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.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
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 following format is RECOMMENDED. mandatory-to-use ticket format. The format described in the sub-
sections are RECOMMENDED.
A.1. Recommended 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 17, line 48 skipping to change at page 18, line 45
} 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 a recent draft The reader is referred to [I-D.rescorla-stateless-tokens] that
[I-D.rescorla-stateless-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. Recommended 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 RECOMMEND 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 18, line 28 skipping to change at page 19, line 29
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. -00 B.1. -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.2. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.2. -01 B.3. -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.3. -00 B.4. -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.4. -04 B.5. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.5. -03 B.6. -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.6. -02 B.7. -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.7. -01 B.8. -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.8. -00 B.9. -00
Initial version. This draft is a selective merge of Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00. draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
skipping to change at page 21, line 4 skipping to change at line 909
Email: ldondeti@qualcomm.com Email: ldondeti@qualcomm.com
Vidya Narayanan Vidya Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
5775 Morehouse Dr 5775 Morehouse Dr
San Diego, CA San Diego, CA
USA USA
Phone: +1 858-845-2483 Phone: +1 858-845-2483
Email: vidyan@qualcomm.com Email: vidyan@qualcomm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 49 change blocks. 
122 lines changed or deleted 180 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/