idnits 2.17.1 draft-ietf-ipsecme-ikev2-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 889. 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 date (November 17, 2008) is 5638 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 262, but not defined == Missing Reference: 'TSi' is mentioned on line 350, but not defined == Missing Reference: 'TSr' is mentioned on line 350, but not defined -- Looks like a reference, but probably isn't: '3' on line 749 -- Looks like a reference, but probably isn't: '8' on line 750 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- 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 (~~), 4 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: May 21, 2009 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 November 17, 2008 11 IKEv2 Session Resumption 12 draft-ietf-ipsecme-ikev2-resumption-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 21, 2009. 39 Abstract 41 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 42 computational and communication overhead with respect to the number 43 of round-trips required and the cryptographic operations involved. 44 In remote access situations, the Extensible Authentication Protocol 45 (EAP) is used for authentication, which adds several more round trips 46 and consequently latency. 48 To re-establish security associations (SA) upon a failure recovery 49 condition is time consuming, especially when an IPsec peer, such as a 50 VPN gateway, needs to re-establish a large number of SAs with various 51 end points. A high number of concurrent sessions might cause 52 additional problems for an IPsec peer during SA re-establishment. 54 In order to avoid the need to re-run the key exchange protocol from 55 scratch it would be useful to provide an efficient way to resume an 56 IKE/IPsec session. This document proposes an extension to IKEv2 that 57 allows a client to re-establish an IKE SA with a gateway in a highly 58 efficient manner, utilizing a previously established IKE SA. 60 A client can reconnect to a gateway from which it was disconnected. 61 The proposed approach uses a IKEv2 state (or a reference into a state 62 store). to store state information that is later made available to 63 the IKEv2 responder for re-authentication. Restoring state 64 information by utilizing a ticket is one possible way. This document 65 does not specify the format of the ticket but recommendations are 66 provided. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 75 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8 76 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 9 77 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 10 78 4.2.3. Requesting a ticket during resumption . . . . . . . . 10 79 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 80 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 11 81 4.5. Processing Guidelines for IKE SA Establishment . . . . . . 11 82 5. Ticket Recommendations . . . . . . . . . . . . . . . . . . . . 12 83 5.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 12 84 5.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 13 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 13 88 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 14 89 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 90 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 14 91 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 14 92 7.6. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15 93 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 15 94 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 15 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 99 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 17 100 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 101 B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 104 B.4. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 B.5. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 B.6. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 110 Intellectual Property and Copyright Statements . . . . . . . . . . 21 112 1. Introduction 114 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 115 computational and communication overhead with respect to the number 116 of round-trips required and the cryptographic operations involved. 117 In particular the Extensible Authentication Protocol (EAP) is used 118 for authentication in remote access cases, which increases latency. 120 To re-establish security associations (SA) upon a failure recovery 121 condition is time-consuming, especially when an IPsec peer, such as a 122 VPN gateway, needs to re-establish a large number of SAs with various 123 end points. A high number of concurrent sessions might cause 124 additional problems for an IPsec responder. 126 In many failure cases it would be useful to provide an efficient way 127 to resume an interrupted IKE/IPsec session. This document proposes 128 an extension to IKEv2 that allows a client to re-establish an IKE SA 129 with a gateway in a highly efficient manner, utilizing a previously 130 established IKE SA. 132 A client can reconnect to a gateway from which it was disconnected. 133 One way to ensure that the IKEv2 responder is able to recreate the 134 state information is by maintaining IKEv2 state (or a reference into 135 a state store) in a "ticket", an opaque data structure. This ticket 136 is created by the server and forwarded to the client. The IKEv2 137 protocol is extended to allow a client to request and present a 138 ticket. 140 This approach is similar to the one taken by TLS session resumption 141 [RFC4507] with the required adaptations for IKEv2, e.g., to 142 accommodate the two-phase protocol structure. We have borrowed 143 heavily from that specification. 145 The proposed solution should additionally meet the following goals: 147 o Using only symmetric cryptography to minimize CPU consumption. 148 o Allowing a gateway to push state to clients. 149 o Providing cryptographic agility. 150 o Having no negative impact on IKEv2 security features. 152 The following are non-goals of this solution: 153 o Providing load balancing among gateways. 154 o Specifying how a client detects the need for a failover. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 This document uses terminology defined in [RFC4301], [RFC4306], and 163 [RFC4555]. In addition, this document uses the following terms: 165 Ticket: An IKEv2 ticket is a data structure that contains all the 166 necessary information that allows an IKEv2 responder to re- 167 establish an IKEv2 security association. 169 In this document we use the term ticket and thereby refer to an 170 opaque data structure that may either contain IKEv2 state as 171 described above or a reference pointing to such state. 173 3. Usage Scenario 175 This specification envisions two usage scenarios for efficient IKEv2 176 and IPsec SA session re-establishment. 178 The first is similar to the use case specified in Section 1.1.3 of 179 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 180 used to establish a secure channel between a remote access client and 181 a gateway; the traffic flow may be between the client and entities 182 beyond the gateway. 184 The second use case focuses on the usage of transport (or tunnel) 185 mode to secure the communicate between two end points (e.g., two 186 servers). The two endpoints have a client-server relationship with 187 respect to a protocol that runs using the protections afforded by the 188 IPsec SA. 190 (a) 192 +-+-+-+-+-+ +-+-+-+-+-+ 193 ! ! IKEv2/IKEv2-EAP ! ! Protected 194 ! Remote !<------------------------>! ! Subnet 195 ! Access ! ! Access !<--- and/or 196 ! Client !<------------------------>! Gateway ! Internet 197 ! ! IPsec tunnel ! ! 198 +-+-+-+-+-+ +-+-+-+-+-+ 200 (b) 202 +-+-+-+-+-+ +-+-+-+-+-+ 203 ! ! IKE_SESSION_RESUME ! ! 204 ! Remote !<------------------------>! ! 205 ! Access ! ! Access ! 206 ! Client !<------------------------>! Gateway ! 207 ! ! IPsec tunnel ! ! 208 +-+-+-+-+-+ +-+-+-+-+-+ 210 Figure 1: Resuming a Session with a Remote Access Gateway 212 In this scenario, an end-host (an entity with a host implementation 213 of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a 214 gateway in a remote network using IKEv2. The end-host in this 215 scenario is sometimes referred to as a remote access client. At a 216 later stage when a client needs to re-establish the IKEv2 session it 217 may choose to establish IPsec SAs using a full IKEv2 exchange or the 218 IKE_SESSION_RESUME exchange (shown in Figure 1). 220 In this scenario, the client needs to get an IP address from the 221 remote network so that traffic can be encapsulated by the remote 222 access gateway before reaching the client. In the initial exchange, 223 the gateway may acquire IP addresses from the address pool of a local 224 DHCP server. The session resumption exchange may need to support the 225 assignment of a new IP address. 227 The protocol defined in this document supports the re-allocation of 228 an IP address to the client, if this capability is provided by the 229 network. This capability is implicit in the use of the IKE 230 configuration mechanism, which allows the client to present its 231 existing IP address and receive the same address back, if allowed by 232 the gateway. 234 4. Protocol Details 236 This section provides protocol details and contains the normative 237 parts. This document defines two protocol exchanges, namely 238 requesting a ticket, see Section 4.1, and presenting a ticket, see 239 Section 4.2. 241 4.1. Requesting a Ticket 243 A client MAY request a ticket in the following exchanges: 245 o In an IKE_AUTH exchange, as shown in the example message exchange 246 in Figure 2 below. 247 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 248 o In an Informational exchange, if the gateway previously replied 249 with an N(TICKET_ACK) instead of providing a ticket. 250 o In an Informational exchange, when the ticket lifetime is about to 251 expire. 252 o In an IKE_SESSION_RESUME exchange, see Section 4.2.3. 254 Normally, a client requests a ticket in the third message of an IKEv2 255 exchange (the first of IKE_AUTH). Figure 2 shows the message 256 exchange for this typical case. 258 Initiator Responder 259 ----------- ----------- 260 HDR, SAi1, KEi, Ni --> 262 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 264 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 265 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 267 Figure 2: Example Message Exchange for Requesting a Ticket 269 The notification payloads are described in Section 4.3. The above is 270 an example, and IKEv2 allows a number of variants on these messages. 271 A complete description of IKEv2 can be found in [RFC4718]. 273 When an IKEv2 responder receives a request for a ticket using the 274 N(TICKET_REQUEST) payload it MUST perform one of the following 275 operations if it supports the extension defined in this document: 276 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 277 payload in a subsequent message towards the IKEv2 initiator. This 278 is shown in Figure 3. 280 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 281 ticket for some reason. 282 o it returns an N(TICKET_ACK), if it cannot grant a ticket 283 immediately, e.g., due to packet size limitations. In this case 284 the client MAY request a ticket later using an Informational 285 exchange, at any time during the lifetime of the IKE SA. 287 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 288 accept the requested ticket. The ticket may be used later with an 289 IKEv2 responder that supports this extension. Figure 3 shows how the 290 initiator receives the ticket. 292 Initiator Responder 293 ----------- ----------- 294 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 295 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 297 Figure 3: Receiving a Ticket 299 4.2. Presenting a Ticket 301 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange 302 even if it is in possession of a valid ticket. A client MUST NOT 303 present a ticket when it knows that the ticket's lifetime has 304 expired. 306 It is up to the client's local policy to decide when the 307 communication with the IKEv2 responder is seen as interrupted and a 308 new exchange needs to be initiated and the session resumption 309 procedure to be initiated. 311 Tickets are intended for one-time use: a client MUST NOT reuse a 312 ticket, either with the same or with a different gateway. A gateway 313 SHOULD reject a reused ticket. 315 This document specifies a new IKEv2 exchange type called 316 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 317 somewhat similar to the IKE_AUTH exchange, and results in the 318 creation of a Child SA. The client SHOULD NOT use this exchange type 319 unless it knows that the gateway supports it. 321 Initiator Responder 322 ----------- ----------- 323 HDR, Ni, N(TICKET_OPAQUE), [N+,] 324 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 326 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. 328 See Section 4.2.1 for details on computing the protected (SK) 329 payload. 331 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 332 payload it MUST perform one of the following steps if it supports the 333 extension defined in this document: 334 o If it is willing to accept the ticket, it responds as shown in 335 Figure 4. 336 o It responds with an unprotected N(TICKET_NACK) notification, if it 337 rejects the ticket for any reason. In that case, the initiator 338 should re-initiate a regular IKE exchange. One such case is when 339 the responder receives a ticket for an IKE SA that has previously 340 been terminated on the responder itself, which may indicate 341 inconsistent state between the IKEv2 initiator and the responder. 342 However, a responder is not required to maintain the state for 343 terminated sessions. 344 o When the responder receives a ticket for an IKE SA that is still 345 active and if the responder accepts it, then the old SAs SHOULD be 346 silently deleted without sending a DELETE informational exchange. 348 Initiator Responder 349 ----------- ----------- 350 <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 351 [CP(CFG_REPLY)]} 353 Figure 4: IKEv2 Responder accepts the ticket 355 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 357 The SK payload is protected using the cryptographic parameters 358 derived from the ticket, see Section 4.2.1 below. 360 At this point a new IKE SA is created by both parties, see 361 Section 4.5. This is followed by normal derivation of a child SA, 362 per Section 2.17 of [RFC4306]. 364 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 366 The two messages of this exchange are protected by a "subset" IKE SA. 367 The key material is derived from the ticket, as follows: 369 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 371 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 372 from the ticket. Ni guarantees freshness of the key material. SK_d2 373 is used later to derive the new IKE SA, see Section 4.5. 375 See [RFC4306] for the notation. "prf" is determined from the SA value 376 in the ticket. 378 4.2.2. Presenting a Ticket: The DoS Case 380 When receiving the first message of the IKE_SESSION_RESUME exchange, 381 the gateway may decide that it is under a denial-of-service attack. 382 In such a case, the gateway SHOULD defer the establishment of session 383 state until it has verified the identity of the client. We use a 384 variation of the IKEv2 Cookie mechanism, whereby the cookie is 385 protected. 387 In the two messages that follow, the gateway responds that it is 388 unwilling to resume the session until the client is verified, and the 389 client resubmits its first message, this time with the cookie: 391 Initiator Responder 392 ----------- ----------- 393 <-- HDR, SK{N(COOKIE)} 395 HDR, Ni, N(TICKET_OPAQUE), [N+,] 396 SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 398 Assuming the cookie is correct, the gateway now replies normally. 400 This now becomes a 4-message exchange. The entire exchange is 401 protected as defined in Section 4.2.1. 403 See Section 2.6 and Section 3.10.1 of [RFC4306] for more guidance 404 regarding the usage and syntax of the cookie. Note that the cookie 405 is completely independent of the IKEv2 ticket. 407 4.2.3. Requesting a ticket during resumption 409 When resuming a session, a client will typically request a new ticket 410 immediately, so it is able to resume the session again in the case of 411 a second failure. Therefore, the N(TICKET_REQUEST) and 412 N(TICKET_OPAQUE) notifications may be piggybacked as protected 413 payloads to the IKE_SESSION_RESUME exchange. 415 The returned ticket (if any) will correspond to the IKE SA created 416 per the rules described in Section 4.5. 418 4.3. IKE Notifications 420 This document defines a number of notifications. The notification 421 numbers are TBA by IANA. 423 +-------------------+--------+-----------------+ 424 | Notification Name | Number | Data | 425 +-------------------+--------+-----------------+ 426 | TICKET_OPAQUE | TBA1 | See Section 4.4 | 427 | TICKET_REQUEST | TBA2 | None | 428 | TICKET_ACK | TBA3 | None | 429 | TICKET_NACK | TBA4 | None | 430 +-------------------+--------+-----------------+ 432 4.4. TICKET_OPAQUE Notify Payload 434 The data for the TICKET_OPAQUE Notify payload consists of the Notify 435 message header, a lifetime field and the ticket itself. The four 436 octet lifetime field contains the number of seconds until the ticket 437 expires (encoded as an unsigned integer). 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 ! Next Payload !C! Reserved ! Payload Length ! 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 ! Lifetime ! 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 ! ! 449 ~ Ticket ~ 450 ! ! 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 5: TICKET_OPAQUE Notify Payload 455 4.5. Processing Guidelines for IKE SA Establishment 457 When a ticket is presented, the gateway parses the ticket to retrieve 458 the state of the old IKE SA, and the client retrieves this state from 459 its local store. Both peers now create state for the new IKE SA as 460 follows: 462 o The SA value (transforms etc.) is taken directly from the ticket. 463 o The sequence numbers are reset to 0. 464 o The IDi value is obtained from the ticket. 465 o The IDr value is obtained from the new exchange. The gateway MAY 466 make policy decisions based on the IDr value encoded in the 467 ticket. 468 o The SPI values are created anew, similarly to a regular IKE 469 exchange. SPI values from the ticket SHOULD NOT be reused. This 470 restriction is to avoid problems caused by collisions with other 471 SPI values used already by the initiator/responder. The SPI value 472 should only be reused if collision avoidance can be ensured 473 through other means. 475 The cryptographic material is refreshed based on the ticket and the 476 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 477 value is derived as follows: 479 SKEYSEED = prf(SK_d2, Ni | Nr) 481 where SK_d2 was computed earlier (Section 4.2.1). 483 The keys are derived as follows, unchanged from IKEv2: 485 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 486 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 488 where SPIi, SPIr are the SPI values created in the new IKE exchange. 490 See [RFC4306] for the notation. "prf" is determined from the SA value 491 in the ticket. 493 5. Ticket Recommendations 495 5.1. Ticket Content 497 As noted above, the ticket represents a partial IKEv2 state, either 498 by reference or by value. When passing the state by value, the 499 ticket MUST contain an integrity-protected reference to partial IKEv2 500 state, containing the state items described further in this section. 501 We note that such a ticket is analogous to the concept of 'stub', as 502 defined in [I-D.xu-ike-sa-sync], or the concept of a Session ID from 503 TLS. 505 When the state is passed by value, the ticket MUST encode at least 506 the following state from an IKE SA. These values MUST be encrypted 507 and authenticated. 509 o IDi, IDr. 510 o SPIi, SPIr. 511 o SAr (the accepted proposal). 512 o SK_d. 514 In addition, the ticket MUST encode a protected ticket expiration 515 value. 517 The ticket MUST include a key identity field, so that encryption and 518 authentication can be changed, and when necessary, algorithms can be 519 replaced. 521 5.2. Ticket Identity and Lifecycle 523 Each ticket is associated with a single IKE SA. In particular, when 524 an IKE SA is deleted, the client MUST delete its stored ticket. A 525 ticket is therefore associated with the tuple (IDi, IDr). 527 The lifetime of the ticket carried in the N(TICKET_OPAQUE) 528 notification SHOULD be the minimum of the IKE SA lifetime (per the 529 gateway's local policy) and its re-authentication time, according to 530 [RFC4478]. Even if neither of these are enforced by the gateway, a 531 finite lifetime MUST be specified for the ticket. 533 6. IANA Considerations 535 This document requires a number of IKEv2 notification status types in 536 Section 4.3, to be registered by IANA. The corresponding registry 537 was established by IANA. 539 The document defines a new IKEv2 exchange in Section 4.2. The 540 corresponding registry was established by IANA. 542 7. Security Considerations 544 This section addresses security issues related to the usage of a 545 ticket. The text below assumes that the IKE state is contained 546 explicitly in the ticket ("passed by value"). In most cases, there 547 are similar risks when the state is passed by reference. 549 7.1. Stolen Tickets 551 An eavesdropper or man-in-the-middle may try to obtain a ticket and 552 use it to establish a session with the IKEv2 responder. This can 553 happen in different ways: by eavesdropping on the initial 554 communication and copying the ticket when it is granted and before it 555 is used, or by listening in on a client's use of the ticket to resume 556 a session. However, since the ticket's contents is encrypted and the 557 attacker does not know the corresponding secret key, a stolen ticket 558 cannot be used by an attacker to succesfully resume a session. An 559 IKEv2 responder MUST use strong encryption and integrity protection 560 of the ticket to prevent an attacker from obtaining the ticket's 561 contents, e.g., by using a brute force attack. 563 7.2. Forged Tickets 565 A malicious user could forge or alter a ticket in order to resume a 566 session, to extend its lifetime, to impersonate as another user, or 567 to gain additional privileges. This attack is not possible if the 568 ticket is protected using a strong integrity protection algorithm. 570 7.3. Denial of Service Attacks 572 An adversary could generate and send a large number of tickets to a 573 gateway for verification. To minimize the possibility of such denial 574 of service, ticket verification should be lightweight (e.g., using 575 efficient symmetric key cryptographic algorithms). 577 7.4. Ticket Protection Key Management 579 A full description of the management of the keys used to protect the 580 ticket is beyond the scope of this document. A list of RECOMMENDED 581 practices is given below. 582 o The keys should be generated securely following the randomness 583 recommendations in [RFC4086]. 584 o The keys and cryptographic protection algorithms should be at 585 least 128 bits in strength. 586 o The keys should not be used for any other purpose than generating 587 and verifying tickets. 588 o The keys should be changed regularly. 589 o The keys should be changed if the ticket format or cryptographic 590 protection algorithms change. 592 7.5. Ticket Lifetime 594 An IKEv2 responder controls the lifetime of a ticket, based on the 595 operational and security requirements of the environment in which it 596 is deployed. The responder provides information about the ticket 597 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 599 7.6. Ticket Format 601 Great care must be taken when defining a ticket format such that the 602 requirements outlined in Section 5.1 are met. In particular, if 603 confidential information, such as a secret key, is transferred to the 604 client, it MUST be done using secure communication to prevent 605 attackers from obtaining or modifying the key. Also, the ticket MUST 606 have its integrity and confidentiality protected with strong 607 cryptographic techniques to prevent a breach in the security of the 608 system. 610 7.7. Identity Privacy, Anonymity, and Unlinkability 612 Since opaque state information is passed around between the IKEv2 613 initiator and the IKEv2 responder it is important that leakage of 614 information, such as the identities of an IKEv2 initiator and a 615 responder, MUST be avoided (e.g., with the help of encryption. Thus, 616 it prevents the disclosure of potentially sensitive information. 618 When an IKEv2 initiator presents a ticket as part of the 619 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 620 exchange. There is thereby the possibility for an on-path adversary 621 to observe multiple exchange handshakes where the same state 622 information is used and therefore to conclude that they belong to the 623 same communication end points. 625 This document therefore envisions that the ticket is presented to the 626 IKEv2 responder only once; multiple usage of the ticket is not 627 provided. 629 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange 631 A major design goal of this protocol extension has been the two- 632 message exchange for session resumption. There is a tradeoff between 633 this abbreviated exchange and replay protection. It is RECOMMENDED 634 that an IKEv2 responder should cache tickets, and reject replayed 635 ones. However, some gateways may not do that in order to reduce 636 state size. An adversary may attempt to replay a ticket. To 637 mitigate these risks a client may be required by the gateway to show 638 that it knows the ticket's secret, before any state is committed on 639 the gateway side. Note that this is a stronger guarantee than the 640 regular IKE cookie mechanism, which only shows IP return routability 641 of the client. This is enabled by including the cookie in the 642 protected portion of the message. 644 For performance reasons, the cookie mechanism is optional, and 645 invoked by the gateway only when it suspects that it is the subject 646 of a denial-of-service attack. 648 In any case, a ticket replayed by an adversary only causes partial 649 IKE state to be created on the gateway. The IKE exchange cannot be 650 completed and an IKE SA cannot be created unless the client knows the 651 ticket's secret values. 653 8. Acknowledgements 655 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 656 Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ 657 Housely, Yoav Nir and Tero Kivinen for their comments. We would to 658 particularly thank Florian Tegeler and Stjepan Gros for their help 659 with their implementation efforts and Florian Tegeler for his formal 660 verification using the CASPER tool set. 662 We would furthermore like to thank the authors of 663 [I-D.xu-ike-sa-sync] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke 664 Xu) for their input on the stub concept. 666 9. References 668 9.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 674 RFC 4306, December 2005. 676 9.2. Informative References 678 [I-D.rescorla-stateless-tokens] 679 Rescorla, E., "How to Implement Secure (Mostly) Stateless 680 Tokens", draft-rescorla-stateless-tokens-01 (work in 681 progress), March 2007. 683 [I-D.xu-ike-sa-sync] 684 Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA 685 Synchronization for session resumption", 686 draft-xu-ike-sa-sync-01 (work in progress), October 2008. 688 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 689 Requirements for Security", BCP 106, RFC 4086, June 2005. 691 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 692 Internet Protocol", RFC 4301, December 2005. 694 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 695 (IKEv2) Protocol", RFC 4478, April 2006. 697 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 698 "Transport Layer Security (TLS) Session Resumption without 699 Server-Side State", RFC 4507, May 2006. 701 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 702 (MOBIKE)", RFC 4555, June 2006. 704 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 705 Implementation Guidelines", RFC 4718, October 2006. 707 Appendix A. Ticket Format 709 This document does not specify a mandatory-to-implement or a 710 mandatory-to-use ticket format. The following format is RECOMMENDED. 712 struct { 713 [authenticated] struct { 714 octet format_version; // 1 for this version of the protocol 715 octet reserved[3]; // sent as 0, ignored by receiver. 716 octet key_id[8]; // arbitrary byte string 717 opaque IV[0..255]; // actual length (possibly 0) depends 718 // on the encryption algorithm 720 [encrypted] struct { 721 opaque IDi, IDr; // the full payloads 722 octet SPIi[8], SPIr[8]; 723 opaque SA; // the full SAr payload 724 octet SK_d[0..255]; // actual length depends on SA value 725 int32 expiration; // an absolute time value, seconds 726 // since Jan. 1, 1970 727 } ikev2_state; 728 } protected_part; 729 opaque MAC[0..255]; // the length (possibly 0) depends 730 // on the integrity algorithm 731 } ticket; 733 Note that the key defined by "key_id" determines the encryption and 734 authentication algorithms used for this ticket. Those algorithms are 735 unrelated to the transforms defined by the SA payload. 737 The reader is referred to a recent draft 738 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 739 identical) ticket format, and discusses related security 740 considerations in depth. 742 For implementations that prefer to pass a reference to IKE state in 743 the ticket, rather than the state itself, we RECOMMEND the following 744 format: 746 struct { 747 [authenticated] struct { 748 octet format_version; // 1 for this version of the protocol 749 octet reserved[3]; // sent as 0, ignored by receiver. 750 octet key_id[8]; // arbitrary byte string 752 struct { 753 opaque state_ref; // reference to IKE state 754 int32 expiration; // an absolute time value, seconds 755 // since Jan. 1, 1970 756 } ikev2_state_ref; 757 } protected_part; 758 opaque MAC[0..255]; // the length depends 759 // on the integrity algorithm 760 } ticket; 762 Appendix B. Change Log 764 B.1. -00 766 Resubmitted document as a WG item. 768 B.2. -01 770 Added reference to [I-D.xu-ike-sa-sync] 772 Included recommended ticket format into the appendix 774 Various editorial improvements within the document 776 B.3. -00 778 Issued a -00 version for the IPSECME working group. Reflected 779 discussions at IETF#72 regarding the strict focus on session 780 resumption. Consequently, text about failover was removed. 782 B.4. -04 784 Editorial fixes; references cleaned up; updated author's contact 785 address 787 B.5. -03 789 Removed counter mechanism. Added an optional anti-DoS mechanism, 790 based on IKEv2 cookies (removed previous discussion of cookies). 791 Clarified that gateways may support reallocation of same IP address, 792 if provided by network. Proposed a solution outline to the problem 793 of key exchange for the keys that protect tickets. Added fields to 794 the ticket to enable interoperability. Removed incorrect MOBIKE 795 notification. 797 B.6. -02 799 Clarifications on generation of SPI values, on the ticket's lifetime 800 and on the integrity protection of the anti-replay counter. 801 Eliminated redundant SPIs from the notification payloads. 803 B.7. -01 805 Editorial review. Removed 24-hour limitation on ticket lifetime, 806 lifetime is up to local policy. 808 B.8. -00 810 Initial version. This draft is a selective merge of 811 draft-sheffer-ike-session-resumption-00 and 812 draft-dondeti-ipsec-failover-sol-00. 814 Authors' Addresses 816 Yaron Sheffer 817 Check Point Software Technologies Ltd. 818 5 Hasolelim St. 819 Tel Aviv 67897 820 Israel 822 Email: yaronf@checkpoint.com 823 Hannes Tschofenig 824 Nokia Siemens Networks 825 Linnoitustie 6 826 Espoo 02600 827 Finland 829 Phone: +358 (50) 4871445 830 Email: Hannes.Tschofenig@gmx.net 831 URI: http://www.tschofenig.priv.at 833 Lakshminath Dondeti 834 QUALCOMM, Inc. 835 5775 Morehouse Dr 836 San Diego, CA 837 USA 839 Phone: +1 858-845-1267 840 Email: ldondeti@qualcomm.com 842 Vidya Narayanan 843 QUALCOMM, Inc. 844 5775 Morehouse Dr 845 San Diego, CA 846 USA 848 Phone: +1 858-845-2483 849 Email: vidyan@qualcomm.com 851 Full Copyright Statement 853 Copyright (C) The IETF Trust (2008). 855 This document is subject to the rights, licenses and restrictions 856 contained in BCP 78, and except as set forth therein, the authors 857 retain all their rights. 859 This document and the information contained herein are provided on an 860 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 861 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 862 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 863 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 864 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 865 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 867 Intellectual Property 869 The IETF takes no position regarding the validity or scope of any 870 Intellectual Property Rights or other rights that might be claimed to 871 pertain to the implementation or use of the technology described in 872 this document or the extent to which any license under such rights 873 might or might not be available; nor does it represent that it has 874 made any independent effort to identify any such rights. Information 875 on the procedures with respect to rights in RFC documents can be 876 found in BCP 78 and BCP 79. 878 Copies of IPR disclosures made to the IETF Secretariat and any 879 assurances of licenses to be made available, or the result of an 880 attempt made to obtain a general license or permission for the use of 881 such proprietary rights by implementers or users of this 882 specification can be obtained from the IETF on-line IPR repository at 883 http://www.ietf.org/ipr. 885 The IETF invites any interested party to bring to its attention any 886 copyrights, patents or patent applications, or other proprietary 887 rights that may cover technology that may be required to implement 888 this standard. Please address the information to the IETF at 889 ietf-ipr@ietf.org.