draft-ietf-ipsecme-ikev2-resumption-01.txt   draft-ietf-ipsecme-ikev2-resumption-02.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: July 28, 2009 Nokia Siemens Networks Expires: September 10, 2009 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
January 24, 2009 March 9, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-01.txt draft-ietf-ipsecme-ikev2-resumption-02.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 July 28, 2009. This Internet-Draft will expire on September 10, 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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.
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 10 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8
4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10 4.3.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 10
4.2.3. Requesting a ticket during resumption . . . . . . . . 11 4.3.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10
4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 4.3.3. Requesting a Ticket during Resumption . . . . . . . . 11
4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11 4.4. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11
4.5. Processing Guidelines for IKE SA Establishment . . . . . . 12 4.5. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11
4.6. TICKET_OPAQUE' Notify Payload . . . . . . . . . . . . . . 12
4.7. Processing Guidelines for IKE SA Establishment . . . . . . 12
5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13 5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13
5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 13 5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 15
7.4. Key Management for Tickets By Value . . . . . . . . . . . 15 7.4. Key Management for Tickets By Value . . . . . . . . . . . 16
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 15 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 16
7.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 15 7.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 16
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 16 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 16
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 16 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 18
A.1. Recommended Ticket by Value Format . . . . . . . . . . . . 18 A.1. Recommended Ticket by Value Format . . . . . . . . . . . . 19
A.2. Recommended Ticket by Reference Format . . . . . . . . . . 19 A.2. Recommended Ticket by Reference Format . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.6. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.6. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.7. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.7. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.8. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 7, line 10 skipping to change at page 7, line 10
network. This capability is implicit in the use of the IKE network. This capability is implicit in the use of the IKE
configuration mechanism, which allows the client to present its configuration mechanism, which allows the client to present its
existing IP address and receive the same address back, if allowed by existing IP address and receive the same address back, if allowed by
the gateway. 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.2. 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 a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
o In an Informational exchange, if the gateway previously replied o In an Informational exchange, if the gateway previously replied
with an N(TICKET_ACK) instead of providing a ticket. with an N(TICKET_ACK) instead of providing a ticket.
o In an Informational exchange, when the ticket lifetime is about to o In an Informational exchange, when the ticket lifetime is about to
expire. expire.
o In an IKE_SESSION_RESUME exchange, see Section 4.2.3. o In an IKE_SESSION_RESUME exchange, see Section 4.3.3.
Normally, a client requests a ticket in the third message of an IKEv2 Normally, a client requests a ticket in the third message of an IKEv2
exchange (the first of IKE_AUTH). Figure 2 shows the message exchange (the first of IKE_AUTH). Figure 2 shows the message
exchange for this typical case. exchange for this typical case.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
Figure 2: Example Message Exchange for Requesting a Ticket Figure 2: Example Message Exchange for Requesting a Ticket
The notification payloads are described in Section 4.3. The above is The notification payloads are described in Section 4.4. 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]. A complete description of IKEv2 can be found in [RFC4718].
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_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.
Provided the IKEv2 exchange was successful, the IKEv2 initiator can 4.2. Receiving a Ticket
accept the requested ticket. The ticket may be used later with an
IKEv2 responder that supports this extension. Figure 3 shows how the The IKEv2 initiator receives the ticket and may accept it provided
initiator receives the ticket. the IKEv2 exchange was successful, as described in Section 4.1. The
ticket may be used later with an IKEv2 responder that supports this
extension. Figure 3 shows how 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) [,N(TICKET_GATEWAY_LIST)]} TSr, N(TICKET_OPAQUE) }
Figure 3: Receiving a Ticket Figure 3: Receiving a Ticket
4.2. 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 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, i.e., a client MUST NOT reuse
ticket, either with the same or with a different gateway. A gateway a ticket. A reused ticket SHOULD be rejected by a gateway.
SHOULD reject a reused ticket.
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 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 { [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The value Note: The initiator presents the TICKET_OPAQUE' payload to the
of the Lifetime field in the TICKET_OPAQUE payload is set to the responder as the lifetime field attached to the ticket is not
value that was received when requesting the ticket. relevant to the responder as it is included in the protected form
inside the ticket.
See Section 4.2.1 for details on computing the protected (SK) 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
the SPIr value is set to 0.
See Section 4.3.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
payload it MUST perform one of the following steps if it supports the N(TICKET_OPAQUE') payload it MUST perform one of the following steps
extension defined in this document: 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 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 active and if the responder accepts it, then the old SAs SHOULD be
silently deleted without sending a DELETE informational exchange. 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 {IDr, Nr, SAr2, [TSi, TSr], <-- HDR, SK {Nr, SAr2, [TSi, TSr],
[CP(CFG_REPLY)]} [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'. 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
the SPIr value is set to 0.
The SK payload is protected using the cryptographic parameters The SK payload is protected using the cryptographic parameters
derived from the ticket, see Section 4.2.1 below. derived from the ticket, see Section 4.3.1 below.
At this point a new IKE SA is created by both parties, see At this point a new IKE SA is created by both parties, see
Section 4.5. This is followed by normal derivation of a child SA, Section 4.7. This is followed by normal derivation of a child SA,
per Section 2.17 of [RFC4306]. per Section 2.17 of [RFC4306].
4.2.1. Protection of the IKE_SESSION_RESUME Exchange 4.3.1. Protection of the IKE_SESSION_RESUME Exchange
The two messages of this exchange are protected by a "subset" IKE SA. The two messages of this exchange are protected by a "subset" IKE SA.
The key material is derived from the ticket, as follows: 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) {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 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 from the ticket. Ni guarantees freshness of the key material. SK_d2
is used later to derive the new IKE SA, see Section 4.5. 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 See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket. in the ticket.
4.2.2. Presenting a Ticket: The DoS Case 4.3.2. Presenting a Ticket: The DoS Case
When receiving the first message of the IKE_SESSION_RESUME exchange, When receiving the first message of the IKE_SESSION_RESUME exchange,
the gateway may decide that it is under a denial-of-service attack. 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 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 state until it has verified the identity of the client. We use a
variation of the IKEv2 Cookie mechanism, whereby the cookie is variation of the IKEv2 Cookie mechanism, whereby the cookie is
protected. protected.
In the two messages that follow, the gateway responds that it is In the two messages that follow, the gateway responds that it is
unwilling to resume the session until the client is verified, and the unwilling to resume the session until the client is verified, and the
client resubmits its first message, this time with the cookie: client resubmits its first message, this time with the cookie:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, SK{N(COOKIE)} <-- HDR, SK{N(COOKIE)}
HDR, Ni, N(TICKET_OPAQUE), [N+,] HDR, Ni, N(TICKET_OPAQUE), [N+,]
SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> SK {N(COOKIE), [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
Assuming the cookie is correct, the gateway now replies normally. Assuming the cookie is correct, the gateway now replies normally.
This now becomes a 4-message exchange. The entire exchange is This now becomes a 4-message exchange. The entire exchange is
protected as defined in Section 4.2.1. protected as defined in Section 4.3.1.
See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance
regarding the usage and syntax of the cookie. Note that the cookie regarding the usage and syntax of the cookie. Note that the cookie
is completely independent of the IKEv2 ticket. is completely independent of the IKEv2 ticket.
4.2.3. Requesting a ticket during resumption 4.3.3. 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. Therefore, the N(TICKET_REQUEST) and
N(TICKET_OPAQUE) notifications may be piggybacked as protected N(TICKET_OPAQUE) notifications may be piggybacked as protected
payloads to the IKE_SESSION_RESUME exchange. payloads to the IKE_SESSION_RESUME exchange.
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.5. per the rules described in Section 4.7.
4.3. IKE Notifications 4.4. 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.4 | | TICKET_OPAQUE | TBA1 | See Section 4.5 |
| 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 |
+-------------------+--------+-----------------+ +-------------------+--------+-----------------+
4.4. TICKET_OPAQUE Notify Payload 4.5. 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, a lifetime field and the ticket itself. The four message header, a lifetime field and the ticket itself. The four
octet lifetime field contains the number of seconds until the ticket octet lifetime field contains the number of seconds until the ticket
expires (encoded as an unsigned integer). 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 !
skipping to change at page 12, line 4 skipping to change at page 12, line 18
! 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.6. TICKET_OPAQUE' Notify Payload
The data for the TICKET_OPAQUE' Notify payload consists of the Notify
message header, and the ticket itself. Unlike the TICKET_OPAQUE
payload no lifetime value is included in the TICKET_OPAQUE' Notify
payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ticket ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TICKET_OPAQUE' Notify Payload
4.7. 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 per value. In case a ticket by reference was provided by the client
the gateway needs to resolve the reference in order to obtain the the gateway needs to resolve the reference in order to obtain the
ticket by value. In case the client has already provided the ticket ticket by value. In case the client has already provided the ticket
per value it can parses the ticket. In either case, the gateway 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 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 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: 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 MUST NOT be reused. This
restriction is to avoid problems caused by collisions with other restriction is to avoid problems caused by collisions with other
SPI values used already by the initiator/responder. The SPI value SPI values used already by the initiator/responder.
should only be reused if collision avoidance can be ensured
through other means.
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_d2, Ni | Nr)
where SK_d2 was computed earlier (Section 4.2.1). where SK_d2 was computed earlier (Section 4.3.1).
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.
skipping to change at page 13, line 26 skipping to change at page 14, line 13
[I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. [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. the following state from an IKE SA.
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 The ticket by value MUST include a key identity field, so that keys
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 In addition, the ticket by value and the ticket by reference MUST
contain a protected ticket expiration value that is readable for the contain a protected ticket expiration value that is readable for the
client. 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
[RFC4478]. Even if neither of these are enforced by the gateway, a [RFC4478]. Even if neither of these are enforced by the gateway, a
finite lifetime MUST be specified for the ticket. finite lifetime MUST be specified for the ticket.
The gateway SHOULD set the expiration date for the ticket to a larger
value than the lifetime of the IKE SA. The key that is used to
protect the ticket MUST have a lifetime that is significantly longer
than the lifetime of an IKE SA.
6. IANA Considerations 6. 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.3, to be registered by IANA. The corresponding registry Section 4.4, 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.3. 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. ticket.
7.1. Stolen Tickets 7.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
skipping to change at page 19, line 29 skipping to change at page 20, line 23
int32 expiration; // an absolute time value, seconds int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970 // since Jan. 1, 1970
} ikev2_state_ref; } ikev2_state_ref;
} protected_part; } protected_part;
opaque MAC[0..255]; // the length depends opaque MAC[0..255]; // the length depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
Appendix B. Change Log Appendix B. Change Log
B.1. -01 B.1. -02
Added a new TICKET_OPAQUE' payload that does not have a lifetime
field included.
Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE') when presenting the ticket to the
gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec child SAs would be deleted once the old IKE SA
gets deleted as well.
Clarified the behavior of SPI and sequence number usage.
B.2. -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.2. -00 B.3. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.3. -01 B.4. -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.4. -00 B.5. -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.5. -04 B.6. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.6. -03 B.7. -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.7. -02 B.8. -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.8. -01 B.9. -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.9. -00 B.10. -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. 56 change blocks. 
95 lines changed or deleted 150 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/