draft-ietf-ipsecme-ikev2-resumption-06.txt   draft-ietf-ipsecme-ikev2-resumption-07.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: December 20, 2009 Nokia Siemens Networks Expires: February 22, 2010 Nokia Siemens Networks
June 18, 2009 August 21, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-06.txt draft-ietf-ipsecme-ikev2-resumption-07.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 December 20, 2009. This Internet-Draft will expire on February 22, 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 25 skipping to change at page 3, line 25
4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10 4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10
4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12
4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 13
5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13 5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13
5.1. Generating Cryptographic Material for the Resumed IKE 5.1. Generating Cryptographic Material for the Resumed IKE
SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17 7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17
7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 17 7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18
7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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. Key Management for Tickets By Value . . . . . . . . . . . 20
9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20
9.6. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 20 9.6. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21
9.7. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21 9.7. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21
9.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21 9.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . 24 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
B.1. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.1. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.3. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.5. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.6. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.10. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.11. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.11. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.12. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.12. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.13. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.13. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.14. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.14. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.15. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
additional problems for an IPsec responder. Usability is also additional problems for an IPsec responder. Usability is also
affected when the re-establishment of an IKE SA involves user affected when the re-establishment of an IKE SA involves user
interaction for reauthentication. interaction for reauthentication.
In many failure cases it would be useful to provide an efficient way In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected. The client (IKEv2 initiator) stores the state about the previous IKE
One way to ensure that the IKEv2 responder is able to recreate the SA locally. The gateway (IKEv2 responder) has two options for
state information is by maintaining IKEv2 state (or a reference into maintaining the IKEv2 state about the previous IKE SA:
a state store) in a "ticket", an opaque data structure. This ticket
is created by the gateway and forwarded to the client, or o In the "ticket by reference" approach, the gateway stores the
alternatively, is stored centrally and a reference to it is forwarded state locally, and gives the client a protected and opaque
to the client. The IKEv2 protocol is extended to allow a client to reference (e.g., an index to the gateway's table) that the gateway
request and present a ticket. This document does not mandate the can later use to find the state. The client includes this opaque
format of the ticket structure. In Appendix A a ticket by value and reference when it resumes the session.
a ticket by reference format is proposed. o In the "ticket by value" approach, the gateway stores its state in
a ticket (data structure) that is encrypted and integrity-
protected by a key known only to the gateway. The ticket is
passed to the client (who treats the ticket as an opaque string),
and sent back to the gateway when the session is resumed. The
gateway can then decrypt the ticket and recover the state.
Note that the client behaves identically in both cases, and in
general does not know which approach the gateway is using. Since the
ticket (or reference) is only interpreted by the same party that
created it, this document does not specify the exact format for it.
However, Appendix A contains examples for both "ticket by reference"
and "ticket by value" formats.
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC5077] with the required adaptations for IKEv2, e.g., to [RFC5077] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed accommodate the two-phase protocol structure. We have borrowed
heavily from that specification. heavily from that specification.
The proposed solution should additionally meet the following goals: The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption. o Using only symmetric cryptography to minimize CPU consumption.
o Providing cryptographic agility. o Providing cryptographic agility.
skipping to change at page 8, line 13 skipping to change at page 8, line 18
simultaneously. This mechanism could be used to reduce the load simultaneously. This mechanism could be used to reduce the load
spike for cryptographic operations and authentication spike for cryptographic operations and authentication
infrastructure. infrastructure.
o Losing connectivity can also be predictable and planned; for o Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling. example, putting a laptop to "stand-by" mode before travelling.
This mechanism could be used to re-establish the SA when the This mechanism could be used to re-establish the SA when the
laptop is switched back on (again, with less overhead and without laptop is switched back on (again, with less overhead and without
requiring user interaction for authentication). However such requiring user interaction for authentication). However such
user-level "resumption" may often be disallowed by policy. user-level "resumption" may often be disallowed by policy.
Moreover, this document requires the client to destroy the ticket Moreover, this document requires the client to destroy the ticket
when the user explicitly "logs out" (Section 6.2. when the user explicitly "logs out" (Section 6.2).
4. Protocol Sequences 4. Protocol Sequences
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket, see Section 4.1, and presenting a ticket, see requesting a ticket, see Section 4.1, and presenting a ticket, see
Section 4.3. Section 4.3.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
skipping to change at page 11, line 12 skipping to change at page 11, line 12
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.
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 random value and the initiator sets the SPIi value in the HDR to a new, unique value and
SPIr value is set to 0. the SPIr value is set to 0.
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
payload it MUST perform one of the following steps if it supports the payload it MUST perform one of the following steps if it supports 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 5. Figure 5.
o It responds with an unprotected N(TICKET_NACK) notification, if it o It responds with an unprotected N(TICKET_NACK) notification, if it
rejects the ticket for any reason. In that case, the initiator rejects the ticket for any reason. In that case, the initiator
should re-initiate a regular IKE exchange. One such case is when should re-initiate a regular IKE exchange. One such case is when
skipping to change at page 11, line 38 skipping to change at page 11, line 38
terminated sessions. terminated sessions.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
<-- HDR, Nr [,N+] <-- HDR, Nr [,N+]
Figure 5: IKEv2 Responder accepts the ticket Figure 5: IKEv2 Responder accepts the ticket
Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The
responder copies the SPIi value from the request, and the SPIr value responder copies the SPIi value from the request, and the SPIr value
is set to a random 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,
skipping to change at page 13, line 36 skipping to change at page 13, line 36
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
gateway needs to resolve the reference in order to obtain this state. gateway needs to resolve the reference in order to obtain this state.
In case the client has already provided a ticket by value, the In case the client has already provided a ticket by value, the
gateway can parse the ticket to obtain the state directly. In either gateway can parse the ticket to obtain the state directly. In either
case, the gateway needs to process the ticket state in order to case, the gateway needs to process the ticket state in order to
restore the state of the old IKE SA, and the client retrieves the restore the state of the old IKE SA, and the client retrieves the
same state from its local store. same state from its local store.
The following table, compiled by Pasi Eronen, describes the IKE and The following table describes the IKE and IPsec state of the peers
IPsec state of the peers after session resumption, and how it is after session resumption, and how it is related to their state before
related to their state before the IKE SA was interrupted. When the the IKE SA was interrupted. When the table mentions that a certain
table mentions that a certain state item is taken "from the ticket", state item is taken "from the ticket", this should be construed as:
this should be construed as:
o The client retrieves this item from its local store. o The client retrieves this item from its local store.
o In the case of ticket by value, the gateway encodes this o In the case of ticket by value, the gateway encodes this
information in the ticket. information in the ticket.
o In the case of ticket by reference, the gateway fetches this o In the case of ticket by reference, the gateway fetches this
information from the ticket store. information from the ticket store.
+------------------------------------+------------------------------+ +-------------------------------------+-----------------------------+
| State Item | After Resumption | | State Item | After Resumption |
+------------------------------------+------------------------------+ +-------------------------------------+-----------------------------+
| IDi | From the ticket (but must | | IDi | From the ticket (but must |
| | also be exchanged in | | | also be exchanged in |
| | IKE_AUTH). See also Note 1 | | | IKE_AUTH). See also Note 1 |
| IDr | From the ticket (but must | | IDr | From the ticket (but must |
| | also be exchanged in | | | also be exchanged in |
| | IKE_AUTH) | | | IKE_AUTH) |
| Authentication method (PKI, | From the ticket | | Authentication method (PKI, | From the ticket |
| pre-shared secret, EAP, PKI-less | | | pre-shared secret, EAP, PKI-less | |
| EAP | | | EAP | |
| [I-D.eronen-ipsec-ikev2-eap-auth] | | | [I-D.eronen-ipsec-ikev2-eap-auth] | |
skipping to change at page 14, line 33 skipping to change at page 14, line 33
| SPIs | From new exchange, see Note | | SPIs | From new exchange, see Note |
| | 4 | | | 4 |
| Which peer is the "original | Determined by the initiator | | Which peer is the "original | Determined by the initiator |
| initiator"? | of IKE_SESSION_RESUME | | initiator"? | of IKE_SESSION_RESUME |
| IKE SA sequence numbers (Message | Reset to 0 in | | IKE SA sequence numbers (Message | Reset to 0 in |
| ID) | IKE_SESSION_RESUME, and | | ID) | IKE_SESSION_RESUME, and |
| | subsequently incremented | | | subsequently incremented |
| | normally | | | normally |
| IKE SA algorithms (SAr) | From the ticket | | IKE SA algorithms (SAr) | From the ticket |
| IKE SA keys (SK_*) | The old SK_d is obtained | | IKE SA keys (SK_*) | The old SK_d is obtained |
| | from the ticket and all keys | | | from the ticket and all |
| | are refreshed, see | | | keys are refreshed, see |
| | Section 5.1 | | | Section 5.1 |
| IKE SA window size | Reset to 1 | | IKE SA window size | Reset to 1 |
| Child SAs (ESP/AH) | Created in new exchange, see | | Child SAs (ESP/AH) | Created in new exchange, |
| | Note 7 | | | see Note 6 |
| Internal IP address | Not resumed, but see Note 5 | | Internal IP address | Not resumed, but see Note 5 |
| Other Configuration Payload | Not resumed | | Other Configuration Payload | Not resumed |
| information | | | information | |
| Peer vendor IDs | Implementation specific | | Peer Vendor IDs | Not resumed, resent in new |
| | (needed in the ticket only | | | exchange if required |
| | if vendor-specific state is |
| | required) |
| Peer supports MOBIKE [RFC4555] | From new exchange | | Peer supports MOBIKE [RFC4555] | From new exchange |
| MOBIKE additional addresses | Not resumed, should be | | MOBIKE additional addresses | Not resumed, should be |
| | resent by client if | | | resent by client if |
| | necessary | | | necessary |
| Time until re-authentication | From new exchange (but | | Time until re-authentication | From new exchange (but |
| [RFC4478] | ticket lifetime is bounded | | [RFC4478] | ticket lifetime is bounded |
| | by this duration) | | | by this duration) |
| Peer supports redirects | From new exchange | | Peer supports redirects | From new exchange |
| [I-D.ietf-ipsecme-ikev2-redirect] | | | [I-D.ietf-ipsecme-ikev2-redirect] | |
+------------------------------------+------------------------------+ +-------------------------------------+-----------------------------+
Note 1: The authenticated peer identity used for policy lookups may Note 1: The authenticated peer identity used for policy lookups may
not be the same as the IDi payload (see Sec. 3.5 of not be the same as the IDi payload (see Sec. 3.5 of
[RFC4718]), and if so, MUST be included in the ticket. Note [RFC4718]), and if so, MUST be included in the ticket. Note
that the client may not have access to this value. that the client may not have access to this value.
Note 2: Certificates don't need to be stored if the peer never uses Note 2: Certificates don't need to be stored if the peer never uses
them for anything after the IKE SA is up; however if they them for anything after the IKE SA is up; however if they
are needed, e.g. if exposed to applications via IPsec APIs, are needed, e.g. if exposed to applications via IPsec APIs,
they MUST be stored in the ticket. they MUST be stored in the ticket.
Note 3: If the certificate has an iPAddress SubjectAltName, and the Note 3: If the certificate has an iPAddress SubjectAltName, and the
implementation requires it to match the peer's source IP implementation requires it to match the peer's source IP
address, the same check needs to be performed on session address, the same check needs to be performed on session
resumption and the required information saved locally or in resumption and the required information saved locally or in
the ticket. the ticket.
Note 4: SPI values of the old SA MAY be stored in the ticket, to Note 4: SPI values of the old SA MAY be stored in the ticket, to
help the gateway locate corresponding old IKE state. These help the gateway locate corresponding old IKE state. These
values MUST NOT be used for the resumed SA. values MUST NOT be used for the resumed SA.
Note 5: The client can request the address it was using earlier, and Note 5: The client can request the address it was using earlier, and
if possible, the gateway SHOULD honor the request. if possible, the gateway SHOULD honor the request.
Note 6: IKEv2 features that affect only the IKE_AUTH exchange Note 6: Since information about Child SAs and configuration payloads
(including HTTP_CERT_LOOKUP_SUPPORTED, multiple is not resumed, IKEv2 features related to Child SA
authentication exchanges [RFC4739], ECDSA authentication
[RFC4754], and OCSP [RFC4806]) don't usually need any state
in the IKE SA (after the IKE_AUTH exchanges are done), so
resumption doesn't affect them.
Note 7: Since information about CHILD SAs and configuration payloads
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.
Note 8: New IKEv2 features that are not covered by notes 6 and 7
should specify how they interact with session resumption. IKEv2 features that affect only the IKE_AUTH exchange (including
HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges
[RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't
usually need any state in the IKE SA (after the IKE_AUTH exchanges
are done), so resumption doesn't affect them.
New IKEv2 features that are not covered by note 6 or by the previous
paragraph should specify how they interact with session resumption.
5.1. Generating Cryptographic Material for the Resumed IKE SA 5.1. Generating Cryptographic Material for the Resumed IKE SA
The cryptographic material is refreshed based on the ticket and the The cryptographic material is refreshed based on the ticket and the
nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
value is derived as follows: value is derived as follows:
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr) SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
where SK_d_old is taken from the ticket. The literal string is where SK_d_old is taken from the ticket. The literal string is
encoded as 10 ASCII characters, with no NULL terminator. encoded as 10 ASCII characters, with no NULL terminator.
The keys are derived as follows, unchanged from IKEv2: The keys are derived as follows, unchanged from IKEv2:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
where SPIi, SPIr are the SPI values created in the new IKE exchange. where SPIi, SPIr are the SPI values created in the new IKE exchange.
skipping to change at page 18, line 26 skipping to change at page 18, line 32
~ Ticket ~ ~ Ticket ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TICKET_LT_OPAQUE Notify Payload Figure 6: TICKET_LT_OPAQUE Notify Payload
7.2. TICKET_OPAQUE Notify Payload 7.2. TICKET_OPAQUE Notify Payload
The data for the TICKET_OPAQUE Notify payload consists of the Notify The data for the TICKET_OPAQUE Notify payload consists of the Notify
message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE
payload no lifetime value is included in the TICKET_OPAQUE Notify payload, no lifetime value is included in the TICKET_OPAQUE Notify
payload. payload.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length ! ! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type ! ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
skipping to change at page 18, line 40 skipping to change at page 19, line 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! Reserved ! Payload Length ! ! Next Payload !C! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size = 0 ! Notify Message Type ! ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ Ticket ~ ~ Ticket ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TICKET_OPAQUE Notify Payload Figure 7: TICKET_OPAQUE Notify Payload
8. IANA Considerations 8. IANA Considerations
This document requires a number of IKEv2 notification status types in Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME,
Section 7, to be registered by IANA. The "IKEv2 Notify Message Types whose value is to be allocated (has been allocated) from the "IKEv2
- Status Types" registry was established by IANA. Exchange Types" registry.
The document defines a new IKEv2 exchange in Section 4.3. The Section 7 defines several new IKEv2 notifications whose values are to
corresponding registry was established by IANA. be allocated (have been allocated) from the "IKEv2 Notify Message
Types - Status Types" registry.
9. Security Considerations 9. Security Considerations
This section addresses security issues related to the usage of a This section addresses security issues related to the usage of a
ticket. ticket.
9.1. Stolen Tickets 9.1. Stolen Tickets
A man-in-the-middle may try to eavesdrop on an exchange to obtain a A man-in-the-middle may try to eavesdrop on an exchange to obtain a
ticket by value and use it to establish a session with the IKEv2 ticket by value and use it to establish a session with the IKEv2
skipping to change at page 22, line 42 skipping to change at page 22, line 49
allowable errors", Comm. ACM 13(7):422-6, July 1970. allowable errors", Comm. ACM 13(7):422-6, July 1970.
[I-D.eronen-ipsec-ikev2-eap-auth] [I-D.eronen-ipsec-ikev2-eap-auth]
Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
for EAP-Only Authentication in IKEv2", for EAP-Only Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress), draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress),
April 2009. April 2009.
[I-D.ietf-ipsecme-ikev2-redirect] [I-D.ietf-ipsecme-ikev2-redirect]
Devarapalli, V. and K. Weniger, "Redirect Mechanism for Devarapalli, V. and K. Weniger, "Redirect Mechanism for
IKEv2", draft-ietf-ipsecme-ikev2-redirect-11 (work in IKEv2", draft-ietf-ipsecme-ikev2-redirect-13 (work in
progress), June 2009. progress), August 2009.
[I-D.ietf-ipsecme-ikev2bis] [I-D.ietf-ipsecme-ikev2bis]
Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol: IKEv2", "Internet Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis-03 (work in progress), draft-ietf-ipsecme-ikev2bis-04 (work in progress),
April 2009. July 2009.
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] [I-D.ietf-rohc-ikev2-extensions-hcoipsec]
Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
C. Bormann, "IKEv2 Extensions to Support Robust Header Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec (ROHCoIPsec)", Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec-08 (work in draft-ietf-rohc-ikev2-extensions-hcoipsec-09 (work in
progress), February 2009. progress), August 2009.
[I-D.rescorla-stateless-tokens] [I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-01 (work in Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007. progress), March 2007.
[I-D.xu-ike-sa-sync] [I-D.xu-ike-sa-sync]
Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA
Synchronization for session resumption", Synchronization for session resumption",
draft-xu-ike-sa-sync-01 (work in progress), October 2008. draft-xu-ike-sa-sync-01 (work in progress), October 2008.
skipping to change at page 24, line 7 skipping to change at page 24, line 12
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status
Protocol (OCSP) Extensions to IKEv2", RFC 4806, Protocol (OCSP) Extensions to IKEv2", RFC 4806,
February 2007. February 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
Appendix A. Ticket Format Appendix A. Ticket Format
This document does not specify a mandatory-to-implement or a This document does not specify a particular ticket format nor even
mandatory-to-use ticket format. The formats described in the the suggested contents of a ticket: both are entirely up to the
following sub-sections are provided as useful examples. implementer. The formats described in the following sub-sections are
provided as useful examples, and implementers are free to adopt them
as-is or change them in any way necessary.
A.1. Example Ticket by Value Format A.1. Example Ticket by Value Format
struct { struct {
[authenticated] struct { [authenticated] struct {
octet format_version; // 1 for this version of the protocol octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver. octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string octet key_id[8]; // arbitrary byte string
opaque IV[0..255]; // actual length (possibly 0) depends opaque IV[0..255]; // actual length (possibly 0) depends
// on the encryption algorithm // on the encryption algorithm
skipping to change at page 25, line 25 skipping to change at page 25, line 32
} 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. -06 B.1. -07
Implemented AD Review comments, most of them editorial.
B.2. -06
Clients resuming propely closed sessions and how this can be avoided. Clients resuming propely closed sessions and how this can be avoided.
B.2. -05 B.3. -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.3. -04 B.4. -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.4. -03 B.5. -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).
skipping to change at page 26, line 32 skipping to change at page 26, line 42
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.5. -02 B.6. -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.6. -01 B.7. -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.7. -00 B.8. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.8. -01 B.9. -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.9. -00 B.10. -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.10. -04 B.11. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.11. -03 B.12. -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.12. -02 B.13. -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.13. -01 B.14. -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.14. -00 B.15. -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. 45 change blocks. 
95 lines changed or deleted 111 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/