idnits 2.17.1 draft-ietf-ipsecme-ikev2-resumption-01.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 date (January 24, 2009) is 5569 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) == Missing Reference: 'CERTREQ' is mentioned on line 276, but not defined == Missing Reference: 'TSi' is mentioned on line 367, but not defined == Missing Reference: 'TSr' is mentioned on line 367, but not defined -- Looks like a reference, but probably isn't: '3' on line 800 -- Looks like a reference, but probably isn't: '8' on line 801 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- 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 (==), 6 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: July 28, 2009 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 January 24, 2009 11 IKEv2 Session Resumption 12 draft-ietf-ipsecme-ikev2-resumption-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 28, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 52 computational and communication overhead with respect to the number 53 of round-trips required and the cryptographic operations involved. 54 In remote access situations, the Extensible Authentication Protocol 55 (EAP) is used for authentication, which adds several more round trips 56 and consequently latency. 58 To re-establish security associations (SAs) upon a failure recovery 59 condition is time consuming especially when an IPsec peer (such as a 60 VPN gateway) needs to re-establish a large number of SAs with various 61 end points. A high number of concurrent sessions might cause 62 additional problems for an IPsec peer during SA re-establishment. 64 In order to avoid the need to re-run the key exchange protocol from 65 scratch it would be useful to provide an efficient way to resume an 66 IKE/IPsec session. This document proposes an extension to IKEv2 that 67 allows a client to re-establish an IKE SA with a gateway in a highly 68 efficient manner, utilizing a previously established IKE SA. 70 A client can reconnect to a gateway from which it was disconnected. 71 The proposed approach requires passing opaque data from the IKEv2 72 responder to the IKEv2 initiator, which is later made available to 73 the IKEv2 responder for re-authentication. We use the term ticket to 74 refer to the opaque data that is created by the IKEv2 responder. 75 This document does not specify the format of the ticket but 76 recommendations are provided. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 85 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8 86 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 10 87 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10 88 4.2.3. Requesting a ticket during resumption . . . . . . . . 11 89 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 90 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11 91 4.5. Processing Guidelines for IKE SA Establishment . . . . . . 12 92 5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 13 93 5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 13 94 5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 13 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 14 98 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14 99 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 100 7.4. Key Management for Tickets By Value . . . . . . . . . . . 15 101 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 15 102 7.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 15 103 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 16 104 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 16 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 108 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 109 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 18 110 A.1. Recommended Ticket by Value Format . . . . . . . . . . . . 18 111 A.2. Recommended Ticket by Reference Format . . . . . . . . . . 19 112 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 113 B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 114 B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 117 B.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 118 B.6. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 119 B.7. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 120 B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 121 B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 124 1. Introduction 126 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 127 computational and communication overhead with respect to the number 128 of round-trips required and the cryptographic operations involved. 129 In particular the Extensible Authentication Protocol (EAP) is used 130 for authentication in remote access cases, which increases latency. 132 To re-establish security associations (SA) upon a failure recovery 133 condition is time-consuming, especially when an IPsec peer, such as a 134 VPN gateway, needs to re-establish a large number of SAs with various 135 end points. A high number of concurrent sessions might cause 136 additional problems for an IPsec responder. 138 In many failure cases it would be useful to provide an efficient way 139 to resume an interrupted IKE/IPsec session. This document proposes 140 an extension to IKEv2 that allows a client to re-establish an IKE SA 141 with a gateway in a highly efficient manner, utilizing a previously 142 established IKE SA. 144 A client can reconnect to a gateway from which it was disconnected. 145 One way to ensure that the IKEv2 responder is able to recreate the 146 state information is by maintaining IKEv2 state (or a reference into 147 a state store) in a "ticket", an opaque data structure. This ticket 148 is created by the server and forwarded to the client. The IKEv2 149 protocol is extended to allow a client to request and present a 150 ticket. This document does not mandate the format of the ticket 151 structure but a recommendation is provided. In Appendix A a ticket 152 by value and a ticket by reference format is proposed. 154 This approach is similar to the one taken by TLS session resumption 155 [RFC5077] with the required adaptations for IKEv2, e.g., to 156 accommodate the two-phase protocol structure. We have borrowed 157 heavily from that specification. 159 The proposed solution should additionally meet the following goals: 161 o Using only symmetric cryptography to minimize CPU consumption. 162 o Allowing a gateway to push state to clients. 163 o Providing cryptographic agility. 164 o Having no negative impact on IKEv2 security features. 166 The following are non-goals of this solution: 167 o Providing load balancing among gateways. 168 o Specifying how a client detects the need for a failover. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 This document uses terminology defined in [RFC4301], [RFC4306], and 177 [RFC4555]. In addition, this document uses the following terms: 179 Ticket: An IKEv2 ticket is a data structure that contains all the 180 necessary information that allows an IKEv2 responder to re- 181 establish an IKEv2 security association. 183 In this document we use the term ticket and thereby refer to an 184 opaque data structure that may either contain IKEv2 state as 185 described above or a reference pointing to such state. 187 3. Usage Scenario 189 This specification envisions two usage scenarios for efficient IKEv2 190 and IPsec SA session re-establishment. 192 The first is similar to the use case specified in Section 1.1.3 of 193 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 194 used to establish a secure channel between a remote access client and 195 a gateway; the traffic flow may be between the client and entities 196 beyond the gateway. 198 The second use case focuses on the usage of transport (or tunnel) 199 mode to secure the communicate between two end points (e.g., two 200 servers). The two endpoints have a client-server relationship with 201 respect to a protocol that runs using the protections afforded by the 202 IPsec SA. 204 (a) 206 +-+-+-+-+-+ +-+-+-+-+-+ 207 ! ! IKEv2/IKEv2-EAP ! ! Protected 208 ! Remote !<------------------------>! ! Subnet 209 ! Access ! ! Access !<--- and/or 210 ! Client !<------------------------>! Gateway ! Internet 211 ! ! IPsec tunnel ! ! 212 +-+-+-+-+-+ +-+-+-+-+-+ 214 (b) 216 +-+-+-+-+-+ +-+-+-+-+-+ 217 ! ! IKE_SESSION_RESUME ! ! 218 ! Remote !<------------------------>! ! 219 ! Access ! ! Access ! 220 ! Client !<------------------------>! Gateway ! 221 ! ! IPsec tunnel ! ! 222 +-+-+-+-+-+ +-+-+-+-+-+ 224 Figure 1: Resuming a Session with a Remote Access Gateway 226 In this scenario, an end host (an entity with a host implementation 227 of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a 228 gateway in a remote network using IKEv2. The end host in this 229 scenario is sometimes referred to as a remote access client. At a 230 later stage when a client needs to re-establish the IKEv2 session it 231 may choose to establish IPsec SAs using a full IKEv2 exchange or the 232 IKE_SESSION_RESUME exchange (shown in Figure 1). 234 In this scenario, the client needs to get an IP address from the 235 remote network so that traffic can be encapsulated by the remote 236 access gateway before reaching the client. In the initial exchange, 237 the gateway may acquire IP addresses from the address pool of a local 238 DHCP server. The session resumption exchange may need to support the 239 assignment of a new IP address. 241 The protocol defined in this document supports the re-allocation of 242 an IP address to the client, if this capability is provided by the 243 network. This capability is implicit in the use of the IKE 244 configuration mechanism, which allows the client to present its 245 existing IP address and receive the same address back, if allowed by 246 the gateway. 248 4. Protocol Details 250 This section provides protocol details and contains the normative 251 parts. This document defines two protocol exchanges, namely 252 requesting a ticket, see Section 4.1, and presenting a ticket, see 253 Section 4.2. 255 4.1. Requesting a Ticket 257 A client MAY request a ticket in the following exchanges: 259 o In an IKE_AUTH exchange, as shown in the example message exchange 260 in Figure 2 below. 261 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 262 o In an Informational exchange, if the gateway previously replied 263 with an N(TICKET_ACK) instead of providing a ticket. 264 o In an Informational exchange, when the ticket lifetime is about to 265 expire. 266 o In an IKE_SESSION_RESUME exchange, see Section 4.2.3. 268 Normally, a client requests a ticket in the third message of an IKEv2 269 exchange (the first of IKE_AUTH). Figure 2 shows the message 270 exchange for this typical case. 272 Initiator Responder 273 ----------- ----------- 274 HDR, SAi1, KEi, Ni --> 276 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 278 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 279 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 281 Figure 2: Example Message Exchange for Requesting a Ticket 283 The notification payloads are described in Section 4.3. The above is 284 an example, and IKEv2 allows a number of variants on these messages. 285 A complete description of IKEv2 can be found in [RFC4718]. 287 When an IKEv2 responder receives a request for a ticket using the 288 N(TICKET_REQUEST) payload it MUST perform one of the following 289 operations if it supports the extension defined in this document: 290 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 291 payload in a subsequent message towards the IKEv2 initiator. This 292 is shown in Figure 3. 294 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 295 ticket for some reason. 296 o it returns an N(TICKET_ACK), if it cannot grant a ticket 297 immediately, e.g., due to packet size limitations. In this case 298 the client MAY request a ticket later using an Informational 299 exchange, at any time during the lifetime of the IKE SA. 301 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 302 accept the requested ticket. The ticket may be used later with an 303 IKEv2 responder that supports this extension. Figure 3 shows how the 304 initiator receives the ticket. 306 Initiator Responder 307 ----------- ----------- 308 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 309 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 311 Figure 3: Receiving a Ticket 313 4.2. Presenting a Ticket 315 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange 316 even if it is in possession of a valid ticket. Note that the client 317 can only judge validity in the sense of the ticket lifetime. A 318 client MUST NOT present a ticket when it knows that the ticket's 319 lifetime has expired. 321 It is up to the client's local policy to decide when the 322 communication with the IKEv2 responder is seen as interrupted and a 323 new exchange needs to be initiated and the session resumption 324 procedure to be initiated. 326 Tickets are intended for one-time use: a client MUST NOT reuse a 327 ticket, either with the same or with a different gateway. A gateway 328 SHOULD reject a reused ticket. 330 This document specifies a new IKEv2 exchange type called 331 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 332 somewhat similar to the IKE_AUTH exchange, and results in the 333 creation of a Child SA. The client SHOULD NOT use this exchange type 334 unless it knows that the gateway supports it. 336 Initiator Responder 337 ----------- ----------- 338 HDR, Ni, N(TICKET_OPAQUE), [N+,] 339 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 341 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The value 342 of the Lifetime field in the TICKET_OPAQUE payload is set to the 343 value that was received when requesting the ticket. 345 See Section 4.2.1 for details on computing the protected (SK) 346 payload. 348 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 349 payload it MUST perform one of the following steps if it supports the 350 extension defined in this document: 351 o If it is willing to accept the ticket, it responds as shown in 352 Figure 4. 353 o It responds with an unprotected N(TICKET_NACK) notification, if it 354 rejects the ticket for any reason. In that case, the initiator 355 should re-initiate a regular IKE exchange. One such case is when 356 the responder receives a ticket for an IKE SA that has previously 357 been terminated on the responder itself, which may indicate 358 inconsistent state between the IKEv2 initiator and the responder. 359 However, a responder is not required to maintain the state for 360 terminated sessions. 361 o When the responder receives a ticket for an IKE SA that is still 362 active and if the responder accepts it, then the old SAs SHOULD be 363 silently deleted without sending a DELETE informational exchange. 365 Initiator Responder 366 ----------- ----------- 367 <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 368 [CP(CFG_REPLY)]} 370 Figure 4: IKEv2 Responder accepts the ticket 372 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 374 The SK payload is protected using the cryptographic parameters 375 derived from the ticket, see Section 4.2.1 below. 377 At this point a new IKE SA is created by both parties, see 378 Section 4.5. This is followed by normal derivation of a child SA, 379 per Section 2.17 of [RFC4306]. 381 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 383 The two messages of this exchange are protected by a "subset" IKE SA. 384 The key material is derived from the ticket, as follows: 386 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 388 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 389 from the ticket. Ni guarantees freshness of the key material. SK_d2 390 is used later to derive the new IKE SA, see Section 4.5. 392 See [RFC4306] for the notation. "prf" is determined from the SA value 393 in the ticket. 395 4.2.2. Presenting a Ticket: The DoS Case 397 When receiving the first message of the IKE_SESSION_RESUME exchange, 398 the gateway may decide that it is under a denial-of-service attack. 399 In such a case, the gateway SHOULD defer the establishment of session 400 state until it has verified the identity of the client. We use a 401 variation of the IKEv2 Cookie mechanism, whereby the cookie is 402 protected. 404 In the two messages that follow, the gateway responds that it is 405 unwilling to resume the session until the client is verified, and the 406 client resubmits its first message, this time with the cookie: 408 Initiator Responder 409 ----------- ----------- 410 <-- HDR, SK{N(COOKIE)} 412 HDR, Ni, N(TICKET_OPAQUE), [N+,] 413 SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 415 Assuming the cookie is correct, the gateway now replies normally. 417 This now becomes a 4-message exchange. The entire exchange is 418 protected as defined in Section 4.2.1. 420 See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance 421 regarding the usage and syntax of the cookie. Note that the cookie 422 is completely independent of the IKEv2 ticket. 424 4.2.3. Requesting a ticket during resumption 426 When resuming a session, a client will typically request a new ticket 427 immediately, so it is able to resume the session again in the case of 428 a second failure. Therefore, the N(TICKET_REQUEST) and 429 N(TICKET_OPAQUE) notifications may be piggybacked as protected 430 payloads to the IKE_SESSION_RESUME exchange. 432 The returned ticket (if any) will correspond to the IKE SA created 433 per the rules described in Section 4.5. 435 4.3. IKE Notifications 437 This document defines a number of notifications. The notification 438 numbers are TBA by IANA. 440 +-------------------+--------+-----------------+ 441 | Notification Name | Number | Data | 442 +-------------------+--------+-----------------+ 443 | TICKET_OPAQUE | TBA1 | See Section 4.4 | 444 | TICKET_REQUEST | TBA2 | None | 445 | TICKET_ACK | TBA3 | None | 446 | TICKET_NACK | TBA4 | None | 447 +-------------------+--------+-----------------+ 449 4.4. TICKET_OPAQUE Notify Payload 451 The data for the TICKET_OPAQUE Notify payload consists of the Notify 452 message header, a lifetime field and the ticket itself. The four 453 octet lifetime field contains the number of seconds until the ticket 454 expires (encoded as an unsigned integer). 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ! Next Payload !C! Reserved ! Payload Length ! 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 ! Lifetime ! 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 ! ! 466 ~ Ticket ~ 467 ! ! 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 5: TICKET_OPAQUE Notify Payload 471 4.5. Processing Guidelines for IKE SA Establishment 473 When a ticket is presented, the gateway needs to obtain the ticket 474 per value. In case a ticket by reference was provided by the client 475 the gateway needs to resolve the reference in order to obtain the 476 ticket by value. In case the client has already provided the ticket 477 per value it can parses the ticket. In either case, the gateway 478 needs to process the ticket by value in order to restore the state of 479 the old IKE SA, and the client retrieves this state from its local 480 store. Both peers now create state for the new IKE SA as follows: 482 o The SA value (transforms etc.) is taken directly from the ticket. 483 o The sequence numbers are reset to 0. 484 o The IDi value is obtained from the ticket. 485 o The IDr value is obtained from the new exchange. The gateway MAY 486 make policy decisions based on the IDr value encoded in the 487 ticket. 488 o The SPI values are created anew, similarly to a regular IKE 489 exchange. SPI values from the ticket SHOULD NOT be reused. This 490 restriction is to avoid problems caused by collisions with other 491 SPI values used already by the initiator/responder. The SPI value 492 should only be reused if collision avoidance can be ensured 493 through other means. 495 The cryptographic material is refreshed based on the ticket and the 496 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 497 value is derived as follows: 499 SKEYSEED = prf(SK_d2, Ni | Nr) 501 where SK_d2 was computed earlier (Section 4.2.1). 503 The keys are derived as follows, unchanged from IKEv2: 505 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 506 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 508 where SPIi, SPIr are the SPI values created in the new IKE exchange. 510 See [RFC4306] for the notation. "prf" is determined from the SA value 511 in the ticket. 513 5. Ticket Recommendations 515 5.1. Ticket Content 517 When passing a ticket by value to the client, the ticket content MUST 518 be integrity protected and encrypted. A ticket by reference does not 519 need to be encrypted, as it does not contain any sensitive material, 520 such as keying material. However, access to the storage where that 521 sensitive material is stored MUST be protected so that only 522 unauthorized access is not allowed. We note that such a ticket is 523 analogous to the concept of 'stub', as defined in 524 [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. 526 When the state is passed by value, the ticket MUST encode at least 527 the following state from an IKE SA. 529 o IDi, IDr. 530 o SPIi, SPIr. 531 o SAr (the accepted proposal). 532 o SK_d. 534 The ticket by value MUST include a key identity field, so that 535 encryption and authentication can be changed, and when necessary, 536 algorithms can be replaced. 538 In addition, the ticket by value and the ticket by reference MUST 539 contain a protected ticket expiration value that is readable for the 540 client. 542 5.2. Ticket Identity and Lifecycle 544 Each ticket is associated with a single IKE SA. In particular, when 545 an IKE SA is deleted, the client MUST delete its stored ticket. A 546 ticket is therefore associated with the tuple (IDi, IDr). 548 The lifetime of the ticket carried in the N(TICKET_OPAQUE) 549 notification SHOULD be the minimum of the IKE SA lifetime (per the 550 gateway's local policy) and its re-authentication time, according to 551 [RFC4478]. Even if neither of these are enforced by the gateway, a 552 finite lifetime MUST be specified for the ticket. 554 6. IANA Considerations 556 This document requires a number of IKEv2 notification status types in 557 Section 4.3, to be registered by IANA. The corresponding registry 558 was established by IANA. 560 The document defines a new IKEv2 exchange in Section 4.2. The 561 corresponding registry was established by IANA. 563 7. Security Considerations 565 This section addresses security issues related to the usage of a 566 ticket. 568 7.1. Stolen Tickets 570 An man-in-the-middle may try to eavesdrop on an exchange to obtain a 571 ticket by value and use it to establish a session with the IKEv2 572 responder. This can happen in different ways: by eavesdropping on 573 the initial communication and copying the ticket when it is granted 574 and before it is used, or by listening in on a client's use of the 575 ticket to resume a session. However, since the ticket's contents is 576 encrypted and the attacker does not know the corresponding secret 577 key, a stolen ticket cannot be used by an attacker to succesfully 578 resume a session. An IKEv2 responder MUST use strong encryption and 579 integrity protection of the ticket to prevent an attacker from 580 obtaining the ticket's contents, e.g., by using a brute force attack. 582 Since a ticket by reference does not need to be encrypted. When an 583 adversary is able to eavesdrop on an exchange, as described in the 584 previous paragraph, then the ticket by reference may be obtained. 585 The adversary MUST NOT be able to resolve the ticket via the 586 reference, i.e., access control MUST be enforced to ensure disclosure 587 only to authorized entities. 589 7.2. Forged Tickets 591 A malicious user could forge or alter a ticket by value in order to 592 resume a session, to extend its lifetime, to impersonate as another 593 user, or to gain additional privileges. This attack is not possible 594 if the content of the ticket by value is protected using a strong 595 integrity protection algorithm. 597 In case of a ticket by reference an adversary may attempt to 598 construct a faked ticket by reference to point to state information 599 stored by the IKEv2 responder. This attack will fail because the 600 adversary is not in possession of the keying material associated with 601 the IKEv2 SA. 603 7.3. Denial of Service Attacks 605 An adversary could generate and send a large number of tickets by 606 value to a gateway for verification. To minimize the possibility of 607 such denial of service, ticket verification should be lightweight 608 (e.g., using efficient symmetric key cryptographic algorithms). 610 When an adversary chooses to send a large number of tickets by value 611 then this may lead to an amplification attack as the IKEv2 is forced 612 to resolve the reference to a ticket in order to determine that the 613 adversary is not in possession of the keying material corresponding 614 to the stored state or that the reference is void. To minimize this 615 attack the protocol to resolve the reference should be as lightweight 616 as possible. and should not generate a large number of messages. 618 7.4. Key Management for Tickets By Value 620 A full description of the management of the keys used to protect the 621 ticket by value is beyond the scope of this document. A list of 622 RECOMMENDED practices is given below. 623 o The keys should be generated securely following the randomness 624 recommendations in [RFC4086]. 625 o The keys and cryptographic protection algorithms should be at 626 least 128 bits in strength. 627 o The keys should not be used for any other purpose than generating 628 and verifying tickets. 629 o The keys should be changed regularly. 630 o The keys should be changed if the ticket format or cryptographic 631 protection algorithms change. 633 7.5. Ticket Lifetime 635 An IKEv2 responder controls the validity period of the state 636 information by attaching a lifetime to a ticket. The chosen lifetime 637 is based on the operational and security requirements of the 638 environment in which this IKEv2 extension is deployed. The responder 639 provides information about the ticket lifetime to the IKEv2 640 initiator, allowing it to manage its tickets. 642 7.6. Ticket by Value Format 644 Great care must be taken when defining a ticket format such that the 645 requirements outlined in Section 5.1 are met. In particular, if 646 confidential information, such as a secret key, is transferred to the 647 client it MUST be done using channel security to prevent attackers 648 from obtaining or modifying the ticket. Also, the ticket by value 649 MUST have its integrity and confidentiality protected with strong 650 cryptographic techniques to prevent a breach in the security of the 651 system. 653 7.7. Identity Privacy, Anonymity, and Unlinkability 655 Since opaque state information is passed around between the IKEv2 656 initiator and the IKEv2 responder it is important that leakage of 657 information, such as the identities of an IKEv2 initiator and a 658 responder, MUST be avoided (e.g., with the help of encryption. Thus, 659 it prevents the disclosure of potentially sensitive information. 661 When an IKEv2 initiator presents a ticket as part of the 662 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 663 exchange. There is thereby the possibility for an on-path adversary 664 to observe multiple exchange handshakes where the same state 665 information is used and therefore to conclude that they belong to the 666 same communication end points. 668 This document therefore envisions that the ticket is presented to the 669 IKEv2 responder only once; multiple usage of the ticket is not 670 provided. 672 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange 674 A major design goal of this protocol extension has been the two- 675 message exchange for session resumption. There is a tradeoff between 676 this abbreviated exchange and replay protection. It is RECOMMENDED 677 that an IKEv2 responder should cache tickets, and reject replayed 678 ones. However, some gateways may not do that in order to reduce 679 state size. An adversary may attempt to replay a ticket. To 680 mitigate these risks a client may be required by the gateway to show 681 that it knows the ticket's secret, before any state is committed on 682 the gateway side. Note that this is a stronger guarantee than the 683 regular IKE cookie mechanism, which only shows IP return routability 684 of the client. This is enabled by including the cookie in the 685 protected portion of the message. 687 For performance reasons, the cookie mechanism is optional, and 688 invoked by the gateway only when it suspects that it is the subject 689 of a denial-of-service attack. 691 In any case, a ticket replayed by an adversary only causes partial 692 IKE state to be created on the gateway. The IKE exchange cannot be 693 completed and an IKE SA cannot be created unless the client knows the 694 ticket's secret values. 696 8. Acknowledgements 698 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 699 Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ 700 Housely, Yoav Nir and Tero Kivinen for their comments. We would to 701 particularly thank Florian Tegeler and Stjepan Gros for their help 702 with their implementation efforts and Florian Tegeler for his formal 703 verification using the CASPER tool set. 705 We would furthermore like to thank the authors of 706 [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke 707 Xu) for their input on the stub concept. 709 We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad 710 Muhanna and Stephen Kent for their feedback regarding the ticket by 711 reference concept. 713 9. References 715 9.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 721 RFC 4306, December 2005. 723 9.2. Informative References 725 [I-D.rescorla-stateless-tokens] 726 Rescorla, E., "How to Implement Secure (Mostly) Stateless 727 Tokens", draft-rescorla-stateless-tokens-01 (work in 728 progress), March 2007. 730 [I-D.xu-ike-sa-sync] 731 Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA 732 Synchronization for session resumption", 733 draft-xu-ike-sa-sync-01 (work in progress), October 2008. 735 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 736 Requirements for Security", BCP 106, RFC 4086, June 2005. 738 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 739 Internet Protocol", RFC 4301, December 2005. 741 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 742 (IKEv2) Protocol", RFC 4478, April 2006. 744 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 745 (MOBIKE)", RFC 4555, June 2006. 747 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 748 Implementation Guidelines", RFC 4718, October 2006. 750 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 751 "Transport Layer Security (TLS) Session Resumption without 752 Server-Side State", RFC 5077, January 2008. 754 Appendix A. Ticket Format 756 This document does not specify a mandatory-to-implement or a 757 mandatory-to-use ticket format. The format described in the sub- 758 sections are RECOMMENDED. 760 A.1. Recommended Ticket by Value Format 762 struct { 763 [authenticated] struct { 764 octet format_version; // 1 for this version of the protocol 765 octet reserved[3]; // sent as 0, ignored by receiver. 766 octet key_id[8]; // arbitrary byte string 767 opaque IV[0..255]; // actual length (possibly 0) depends 768 // on the encryption algorithm 770 [encrypted] struct { 771 opaque IDi, IDr; // the full payloads 772 octet SPIi[8], SPIr[8]; 773 opaque SA; // the full SAr payload 774 octet SK_d[0..255]; // actual length depends on SA value 775 int32 expiration; // an absolute time value, seconds 776 // since Jan. 1, 1970 777 } ikev2_state; 778 } protected_part; 779 opaque MAC[0..255]; // the length (possibly 0) depends 780 // on the integrity algorithm 781 } ticket; 783 Note that the key defined by "key_id" determines the encryption and 784 authentication algorithms used for this ticket. Those algorithms are 785 unrelated to the transforms defined by the SA payload. 787 The reader is referred to [I-D.rescorla-stateless-tokens] that 788 recommends a similar (but not identical) ticket format, and discusses 789 related security considerations in depth. 791 A.2. Recommended Ticket by Reference Format 793 For implementations that prefer to pass a reference to IKE state in 794 the ticket, rather than the state itself, we RECOMMEND the following 795 format: 797 struct { 798 [authenticated] struct { 799 octet format_version; // 1 for this version of the protocol 800 octet reserved[3]; // sent as 0, ignored by receiver. 801 octet key_id[8]; // arbitrary byte string 803 struct { 804 opaque state_ref; // reference to IKE state 805 int32 expiration; // an absolute time value, seconds 806 // since Jan. 1, 1970 807 } ikev2_state_ref; 808 } protected_part; 809 opaque MAC[0..255]; // the length depends 810 // on the integrity algorithm 811 } ticket; 813 Appendix B. Change Log 815 B.1. -01 817 Addressed issue#75, see 818 http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included 819 changes throughout the document to ensure that the ticket may contain 820 a reference or a value. 822 B.2. -00 824 Resubmitted document as a WG item. 826 B.3. -01 828 Added reference to [I-D.xu-ike-sa-sync] 830 Included recommended ticket format into the appendix 832 Various editorial improvements within the document 834 B.4. -00 836 Issued a -00 version for the IPSECME working group. Reflected 837 discussions at IETF#72 regarding the strict focus on session 838 resumption. Consequently, text about failover was removed. 840 B.5. -04 842 Editorial fixes; references cleaned up; updated author's contact 843 address 845 B.6. -03 847 Removed counter mechanism. Added an optional anti-DoS mechanism, 848 based on IKEv2 cookies (removed previous discussion of cookies). 849 Clarified that gateways may support reallocation of same IP address, 850 if provided by network. Proposed a solution outline to the problem 851 of key exchange for the keys that protect tickets. Added fields to 852 the ticket to enable interoperability. Removed incorrect MOBIKE 853 notification. 855 B.7. -02 857 Clarifications on generation of SPI values, on the ticket's lifetime 858 and on the integrity protection of the anti-replay counter. 859 Eliminated redundant SPIs from the notification payloads. 861 B.8. -01 863 Editorial review. Removed 24-hour limitation on ticket lifetime, 864 lifetime is up to local policy. 866 B.9. -00 868 Initial version. This draft is a selective merge of 869 draft-sheffer-ike-session-resumption-00 and 870 draft-dondeti-ipsec-failover-sol-00. 872 Authors' Addresses 874 Yaron Sheffer 875 Check Point Software Technologies Ltd. 876 5 Hasolelim St. 877 Tel Aviv 67897 878 Israel 880 Email: yaronf@checkpoint.com 882 Hannes Tschofenig 883 Nokia Siemens Networks 884 Linnoitustie 6 885 Espoo 02600 886 Finland 888 Phone: +358 (50) 4871445 889 Email: Hannes.Tschofenig@gmx.net 890 URI: http://www.tschofenig.priv.at 892 Lakshminath Dondeti 893 QUALCOMM, Inc. 894 5775 Morehouse Dr 895 San Diego, CA 896 USA 898 Phone: +1 858-845-1267 899 Email: ldondeti@qualcomm.com 901 Vidya Narayanan 902 QUALCOMM, Inc. 903 5775 Morehouse Dr 904 San Diego, CA 905 USA 907 Phone: +1 858-845-2483 908 Email: vidyan@qualcomm.com