idnits 2.17.1 draft-sheffer-ike-session-resumption-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2007) is 6304 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 214, but not defined -- Looks like a reference, but probably isn't: '16' on line 426 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-02) exists of draft-friedman-ike-short-term-certs-01 == Outdated reference: A later version (-01) exists of draft-rescorla-stateless-tokens-00 == Outdated reference: A later version (-02) exists of draft-vidya-ipsec-failover-ps-00 -- Obsolete informational reference (is this intentional?): RFC 4507 (Obsoleted by RFC 5077) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 23, 2007 Siemens Networks GmbH & Co KG 6 T. Wan 7 Nortel 8 January 19, 2007 10 Stateless Session Resumption for the IKE Protocol 11 draft-sheffer-ike-session-resumption-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 23, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Internet Key Exchange version 2 (IKEv2) protocol is 45 computationally intensive with respect to the number of round-trips 46 required and cryptographic operations involved. In particular the 47 Extensible Authentication Protocol is used for authentication, which 48 adds additional computational intensity. 50 To re-establish security associations (SA) upon a failure recovery 51 condition is time comsuming, especially when an IPsec peer, such as a 52 VPN gateway, needs to re-establish a large number of SAs with various 53 end points. A high number of concurrent sessions might cause 54 additional problems for an IPsec peer during SA restablishment. 56 In many failure cases it would be useful to provide an efficient way 57 to resume an interrupted IKE/IPsec session. This document proposes 58 an extension to IKEv2 that allows a client to re-establish an IKE SA 59 with a gateway in a highly efficient manner, utilizing a previously 60 establied IKE SA. 62 A client can reconnect to a gateway from which it was disconnected, 63 or alternatively migrate to another gateway that is associated with 64 the previous one. The proposed approach conveys IKEv2 state 65 information, in the form of an encrypted ticket, to a VPN client that 66 is later presented to the VPN gateway for re-authentication. An 67 encrypted ticket cannot be decrypted by a VPN client but allows a VPN 68 gateway to restore state for faster session state setup. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 76 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 5 78 3.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 7 79 3.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 9 80 3.4. Processing Guidelines for IKE SA Establishment . . . . . . 9 81 3.5. Computing the AUTH Payload . . . . . . . . . . . . . . . . 10 82 4. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 10 84 4.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 11 85 4.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 11 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 6.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12 89 6.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12 90 6.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 91 6.4. Ticket Protection Key Management . . . . . . . . . . . . . 12 92 6.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13 93 6.6. Alternate Ticket Formats and Distribution Schemes . . . . 13 94 6.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13 95 6.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 14 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 100 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 15 101 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 102 B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 104 Intellectual Property and Copyright Statements . . . . . . . . . . 17 106 1. Introduction 108 The Internet Key Exchange version 2 (IKEv2) protocol is 109 computationally intensive with respect to the number of round-trips 110 required and cryptographic operations involved. In particular the 111 Extensible Authentication Protocol is used for authentication, which 112 adds additional computational intensity. 114 To re-establish security associations (SA) upon a failure recovery 115 condition is time-consuming, especially when an IPsec peer, such as a 116 VPN gateway, needs to re-establish a large number of SAs with various 117 end points. A high number of concurrent sessions might cause 118 additional problems for an IPsec peer. 120 In many failure cases it would be useful to provide an efficient way 121 to resume an interrupted IKE/IPsec session. This document proposes 122 an extension to IKEv2 that allows a client to re-establish an IKE SA 123 with a gateway in a highly efficient manner, utilizing a previously 124 establied IKE SA. 126 A client can reconnect to a gateway from which it was disconnected, 127 or alternatively migrate to another gateway that is associated with 128 the previous one. This document proposes to maintain an IKEv2 state 129 in a "ticket", an opaque data structure created and used by a server 130 and stored by a client, which the client cannot understand or tamper 131 with. The IKEv2 protocol needs to be extended to allow a client to 132 request and present a ticket. When two gateways mutually trust each 133 other, one can accept a ticket generated by the other. 135 This approach is similar to the one taken by TLS session resumption 136 [RFC4507] with the required adaptations for IKEv2, e.g., to 137 accommodate the two-phase protocol structure. We have borrowed 138 heavily from that specification. 140 1.1. Goals 142 The high-level goal of this extension is to become a building block 143 of an overall IPsec failover solution, according to the requirements 144 defined in [I-D.vidya-ipsec-failover-ps]. 146 Specifically, the proposed extension should allow IPsec sessions to 147 be recovered from failures in remote access scenarios, in a more 148 efficient manner than the basic IKE solution. This efficiency is 149 primarily on the gateway side, since the gateway might have to deal 150 with many thousands of concurrent requests. We should enable the 151 following cases: 153 o Failover from one gateway to another, where the two gateways do 154 not share state but do have mutual trust. For example, the 155 gateways may be operated by the same provider and share the same 156 keying materials to access an encrypted ticket. 157 o Recovery from an intermittent connectivity failure ("network 158 reboot"), where clients reconnect into the same gateway. In this 159 case the gateway would typically had detected the clients' absence 160 and removed the state associated with them. 161 o Recovery from a gateway restart, where clients reconnect into the 162 same gateway. 164 The proposed solution should additionally meet the following goals: 166 o Using only symmetric cryptography to minimize CPU consumption. 167 o Allowing a gateway to push state to clients. 168 o Providing cryptographic agility. 169 o Having no negative impact on IKEv2 security features. 170 Specifically, the solution must not introduce new security 171 vulnerabilities, such as denial-of-service. 173 1.2. Non-Goals 175 The following are non-goals of this solution: 176 o Providing load balancing among gateways. 177 o Specifying how a client detects the need for a failover. 178 o Establishing trust among gateways. 180 2. Requirements Notation 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Protocol Details 188 This section provides protocol details and contains the normative 189 parts. This document defines two protocol exchanges, namely 190 requesting a ticket and presenting a ticket. Section 3.1 describes 191 the procedure to request a ticket and Section 3.2 illustrates how to 192 present a ticket. 194 3.1. Requesting a Ticket 196 A client MAY request a ticket in the following exchanges: 198 o In an IKE_AUTH exchange, as shown in the example message exchange 199 in Figure 1 below. 200 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 201 o In an Informational exchange, if the gateway previously replied 202 with an N(TICKET/Ack) instead of providing a ticket. 203 o In an Informational exchange, when the ticket lifetime is about to 204 expire. 206 Normally, a client requests a ticket in the third message of an IKEv2 207 (the first of IKE_AUTH). Figure 1 shows the message exchange for 208 this typical case. 210 Initiator Responder 211 ----------- ----------- 212 HDR, SAi1, KEi, Ni --> 214 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 216 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 217 AUTH, SAi2, TSi, TSr, N(TICKET/Request)} --> 219 Figure 1: Example Message Exchange for Requesting a Ticket 221 The notification payloads are described in Section 3.3. For 222 editorial reasons a number of IKEv2-specific details are omitted. A 223 complete description of IKEv2 can be found in [RFC4718]. 225 When an IKEv2 responder receives a request for a ticket using the 226 N(TICKET/Request) payload it MUST perform one of the following 227 operations if it supports the extension defined in this document: 228 o it creates a ticket and returns it with the N(TICKET/Opaque) 229 payload in a subsequent message towards the IKEv2 initiator. This 230 exchange is shown in Figure 2. 231 o it returns an N(TICKET/Nack) payload, if it refuses to grant a 232 ticket for some reason. 233 o it returns an N(TICKET/Ack), if it cannot grant a ticket 234 immediately, e.g., due to packet size limitations. In this case 235 the client MAY request a ticket later using an Informational 236 exchange, at any time during the lifetime of the IKE SA. 238 The IKEv2 initiator receives the requested ticket if the IKEv2 239 exchange was successful, and the ticket later be used with an IKEv2 240 responder which supports this extension. The ticket exchange is 241 shown in Figure 2 242 Initiator Responder 243 ----------- ----------- 244 <-- HDR, SK {IDr, [CERT,] AUTH, 245 SAr2, TSi, TSr, N(TICKET/Opaque)} 247 Figure 2: Receiving a Ticket 249 3.2. Presenting a Ticket 251 Following a communication failure, a client re-initiates an IKE 252 exchange to the same gateway or to a different one, and includes a 253 ticket in the first message of IKE_SA_INIT. A client MAY initiate a 254 regular (non-ticket-based ) IKEv2 exchange even if it is in 255 possession of a valid ticket. A client MUST NOT present a ticket 256 after the ticket's lifetime has expired. 258 It is purely a local decision of the client when and based on what 259 information to decide that a communication failure has happened and 260 that a new exchange including the ticket is needed. 262 Initiator Responder 263 ----------- ----------- 264 HDR, SAi1, KEi, Ni, N(TICKET/Opaque) --> 266 When the IKEv2 responder receives a ticket using the N(TICKET/Opaque) 267 payload it MUST perform one of the following steps if it supports the 268 extension defined in this document: 269 o It responds with an N(TICKET/Ack), if it supports this extension 270 and is willing to accept the ticket. This message is shown in 271 Figure 4. 272 o It responds with an N(TICKET/Nack) notification, if it does not 273 accept the ticket for any reason. The responder SHOULD respond 274 with a regular IKE_INIT message #2 including the said 275 notification, and the two IKEv2 peers SHOULD continue with a full, 276 regular IKE exchange. One such case is when the responder 277 receives a ticket for an IKE SA that has previously been 278 terminated on the responder itself, which may indicate 279 inconsistent state between the IKEv2 initiator and the responder. 280 However a responder is not required to maintain the state for 281 terminated sessions. 282 o If the responder receives a ticket for an IKE SA that is still 283 active and accepts it, it SHOULD silently delete the old SA 284 without sending a DELETE Informational exchange. 286 If the responder replies with a standard IKE_INIT message #2 then the 287 initiator can assume that the responder does not implement the 288 extension described in this document. 290 Initiator Responder 291 ----------- ----------- 292 <-- HDR, SAr1, Nr, N(TICKET/Ack) 294 Figure 4: IKEv2 Responder responds with N(TICKET/Ack) 296 The KE payload is omitted in the response, but Ni and Nr are still 297 exchanged to assure the freshness of subsequently derived keying 298 materials. 300 At this point a new IKE SA is created by both parties (see 301 Section 3.4), and used for the following IKE_AUTH exchange. Both 302 parties thereby exchange AUTH payloads, as shown below: 304 Initiator Responder 305 ----------- ----------- 306 --> HDR, SK {IDi, [IDr,] AUTH} 307 <-- HDR, SK {IDr, AUTH} 309 Figure 5: A Stand-Alone IKE_AUTH Exchange 311 See Section 3.5 for the derivation of the AUTH values from the 312 message bytes, the ticket and the nonce values. The initator and the 313 responder MUST verify the AUTH values they receive. The new IKE SA 314 only becomes fully valid if both parties have verified each other's 315 AUTH payload. If either side receives an incorrect AUTH value, it 316 MUST terminate the protocol. 318 the IKE_AUTH exchange can also be piggybacked into a CREATE_CHILD_SA 319 exchange, as shown in Figure 6. It is up to the client to decide 320 whether to piggyback the exchange. 322 --> HDR, SK {IDi, [IDr,] AUTH, SAi2, Ni2, TSi, TSr [, CP(CFG_REQUEST)]} 323 <-- HDR, SK {IDr, AUTH, SAr2, Nr2, TSi, TSr [, CP(CFG_REPLY)]} 325 Figure 6: IKE_AUTH piggybacked on top of a CREATE_CHILD_SA exchange 327 3.3. IKE Notifications 329 This document defines a single notification type, TICKET, with a 330 number of subtypes. The notification number is TBD and the subtypes 331 are listed below: 333 +--------------+---------+-----------+ 334 | Subtype Name | Number | Data | 335 +--------------+---------+-----------+ 336 | Opaque | 1 | See below | 337 | Request | 2 | None | 338 | Ack | 3 | None | 339 | Nack | 4 | None | 340 | Reserved | 5-127 | | 341 | Private Use | 128-255 | | 342 +--------------+---------+-----------+ 344 The data for the Opaque subtype consists of a lifetime duration in 345 seconds (4 octets, denoting the time until the ticket expires), 346 followed by the ticket content. See Section 4.3 for further 347 guidelines regarding the ticket's lifetime, and Section 4.2 for a 348 recommended ticket format. 350 3.4. Processing Guidelines for IKE SA Establishment 352 When a ticket is presented, the gateway parses the ticket to retrieve 353 the state of the old IKE SA, and the client retrieves this state from 354 its local store. Both peers now create state for the new IKE SA as 355 follows: 357 o The SA value (transforms etc.) is taken directly from the ticket. 358 o The sequence numbers are reset to 0. 359 o The IDi value is obtained from the ticket. 360 o The IDr value is obtained from the new exchange. The gateway MAY 361 make policy decisions based on the IDr value encoded in the 362 ticket. 363 o The SPI values are created anew, similarly to a regular IKE 364 exchange. SPI values from the ticket MUST NOT be reused. 366 The cryptographic material is refreshed based on the ticket and the 367 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 368 value is derived as follows: 370 SKEYSEED = prf+(SK_d_old, Ni | Nr) 372 where SK_d_old is the value retrieved from the ticket. 374 The keys are derived as follows, unchanged from IKEv2: 376 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 377 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 379 where SPIi, SPIr are the SPI values created in the new IKE exchange. 381 See [RFC4306] for the notation. "prf" is determined from the SA value 382 in the ticket. 384 3.5. Computing the AUTH Payload 386 The value for the AUTH payload is derived in a manner similar to the 387 usage of IKEv2 pre-shared secret-based authentication, as shown 388 below: 390 AUTH = prf(SK_px, ) 392 Each of the initiator and responder uses its own SK_p value, taken 393 from the newly generated IKE SA. 395 The exact material to be signed is defined in Section 2.15 of 396 [RFC4306]. The notation "IDr'" in RFC 4306 should be applied to the 397 new IDr value included in the exchange, rather than the value in the 398 ticket. 400 4. The IKE Ticket 402 This section lists the required contents of the ticket, and 403 recommends a non-normative format. This is followed by a discussion 404 of the ticket's lifecycle. 406 4.1. Ticket Contents 408 The ticket MUST encode at least the following state from an IKE SA. 409 These values MUST be encrypted and authenticated. 411 o IDi, IDr. 412 o SPIi, SPIr. 413 o SAr (the accepted proposal). 414 o SK_d. 416 In addition, the ticket MUST encode a protected ticket expiration 417 value. 419 4.2. Ticket Format 421 This document does not specify a ticket format. The following format 422 (this entire current section) is a RECOMMENDED implementation. The 423 client SHOULD NOT attempt to decode the ticket. 425 struct { 426 opaque key_name[16]; // ASCII, null-terminated 427 opaque IV[0..255]; // the length (possibly 0) depends 428 // on the encryption algorithm 430 [protected] struct { 431 opaque IDi, IDr; // the full payloads 432 opaque SPIi, SPIr; 433 opaque SA; // the full payload, returned as SAr 434 opaque SK_d; 435 opaque expiration; // an absolute time value 436 } ikev2_state; // encrypted and authenticated 437 opaque MAC[0..255]; // the length (possibly 0) depends 438 // on the integrity algorithm 439 } ticket; 441 Note that the key defined by "key_name" determines the encryption and 442 authentication algorithms used for this ticket. Those algorithms are 443 unrelated to the transforms defined by the SA payload. 445 The reader is referred to a recent draft 446 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 447 identical) ticket format, and discusses related security 448 considerations in depth. 450 4.3. Ticket Identity and Lifecycle 452 Each ticket is associated with a single IKE SA. In particular, when 453 an IKE SA is deleted, the client MUST delete its stored ticket. 455 A ticket is therefore associated with the tuple (IDi, IDr). The 456 client MAY however use a ticket to approach other gateways that are 457 willing to accept it. How a client discovers such gateways is 458 outside the scope of this document. 460 The lifetime included with the ticket in the N(TICKET/Opaque) 461 notification should be the minimum of the IKE SA lifetime (per the 462 gateway's local policy) and its re-authentication time, according to 463 [RFC4478]. Even if neither of these is enforced by the gateway, a 464 finite lifetime MUST be specified for the ticket and SHOULD be less 465 than 24 hours. 467 5. IANA Considerations 469 This document requires the following notifications to be registered 470 by IANA. The corresponding registry was established by IANA. 471 o Notification type (Section 3.3). 472 o Notification subtypes (Section 3.3). 474 6. Security Considerations 476 This section addresses security issues related to the usage of a 477 ticket. 479 6.1. Stolen Tickets 481 An eavesdropper or man-in-the-middle may try to obtain a ticket and 482 use it to establish a session with the IKEv2 responder. However, 483 since the ticket is encrypted and the attacker does not know the 484 corresponding secret key (specifically, SK_d), a stolen ticket cannot 485 be used by an attacker to resume a session. An IKEv2 responder MUST 486 use strong encryption and integrity protection for the ticket to 487 prevent an attacker from obtaining the ticket's contents, e.g., by 488 using a brute force attack. 490 6.2. Forged Tickets 492 A malicious user could forge or alter a ticket in order to resume a 493 session, to extend its lifetime, to impersonate as another user, or 494 to gain additional privileges. This attack is not possible if the 495 ticket is protected using a strong integrity protection algorithm 496 such as a keyed HMAC-SHA1. 498 6.3. Denial of Service Attacks 500 The key_name field defined in the recommended ticket format helps the 501 server efficiently reject tickets that it did not issue. However, an 502 adversary could generate and send a large number of tickets to a 503 gateway for verification. To minimize the possibility of such denial 504 of service, ticket verification should be lightweight (e.g., using 505 efficient symmetric key cryptographic algorithms). See also 506 Section 6.8. 508 6.4. Ticket Protection Key Management 510 A full description of the management of the keys used to protect the 511 ticket is beyond the scope of this document. A list of RECOMMENDED 512 practices is given below. 514 o The keys should be generated securely following the randomness 515 recommendations in [RFC4086]. 516 o The keys and cryptographic protection algorithms should be at 517 least 128 bits in strength. 518 o The keys should not be used for any other purpose than generating 519 and verifying tickets. 520 o The keys should be changed regularly. 521 o The keys should be changed if the ticket format or cryptographic 522 protection algorithms change. 524 6.5. Ticket Lifetime 526 An IKEv2 responder controls the lifetime of a ticket, based on the 527 operational and security requirements of the environment in which it 528 is deployed. The responder provides information about the ticket 529 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 531 An IKEv2 client may present a ticket in its possession to a gateway, 532 even if the IKE SA associated with this ticket had previously been 533 terminated by another gateway (the gateway that originally provided 534 the ticket). Where such usage is against the local security policy, 535 an Invalid Ticket List (ITL) may be used, see 536 [I-D.rescorla-stateless-tokens]. Management of such lists is outside 537 the scope of the current document. Note that a policy that requires 538 tickets to have shorter lifetimes (e.g., 1 hour) significantly 539 mitigates this risk. 541 6.6. Alternate Ticket Formats and Distribution Schemes 543 If the ticket format or distribution scheme defined in this document 544 is not used, then great care must be taken in analyzing the security 545 of the solution. In particular, if confidential information, such as 546 a secret key, is transferred to the client, it MUST be done using 547 secure communication to prevent attackers from obtaining or modifying 548 the key. Also, the ticket MUST have its integrity and 549 confidentiality protected with strong cryptographic techniques to 550 prevent a breach in the security of the system. 552 6.7. Identity Privacy, Anonymity, and Unlinkability 554 This document mandates that the content of the ticket MUST be 555 encrypted in order to avoid leakage of information, such as the 556 identities of an IKEv2 initiator and a responder. Thus, it prevents 557 the disclosure of potentially sensitive information carried within 558 the ticket. 560 When an IKEv2 initiator presents the ticket as part of the first 561 message of the IKE_SA_INIT exchange, confidentiality is not provided 562 for the exchange. Althought the ticket itself is encrypted there 563 might still be a possibility for an on-path adversary to observe 564 multiple exchange handshakes where the same ticket is used and 565 therefore to conclude that they belong to the same communication end 566 points. Administrators that use the ticket mechanism described in 567 this document should be aware that unlinkability may not be provided 568 by this mechanism. Note, however, that IKEv2 does not provide active 569 user identity confidentiality for the IKEv2 initiator either. 571 6.8. Usage of IKE Cookies 573 The extension specified in this document eliminates most potential 574 denial-of-service attacks that the cookie mechanism aims to solve. 575 However, memory exhaustion remains possible. Therefore the cookie 576 mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the 577 gateway for the modified IKE_INIT exchange described in Section 3.2. 579 7. Acknowledgements 581 We would like to thank Pasi Eronen and Yoav Nir for their review of 582 early drafts. 584 8. References 586 8.1. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 592 RFC 4306, December 2005. 594 8.2. Informative References 596 [I-D.friedman-ike-short-term-certs] 597 Friedman, A., "Short-Term Certificates", 598 draft-friedman-ike-short-term-certs-01 (work in progress), 599 December 2006. 601 [I-D.rescorla-stateless-tokens] 602 Rescorla, E., "How to Implement Secure (Mostly) Stateless 603 Tokens", draft-rescorla-stateless-tokens-00 (work in 604 progress), January 2007. 606 [I-D.vidya-ipsec-failover-ps] 607 Narayanan, V., "IPsec Gateway Failover and Redundancy - 608 Problem Statement and Goals", 609 draft-vidya-ipsec-failover-ps-00 (work in progress), 610 December 2006. 612 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 613 Requirements for Security", BCP 106, RFC 4086, June 2005. 615 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 616 (IKEv2) Protocol", RFC 4478, April 2006. 618 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 619 "Transport Layer Security (TLS) Session Resumption without 620 Server-Side State", RFC 4507, May 2006. 622 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 623 Implementation Guidelines", RFC 4718, October 2006. 625 Appendix A. Related Work 627 [I-D.friedman-ike-short-term-certs] is on-going work that discusses 628 the use of short-term certificates for client re-authentication. It 629 is similar to the ticket approach described in this document in that 630 they both require enhancements to IKEv2 to allow information request, 631 e.g., for a certificate or a ticket. However, the changes required 632 by the former are fewer since an obtained certificate is valid for 633 any IKE responder that is able to verify them. On the other hand, 634 short-term certificates, while eliminating the usability issues of 635 user re-authentication, do not reduce the amount of effort performed 636 by the gateway in failover situations. 638 Appendix B. Change Log 640 B.1. -00 642 Initial version. 644 Authors' Addresses 646 Yaron Sheffer 647 Check Point Software Technologies Ltd. 648 3A Jabotinsky St. 649 Ramat Gan 52520 650 Israel 652 Email: yaronf at checkpoint dot com 654 Hannes Tschofenig 655 Siemens Networks GmbH & Co KG 656 Otto-Hahn-Ring 6 657 Munich, Bavaria 81739 658 Germany 660 Phone: +49 89 636 40390 661 Email: Hannes.Tschofenig@siemens.com 662 URI: http://www.tschofenig.com 664 Tao Wan 665 Nortel Networks 666 250 Sidney Street 667 Belleville, Ontario K8N 5B7 668 Canada 670 Phone: +1 613 961 2350 671 Email: twan (at) nortel (dot) com 673 Full Copyright Statement 675 Copyright (C) The IETF Trust (2007). 677 This document is subject to the rights, licenses and restrictions 678 contained in BCP 78, and except as set forth therein, the authors 679 retain all their rights. 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 684 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 685 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 686 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Intellectual Property 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org. 713 Acknowledgment 715 Funding for the RFC Editor function is provided by the IETF 716 Administrative Support Activity (IASA).