idnits 2.17.1 draft-ietf-ipsecme-ikev2-resumption-09.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 (October 21, 2009) is 5300 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 1096 -- Looks like a reference, but probably isn't: '8' on line 1097 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-ikev2bis-05 == Outdated reference: A later version (-12) exists of draft-ietf-rohc-ikev2-extensions-hcoipsec-09 -- 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 (~~), 4 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: April 24, 2010 Nokia Siemens Networks 6 October 21, 2009 8 IKEv2 Session Resumption 9 draft-ietf-ipsecme-ikev2-resumption-09.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 April 24, 2010. 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 . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . 18 105 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 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. Detecting the Need for Resumption . . . . . . . . . . . . 20 112 9.5. Key Management for Tickets By Value . . . . . . . . . . . 20 113 9.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 21 114 9.7. Tickets and Identity . . . . . . . . . . . . . . . . . . . 21 115 9.8. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21 116 9.9. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21 117 9.10. Identity Privacy, Anonymity, and Unlinkability . . . . . . 22 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 122 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24 123 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 25 124 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25 125 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 126 B.1. -09 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 127 B.2. -08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 128 B.3. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 129 B.4. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 130 B.5. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 131 B.6. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 132 B.7. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 133 B.8. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 134 B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 135 B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 136 B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 137 B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 138 B.13. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 139 B.14. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 140 B.15. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 141 B.16. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 142 B.17. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 145 1. Introduction 147 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 148 computational and communication overhead with respect to the number 149 of round-trips required and the cryptographic operations involved. 150 In particular the Extensible Authentication Protocol (EAP) is used 151 for authentication in remote access cases, which increases latency. 153 To re-establish security associations (SA) upon a failure recovery 154 condition is time-consuming, especially when an IPsec peer, such as a 155 VPN gateway, needs to re-establish a large number of SAs with various 156 end points. A high number of concurrent sessions might cause 157 additional problems for an IPsec responder. Usability is also 158 affected when the re-establishment of an IKE SA involves user 159 interaction for reauthentication. 161 In many failure cases it would be useful to provide an efficient way 162 to resume an interrupted IKE/IPsec session. This document proposes 163 an extension to IKEv2 that allows a client to re-establish an IKE SA 164 with a gateway in a highly efficient manner, utilizing a previously 165 established IKE SA. 167 The client (IKEv2 initiator) stores the state about the previous IKE 168 SA locally. The gateway (IKEv2 responder) has two options for 169 maintaining the IKEv2 state about the previous IKE SA: 171 o In the "ticket by reference" approach, the gateway stores the 172 state locally, and gives the client a protected and opaque 173 reference (e.g., an index to the gateway's table) that the gateway 174 can later use to find the state. The client includes this opaque 175 reference when it resumes the session. 176 o In the "ticket by value" approach, the gateway stores its state in 177 a ticket (data structure) that is encrypted and integrity- 178 protected by a key known only to the gateway. The ticket is 179 passed to the client (who treats the ticket as an opaque string), 180 and sent back to the gateway when the session is resumed. The 181 gateway can then decrypt the ticket and recover the state. 183 Note that the client behaves identically in both cases, and in 184 general does not know which approach the gateway is using. Since the 185 ticket (or reference) is only interpreted by the same party that 186 created it, this document does not specify the exact format for it. 187 However, Appendix A contains examples for both "ticket by reference" 188 and "ticket by value" formats. 190 This approach is similar to the one taken by TLS session resumption 191 [RFC5077] with the required adaptations for IKEv2, e.g., to 192 accommodate the two-phase protocol structure. We have borrowed 193 heavily from that specification. 195 The proposed solution should additionally meet the following goals: 197 o Using only symmetric cryptography to minimize CPU consumption. 198 o Providing cryptographic agility. 199 o Having no negative impact on IKEv2 security features. 201 The following are non-goals of this solution: 202 o Failover from one gateway to another. This use case may be added 203 in a future specification. 204 o Providing load balancing among gateways. 205 o Specifying how a client detects the need for resumption. 207 2. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 This document uses terminology defined in [RFC4301] and [RFC4306]. 214 In addition, this document uses the following terms: 216 Ticket: An IKEv2 ticket is a data structure that contains all the 217 necessary information that allows an IKEv2 responder to re- 218 establish an IKEv2 security association. 220 In this document we use the term "ticket" and thereby refer to an 221 opaque data structure that may either contain IKEv2 state as 222 described above or a reference pointing to such state. 224 3. Usage Scenario 226 This specification envisions two usage scenarios for efficient IKEv2 227 and IPsec SA session re-establishment. 229 The first is similar to the use case specified in Section 1.1.3 of 230 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 231 used to establish a secure channel between a remote access client and 232 a gateway; the traffic flow may be between the client and entities 233 beyond the gateway. This scenario is further discussed below. 235 The second use case focuses on the usage of transport (or tunnel) 236 mode to secure the communicate between two end points (e.g., two 237 servers). The two endpoints have a client-server relationship with 238 respect to a protocol that runs using the protections afforded by the 239 IPsec SA. 241 (a) 243 +-+-+-+-+-+ +-+-+-+-+-+ 244 | | IKEv2/IKEv2-EAP | | Protected 245 | Remote |<------------------------>| | Subnet 246 | Access | | Access |<--- and/or 247 | Client |<------------------------>| Gateway | Internet 248 | | IPsec tunnel | | 249 +-+-+-+-+-+ +-+-+-+-+-+ 251 (b) 253 +-+-+-+-+-+ +-+-+-+-+-+ 254 | | IKE_SESSION_RESUME | | 255 | Remote |<------------------------>| | 256 | Access | | Access | 257 | Client |<------------------------>| Gateway | 258 | | IPsec tunnel | | 259 +-+-+-+-+-+ +-+-+-+-+-+ 261 Figure 1: Resuming a Session with a Remote Access Gateway 263 In the first use case above, an end host (an entity with a host 264 implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA 265 with a gateway in a remote network using IKEv2. The end host in this 266 scenario is sometimes referred to as a remote access client. At a 267 later stage when a client needs to re-establish the IKEv2 session it 268 may choose to establish IPsec SAs using a full IKEv2 exchange or the 269 IKE_SESSION_RESUME exchange (shown in Figure 1). 271 For either of the above use cases, there are multiple possible 272 situations where the mechanism specified in this document could be 273 useful. These include the following (note that this list is not 274 meant to be exhaustive, and any particular deployment may not care 275 about all of these): 277 o If a client temporarily loses network connectivity (and the IKE SA 278 times out through the liveness test facility, a.k.a. "dead peer 279 detection"), this mechanism could be used to re-establish the SA 280 with less overhead (network, CPU, authentication infrastructure) 281 and without requiring user interaction for authentication. 282 o If the connectivity problems affect a large number of clients 283 (e.g., a large remote access VPN gateway), when the connectivity 284 is restored, all the clients might reconnect almost 285 simultaneously. This mechanism could be used to reduce the load 286 spike for cryptographic operations and authentication 287 infrastructure. 288 o Losing connectivity can also be predictable and planned; for 289 example, putting a laptop to "stand-by" mode before travelling. 290 This mechanism could be used to re-establish the SA when the 291 laptop is switched back on (again, with less overhead and without 292 requiring user interaction for authentication). However such 293 user-level "resumption" may often be disallowed by policy. 294 Moreover, this document requires the client to destroy the ticket 295 when the user explicitly "logs out" (Section 6.2). 297 4. Protocol Sequences 299 This section provides protocol details and contains the normative 300 parts. This document defines two protocol exchanges, namely 301 requesting a ticket, see Section 4.1, and presenting a ticket, see 302 Section 4.3. 304 4.1. Requesting a Ticket 306 A client MAY request a ticket in the following exchanges: 308 o In an IKE_AUTH exchange, as shown in the example message exchange 309 in Figure 2 below. 310 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only 311 when this exchange is initiated by the client). 312 o In an Informational exchange at any time, e.g. if the gateway 313 previously replied with an N(TICKET_ACK) instead of providing a 314 ticket, or when the ticket lifetime is about to expire, or 315 following a gateway-initiated IKE rekey. All such Informational 316 exchanges MUST be initiated by the client. 317 o While resuming an IKE session, i.e. in the IKE_AUTH exchange that 318 follows an IKE_SESSION_RESUME exchange, see Section 4.3.3. 320 Normally, a client requests a ticket in the third message of an IKEv2 321 exchange (the first of IKE_AUTH). Figure 2 shows the message 322 exchange for this typical case. 324 Initiator Responder 325 ----------- ----------- 326 HDR, SAi1, KEi, Ni --> 328 <-- HDR, SAr1, KEr, Nr [, CERTREQ] 330 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 331 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 333 Figure 2: Example Message Exchange for Requesting a Ticket 335 The notification payloads are described in Section 7. The above is 336 an example, and IKEv2 allows a number of variants on these messages. 337 Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details 338 on IKEv2. 340 When an IKEv2 responder receives a request for a ticket using the 341 N(TICKET_REQUEST) payload it MUST perform one of the following 342 operations if it supports the extension defined in this document: 343 o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE) 344 payload in a subsequent message towards the IKEv2 initiator. This 345 is shown in Figure 3. 346 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 347 ticket for some reason. 348 o it returns an N(TICKET_ACK), if it cannot grant a ticket 349 immediately, e.g., due to packet size limitations. In this case 350 the client MAY request a ticket later using an Informational 351 exchange, at any time during the lifetime of the IKE SA. 352 Regardless of this choice, there is no change to the behavior of the 353 responder with respect to the IKE exchange, and the proper IKE 354 response (e.g. an IKE_AUTH response or an error notification) MUST be 355 sent. 357 4.2. Receiving a Ticket 359 The IKEv2 initiator receives the ticket and may accept it, provided 360 the IKEv2 exchange was successful. The ticket may be used later with 361 an IKEv2 responder that supports this extension. Figure 3 shows how 362 the initiator receives the ticket. 364 Initiator Responder 365 ----------- ----------- 366 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 367 TSr, N(TICKET_LT_OPAQUE) } 369 Figure 3: Receiving a Ticket 371 When a multi-round-trip IKE_AUTH exchange is used, the 372 N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH 373 request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST 374 only be returned in the final IKE_AUTH response. 376 When the client accepts the ticket, it stores it in its local storage 377 for later use, along with the IKE SA that the ticket refers to. 378 Since the ticket itself is opaque to the client, the local storage 379 MUST also include all items marked as "from the ticket" in the table 380 of Section 5. 382 4.3. Presenting a Ticket 384 When the client wishes to recover from an interrupted session, it 385 presents the ticket to resume the session. This section describes 386 the resumption process, consisting of some preparations, an 387 IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization. 389 4.3.1. Prologue 391 It is up to the client's local policy to decide when the 392 communication with the IKEv2 responder is seen as interrupted and the 393 session resumption procedure is to be initiated. 395 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange 396 even if it is in possession of a valid, unexpired ticket. A client 397 MUST NOT present a ticket when it knows that the ticket's lifetime 398 has expired. 400 Tickets are intended for one-time use, i.e. a client MUST NOT reuse a 401 ticket. A reused ticket SHOULD be rejected by a gateway. Note that 402 a ticket is considered as used only when an IKE SA has been 403 established successfully with it. 405 4.3.2. IKE_SESSION_RESUME Exchange 407 This document specifies a new IKEv2 exchange type called 408 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 409 equivalent to the IKE_SA_INIT exchange, and MUST be followed by an 410 IKE_AUTH exchange. The client SHOULD NOT use this exchange type 411 unless it knows that the gateway supports it (this condition is 412 trivially true in the context of the current document, since the 413 client always resumes into the same gateway that generated the 414 ticket). 416 Initiator Responder 417 ----------- ----------- 418 HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] --> 420 Figure 4: IKEv2 Initiator wishes to resume an IKE SA 422 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 423 initiator sets the SPIi value in the HDR to a new, unique value and 424 the SPIr value is set to 0. 426 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 427 payload it MUST perform one of the following steps if it supports the 428 extension defined in this document: 430 o If it is willing to accept the ticket, it responds as shown in 431 Figure 5. 432 o It responds with an unprotected N(TICKET_NACK) notification, if it 433 rejects the ticket for any reason. In that case, the initiator 434 should re-initiate a regular IKE exchange. One such case is when 435 the responder receives a ticket for an IKE SA that has previously 436 been terminated on the responder itself, which may indicate 437 inconsistent state between the IKEv2 initiator and the responder. 438 However, a responder is not required to maintain the state for 439 terminated sessions. 441 Initiator Responder 442 ----------- ----------- 443 <-- HDR, Nr [,N+] 445 Figure 5: IKEv2 Responder accepts the ticket 447 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 448 responder copies the SPIi value from the request, and the SPIr value 449 is set to a new, unique value. 451 Where not specified otherwise, the IKE_SESSION_RESUME exchange 452 behaves exactly like the IKE_SA_INIT exchange. Specifically: 454 o The client MAY resume the IKE exchange from any IP address and 455 port, regardless of its original address. The gateway MAY reject 456 the resumed exchange if its policy depends on the client's address 457 (although this rarely makes sense). 459 o The first message MAY be rejected in denial of service situations, 460 with the initiator instructed to send a cookie. 461 o Notifications normally associated with IKE_SA_INIT can be sent. 462 In particular, NAT detection payloads. 463 o The client's NAT traversal status SHOULD be determined anew in 464 IKE_SESSION_RESUME. If NAT is detected, the initiator switches to 465 UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT 466 status is explicitly not part of the session resumption state. 467 o The SPI values and Message ID fields behave similarly to 468 IKE_SA_INIT. 470 Although the IKE SA is not fully valid until the completion of the 471 IKE_AUTH exchange, the peers must create much of the SA state 472 (Section 5) now. Specifically, the shared key values are required to 473 protect the IKE_AUTH payloads. Their generation is described in 474 Section 5.1. 476 4.3.3. IKE_AUTH Exchange 478 Following the IKE_SESSION_RESUME exchange, the client MUST initiate 479 an IKE_AUTH exchange, which is largely as specified in [RFC4306]. 480 This section lists the differences and constraints compared to the 481 base document. 483 The value of the AUTH payload is derived in a manner similar to the 484 usage of IKEv2 pre-shared secret authentication: 486 AUTH = prf(SK_px, ) 488 Each of the initiator and responder uses its own value for SK_px, 489 namely SK_pi for the initiator and SK_pr for the responder. Both are 490 taken from the newly generated IKE SA, Section 5.1. 492 The exact material to be signed is defined in Section 2.15 of 493 [RFC4306]. 495 The IDi value sent in the IKE_AUTH exchange MUST be identical to the 496 value included in the ticket. A CERT payload MUST NOT be included in 497 this exchange, and therefore a new IDr value cannot be negotiated 498 (since it would not be authenticated). As a result, the IDr value 499 sent (by the gateway, and optionally by the client) in this exchange 500 MUST also be identical to the value included in the ticket. 502 When resuming a session, a client will typically request a new ticket 503 immediately, so that it is able to resume the session again in the 504 case of a second failure. The N(TICKET_REQUEST) and 505 N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH 506 exchange that follows the IKE_SESSION_RESUME exchange, with similar 507 behavior to a ticket request during a regular IKE exchange, 508 Section 4.1. The returned ticket (if any) will correspond to the IKE 509 SA created per the rules described in Section 5. 511 4.3.4. Epilogue 513 Following the IKE_AUTH exchange, a new IKE SA is created by both 514 parties, see Section 5, and a Child SA is derived, per Section 2.17 515 of [RFC4306]. 517 When the responder receives a ticket for an IKE SA that is still 518 active and if the responder accepts it (i.e. following successful 519 completion of the IKE_AUTH exchange), the old SA SHOULD be silently 520 deleted without sending a DELETE informational exchange. 521 Consequently, all the dependent IPsec Child SAs are also deleted. 523 5. IKE and IPsec State After Resumption 525 During the resumption process, both peers create IKE and IPsec state 526 for the resumed IKE SA. Although the SA is only completed following 527 a successful IKE_AUTH exchange, many of its components are created 528 earlier, notably the SA's crypto material (Section 5.1). 530 When a ticket is presented, the gateway needs to obtain the ticket 531 state. In case a ticket by reference was provided by the client, the 532 gateway needs to resolve the reference in order to obtain this state. 533 In case the client has already provided a ticket by value, the 534 gateway can parse the ticket to obtain the state directly. In either 535 case, the gateway needs to process the ticket state in order to 536 restore the state of the old IKE SA, and the client retrieves the 537 same state from its local store. 539 The following table describes the IKE and IPsec state of the peers 540 after session resumption, and how it is related to their state before 541 the IKE SA was interrupted. When the table mentions that a certain 542 state item is taken "from the ticket", this should be construed as: 543 o The client retrieves this item from its local store. 544 o In the case of ticket by value, the gateway encodes this 545 information in the ticket. 546 o In the case of ticket by reference, the gateway fetches this 547 information from the ticket store. 549 +-------------------------------------+-----------------------------+ 550 | State Item | After Resumption | 551 +-------------------------------------+-----------------------------+ 552 | IDi | From the ticket (but must | 553 | | also be exchanged in | 554 | | IKE_AUTH). See also Note 1 | 555 | IDr | From the ticket (but must | 556 | | also be exchanged in | 557 | | IKE_AUTH) | 558 | Authentication method (PKI, | From the ticket | 559 | pre-shared secret, EAP, PKI-less | | 560 | EAP | | 561 | [I-D.eronen-ipsec-ikev2-eap-auth] | | 562 | etc.) | | 563 | Certificates (when applicable) | From the ticket, see Note 2 | 564 | Local IP address/port, peer IP | Selected by the client, see | 565 | address/port | Note 3 | 566 | NAT detection status | From new exchange | 567 | SPIs | From new exchange, see Note | 568 | | 4 | 569 | Which peer is the "original | Determined by the initiator | 570 | initiator"? | of IKE_SESSION_RESUME | 571 | IKE SA sequence numbers (Message | Reset to 0 in | 572 | ID) | IKE_SESSION_RESUME, and | 573 | | subsequently incremented | 574 | | normally | 575 | IKE SA algorithms (SAr) | From the ticket | 576 | IKE SA keys (SK_*) | The old SK_d is obtained | 577 | | from the ticket and all | 578 | | keys are refreshed, see | 579 | | Section 5.1 | 580 | IKE SA window size | Reset to 1 | 581 | Child SAs (ESP/AH) | Created in new exchange, | 582 | | see Note 6 | 583 | Internal IP address | Not resumed, but see Note 5 | 584 | Other Configuration Payload | Not resumed | 585 | information | | 586 | Peer Vendor IDs | Not resumed, resent in new | 587 | | exchange if required | 588 | Peer supports MOBIKE [RFC4555] | From new exchange | 589 | MOBIKE additional addresses | Not resumed, should be | 590 | | resent by client if | 591 | | necessary | 592 | Time until re-authentication | From new exchange (but | 593 | [RFC4478] | ticket lifetime is bounded | 594 | | by this duration) | 595 | Peer supports redirects | From new exchange | 596 | [I-D.ietf-ipsecme-ikev2-redirect] | | 597 +-------------------------------------+-----------------------------+ 599 Note 1: The authenticated peer identity used for policy lookups may 600 not be the same as the IDi payload. This is possible when 601 using certain EAP methods, see Sec. 3.5 of [RFC4718]. If 602 these identities are indeed different, then the 603 authenticated client identity MUST be included in the 604 ticket. Note that the client may not have access to this 605 value. 606 Note 2: Certificates don't need to be stored if the peer never uses 607 them for anything after the IKE SA is up; however if they 608 are needed, e.g. if exposed to applications via IPsec APIs, 609 they MUST be stored in the ticket. 610 Note 3: If the certificate has an iPAddress SubjectAltName, and the 611 implementation requires it to match the peer's source IP 612 address, the same check needs to be performed on session 613 resumption and the required information saved locally or in 614 the ticket. 615 Note 4: SPI values of the old SA MAY be stored in the ticket, to 616 help the gateway locate corresponding old IKE state. These 617 values MUST NOT be used for the resumed SA. 618 Note 5: The client can request the address it was using earlier, and 619 if possible, the gateway SHOULD honor the request. 620 Note 6: Since information about Child SAs and configuration payloads 621 is not resumed, IKEv2 features related to Child SA 622 negotiation (such as IPCOMP_SUPPORTED, 623 ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec 624 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration) 625 aren't usually affected by session resumption. 627 IKEv2 features that affect only the IKE_AUTH exchange (including 628 HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges 629 [RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't 630 usually need any state in the IKE SA (after the IKE_AUTH exchanges 631 are done), so resumption doesn't affect them. 633 New IKEv2 features that are not covered by note 6 or by the previous 634 paragraph should specify how they interact with session resumption. 636 5.1. Generating Cryptographic Material for the Resumed IKE SA 638 The cryptographic material is refreshed based on the ticket and the 639 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 640 value is derived as follows: 642 SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr) 644 where SK_d_old is taken from the ticket. The literal string is 645 encoded as 10 ASCII characters, with no NULL terminator. 647 The keys are derived as follows, unchanged from IKEv2: 649 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 650 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 652 where SPIi, SPIr are the SPI values created in the new IKE exchange. 654 See [RFC4306] for the notation. "prf" is determined from the SA value 655 in the ticket. 657 6. Ticket Handling 659 6.1. Ticket Content 661 When passing a ticket by value to the client, the ticket content MUST 662 be integrity protected and encrypted. 664 A ticket by reference does not need to be encrypted, as it does not 665 contain any sensitive material, such as keying material. However, 666 access to the storage where that sensitive material is stored MUST be 667 protected so that only authorized access is allowed. We note that 668 such a ticket is analogous to the concept of 'stub', as defined in 669 [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. 671 Although not strictly required for cryptographic protection, it is 672 RECOMMENDED to integrity-protect the ticket by reference. Failing to 673 do so could result in various security vulnerabilities on the gateway 674 side, depending on the format of the reference. Potential 675 vulnerabilities include access by the gateway to unintended URLs 676 (similar to cross-site scripting) or SQL injection. 678 When the state is passed by value, the ticket MUST encode all state 679 information marked "from the ticket" in the table on Section 5. The 680 same state MUST be stored in the ticket store, in the case of ticket 681 by reference. 683 A ticket by value MUST include a protected expiration time, which is 684 an absolute time value and SHOULD correspond to the value included in 685 the TICKET_LT_OPAQUE payload. 687 The ticket by value MUST additionally include a key identity field, 688 so that keys for ticket encryption and authentication can be changed, 689 and when necessary, algorithms can be replaced. 691 6.2. Ticket Identity and Lifecycle 693 Each ticket is associated with a single IKE SA. In particular, when 694 an IKE SA is deleted by the client or the gateway, the client MUST 695 delete its stored ticket. Similarly, when credentials associated 696 with the IKE SA are invalidated (e.g. when a user logs out), the 697 ticket MUST be deleted. When the IKE SA is rekeyed the ticket is 698 invalidated, and the client SHOULD request a new ticket. When a 699 client does not follow these rules, it might present an invalid 700 ticket to the gateway. See Section 9.8 for more about this issue. 702 The lifetime of the ticket sent by the gateway SHOULD be the minimum 703 of the IKE SA lifetime (per the gateway's local policy) and its re- 704 authentication time, according to [RFC4478]. Even if neither of 705 these are enforced by the gateway, a finite lifetime MUST be 706 specified for the ticket. 708 The key that is used to protect the ticket MUST have a lifetime that 709 is significantly longer than the lifetime of an IKE SA. 711 In normal operation, the client will request a ticket when 712 establishing the initial IKE SA, and then every time the SA is 713 rekeyed or re-established because of re-authentication. 715 7. IKE Notifications 717 This document defines a number of notifications. The Notify Message 718 types are TBA by IANA. 720 +-------------------+-------+-----------------+ 721 | Notification Name | Value | Data | 722 +-------------------+-------+-----------------+ 723 | TICKET_LT_OPAQUE | TBA1 | See Section 7.1 | 724 | TICKET_REQUEST | TBA2 | None | 725 | TICKET_ACK | TBA3 | None | 726 | TICKET_NACK | TBA4 | None | 727 | TICKET_OPAQUE | TBA5 | See Section 7.2 | 728 +-------------------+-------+-----------------+ 730 For all these notifications, the Protocol ID and the SPI Size fields 731 MUST both be sent as 0. 733 7.1. TICKET_LT_OPAQUE Notify Payload 735 The data for the TICKET_LT_OPAQUE Notify payload consists of the 736 Notify message header, a Lifetime field and the ticket itself. The 737 four octet Lifetime field contains a relative time value, the number 738 of seconds until the ticket expires (encoded as an unsigned integer, 739 in network byte order). 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Next Payload |C| Reserved | Payload Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Protocol ID | SPI Size = 0 | Notify Message Type | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Lifetime | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 ~ Ticket ~ 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 6: TICKET_LT_OPAQUE Notify Payload 757 7.2. TICKET_OPAQUE Notify Payload 759 The data for the TICKET_OPAQUE Notify payload consists of the Notify 760 message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE 761 payload, no lifetime value is included in the TICKET_OPAQUE Notify 762 payload. 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Next Payload |C| Reserved | Payload Length | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Protocol ID | SPI Size = 0 | Notify Message Type | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | | 772 ~ Ticket ~ 773 | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Figure 7: TICKET_OPAQUE Notify Payload 777 8. IANA Considerations 779 Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME, 780 whose value is to be allocated (has been allocated) from the "IKEv2 781 Exchange Types" registry. 783 Section 7 defines several new IKEv2 notifications whose Message Type 784 values are to be allocated (have been allocated) from the "IKEv2 785 Notify Message Types - Status Types" registry. 787 9. Security Considerations 789 This section addresses security issues related to the usage of a 790 ticket. 792 9.1. Stolen Tickets 794 A man-in-the-middle may try to eavesdrop on an exchange to obtain a 795 ticket by value and use it to establish a session with the IKEv2 796 responder. Since all exchanges where the client obtains a ticket are 797 encrypted, this is only possible by listening in on a client's use of 798 the ticket to resume a session. However, since the ticket's contents 799 are encrypted and the attacker does not know the corresponding secret 800 key, a stolen ticket cannot be used by an attacker to successfully 801 resume a session. An IKEv2 responder MUST use strong encryption and 802 integrity protection of the ticket to prevent an attacker from 803 obtaining the ticket's contents, e.g., by using a brute force attack. 805 A ticket by reference does not need to be encrypted. When an 806 adversary is able to eavesdrop on a resumption attempt, as described 807 in the previous paragraph, then the ticket by reference may be 808 obtained. A ticket by reference cannot be used by an attacker to 809 successfully resume a session, for the same reasons as for a ticket 810 by value, namely because the attacker would not be able to prove, 811 during IKE_AUTH, its knowledge of the secret part of the IKE state 812 embedded in the ticket. Moreover, the adversary MUST NOT be able to 813 resolve the ticket via the reference, i.e., access control MUST be 814 enforced to ensure disclosure only to authorized entities. 816 9.2. Forged Tickets 818 A malicious user could forge or alter a ticket by value in order to 819 resume a session, to extend its lifetime, to impersonate as another 820 user, or to gain additional privileges. This attack is not possible 821 if the content of the ticket by value is protected using a strong 822 integrity protection algorithm. 824 In case of a ticket by reference an adversary may attempt to 825 construct a fake ticket by reference to point to state information 826 stored by the IKEv2 responder. This attack will fail because the 827 adversary is not in possession of the keying material associated with 828 the IKEv2 SA. As noted in Section 6.1, it is often useful to 829 integrity-protect the ticket by reference, too. 831 9.3. Denial of Service Attacks 833 An adversary could generate and send a large number of tickets by 834 value to a gateway for verification. Such an attack could burden the 835 gateway's CPU, and/or exhaust its memory with half-open IKE state. 836 To minimize the possibility of such denial of service, ticket 837 verification should be lightweight (e.g., using efficient symmetric 838 key cryptographic algorithms). 840 When an adversary chooses to send a large number of tickets by 841 reference then this may lead to an amplification attack as the IKEv2 842 responder is forced to resolve the reference to a ticket in order to 843 determine that the adversary is not in possession of the keying 844 material corresponding to the stored state or that the reference is 845 void. To minimize this attack, the protocol to resolve the reference 846 should be as lightweight as possible and should not generate a large 847 number of messages. 849 Note also that the regular IKEv2 cookie mechanism can be used to 850 handle state-overflow DoS situations. 852 9.4. Detecting the Need for Resumption 854 Detecting when an old IKE SA is no longer usable and needs to be 855 resumed is out of scope of the current document. However, clients 856 are warned against implementing a more liberal policy than that used 857 to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular, 858 untrusted messages MUST NOT be relied upon to make this decision. 860 9.5. Key Management for Tickets By Value 862 A full description of the management of the keys used to protect the 863 ticket by value is beyond the scope of this document. A list of 864 RECOMMENDED practices is given below. 865 o The keys should be generated securely following the randomness 866 recommendations in [RFC4086]. 868 o The keys and cryptographic protection algorithms should be at 869 least 128 bits in strength. 870 o The keys should not be used for any other purpose than generating 871 and verifying tickets. 872 o The keys should be changed regularly. 873 o The keys should be changed if the ticket format or cryptographic 874 protection algorithms change. 876 9.6. Ticket Lifetime 878 An IKEv2 responder controls the validity period of the state 879 information by attaching a lifetime to a ticket. The chosen lifetime 880 is based on the operational and security requirements of the 881 environment in which this IKEv2 extension is deployed. The responder 882 provides information about the ticket lifetime to the IKEv2 883 initiator, allowing it to manage its tickets. 885 9.7. Tickets and Identity 887 A ticket is associated with a certain identity, and MUST be managed 888 securely on the client side. Section 6.2 requires that a ticket be 889 deleted when the credentials associated with the ticket's identity 890 are no longer valid, e.g. when a user whose credentials were used to 891 create the SA logs out. 893 9.8. Ticket Revocation 895 A misbehaving client could present a ticket in its possession to the 896 gateway resulting in session resumption, even though the IKE SA 897 associated with this ticket had previously been deleted. This is 898 disallowed by Section 6.2. This issue is unique to ticket by value 899 cases, since a ticket by reference will have been deleted from the 900 ticket store. 902 To avoid this issue for ticket by value, an Invalid Ticket List (ITL) 903 may be maintained by the gateway, see 904 [I-D.rescorla-stateless-tokens]. This can be a simple blacklist of 905 revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens] 906 suggests to use Bloom Filters [Bloom70] to maintain the list in 907 constant space. Management of such lists is outside the scope of the 908 current document. Note that a policy that requires tickets to have 909 shorter lifetimes (e.g., 1 hour) significantly mitigates this issue. 911 9.9. Ticket by Value Format 913 The ticket's format is not defined by this document, since this is 914 not required for interoperability. However great care must be taken 915 when defining a ticket format such that the requirements outlined in 916 Section 6.1 are met. The ticket by value MUST have its integrity and 917 confidentiality protected with strong cryptographic techniques to 918 prevent a breach in the security of the system. 920 9.10. Identity Privacy, Anonymity, and Unlinkability 922 Since opaque state information is passed around between the IKEv2 923 initiator and the IKEv2 responder it is important that leakage of 924 information, such as the identities of an IKEv2 initiator and a 925 responder, MUST be avoided. 927 When an IKEv2 initiator presents a ticket as part of the 928 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 929 exchange. There is thereby the possibility for an on-path adversary 930 to observe multiple exchange handshakes where the same state 931 information is used and therefore to conclude that they belong to the 932 same communication end points. 934 This document therefore requires that the ticket be presented to the 935 IKEv2 responder only once; under normal circumstances (e.g. no active 936 attacker), there should be no multiple use of the same ticket. 938 We are not aware of additional security issues associated with ticket 939 reuse: the protocol guarantees freshness of the generated crypto 940 material even in such cases. As noted in Section 4.3.1, the gateway 941 SHOULD prevent multiple uses of the same ticket. But this is only an 942 extra precaution, to ensure that clients do not implement reuse. In 943 other words, the gateway is not expected to cache old tickets for 944 extended periods of time. 946 10. Acknowledgements 948 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 949 Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ 950 Housely, Yoav Nir, Peny Yang, Sean Turner and Tero Kivinen for their 951 comments. We would like to particularly thank Florian Tegeler and 952 Stjepan Gros for their implementation efforts and Florian Tegeler for 953 a formal verification using the Casper tool set. 955 We would furthermore like to thank the authors of 956 [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke 957 Xu) for their input on the stub concept. 959 We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad 960 Muhanna and Stephen Kent for their feedback regarding the ticket by 961 reference concept. 963 Vidya Narayanan and Lakshminath Dondeti coauthored several past 964 versions of this document, and we acknowledge their significant 965 contribution. 967 11. References 969 11.1. Normative References 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 975 RFC 4306, December 2005. 977 11.2. Informative References 979 [Bloom70] Bloom, B., "Space/time trade-offs in hash coding with 980 allowable errors", Comm. ACM 13(7):422-6, July 1970. 982 [I-D.eronen-ipsec-ikev2-eap-auth] 983 Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 984 for EAP-Only Authentication in IKEv2", 985 draft-eronen-ipsec-ikev2-eap-auth-07 (work in progress), 986 October 2009. 988 [I-D.ietf-ipsecme-ikev2-redirect] 989 Devarapalli, V. and K. Weniger, "Redirect Mechanism for 990 IKEv2", draft-ietf-ipsecme-ikev2-redirect-13 (work in 991 progress), August 2009. 993 [I-D.ietf-ipsecme-ikev2bis] 994 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 995 "Internet Key Exchange Protocol: IKEv2", 996 draft-ietf-ipsecme-ikev2bis-05 (work in progress), 997 October 2009. 999 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] 1000 Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 1001 Bormann, "IKEv2 Extensions to Support Robust Header 1002 Compression over IPsec (ROHCoIPsec)", 1003 draft-ietf-rohc-ikev2-extensions-hcoipsec-09 (work in 1004 progress), August 2009. 1006 [I-D.rescorla-stateless-tokens] 1007 Rescorla, E., "How to Implement Secure (Mostly) Stateless 1008 Tokens", draft-rescorla-stateless-tokens-01 (work in 1009 progress), March 2007. 1011 [I-D.xu-ike-sa-sync] 1012 Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA 1013 Synchronization for session resumption", 1014 draft-xu-ike-sa-sync-01 (work in progress), October 2008. 1016 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1017 Requirements for Security", BCP 106, RFC 4086, June 2005. 1019 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1020 Internet Protocol", RFC 4301, December 2005. 1022 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 1023 (IKEv2) Protocol", RFC 4478, April 2006. 1025 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1026 (MOBIKE)", RFC 4555, June 2006. 1028 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 1029 Implementation Guidelines", RFC 4718, October 2006. 1031 [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication 1032 Exchanges in the Internet Key Exchange (IKEv2) Protocol", 1033 RFC 4739, November 2006. 1035 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 1036 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 1037 RFC 4754, January 2007. 1039 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 1040 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 1041 February 2007. 1043 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1044 "Transport Layer Security (TLS) Session Resumption without 1045 Server-Side State", RFC 5077, January 2008. 1047 Appendix A. Ticket Format 1049 This document does not specify a particular ticket format nor even 1050 the suggested contents of a ticket: both are entirely up to the 1051 implementer. The formats described in the following sub-sections are 1052 provided as useful examples, and implementers are free to adopt them 1053 as-is or change them in any way necessary. 1055 A.1. Example Ticket by Value Format 1057 struct { 1058 [authenticated] struct { 1059 octet format_version; // 1 for this version of the protocol 1060 octet reserved[3]; // sent as 0, ignored by receiver. 1061 octet key_id[8]; // arbitrary byte string 1062 opaque IV[0..255]; // actual length (possibly 0) depends 1063 // on the encryption algorithm 1065 [encrypted] struct { 1066 opaque IDi, IDr; // the full payloads 1067 octet SPIi[8], SPIr[8]; 1068 opaque SA; // the full SAr payload 1069 octet SK_d[0..255]; // actual length depends on SA value 1070 enum ... authentication_method; 1071 int32 expiration; // an absolute time value, seconds 1072 // since Jan. 1, 1970 1073 } ikev2_state; 1074 } protected_part; 1075 opaque MAC[0..255]; // the length (possibly 0) depends 1076 // on the integrity algorithm 1077 } ticket; 1079 Note that the key defined by "key_id" determines the encryption and 1080 authentication algorithms used for this ticket. Those algorithms are 1081 unrelated to the transforms defined by the SA payload. 1083 The reader is referred to [I-D.rescorla-stateless-tokens] that 1084 recommends a similar (but not identical) ticket format, and discusses 1085 related security considerations in depth. 1087 A.2. Example Ticket by Reference Format 1089 For implementations that prefer to pass a reference to IKE state in 1090 the ticket, rather than the state itself, we suggest the following 1091 format: 1093 struct { 1094 [authenticated] struct { 1095 octet format_version; // 1 for this version of the protocol 1096 octet reserved[3]; // sent as 0, ignored by receiver. 1097 octet key_id[8]; // arbitrary byte string 1099 struct { 1100 opaque state_ref; // reference to IKE state 1101 int32 expiration; // an absolute time value, seconds 1102 // since Jan. 1, 1970 1103 } ikev2_state_ref; 1104 } protected_part; 1105 opaque MAC[0..255]; // the length depends 1106 // on the integrity algorithm 1107 } ticket; 1109 Appendix B. Change Log 1111 Note to RFC Editor: remove this appendix before publication. 1113 B.1. -09 1115 Implemented IESG and opsdir review comments. 1117 B.2. -08 1119 Implemented IETF LC, secdir and gen-art comments. 1121 B.3. -07 1123 Implemented AD Review comments, most of them editorial. 1125 B.4. -06 1127 Clients resuming propely closed sessions and how this can be avoided. 1129 B.5. -05 1131 Editorial changes: reordered and merged some sections. 1133 Restated the use cases. 1135 IDr is not negotiated during resumption, the gateway must use the 1136 stored IDr. 1138 Multiple small clarifications based on Pasi's LC review. 1140 IPR: pre5378Trust200902. 1142 B.6. -04 1144 Closed issue #105, Non-PKI use of EAP, and resumption. 1146 Closed issue #106, Resumption and NAT detection and changing ports. 1148 B.7. -03 1150 Changed the protocol from one to two round trips, to simplify the 1151 security assumptions. Eliminated security considerations associated 1152 with the previous version. 1154 Closed issue #69, Clarify behavior of SPI and sequence numbers. 1156 Closed issue #70, Ticket lifetime - explicit or not? (and ticket push 1157 from gateway). 1159 Closed issue #99, Ticket example: downgrade. 1161 Closed issue #76, IPsec Child SAs during resumption. 1163 Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption. 1165 Closed issue #95, Minor nits for ikev2-resumption-02. 1167 Closed issue #97, Clarify what state comes from where. 1169 Closed issue #98, Replays in 1-RTT protocol. 1171 Closed issue #100, NAT detection [and] IP address change. 1173 Closed issue #101, Assorted issues by Tero. 1175 B.8. -02 1177 Added a new TICKET_OPAQUE payload that does not have a lifetime field 1178 included. 1180 Removed the lifetime usage from the IKE_SESSION_RESUME exchange 1181 (utilizing the TICKET_OPAQUE) when presenting the ticket to the 1182 gateway. 1184 Removed IDi payloads from the IKE_SESSION_RESUME exchange. 1186 Clarified that IPsec Child SAs would be deleted once the old IKE SA 1187 gets deleted as well. 1189 Clarified the behavior of SPI and sequence number usage. 1191 B.9. -01 1193 Addressed issue#75, see 1194 http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included 1195 changes throughout the document to ensure that the ticket may contain 1196 a reference or a value. 1198 B.10. -00 1200 Resubmitted document as a WG item. 1202 B.11. -01 1204 Added reference to [I-D.xu-ike-sa-sync] 1206 Included recommended ticket format into the appendix 1208 Various editorial improvements within the document 1210 B.12. -00 1212 Issued a -00 version for the IPSECME working group. Reflected 1213 discussions at IETF#72 regarding the strict focus on session 1214 resumption. Consequently, text about failover was removed. 1216 B.13. -04 1218 Editorial fixes; references cleaned up; updated author's contact 1219 address 1221 B.14. -03 1223 Removed counter mechanism. Added an optional anti-DoS mechanism, 1224 based on IKEv2 cookies (removed previous discussion of cookies). 1225 Clarified that gateways may support reallocation of same IP address, 1226 if provided by network. Proposed a solution outline to the problem 1227 of key exchange for the keys that protect tickets. Added fields to 1228 the ticket to enable interoperability. Removed incorrect MOBIKE 1229 notification. 1231 B.15. -02 1233 Clarifications on generation of SPI values, on the ticket's lifetime 1234 and on the integrity protection of the anti-replay counter. 1235 Eliminated redundant SPIs from the notification payloads. 1237 B.16. -01 1239 Editorial review. Removed 24-hour limitation on ticket lifetime, 1240 lifetime is up to local policy. 1242 B.17. -00 1244 Initial version. This draft is a selective merge of 1245 draft-sheffer-ike-session-resumption-00 and 1246 draft-dondeti-ipsec-failover-sol-00. 1248 Authors' Addresses 1250 Yaron Sheffer 1251 Check Point Software Technologies Ltd. 1252 5 Hasolelim St. 1253 Tel Aviv 67897 1254 Israel 1256 Email: yaronf@checkpoint.com 1258 Hannes Tschofenig 1259 Nokia Siemens Networks 1260 Linnoitustie 6 1261 Espoo 02600 1262 Finland 1264 Phone: +358 (50) 4871445 1265 Email: Hannes.Tschofenig@gmx.net 1266 URI: http://www.tschofenig.priv.at