draft-ietf-ipsecme-ikev2-resumption-07.txt   draft-ietf-ipsecme-ikev2-resumption-08.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: February 22, 2010 Nokia Siemens Networks Expires: March 25, 2010 Nokia Siemens Networks
August 21, 2009 September 21, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-07.txt draft-ietf-ipsecme-ikev2-resumption-08.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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 February 22, 2010. This Internet-Draft will expire on March 25, 2010.
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 32 skipping to change at page 3, line 32
6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17 7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17
7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18 7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18
7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20
9.4. Key Management for Tickets By Value . . . . . . . . . . . 20 9.4. Detecting the Need for Resumption . . . . . . . . . . . . 20
9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20 9.5. Key Management for Tickets By Value . . . . . . . . . . . 20
9.6. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21 9.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 21
9.7. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21 9.7. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21
9.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21 9.8. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21
9.9. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24
A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 24 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 24
A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
B.1. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.1. -08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.3. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.3. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.6. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.6. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.7. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.10. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.11. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.11. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.12. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.12. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.13. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.13. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.14. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.14. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.15. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.15. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 B.16. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol has a certain The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved. of round-trips required and the cryptographic operations involved.
In particular the Extensible Authentication Protocol (EAP) is used In particular the Extensible Authentication Protocol (EAP) is used
for authentication in remote access cases, which increases latency. for authentication in remote access cases, which increases latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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).
For either of the above use cases, there are multiple possible For either of the above use cases, there are multiple possible
situations where the mechanism specified in this document could be situations where the mechanism specified in this document could be
useful. These include the following (note that this list is not useful. These include the following (note that this list is not
meant to be exhaustive, and any particular deployment may not care meant to be exhaustive, and any particular deployment may not care
about all of these): about all of these):
o If a client temporarily loses network connectivity (and the IKE SA o If a client temporarily loses network connectivity (and the IKE SA
times out through the livensss test facility, a.k.a. "dead peer times out through the liveness test facility, a.k.a. "dead peer
detection"), this mechanism could be used to re-establish the SA detection"), this mechanism could be used to re-establish the SA
with less overhead (network, CPU, authentication infrastructure) with less overhead (network, CPU, authentication infrastructure)
and without requiring user interaction for authentication. and without requiring user interaction for authentication.
o If the connectivity problems affect a large number of clients o If the connectivity problems affect a large number of clients
(e.g., a large remote access VPN gateway), when the connectivity (e.g., a large remote access VPN gateway), when the connectivity
is restored, all the clients might reconnect almost is restored, all the clients might reconnect almost
simultaneously. This mechanism could be used to reduce the load simultaneously. This mechanism could be used to reduce the load
spike for cryptographic operations and authentication spike for cryptographic operations and authentication
infrastructure. infrastructure.
o Losing connectivity can also be predictable and planned; for o Losing connectivity can also be predictable and planned; for
skipping to change at page 10, line 47 skipping to change at page 10, line 47
ticket. A reused ticket SHOULD be rejected by a gateway. Note that ticket. A reused ticket SHOULD be rejected by a gateway. Note that
a ticket is considered as used only when an IKE SA has been a ticket is considered as used only when an IKE SA has been
established successfully with it. established successfully with it.
4.3.2. IKE_SESSION_RESUME Exchange 4.3.2. IKE_SESSION_RESUME Exchange
This document specifies a new IKEv2 exchange type called This document specifies a new IKEv2 exchange type called
IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
equivalent to the IKE_SA_INIT exchange, and MUST be followed by an equivalent to the IKE_SA_INIT exchange, and MUST be followed by an
IKE_AUTH exchange. The client SHOULD NOT use this exchange type IKE_AUTH exchange. The client SHOULD NOT use this exchange type
unless it knows that the gateway supports it. unless it knows that the gateway supports it (this condition is
trivially true in the context of the current document, since the
client always resumes into the same gateway that generated the
ticket).
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] --> HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
Figure 4: IKEv2 Initiator wishes to resume an IKE SA Figure 4: IKEv2 Initiator wishes to resume an IKE SA
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The
initiator sets the SPIi value in the HDR to a new, unique value and initiator sets the SPIi value in the HDR to a new, unique value and
the SPIr value is set to 0. the SPIr value is set to 0.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
is set to a new, unique value . is set to a new, unique value .
Where not specified otherwise, the IKE_SESSION_RESUME exchange Where not specified otherwise, the IKE_SESSION_RESUME exchange
behaves exactly like the IKE_SA_INIT exchange. Specifically: behaves exactly like the IKE_SA_INIT exchange. Specifically:
o The client MAY resume the IKE exchange from any IP address and o The client MAY resume the IKE exchange from any IP address and
port, regardless of its original address. The gateway MAY reject port, regardless of its original address. The gateway MAY reject
the resumed exchange if its policy depends on the client's address the resumed exchange if its policy depends on the client's address
(although this rarely makes sense). (although this rarely makes sense).
o The first message may be rejected in denial of service situations, o The first message MAY be rejected in denial of service situations,
with the initiator instructed to send a cookie. with the initiator instructed to send a cookie.
o Notifications normally associated with IKE_SA_INIT can be sent. o Notifications normally associated with IKE_SA_INIT can be sent.
In particular, NAT detection payloads. In particular, NAT detection payloads.
o The client's NAT traversal status SHOULD be determined anew in o The client's NAT traversal status SHOULD be determined anew in
IKE_SESSION_RESUME. If NAT is detected, the initiator switches to IKE_SESSION_RESUME. If NAT is detected, the initiator switches to
UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT
status is explicitly not part of the session resumption state. status is explicitly not part of the session resumption state.
o The SPI values and Message ID fields behave similarly to o The SPI values and Message ID fields behave similarly to
IKE_SA_INIT. IKE_SA_INIT.
skipping to change at page 13, line 11 skipping to change at page 13, line 11
case of a second failure. The N(TICKET_REQUEST) and case of a second failure. The N(TICKET_REQUEST) and
N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH
exchange that follows the IKE_SESSION_RESUME exchange, with similar exchange that follows the IKE_SESSION_RESUME exchange, with similar
behavior to a ticket request during a regular IKE exchange, behavior to a ticket request during a regular IKE exchange,
Section 4.1. The returned ticket (if any) will correspond to the IKE Section 4.1. The returned ticket (if any) will correspond to the IKE
SA created per the rules described in Section 5. SA created per the rules described in Section 5.
4.3.4. Epilogue 4.3.4. Epilogue
Following the IKE_AUTH exchange, a new IKE SA is created by both Following the IKE_AUTH exchange, a new IKE SA is created by both
parties, see Section 5, and a child SA is derived, per Section 2.17 parties, see Section 5, and a Child SA is derived, per Section 2.17
of [RFC4306]. of [RFC4306].
When the responder receives a ticket for an IKE SA that is still When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it (i.e. following successful active and if the responder accepts it (i.e. following successful
completion of the IKE_AUTH exchange), the old SA SHOULD be silently completion of the IKE_AUTH exchange), the old SA SHOULD be silently
deleted without sending a DELETE informational exchange. deleted without sending a DELETE informational exchange.
Consequently, all the dependent IPsec child SAs are also deleted. Consequently, all the dependent IPsec Child SAs are also deleted.
5. IKE and IPsec State After Resumption 5. IKE and IPsec State After Resumption
During the resumption process, both peers create IKE and IPsec state During the resumption process, both peers create IKE and IPsec state
for the resumed IKE SA. Although the SA is only completed following for the resumed IKE SA. Although the SA is only completed following
a successful IKE_AUTH exchange, many of its components are created a successful IKE_AUTH exchange, many of its components are created
earlier, notably the SA's crypto material (Section 5.1). earlier, notably the SA's crypto material (Section 5.1).
When a ticket is presented, the gateway needs to obtain the ticket When a ticket is presented, the gateway needs to obtain the ticket
state. In case a ticket by reference was provided by the client, the state. In case a ticket by reference was provided by the client, the
skipping to change at page 15, line 30 skipping to change at page 15, line 30
the ticket. the ticket.
Note 4: SPI values of the old SA MAY be stored in the ticket, to Note 4: SPI values of the old SA MAY be stored in the ticket, to
help the gateway locate corresponding old IKE state. These help the gateway locate corresponding old IKE state. These
values MUST NOT be used for the resumed SA. values MUST NOT be used for the resumed SA.
Note 5: The client can request the address it was using earlier, and Note 5: The client can request the address it was using earlier, and
if possible, the gateway SHOULD honor the request. if possible, the gateway SHOULD honor the request.
Note 6: Since information about Child SAs and configuration payloads Note 6: Since information about Child SAs and configuration payloads
is not resumed, IKEv2 features related to Child SA is not resumed, IKEv2 features related to Child SA
negotiation (such as IPCOMP_SUPPORTED, negotiation (such as IPCOMP_SUPPORTED,
ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration [I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration)
aren't usually affected by session resumption. aren't usually affected by session resumption.
IKEv2 features that affect only the IKE_AUTH exchange (including IKEv2 features that affect only the IKE_AUTH exchange (including
HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges
[RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't [RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't
usually need any state in the IKE SA (after the IKE_AUTH exchanges usually need any state in the IKE SA (after the IKE_AUTH exchanges
are done), so resumption doesn't affect them. are done), so resumption doesn't affect them.
New IKEv2 features that are not covered by note 6 or by the previous New IKEv2 features that are not covered by note 6 or by the previous
paragraph should specify how they interact with session resumption. paragraph should specify how they interact with session resumption.
skipping to change at page 16, line 28 skipping to change at page 16, line 28
6. Ticket Handling 6. Ticket Handling
6.1. Ticket Content 6.1. Ticket Content
When passing a ticket by value to the client, the ticket content MUST When passing a ticket by value to the client, the ticket content MUST
be integrity protected and encrypted. be integrity protected and encrypted.
A ticket by reference does not need to be encrypted, as it does not A ticket by reference does not need to be encrypted, as it does not
contain any sensitive material, such as keying material. However, contain any sensitive material, such as keying material. However,
access to the storage where that sensitive material is stored MUST be access to the storage where that sensitive material is stored MUST be
protected so that only unauthorized access is not allowed. We note protected so that only authorized access is allowed. We note that
that such a ticket is analogous to the concept of 'stub', as defined such a ticket is analogous to the concept of 'stub', as defined in
in [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.
Although not strictly required for cryptographic protection, it is Although not strictly required for cryptographic protection, it is
RECOMMENDED to integrity-protect the ticket by reference. Failing to RECOMMENDED to integrity-protect the ticket by reference. Failing to
do so could result in various security vulnerabilities on the gateway do so could result in various security vulnerabilities on the gateway
side, depending on the format of the reference. Potential side, depending on the format of the reference. Potential
vulnerabilities include access by the gateway to unintended URLs vulnerabilities include access by the gateway to unintended URLs
(similar to cross-site scripting) or SQL injection. (similar to cross-site scripting) or SQL injection.
When the state is passed by value, the ticket MUST encode all state When the state is passed by value, the ticket MUST encode all state
information marked "from the ticket" in the table on Section 5. The information marked "from the ticket" in the table on Section 5. The
skipping to change at page 17, line 15 skipping to change at page 17, line 15
6.2. Ticket Identity and Lifecycle 6.2. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted by the client or the gateway, the client MUST an IKE SA is deleted by the client or the gateway, the client MUST
delete its stored ticket. Similarly, when credentials associated delete its stored ticket. Similarly, when credentials associated
with the IKE SA are invalidated (e.g. when a user logs out), the with the IKE SA are invalidated (e.g. when a user logs out), the
ticket MUST be deleted. When the IKE SA is rekeyed the ticket is ticket MUST be deleted. When the IKE SA is rekeyed the ticket is
invalidated, and the client SHOULD request a new ticket. When a invalidated, and the client SHOULD request a new ticket. When a
client does not follow these rules, it might present an invalid client does not follow these rules, it might present an invalid
ticket to the gateway. See Section 9.6 for more about this issue. ticket to the gateway. See Section 9.7 for more about this issue.
The lifetime of the ticket sent by the gateway SHOULD be the minimum The lifetime of the ticket sent by the gateway SHOULD be the minimum
of the IKE SA lifetime (per the gateway's local policy) and its re- of the IKE SA lifetime (per the gateway's local policy) and its re-
authentication time, according to [RFC4478]. Even if neither of authentication time, according to [RFC4478]. Even if neither of
these are enforced by the gateway, a finite lifetime MUST be these are enforced by the gateway, a finite lifetime MUST be
specified for the ticket. specified for the ticket.
The key that is used to protect the ticket MUST have a lifetime that The key that is used to protect the ticket MUST have a lifetime that
is significantly longer than the lifetime of an IKE SA. is significantly longer than the lifetime of an IKE SA.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
value to a gateway for verification. To minimize the possibility of value to a gateway for verification. To minimize the possibility of
such denial of service, ticket verification should be lightweight such denial of service, ticket verification should be lightweight
(e.g., using efficient symmetric key cryptographic algorithms). (e.g., using efficient symmetric key cryptographic algorithms).
When an adversary chooses to send a large number of tickets by When an adversary chooses to send a large number of tickets by
reference then this may lead to an amplification attack as the IKEv2 reference then this may lead to an amplification attack as the IKEv2
responder is forced to resolve the reference to a ticket in order to responder is forced to resolve the reference to a ticket in order to
determine that the adversary is not in possession of the keying determine that the adversary is not in possession of the keying
material corresponding to the stored state or that the reference is material corresponding to the stored state or that the reference is
void. To minimize this attack, the protocol to resolve the reference void. To minimize this attack, the protocol to resolve the reference
should be as lightweight as possible. and should not generate a large should be as lightweight as possible and should not generate a large
number of messages. number of messages.
9.4. Key Management for Tickets By Value 9.4. Detecting the Need for Resumption
Detecting when an old IKE SA is no longer usable and needs to be
resumed is out of scope of the current document. However, clients
are warned against implementing a more liberal policy than that used
to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular,
untrusted messages MUST NOT be relied upon to make this decision.
9.5. Key Management for Tickets By Value
A full description of the management of the keys used to protect the A full description of the management of the keys used to protect the
ticket by value is beyond the scope of this document. A list of ticket by value is beyond the scope of this document. A list of
RECOMMENDED practices is given below. RECOMMENDED practices is given below.
o The keys should be generated securely following the randomness o The keys should be generated securely following the randomness
recommendations in [RFC4086]. recommendations in [RFC4086].
o The keys and cryptographic protection algorithms should be at o The keys and cryptographic protection algorithms should be at
least 128 bits in strength. least 128 bits in strength.
o The keys should not be used for any other purpose than generating o The keys should not be used for any other purpose than generating
and verifying tickets. and verifying tickets.
o The keys should be changed regularly. o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic o The keys should be changed if the ticket format or cryptographic
protection algorithms change. protection algorithms change.
9.5. Ticket Lifetime 9.6. Ticket Lifetime
An IKEv2 responder controls the validity period of the state An IKEv2 responder controls the validity period of the state
information by attaching a lifetime to a ticket. The chosen lifetime information by attaching a lifetime to a ticket. The chosen lifetime
is based on the operational and security requirements of the is based on the operational and security requirements of the
environment in which this IKEv2 extension is deployed. The responder environment in which this IKEv2 extension is deployed. The responder
provides information about the ticket lifetime to the IKEv2 provides information about the ticket lifetime to the IKEv2
initiator, allowing it to manage its tickets. initiator, allowing it to manage its tickets.
9.6. Ticket Revocation 9.7. Ticket Revocation
A misbehaving client could present a ticket in its possession to the A misbehaving client could present a ticket in its possession to the
gateway resulting in session resumption, even though the IKE SA gateway resulting in session resumption, even though the IKE SA
associated with this ticket had previously been deleted. This is associated with this ticket had previously been deleted. This is
disallowed by Section 6.2. This issue is unique to ticket by value disallowed by Section 6.2. This issue is unique to ticket by value
cases, since a ticket by reference will have been deleted from the cases, since a ticket by reference will have been deleted from the
ticket store. ticket store.
To avoid this issue for ticket by value, an Invalid Ticket List (ITL) To avoid this issue for ticket by value, an Invalid Ticket List (ITL)
may be maintained by the gateway, see may be maintained by the gateway, see
[I-D.rescorla-stateless-tokens]. This can be a simple blacklist of [I-D.rescorla-stateless-tokens]. This can be a simple blacklist of
revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens] revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens]
suggests to use Bloom Filters [Bloom70] to maintain the list in suggests to use Bloom Filters [Bloom70] to maintain the list in
constant space. Management of such lists is outside the scope of the constant space. Management of such lists is outside the scope of the
current document. Note that a policy that requires tickets to have current document. Note that a policy that requires tickets to have
shorter lifetimes (e.g., 1 hour) significantly mitigates this issue. shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
9.7. Ticket by Value Format 9.8. Ticket by Value Format
The ticket's format is not defined by this document, since this is The ticket's format is not defined by this document, since this is
not required for interoperability. However great care must be taken not required for interoperability. However great care must be taken
when defining a ticket format such that the requirements outlined in when defining a ticket format such that the requirements outlined in
Section 6.1 are met. The ticket by value MUST have its integrity and Section 6.1 are met. The ticket by value MUST have its integrity and
confidentiality protected with strong cryptographic techniques to confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system. prevent a breach in the security of the system.
9.8. Identity Privacy, Anonymity, and Unlinkability 9.9. Identity Privacy, Anonymity, and Unlinkability
Since opaque state information is passed around between the IKEv2 Since opaque state information is passed around between the IKEv2
initiator and the IKEv2 responder it is important that leakage of initiator and the IKEv2 responder it is important that leakage of
information, such as the identities of an IKEv2 initiator and a information, such as the identities of an IKEv2 initiator and a
responder, MUST be avoided. responder, MUST be avoided.
When an IKEv2 initiator presents a ticket as part of the When an IKEv2 initiator presents a ticket as part of the
IKE_SESSION_RESUME exchange, confidentiality is not provided for the IKE_SESSION_RESUME exchange, confidentiality is not provided for the
exchange. There is thereby the possibility for an on-path adversary exchange. There is thereby the possibility for an on-path adversary
to observe multiple exchange handshakes where the same state to observe multiple exchange handshakes where the same state
information is used and therefore to conclude that they belong to the information is used and therefore to conclude that they belong to the
same communication end points. same communication end points.
This document therefore requires that the ticket be presented to the This document therefore requires that the ticket be presented to the
IKEv2 responder only once; under normal circumstances (e.g. no active IKEv2 responder only once; under normal circumstances (e.g. no active
attacker), there should be no multiple use of the same ticket. attacker), there should be no multiple use of the same ticket.
We are not aware of additional security issues associated with ticket
reuse: the protocol guarantees freshness of the generated crypto
material even in such cases. As noted in Section 4.3.1, the gateway
SHOULD prevent multiple uses of the same ticket. But this is only an
extra precaution, to ensure that clients do not implement reuse. In
other words, the gateway is not expected to cache old tickets for
extended periods of time.
10. Acknowledgements 10. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ
Housely, Yoav Nir and Tero Kivinen for their comments. We would like Housely, Yoav Nir, Peny Yang, Sean Turner and Tero Kivinen for their
to particularly thank Florian Tegeler and Stjepan Gros for their comments. We would like to particularly thank Florian Tegeler and
implementation efforts and Florian Tegeler for a formal verification Stjepan Gros for their implementation efforts and Florian Tegeler for
using the Casper tool set. a formal verification using the Casper tool set.
We would furthermore like to thank the authors of We would furthermore like to thank the authors of
[I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke
Xu) for their input on the stub concept. Xu) for their input on the stub concept.
We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad
Muhanna and Stephen Kent for their feedback regarding the ticket by Muhanna and Stephen Kent for their feedback regarding the ticket by
reference concept. reference concept.
Vidya Narayanan and Lakshminath Dondeti coauthored several past Vidya Narayanan and Lakshminath Dondeti coauthored several past
skipping to change at page 25, line 32 skipping to change at page 26, line 25
} 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
Note to RFC Editor: remove this appendix before publication. Note to RFC Editor: remove this appendix before publication.
B.1. -07 B.1. -08
Implemented IETF LC, secdir and gen-art comments.
B.2. -07
Implemented AD Review comments, most of them editorial. Implemented AD Review comments, most of them editorial.
B.2. -06 B.3. -06
Clients resuming propely closed sessions and how this can be avoided. Clients resuming propely closed sessions and how this can be avoided.
B.3. -05 B.4. -05
Editorial changes: reordered and merged some sections. Editorial changes: reordered and merged some sections.
Restated the use cases. Restated the use cases.
IDr is not negotiated during resumption, the gateway must use the IDr is not negotiated during resumption, the gateway must use the
stored IDr. stored IDr.
Multiple small clarifications based on Pasi's LC review. Multiple small clarifications based on Pasi's LC review.
IPR: pre5378Trust200902. IPR: pre5378Trust200902.
B.4. -04 B.5. -04
Closed issue #105, Non-PKI use of EAP, and resumption. Closed issue #105, Non-PKI use of EAP, and resumption.
Closed issue #106, Resumption and NAT detection and changing ports. Closed issue #106, Resumption and NAT detection and changing ports.
B.5. -03 B.6. -03
Changed the protocol from one to two round trips, to simplify the Changed the protocol from one to two round trips, to simplify the
security assumptions. Eliminated security considerations associated security assumptions. Eliminated security considerations associated
with the previous version. with the previous version.
Closed issue #69, Clarify behavior of SPI and sequence numbers. Closed issue #69, Clarify behavior of SPI and sequence numbers.
Closed issue #70, Ticket lifetime - explicit or not? (and ticket push Closed issue #70, Ticket lifetime - explicit or not? (and ticket push
from gateway). from gateway).
Closed issue #99, Ticket example: downgrade. Closed issue #99, Ticket example: downgrade.
Closed issue #76, IPsec child SAs during resumption. Closed issue #76, IPsec Child SAs during resumption.
Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption. Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption.
Closed issue #95, Minor nits for ikev2-resumption-02. Closed issue #95, Minor nits for ikev2-resumption-02.
Closed issue #97, Clarify what state comes from where. Closed issue #97, Clarify what state comes from where.
Closed issue #98, Replays in 1-RTT protocol. Closed issue #98, Replays in 1-RTT protocol.
Closed issue #100, NAT detection [and] IP address change. Closed issue #100, NAT detection [and] IP address change.
Closed issue #101, Assorted issues by Tero. Closed issue #101, Assorted issues by Tero.
B.6. -02 B.7. -02
Added a new TICKET_OPAQUE payload that does not have a lifetime field Added a new TICKET_OPAQUE payload that does not have a lifetime field
included. included.
Removed the lifetime usage from the IKE_SESSION_RESUME exchange Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE) when presenting the ticket to the (utilizing the TICKET_OPAQUE) when presenting the ticket to the
gateway. gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange. Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec child SAs would be deleted once the old IKE SA Clarified that IPsec Child SAs would be deleted once the old IKE SA
gets deleted as well. gets deleted as well.
Clarified the behavior of SPI and sequence number usage. Clarified the behavior of SPI and sequence number usage.
B.7. -01 B.8. -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.8. -00 B.9. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.9. -01 B.10. -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.10. -00 B.11. -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.11. -04 B.12. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.12. -03 B.13. -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.13. -02 B.14. -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.14. -01 B.15. -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.15. -00 B.16. -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. 39 change blocks. 
64 lines changed or deleted 89 lines changed or added

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