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