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