idnits 2.17.1 draft-ietf-ipsecme-ikev2-resumption-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2009) is 5421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 1010 -- Looks like a reference, but probably isn't: '8' on line 1011 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-06 == Outdated reference: A later version (-13) exists of draft-ietf-ipsecme-ikev2-redirect-10 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-ikev2bis-03 == Outdated reference: A later version (-12) exists of draft-ietf-rohc-ikev2-extensions-hcoipsec-08 -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Standards Track H. Tschofenig 5 Expires: December 18, 2009 Nokia Siemens Networks 6 June 16, 2009 8 IKEv2 Session Resumption 9 draft-ietf-ipsecme-ikev2-resumption-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 18, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 58 computational and communication overhead with respect to the number 59 of round-trips required and the cryptographic operations involved. 60 In remote access situations, the Extensible Authentication Protocol 61 (EAP) is used for authentication, which adds several more round trips 62 and consequently latency. 64 To re-establish security associations (SAs) upon a failure recovery 65 condition is time consuming especially when an IPsec peer (such as a 66 VPN gateway) needs to re-establish a large number of SAs with various 67 end points. A high number of concurrent sessions might cause 68 additional problems for an IPsec peer during SA re-establishment. 70 In order to avoid the need to re-run the key exchange protocol from 71 scratch it would be useful to provide an efficient way to resume an 72 IKE/IPsec session. This document proposes an extension to IKEv2 that 73 allows a client to re-establish an IKE SA with a gateway in a highly 74 efficient manner, utilizing a previously established IKE SA. 76 A client can reconnect to a gateway from which it was disconnected. 77 The proposed approach encodes partial IKE state into an opaque 78 ticket, which can be stored on the client or in a centralized store, 79 and is later made available to the IKEv2 responder for re- 80 authentication. We use the term ticket to refer to the opaque data 81 that is created by the IKEv2 responder. This document does not 82 specify the format of the ticket but examples are provided. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 89 4. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 8 90 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 8 91 4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9 92 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 93 4.3.1. Prologue . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10 95 4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 96 4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 12 97 5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13 98 5.1. Generating Cryptographic Material for the Resumed IKE 99 SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 101 6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 102 6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 103 7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17 104 7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 17 105 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 108 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19 109 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 110 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20 111 9.4. Key Management for Tickets By Value . . . . . . . . . . . 20 112 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20 113 9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 20 114 9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21 115 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 117 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 118 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 119 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 23 120 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 23 121 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 24 122 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 123 B.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 124 B.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 125 B.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 126 B.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 127 B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 128 B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 129 B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 130 B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 B.9. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 132 B.10. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 133 B.11. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 134 B.12. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 135 B.13. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 138 1. Introduction 140 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 141 computational and communication overhead with respect to the number 142 of round-trips required and the cryptographic operations involved. 143 In particular the Extensible Authentication Protocol (EAP) is used 144 for authentication in remote access cases, which increases latency. 146 To re-establish security associations (SA) upon a failure recovery 147 condition is time-consuming, especially when an IPsec peer, such as a 148 VPN gateway, needs to re-establish a large number of SAs with various 149 end points. A high number of concurrent sessions might cause 150 additional problems for an IPsec responder. Usability is also 151 affected when the re-establishment of an IKE SA involves user 152 interaction for reauthentication. 154 In many failure cases it would be useful to provide an efficient way 155 to resume an interrupted IKE/IPsec session. This document proposes 156 an extension to IKEv2 that allows a client to re-establish an IKE SA 157 with a gateway in a highly efficient manner, utilizing a previously 158 established IKE SA. 160 A client can reconnect to a gateway from which it was disconnected. 161 One way to ensure that the IKEv2 responder is able to recreate the 162 state information is by maintaining IKEv2 state (or a reference into 163 a state store) in a "ticket", an opaque data structure. This ticket 164 is created by the gateway and forwarded to the client, or 165 alternatively, is stored centrally and a reference to it is forwarded 166 to the client. The IKEv2 protocol is extended to allow a client to 167 request and present a ticket. This document does not mandate the 168 format of the ticket structure. In Appendix A a ticket by value and 169 a ticket by reference format is proposed. 171 This approach is similar to the one taken by TLS session resumption 172 [RFC5077] with the required adaptations for IKEv2, e.g., to 173 accommodate the two-phase protocol structure. We have borrowed 174 heavily from that specification. 176 The proposed solution should additionally meet the following goals: 178 o Using only symmetric cryptography to minimize CPU consumption. 179 o Providing cryptographic agility. 180 o Having no negative impact on IKEv2 security features. 182 The following are non-goals of this solution: 183 o Failover from one gateway to another. This use case may be added 184 in a future specification. 186 o Providing load balancing among gateways. 187 o Specifying how a client detects the need for resumption. 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 This document uses terminology defined in [RFC4301] and [RFC4306]. 196 In addition, this document uses the following terms: 198 Ticket: An IKEv2 ticket is a data structure that contains all the 199 necessary information that allows an IKEv2 responder to re- 200 establish an IKEv2 security association. 202 In this document we use the term "ticket" and thereby refer to an 203 opaque data structure that may either contain IKEv2 state as 204 described above or a reference pointing to such state. 206 3. Usage Scenario 208 This specification envisions two usage scenarios for efficient IKEv2 209 and IPsec SA session re-establishment. 211 The first is similar to the use case specified in Section 1.1.3 of 212 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 213 used to establish a secure channel between a remote access client and 214 a gateway; the traffic flow may be between the client and entities 215 beyond the gateway. This scenario is further discussed below. 217 The second use case focuses on the usage of transport (or tunnel) 218 mode to secure the communicate between two end points (e.g., two 219 servers). The two endpoints have a client-server relationship with 220 respect to a protocol that runs using the protections afforded by the 221 IPsec SA. 223 (a) 225 +-+-+-+-+-+ +-+-+-+-+-+ 226 ! ! IKEv2/IKEv2-EAP ! ! Protected 227 ! Remote !<------------------------>! ! Subnet 228 ! Access ! ! Access !<--- and/or 229 ! Client !<------------------------>! Gateway ! Internet 230 ! ! IPsec tunnel ! ! 231 +-+-+-+-+-+ +-+-+-+-+-+ 233 (b) 235 +-+-+-+-+-+ +-+-+-+-+-+ 236 ! ! IKE_SESSION_RESUME ! ! 237 ! Remote !<------------------------>! ! 238 ! Access ! ! Access ! 239 ! Client !<------------------------>! Gateway ! 240 ! ! IPsec tunnel ! ! 241 +-+-+-+-+-+ +-+-+-+-+-+ 243 Figure 1: Resuming a Session with a Remote Access Gateway 245 In the first use case above, an end host (an entity with a host 246 implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA 247 with a gateway in a remote network using IKEv2. The end host in this 248 scenario is sometimes referred to as a remote access client. At a 249 later stage when a client needs to re-establish the IKEv2 session it 250 may choose to establish IPsec SAs using a full IKEv2 exchange or the 251 IKE_SESSION_RESUME exchange (shown in Figure 1). 253 For either of the above use cases, there are multiple possible 254 situations where the mechanism specified in this document could be 255 useful. These include the following (note that this list is not 256 meant to be exhaustive, and any particular deployment may not care 257 about all of these): 259 o If a client temporarily loses network connectivity (and the IKE SA 260 times out through the livensss test facility, a.k.a. "dead peer 261 detection"), this mechanism could be used to re-establish the SA 262 with less overhead (network, CPU, authentication infrastructure) 263 and without requiring user interaction for authentication. 264 o If the connectivity problems affect a large number of clients 265 (e.g., a large remote access VPN gateway), when the connectivity 266 is restored, all the clients might reconnect almost 267 simultaneously. This mechanism could be used to reduce the load 268 spike for cryptographic operations and authentication 269 infrastructure. 270 o Losing connectivity can also be predictable and planned; for 271 example, putting a laptop to "stand-by" mode before travelling. 272 This mechanism could be used to re-establish the SA when the 273 laptop is switched back on (again, with less overhead and without 274 requiring user interaction for authentication). However such 275 user-level "resumption" may often be disallowed by policy. 277 4. Protocol Sequences 279 This section provides protocol details and contains the normative 280 parts. This document defines two protocol exchanges, namely 281 requesting a ticket, see Section 4.1, and presenting a ticket, see 282 Section 4.3. 284 4.1. Requesting a Ticket 286 A client MAY request a ticket in the following exchanges: 288 o In an IKE_AUTH exchange, as shown in the example message exchange 289 in Figure 2 below. 290 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only 291 when this exchange is initiated by the client). 292 o In an Informational exchange at any time, e.g. if the gateway 293 previously replied with an N(TICKET_ACK) instead of providing a 294 ticket, or when the ticket lifetime is about to expire, or 295 following a gateway-initiated IKE rekey. All such Informational 296 exchanges MUST be initiated by the client. 297 o While resuming an IKE session, i.e. in the IKE_AUTH exchange that 298 follows an IKE_SESSION_RESUME exchange, see Section 4.3.3. 300 Normally, a client requests a ticket in the third message of an IKEv2 301 exchange (the first of IKE_AUTH). Figure 2 shows the message 302 exchange for this typical case. 304 Initiator Responder 305 ----------- ----------- 306 HDR, SAi1, KEi, Ni --> 308 <-- HDR, SAr1, KEr, Nr [, CERTREQ] 310 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 311 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 312 Figure 2: Example Message Exchange for Requesting a Ticket 314 The notification payloads are described in Section 7. The above is 315 an example, and IKEv2 allows a number of variants on these messages. 316 Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details 317 on IKEv2. 319 When an IKEv2 responder receives a request for a ticket using the 320 N(TICKET_REQUEST) payload it MUST perform one of the following 321 operations if it supports the extension defined in this document: 322 o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE) 323 payload in a subsequent message towards the IKEv2 initiator. This 324 is shown in Figure 3. 325 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 326 ticket for some reason. 327 o it returns an N(TICKET_ACK), if it cannot grant a ticket 328 immediately, e.g., due to packet size limitations. In this case 329 the client MAY request a ticket later using an Informational 330 exchange, at any time during the lifetime of the IKE SA. 331 Regardless of this choice, there is no change to the behavior of the 332 responder with respect to the IKE exchange, and the proper IKE 333 response (e.g. an IKE_AUTH response or an error notification) MUST be 334 sent. 336 4.2. Receiving a Ticket 338 The IKEv2 initiator receives the ticket and may accept it, provided 339 the IKEv2 exchange was successful. The ticket may be used later with 340 an IKEv2 responder that supports this extension. Figure 3 shows how 341 the initiator receives the ticket. 343 Initiator Responder 344 ----------- ----------- 345 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 346 TSr, N(TICKET_LT_OPAQUE) } 348 Figure 3: Receiving a Ticket 350 When a multi-round-trip IKE_AUTH exchange is used, the 351 N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH 352 request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST 353 only be returned in the final IKE_AUTH response. 355 When the client accepts the ticket, it stores it in its local storage 356 for later use, along with the IKE SA that the ticket refers to. 358 Since the ticket itself is opaque to the client, the local storage 359 MUST also include all items marked as "from the ticket" in the table 360 of Section 5. 362 4.3. Presenting a Ticket 364 When the client wishes to recover from an interrupted session, it 365 presents the ticket to resume the session. This section describes 366 the resumption process, consisting of some preparations, an 367 IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization. 369 4.3.1. Prologue 371 It is up to the client's local policy to decide when the 372 communication with the IKEv2 responder is seen as interrupted and the 373 session resumption procedure is to be initiated. 375 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange 376 even if it is in possession of a valid, unexpired ticket. A client 377 MUST NOT present a ticket when it knows that the ticket's lifetime 378 has expired. 380 Tickets are intended for one-time use, i.e. a client MUST NOT reuse a 381 ticket. A reused ticket SHOULD be rejected by a gateway. Note that 382 a ticket is considered as used only when an IKE SA has been 383 established successfully with it. 385 4.3.2. IKE_SESSION_RESUME Exchange 387 This document specifies a new IKEv2 exchange type called 388 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 389 equivalent to the IKE_SA_INIT exchange, and MUST be followed by an 390 IKE_AUTH exchange. The client SHOULD NOT use this exchange type 391 unless it knows that the gateway supports it. 393 Initiator Responder 394 ----------- ----------- 395 HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] --> 397 Figure 4: IKEv2 Initiator wishes to resume an IKE SA 399 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 400 initiator sets the SPIi value in the HDR to a random value and the 401 SPIr value is set to 0. 403 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 404 payload it MUST perform one of the following steps if it supports the 405 extension defined in this document: 407 o If it is willing to accept the ticket, it responds as shown in 408 Figure 5. 409 o It responds with an unprotected N(TICKET_NACK) notification, if it 410 rejects the ticket for any reason. In that case, the initiator 411 should re-initiate a regular IKE exchange. One such case is when 412 the responder receives a ticket for an IKE SA that has previously 413 been terminated on the responder itself, which may indicate 414 inconsistent state between the IKEv2 initiator and the responder. 415 However, a responder is not required to maintain the state for 416 terminated sessions. 418 Initiator Responder 419 ----------- ----------- 420 <-- HDR, Nr [,N+] 422 Figure 5: IKEv2 Responder accepts the ticket 424 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 425 responder copies the SPIi value from the request, and the SPIr value 426 is set to a random value . 428 Where not specified otherwise, the IKE_SESSION_RESUME exchange 429 behaves exactly like the IKE_SA_INIT exchange. Specifically: 431 o The client MAY resume the IKE exchange from any IP address and 432 port, regardless of its original address. The gateway MAY reject 433 the resumed exchange if its policy depends on the client's address 434 (although this rarely makes sense). 435 o The first message may be rejected in denial of service situations, 436 with the initiator instructed to send a cookie. 437 o Notifications normally associated with IKE_SA_INIT can be sent. 438 In particular, NAT detection payloads. 439 o The client's NAT traversal status SHOULD be determined anew in 440 IKE_SESSION_RESUME. If NAT is detected, the initiator switches to 441 UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT 442 status is explicitly not part of the session resumption state. 443 o The SPI values and Message ID fields behave similarly to 444 IKE_SA_INIT. 446 Although the IKE SA is not fully valid until the completion of the 447 IKE_AUTH exchange, the peers must create much of the SA state 448 (Section 5) now. Specifically, the SK_xx values are required to 449 protect the IKE_AUTH payloads. 451 4.3.3. IKE_AUTH Exchange 453 Following the IKE_SESSION_RESUME exchange, the client MUST initiate 454 an IKE_AUTH exchange, which is largely as specified in [RFC4306]. 455 This section lists the differences and constraints compared to the 456 base document. 458 The value of the AUTH payload is derived in a manner similar to the 459 usage of IKEv2 pre-shared secret authentication: 461 AUTH = prf(SK_px, ) 463 Each of the initiator and responder uses its own SK_p value, taken 464 from the newly generated IKE SA, Section 5.1. 466 The exact material to be signed is defined in Section 2.15 of 467 [RFC4306]. 469 The IDi value sent in the IKE_AUTH exchange MUST be identical to the 470 value included in the ticket. A CERT payload MUST NOT be included in 471 this exchange, and therefore a new IDr value cannot be negotiated 472 (since it would not be authenticated). As a result, the IDr value 473 sent (by the gateway, and optionally by the client) in this exchange 474 MUST also be identical to the value included in the ticket. 476 When resuming a session, a client will typically request a new ticket 477 immediately, so that it is able to resume the session again in the 478 case of a second failure. The N(TICKET_REQUEST) and 479 N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH 480 exchange that follows the IKE_SESSION_RESUME exchange, with similar 481 behavior to a ticket request during a regular IKE exchange, 482 Section 4.1. The returned ticket (if any) will correspond to the IKE 483 SA created per the rules described in Section 5. 485 4.3.4. Epilogue 487 Following the IKE_AUTH exchange, a new IKE SA is created by both 488 parties, see Section 5, and a child SA is derived, per Section 2.17 489 of [RFC4306]. 491 When the responder receives a ticket for an IKE SA that is still 492 active and if the responder accepts it (i.e. following successful 493 completion of the IKE_AUTH exchange), the old SA SHOULD be silently 494 deleted without sending a DELETE informational exchange. 495 Consequently, all the dependent IPsec child SAs are also deleted. 497 5. IKE and IPsec State After Resumption 499 During the resumption process, both peers create IKE and IPsec state 500 for the resumed IKE SA. Although the SA is only completed following 501 a successful IKE_AUTH exchange, many of its components are created 502 earlier, notably the SA's crypto material (Section 5.1). 504 When a ticket is presented, the gateway needs to obtain the ticket 505 state. In case a ticket by reference was provided by the client, the 506 gateway needs to resolve the reference in order to obtain this state. 507 In case the client has already provided a ticket by value, the 508 gateway can parse the ticket to obtain the state directly. In either 509 case, the gateway needs to process the ticket state in order to 510 restore the state of the old IKE SA, and the client retrieves the 511 same state from its local store. 513 The following table, compiled by Pasi Eronen, describes the IKE and 514 IPsec state of the peers after session resumption, and how it is 515 related to their state before the IKE SA was interrupted. When the 516 table mentions that a certain state item is taken "from the ticket", 517 this should be construed as: 518 o The client retrieves this item from its local store. 519 o In the case of ticket by value, the gateway encodes this 520 information in the ticket. 521 o In the case of ticket by reference, the gateway fetches this 522 information from the ticket store. 524 +------------------------------------+------------------------------+ 525 | State Item | After Resumption | 526 +------------------------------------+------------------------------+ 527 | IDi | From the ticket (but must | 528 | | also be exchanged in | 529 | | IKE_AUTH). See also Note 1 | 530 | IDr | From the ticket (but must | 531 | | also be exchanged in | 532 | | IKE_AUTH) | 533 | Authentication method (PKI, | From the ticket | 534 | pre-shared secret, EAP, PKI-less | | 535 | EAP | | 536 | [I-D.eronen-ipsec-ikev2-eap-auth] | | 537 | etc.) | | 538 | Certificates (when applicable) | From the ticket, see Note 2 | 539 | Local IP address/port, peer IP | Selected by the client, see | 540 | address/port | Note 3 | 541 | NAT detection status | From new exchange | 542 | SPIs | From new exchange, see Note | 543 | | 4 | 544 | Which peer is the "original | Determined by the initiator | 545 | initiator"? | of IKE_SESSION_RESUME | 546 | IKE SA sequence numbers (Message | Reset to 0 in | 547 | ID) | IKE_SESSION_RESUME, and | 548 | | subsequently incremented | 549 | | normally | 550 | IKE SA algorithms (SAr) | From the ticket | 551 | IKE SA keys (SK_*) | The old SK_d is obtained | 552 | | from the ticket and all keys | 553 | | are refreshed, see | 554 | | Section 5.1 | 555 | IKE SA window size | Reset to 1 | 556 | Child SAs (ESP/AH) | Created in new exchange, see | 557 | | Note 7 | 558 | Internal IP address | Not resumed, but see Note 5 | 559 | Other Configuration Payload | Not resumed | 560 | information | | 561 | Peer vendor IDs | Implementation specific | 562 | | (needed in the ticket only | 563 | | if vendor-specific state is | 564 | | required) | 565 | Peer supports MOBIKE [RFC4555] | From new exchange | 566 | MOBIKE additional addresses | Not resumed, should be | 567 | | resent by client if | 568 | | necessary | 569 | Time until re-authentication | From new exchange (but | 570 | [RFC4478] | ticket lifetime is bounded | 571 | | by this duration) | 572 | Peer supports redirects | From new exchange | 573 | [I-D.ietf-ipsecme-ikev2-redirect] | | 574 +------------------------------------+------------------------------+ 576 Note 1: The authenticated peer identity used for policy lookups may 577 not be the same as the IDi payload (see Sec. 3.5 of 578 [RFC4718]), and if so, MUST be included in the ticket. Note 579 that the client may not have access to this value. 580 Note 2: Certificates don't need to be stored if the peer never uses 581 them for anything after the IKE SA is up; however if they 582 are needed, e.g. if exposed to applications via IPsec APIs, 583 they MUST be stored in the ticket. 584 Note 3: If the certificate has an iPAddress SubjectAltName, and the 585 implementation requires it to match the peer's source IP 586 address, the same check needs to be performed on session 587 resumption and the required information saved locally or in 588 the ticket. 589 Note 4: SPI values of the old SA MAY be stored in the ticket, to 590 help the gateway locate corresponding old IKE state. These 591 values MUST NOT be used for the resumed SA. 592 Note 5: The client can request the address it was using earlier, and 593 if possible, the gateway SHOULD honor the request. 594 Note 6: IKEv2 features that affect only the IKE_AUTH exchange 595 (including HTTP_CERT_LOOKUP_SUPPORTED, multiple 596 authentication exchanges [RFC4739], ECDSA authentication 597 [RFC4754], and OCSP [RFC4806]) don't usually need any state 598 in the IKE SA (after the IKE_AUTH exchanges are done), so 599 resumption doesn't affect them. 600 Note 7: Since information about CHILD SAs and configuration payloads 601 is not resumed, IKEv2 features related to CHILD SA 602 negotiation (such as IPCOMP_SUPPORTED, 603 ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec 604 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration 605 aren't usually affected by session resumption. 606 Note 8: New IKEv2 features that are not covered by notes 6 and 7 607 should specify how they interact with session resumption. 609 5.1. Generating Cryptographic Material for the Resumed IKE SA 611 The cryptographic material is refreshed based on the ticket and the 612 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 613 value is derived as follows: 615 SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr) 617 where SK_d_old is taken from the ticket. The literal string is 618 encoded as 10 ASCII characters, with no NULL terminator. 620 The keys are derived as follows, unchanged from IKEv2: 622 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 623 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 625 where SPIi, SPIr are the SPI values created in the new IKE exchange. 627 See [RFC4306] for the notation. "prf" is determined from the SA value 628 in the ticket. 630 6. Ticket Handling 632 6.1. Ticket Content 634 When passing a ticket by value to the client, the ticket content MUST 635 be integrity protected and encrypted. 637 A ticket by reference does not need to be encrypted, as it does not 638 contain any sensitive material, such as keying material. However, 639 access to the storage where that sensitive material is stored MUST be 640 protected so that only unauthorized access is not allowed. We note 641 that such a ticket is analogous to the concept of 'stub', as defined 642 in [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. 644 Although not strictly required for cryptographic protection, it is 645 RECOMMENDED to integrity-protect the ticket by reference. Failing to 646 do so could result in various security vulnerabilities on the gateway 647 side, depending on the format of the reference. Potential 648 vulnerabilities include access by the gateway to unintended URLs 649 (similar to cross-site scripting) or SQL injection. 651 When the state is passed by value, the ticket MUST encode all state 652 information marked "from the ticket" in the table on Section 5. The 653 same state MUST be stored in the ticket store, in the case of ticket 654 by reference. 656 A ticket by value MUST include a protected expiration time, which is 657 an absolute time value and SHOULD correspond to the value included in 658 the TICKET_LT_OPAQUE payload. 660 The ticket by value MUST additionally include a key identity field, 661 so that keys for ticket encryption and authentication can be changed, 662 and when necessary, algorithms can be replaced. 664 6.2. Ticket Identity and Lifecycle 666 Each ticket is associated with a single IKE SA. In particular, when 667 an IKE SA is deleted, the client MUST delete its stored ticket. 668 Similarly, when credentials associated with the IKE SA are 669 invalidated (e.g. when a user logs out), the ticket MUST be deleted. 670 When the IKE SA is rekeyed the ticket is invalidated, and the client 671 SHOULD request a new ticket. 673 The lifetime of the ticket sent by the gateway SHOULD be the minimum 674 of the IKE SA lifetime (per the gateway's local policy) and its re- 675 authentication time, according to [RFC4478]. Even if neither of 676 these are enforced by the gateway, a finite lifetime MUST be 677 specified for the ticket. 679 The key that is used to protect the ticket MUST have a lifetime that 680 is significantly longer than the lifetime of an IKE SA. 682 In normal operation, the client will request a ticket when 683 establishing the initial IKE SA, and then every time the SA is 684 rekeyed or re-established because of re-authentication. 686 7. IKE Notifications 688 This document defines a number of notifications. The notification 689 numbers are TBA by IANA. 691 +-------------------+--------+-----------------+ 692 | Notification Name | Number | Data | 693 +-------------------+--------+-----------------+ 694 | TICKET_LT_OPAQUE | TBA1 | See Section 7.1 | 695 | TICKET_REQUEST | TBA2 | None | 696 | TICKET_ACK | TBA3 | None | 697 | TICKET_NACK | TBA4 | None | 698 | TICKET_OPAQUE | TBA5 | See Section 7.2 | 699 +-------------------+--------+-----------------+ 701 For all these notifications, the Protocol ID and the SPI Size fields 702 MUST both be sent as 0. 704 7.1. TICKET_LT_OPAQUE Notify Payload 706 The data for the TICKET_LT_OPAQUE Notify payload consists of the 707 Notify message header, a Lifetime field and the ticket itself. The 708 four octet Lifetime field contains a relative time value, the number 709 of seconds until the ticket expires (encoded as an unsigned integer). 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 ! Next Payload !C! Reserved ! Payload Length ! 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 ! Lifetime ! 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 ! ! 721 ~ Ticket ~ 722 ! ! 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Figure 6: TICKET_LT_OPAQUE Notify Payload 727 7.2. TICKET_OPAQUE Notify Payload 729 The data for the TICKET_OPAQUE Notify payload consists of the Notify 730 message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE 731 payload no lifetime value is included in the TICKET_OPAQUE Notify 732 payload. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 ! Next Payload !C! Reserved ! Payload Length ! 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 ! ! 742 ~ Ticket ~ 743 ! ! 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 7: TICKET_OPAQUE Notify Payload 748 8. IANA Considerations 750 This document requires a number of IKEv2 notification status types in 751 Section 7, to be registered by IANA. The "IKEv2 Notify Message Types 752 - Status Types" registry was established by IANA. 754 The document defines a new IKEv2 exchange in Section 4.3. The 755 corresponding registry was established by IANA. 757 9. Security Considerations 759 This section addresses security issues related to the usage of a 760 ticket. 762 9.1. Stolen Tickets 764 A man-in-the-middle may try to eavesdrop on an exchange to obtain a 765 ticket by value and use it to establish a session with the IKEv2 766 responder. Since all exchanges where the client obtains a ticket are 767 encrypted, this is only possible by listening in on a client's use of 768 the ticket to resume a session. However, since the ticket's contents 769 are encrypted and the attacker does not know the corresponding secret 770 key, a stolen ticket cannot be used by an attacker to successfully 771 resume a session. An IKEv2 responder MUST use strong encryption and 772 integrity protection of the ticket to prevent an attacker from 773 obtaining the ticket's contents, e.g., by using a brute force attack. 775 A ticket by reference does not need to be encrypted. When an 776 adversary is able to eavesdrop on a resumption attempt, as described 777 in the previous paragraph, then the ticket by reference may be 778 obtained. A ticket by reference cannot be used by an attacker to 779 successfully resume a session, for the same reasons as for a ticket 780 by value. Moreover, the adversary MUST NOT be able to resolve the 781 ticket via the reference, i.e., access control MUST be enforced to 782 ensure disclosure only to authorized entities. 784 9.2. Forged Tickets 786 A malicious user could forge or alter a ticket by value in order to 787 resume a session, to extend its lifetime, to impersonate as another 788 user, or to gain additional privileges. This attack is not possible 789 if the content of the ticket by value is protected using a strong 790 integrity protection algorithm. 792 In case of a ticket by reference an adversary may attempt to 793 construct a fake ticket by reference to point to state information 794 stored by the IKEv2 responder. This attack will fail because the 795 adversary is not in possession of the keying material associated with 796 the IKEv2 SA. As noted in Section 6.1, it is often useful to 797 integrity-protect the ticket by reference, too. 799 9.3. Denial of Service Attacks 801 An adversary could generate and send a large number of tickets by 802 value to a gateway for verification. To minimize the possibility of 803 such denial of service, ticket verification should be lightweight 804 (e.g., using efficient symmetric key cryptographic algorithms). 806 When an adversary chooses to send a large number of tickets by 807 reference then this may lead to an amplification attack as the IKEv2 808 responder is forced to resolve the reference to a ticket in order to 809 determine that the adversary is not in possession of the keying 810 material corresponding to the stored state or that the reference is 811 void. To minimize this attack, the protocol to resolve the reference 812 should be as lightweight as possible. and should not generate a large 813 number of messages. 815 9.4. Key Management for Tickets By Value 817 A full description of the management of the keys used to protect the 818 ticket by value is beyond the scope of this document. A list of 819 RECOMMENDED practices is given below. 820 o The keys should be generated securely following the randomness 821 recommendations in [RFC4086]. 822 o The keys and cryptographic protection algorithms should be at 823 least 128 bits in strength. 824 o The keys should not be used for any other purpose than generating 825 and verifying tickets. 826 o The keys should be changed regularly. 827 o The keys should be changed if the ticket format or cryptographic 828 protection algorithms change. 830 9.5. Ticket Lifetime 832 An IKEv2 responder controls the validity period of the state 833 information by attaching a lifetime to a ticket. The chosen lifetime 834 is based on the operational and security requirements of the 835 environment in which this IKEv2 extension is deployed. The responder 836 provides information about the ticket lifetime to the IKEv2 837 initiator, allowing it to manage its tickets. 839 9.6. Ticket by Value Format 841 The ticket's format is not defined by this document, since this is 842 not required for interoperability. However great care must be taken 843 when defining a ticket format such that the requirements outlined in 844 Section 6.1 are met. The ticket by value MUST have its integrity and 845 confidentiality protected with strong cryptographic techniques to 846 prevent a breach in the security of the system. 848 9.7. Identity Privacy, Anonymity, and Unlinkability 850 Since opaque state information is passed around between the IKEv2 851 initiator and the IKEv2 responder it is important that leakage of 852 information, such as the identities of an IKEv2 initiator and a 853 responder, MUST be avoided. 855 When an IKEv2 initiator presents a ticket as part of the 856 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 857 exchange. There is thereby the possibility for an on-path adversary 858 to observe multiple exchange handshakes where the same state 859 information is used and therefore to conclude that they belong to the 860 same communication end points. 862 This document therefore requires that the ticket be presented to the 863 IKEv2 responder only once; under normal circumstances (e.g. no active 864 attacker), there should be no multiple use of the same ticket. 866 10. Acknowledgements 868 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 869 Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ 870 Housely, Yoav Nir and Tero Kivinen for their comments. We would like 871 to particularly thank Florian Tegeler and Stjepan Gros for their 872 implementation efforts and Florian Tegeler for a formal verification 873 using the Casper tool set. 875 We would furthermore like to thank the authors of 876 [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke 877 Xu) for their input on the stub concept. 879 We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad 880 Muhanna and Stephen Kent for their feedback regarding the ticket by 881 reference concept. 883 Vidya Narayanan and Lakshminath Dondeti coauthored several past 884 versions of this document, and we acknowledge their significant 885 contribution. 887 11. References 889 11.1. Normative References 891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 892 Requirement Levels", BCP 14, RFC 2119, March 1997. 894 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 895 RFC 4306, December 2005. 897 11.2. Informative References 899 [I-D.eronen-ipsec-ikev2-eap-auth] 900 Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 901 for EAP-Only Authentication in IKEv2", 902 draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress), 903 April 2009. 905 [I-D.ietf-ipsecme-ikev2-redirect] 906 Devarapalli, V. and K. Weniger, "Redirect Mechanism for 907 IKEv2", draft-ietf-ipsecme-ikev2-redirect-10 (work in 908 progress), May 2009. 910 [I-D.ietf-ipsecme-ikev2bis] 911 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 912 "Internet Key Exchange Protocol: IKEv2", 913 draft-ietf-ipsecme-ikev2bis-03 (work in progress), 914 April 2009. 916 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] 917 Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and 918 C. Bormann, "IKEv2 Extensions to Support Robust Header 919 Compression over IPsec (ROHCoIPsec)", 920 draft-ietf-rohc-ikev2-extensions-hcoipsec-08 (work in 921 progress), February 2009. 923 [I-D.rescorla-stateless-tokens] 924 Rescorla, E., "How to Implement Secure (Mostly) Stateless 925 Tokens", draft-rescorla-stateless-tokens-01 (work in 926 progress), March 2007. 928 [I-D.xu-ike-sa-sync] 929 Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA 930 Synchronization for session resumption", 931 draft-xu-ike-sa-sync-01 (work in progress), October 2008. 933 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 934 Requirements for Security", BCP 106, RFC 4086, June 2005. 936 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 937 Internet Protocol", RFC 4301, December 2005. 939 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 940 (IKEv2) Protocol", RFC 4478, April 2006. 942 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 943 (MOBIKE)", RFC 4555, June 2006. 945 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 946 Implementation Guidelines", RFC 4718, October 2006. 948 [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication 949 Exchanges in the Internet Key Exchange (IKEv2) Protocol", 950 RFC 4739, November 2006. 952 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 953 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 954 RFC 4754, January 2007. 956 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 957 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 958 February 2007. 960 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 961 "Transport Layer Security (TLS) Session Resumption without 962 Server-Side State", RFC 5077, January 2008. 964 Appendix A. Ticket Format 966 This document does not specify a mandatory-to-implement or a 967 mandatory-to-use ticket format. The formats described in the 968 following sub-sections are provided as useful examples. 970 A.1. Example Ticket by Value Format 971 struct { 972 [authenticated] struct { 973 octet format_version; // 1 for this version of the protocol 974 octet reserved[3]; // sent as 0, ignored by receiver. 975 octet key_id[8]; // arbitrary byte string 976 opaque IV[0..255]; // actual length (possibly 0) depends 977 // on the encryption algorithm 979 [encrypted] struct { 980 opaque IDi, IDr; // the full payloads 981 octet SPIi[8], SPIr[8]; 982 opaque SA; // the full SAr payload 983 octet SK_d[0..255]; // actual length depends on SA value 984 enum ... authentication_method; 985 int32 expiration; // an absolute time value, seconds 986 // since Jan. 1, 1970 987 } ikev2_state; 988 } protected_part; 989 opaque MAC[0..255]; // the length (possibly 0) depends 990 // on the integrity algorithm 991 } ticket; 993 Note that the key defined by "key_id" determines the encryption and 994 authentication algorithms used for this ticket. Those algorithms are 995 unrelated to the transforms defined by the SA payload. 997 The reader is referred to [I-D.rescorla-stateless-tokens] that 998 recommends a similar (but not identical) ticket format, and discusses 999 related security considerations in depth. 1001 A.2. Example Ticket by Reference Format 1003 For implementations that prefer to pass a reference to IKE state in 1004 the ticket, rather than the state itself, we suggest the following 1005 format: 1007 struct { 1008 [authenticated] struct { 1009 octet format_version; // 1 for this version of the protocol 1010 octet reserved[3]; // sent as 0, ignored by receiver. 1011 octet key_id[8]; // arbitrary byte string 1013 struct { 1014 opaque state_ref; // reference to IKE state 1015 int32 expiration; // an absolute time value, seconds 1016 // since Jan. 1, 1970 1017 } ikev2_state_ref; 1018 } protected_part; 1019 opaque MAC[0..255]; // the length depends 1020 // on the integrity algorithm 1021 } ticket; 1023 Appendix B. Change Log 1025 Note to RFC Editor: remove this appendix before publication. 1027 B.1. -05 1029 Editorial changes: reordered and merged some sections. 1031 Restated the use cases. 1033 IDr is not negotiated during resumption, the gateway must use the 1034 stored IDr. 1036 Multiple small clarifications based on Pasi's LC review. 1038 IPR: pre5378Trust200902. 1040 B.2. -04 1042 Closed issue #105, Non-PKI use of EAP, and resumption. 1044 Closed issue #106, Resumption and NAT detection and changing ports. 1046 B.3. -03 1048 Changed the protocol from one to two round trips, to simplify the 1049 security assumptions. Eliminated security considerations associated 1050 with the previous version. 1052 Closed issue #69, Clarify behavior of SPI and sequence numbers. 1054 Closed issue #70, Ticket lifetime - explicit or not? (and ticket push 1055 from gateway). 1057 Closed issue #99, Ticket example: downgrade. 1059 Closed issue #76, IPsec child SAs during resumption. 1061 Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption. 1063 Closed issue #95, Minor nits for ikev2-resumption-02. 1065 Closed issue #97, Clarify what state comes from where. 1067 Closed issue #98, Replays in 1-RTT protocol. 1069 Closed issue #100, NAT detection [and] IP address change. 1071 Closed issue #101, Assorted issues by Tero. 1073 B.4. -02 1075 Added a new TICKET_OPAQUE payload that does not have a lifetime field 1076 included. 1078 Removed the lifetime usage from the IKE_SESSION_RESUME exchange 1079 (utilizing the TICKET_OPAQUE) when presenting the ticket to the 1080 gateway. 1082 Removed IDi payloads from the IKE_SESSION_RESUME exchange. 1084 Clarified that IPsec child SAs would be deleted once the old IKE SA 1085 gets deleted as well. 1087 Clarified the behavior of SPI and sequence number usage. 1089 B.5. -01 1091 Addressed issue#75, see 1092 http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included 1093 changes throughout the document to ensure that the ticket may contain 1094 a reference or a value. 1096 B.6. -00 1098 Resubmitted document as a WG item. 1100 B.7. -01 1102 Added reference to [I-D.xu-ike-sa-sync] 1104 Included recommended ticket format into the appendix 1106 Various editorial improvements within the document 1108 B.8. -00 1110 Issued a -00 version for the IPSECME working group. Reflected 1111 discussions at IETF#72 regarding the strict focus on session 1112 resumption. Consequently, text about failover was removed. 1114 B.9. -04 1116 Editorial fixes; references cleaned up; updated author's contact 1117 address 1119 B.10. -03 1121 Removed counter mechanism. Added an optional anti-DoS mechanism, 1122 based on IKEv2 cookies (removed previous discussion of cookies). 1123 Clarified that gateways may support reallocation of same IP address, 1124 if provided by network. Proposed a solution outline to the problem 1125 of key exchange for the keys that protect tickets. Added fields to 1126 the ticket to enable interoperability. Removed incorrect MOBIKE 1127 notification. 1129 B.11. -02 1131 Clarifications on generation of SPI values, on the ticket's lifetime 1132 and on the integrity protection of the anti-replay counter. 1133 Eliminated redundant SPIs from the notification payloads. 1135 B.12. -01 1137 Editorial review. Removed 24-hour limitation on ticket lifetime, 1138 lifetime is up to local policy. 1140 B.13. -00 1142 Initial version. This draft is a selective merge of 1143 draft-sheffer-ike-session-resumption-00 and 1144 draft-dondeti-ipsec-failover-sol-00. 1146 Authors' Addresses 1148 Yaron Sheffer 1149 Check Point Software Technologies Ltd. 1150 5 Hasolelim St. 1151 Tel Aviv 67897 1152 Israel 1154 Email: yaronf@checkpoint.com 1156 Hannes Tschofenig 1157 Nokia Siemens Networks 1158 Linnoitustie 6 1159 Espoo 02600 1160 Finland 1162 Phone: +358 (50) 4871445 1163 Email: Hannes.Tschofenig@gmx.net 1164 URI: http://www.tschofenig.priv.at