idnits 2.17.1 draft-sheffer-ipsec-failover-03.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 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. 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 (March 19, 2008) is 5881 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 373, but not defined == Missing Reference: 'TSi' is mentioned on line 467, but not defined == Missing Reference: 'TSr' is mentioned on line 467, but not defined -- Looks like a reference, but probably isn't: '3' on line 693 -- Looks like a reference, but probably isn't: '8' on line 700 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- 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 (==), 12 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: Experimental H. Tschofenig 5 Expires: September 20, 2008 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 March 19, 2008 11 IPsec Gateway Failover Protocol 12 draft-sheffer-ipsec-failover-03.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 September 20, 2008. 39 Abstract 41 The Internet Key Exchange version 2 (IKEv2) protocol has 42 computational and communication overhead with respect to the number 43 of round-trips required and cryptographic operations involved. In 44 remote access situations, the Extensible Authentication Protocol is 45 used for authentication, which adds several more round trips and 46 therefore 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 many failure cases it would be useful to provide an efficient way 55 to resume an interrupted IKE/IPsec session. This document proposes 56 an extension to IKEv2 that allows a client to re-establish an IKE SA 57 with a gateway in a highly efficient manner, utilizing a previously 58 established IKE SA. 60 A client can reconnect to a gateway from which it was disconnected, 61 or alternatively migrate to another gateway that is associated with 62 the previous one. The proposed approach conveys IKEv2 state 63 information, in the form of an encrypted ticket, to a VPN client that 64 is later presented to the VPN gateway for re-authentication. The 65 encrypted ticket can only be decrypted by the VPN gateway in order to 66 restore state for faster session setup. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6 76 3.2. Recovering from an Application Server Failover . . . . . . 8 77 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9 79 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 80 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12 81 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 12 82 4.2.3. Requesting a ticket during resumption . . . . . . . . 13 83 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13 84 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14 85 4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14 86 4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15 87 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16 89 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17 90 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 91 5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18 95 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 96 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19 97 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19 98 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19 99 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20 100 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20 101 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 106 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22 107 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 108 B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 111 B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 113 Intellectual Property and Copyright Statements . . . . . . . . . . 25 115 1. Introduction 117 The Internet Key Exchange version 2 (IKEv2) protocol has 118 computational and communication overhead with respect to the number 119 of round-trips required and cryptographic operations involved. In 120 particular the Extensible Authentication Protocol is used for 121 authentication in remote access cases, which increases latency. 123 To re-establish security associations (SA) upon a failure recovery 124 condition is time-consuming, especially when an IPsec peer, such as a 125 VPN gateway, needs to re-establish a large number of SAs with various 126 end points. A high number of concurrent sessions might cause 127 additional problems for an IPsec peer. 129 In many failure cases it would be useful to provide an efficient way 130 to resume an interrupted IKE/IPsec session. This document proposes 131 an extension to IKEv2 that allows a client to re-establish an IKE SA 132 with a gateway in a highly efficient manner, utilizing a previously 133 established IKE SA. 135 A client can reconnect to a gateway from which it was disconnected, 136 or alternatively migrate to another gateway that is associated with 137 the previous one. This document proposes to maintain IKEv2 state in 138 a "ticket", an opaque data structure created and used by a server and 139 stored by a client, which the client cannot understand or tamper 140 with. The IKEv2 protocol is extended to allow a client to request 141 and present a ticket. When two gateways mutually trust each other, 142 one can accept a ticket generated by the other. 144 This approach is similar to the one taken by TLS session resumption 145 [RFC4507] with the required adaptations for IKEv2, e.g., to 146 accommodate the two-phase protocol structure. We have borrowed 147 heavily from that specification. 149 1.1. Goals 151 The high-level goal of this extension is to provide an IPsec failover 152 solution, according to the requirements defined in 153 [I-D.vidya-ipsec-failover-ps]. 155 Specifically, the proposed extension should allow IPsec sessions to 156 be recovered from failures in remote access scenarios, in a more 157 efficient manner than the basic IKE solution. This efficiency is 158 primarily on the gateway side, since the gateway might have to deal 159 with many thousands of concurrent requests. We should enable the 160 following cases: 162 o Failover from one gateway to another, where the two gateways do 163 not share state but do have mutual trust. For example, the 164 gateways may be operated by the same provider and share the same 165 keying materials to access an encrypted ticket. 166 o Recovery from an intermittent connectivity, where clients 167 reconnect into the same gateway. In this case, the gateway would 168 typically have detected the clients' absence and removed the state 169 associated with them. 170 o Recovery from a gateway restart, where clients reconnect into the 171 same gateway. 173 The proposed solution should additionally meet the following goals: 175 o Using only symmetric cryptography to minimize CPU consumption. 176 o Allowing a gateway to push state to clients. 177 o Providing cryptographic agility. 178 o Having no negative impact on IKEv2 security features. 180 1.2. Non-Goals 182 The following are non-goals of this solution: 183 o Providing load balancing among gateways. 184 o Specifying how a client detects the need for a failover. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 This document uses terminology defined in [RFC4301], [RFC4306], and 193 [RFC4555]. In addition, this document uses the following terms: 195 Secure domain: A secure domain comprises a set of gateways that are 196 able to resume an IKEv2 session that may have been established by 197 any other gateway within the domain. All gateways in the secure 198 domain are expected to share some secrets, so that they can 199 generate an IKEv2 ticket, verify the validity of the ticket and 200 extract the IKEv2 policy and session key material from the ticket. 201 IKEv2 ticket: An IKEv2 ticket is a data structure that contains all 202 the necessary information that allows any gateway within the same 203 secure domain as the gateway that created the ticket to verify the 204 validity of the ticket and extract IKEv2 policy and session keys 205 to re-establish an IKEv2 session. 207 Stateless failover: When the IKEv2 session state is stored at the 208 client, the IKEv2 responder is "stateless" until the client 209 restores the SA with one of the gateways within the secure domain; 210 thus, we refer to SA resumption with SA storage at the client as 211 stateless session resumption. 212 Stateful failover: When the infrastructure maintains IKEv2 session 213 state, we refer to the process of IKEv2 SA re-establishment as 214 stateful session resumption. 216 3. Usage Scenarios 218 This specification envisions two usage scenarios for efficient IKEv2 219 and IPsec SA session re-establishment. 221 The first is similar to the use case specified in Section 1.1.3 of 222 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 223 used to establish a secure channel between a remote access client and 224 a gateway; the traffic flow may be between the client and entities 225 beyond the gateway. 227 The second use case focuses on the usage of transport (or tunnel) 228 mode to secure the communicate between two end points (e.g., two 229 servers). The two endpoints have a client-server relationship with 230 respect to a protocol that runs using the protections afforded by the 231 IPsec SA. 233 3.1. Recovering from a Remote Access Gateway Failover 234 (a) 236 +-+-+-+-+-+ +-+-+-+-+-+ 237 ! ! IKEv2/IKEv2-EAP ! ! Protected 238 ! Remote !<------------------------>! Remote ! Subnet 239 ! Access ! ! Access !<--- and/or 240 ! Client !<------------------------>! Gateway ! Internet 241 ! ! IPsec tunnel ! ! 242 +-+-+-+-+-+ +-+-+-+-+-+ 244 (b) 246 +-+-+-+-+-+ +-+-+-+-+-+ 247 ! ! IKE_SESSION_RESUME ! ! 248 ! Remote !<------------------------>! New/Old ! 249 ! Access ! ! Gateway ! 250 ! Client !<------------------------>! ! 251 ! ! IPsec tunnel ! ! 252 +-+-+-+-+-+ +-+-+-+-+-+ 254 Figure 1: Remote Access Gateway Failure 256 In this scenario, an end-host (an entity with a host implementation 257 of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a 258 gateway in a remote network using IKEv2. The end-host in this 259 scenario is sometimes referred to as a remote access client. When 260 the remote gateway fails, all the clients associated with the gateway 261 either need to re-establish IKEv2 sessions with another gateway 262 within the same secure domain of the original gateway, or with the 263 original gateway if the server is back online soon. 265 The clients may choose to establish IPsec SAs using a full IKEv2 266 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). 268 In this scenario, the client needs to get an IP address from the 269 remote network so that traffic can be encapsulated by the remote 270 access gateway before reaching the client. In the initial exchange, 271 the gateway may acquire IP addresses from the address pool of a local 272 DHCP server. The new gateway that a client gets associated may not 273 receive addresses from the same address pool. Thus, the session 274 resumption protocol needs to support the assignment of a new IP 275 address. 277 The protocol defined in this document supports the re-allocation of 278 an IP address to the client, if this capability is provided by the 279 network. For example, if routing tables are modified so that traffic 280 is rerouted through the new gateway. This capability is implicit in 281 the use of the IKE Config mechanism, which allows the client to 282 present its existing IP address and receive the same address back, if 283 allowed by the gateway. 285 The protocol defined here supports both stateful and stateless 286 scenarios. In other words, tickets can be stored wholly on the 287 client, or the ticket can be stored on the gateway (or in a database 288 shared between multiple gateways), with the client only presenting a 289 handle that identifies a particular ticket. In fact these scenarios 290 are transparent to the protocols, with the only change being the non- 291 mandatory ticket format. 293 3.2. Recovering from an Application Server Failover 295 (a) 297 +-+-+-+-+-+ +-+-+-+-+-+ 298 ! App. ! IKEv2/IKEv2-EAP ! App. ! 299 ! Client !<------------------------>! Server ! 300 ! & ! ! & ! 301 ! IPsec !<------------------------>! IPsec ! 302 ! host ! IPsec transport/ ! host ! 303 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 305 (b) 307 +-+-+-+-+-+ +-+-+-+-+-+ 308 ! App. ! IKE_SESSION_RESUME ! New ! 309 ! Client !<------------------------>! Server ! 310 ! & ! ! & ! 311 ! IPsec !<------------------------>! IPsec ! 312 ! host ! IPsec transport/ ! host ! 313 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 315 Figure 2: Application Server Failover 317 The second usage scenario is as follows: two entities with IPsec host 318 implementations establish an IPsec transport or tunnel mode SA 319 between themselves; this is similar to the model described in Section 320 1.1.2. of [RFC4306]. At the application level, one of the entities 321 is always the client and the other is a server. From that view 322 point, the IKEv2 exchange is always initiated by the client. This 323 allows the Initiator (the client) to authenticate itself using EAP, 324 as long as the Responder (or the application server) allows it. 326 If the application server fails, the client may find other servers 327 within the same secure domain for service continuity. It may use a 328 full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- 329 establish the IPsec SAs for secure communication required by the 330 application layer signaling. 332 The client-server relationship at the application layer ensures that 333 one of the entities in this usage scenario is unambiguously always 334 the Initiator and the other the Responder. This role determination 335 also allows the Initiator to request an address in the Responder's 336 network using the Configuration Payload mechanism of the IKEv2 337 protocol. If the client has thus received an address during the 338 initial IKEv2 exchange, when it associates with a new server upon 339 failure of the original server, it needs to request an address, 340 specifying its assigned address. The server may allow the client to 341 use the original address or if it is not permitted to use that 342 address, assign a new address. 344 4. Protocol Details 346 This section provides protocol details and contains the normative 347 parts. This document defines two protocol exchanges, namely 348 requesting a ticket and presenting a ticket. Section 4.1 describes 349 the procedure to request a ticket and Section 4.2 illustrates how to 350 present a ticket. 352 4.1. Requesting a Ticket 354 A client MAY request a ticket in the following exchanges: 356 o In an IKE_AUTH exchange, as shown in the example message exchange 357 in Figure 3 below. 358 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 359 o In an Informational exchange, if the gateway previously replied 360 with an N(TICKET_ACK) instead of providing a ticket. 361 o In an Informational exchange, when the ticket lifetime is about to 362 expire. 363 o In an IKE_SESSION_RESUME exchange, see Section 4.2.3. 365 Normally, a client requests a ticket in the third message of an IKEv2 366 exchange (the first of IKE_AUTH). Figure 3 shows the message 367 exchange for this typical case. 369 Initiator Responder 370 ----------- ----------- 371 HDR, SAi1, KEi, Ni --> 373 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 375 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 376 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 378 Figure 3: Example Message Exchange for Requesting a Ticket 380 The notification payloads are described in Section 4.3. The above is 381 an example, and IKEv2 allows a number of variants on these messages. 382 A complete description of IKEv2 can be found in [RFC4718]. 384 When an IKEv2 responder receives a request for a ticket using the 385 N(TICKET_REQUEST) payload it MUST perform one of the following 386 operations if it supports the extension defined in this document: 387 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 388 payload in a subsequent message towards the IKEv2 initiator. This 389 is shown in Figure 4. 390 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 391 ticket for some reason. 392 o it returns an N(TICKET_ACK), if it cannot grant a ticket 393 immediately, e.g., due to packet size limitations. In this case 394 the client MAY request a ticket later using an Informational 395 exchange, at any time during the lifetime of the IKE SA. 397 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 398 accept the requested ticket. The ticket may be used later with an 399 IKEv2 responder which supports this extension. Figure 4 shows how 400 the initiator receives the ticket. 402 Initiator Responder 403 ----------- ----------- 404 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 405 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 407 Figure 4: Receiving a Ticket 409 4.2. Presenting a Ticket 411 Following a communication failure, a client re-initiates an IKE 412 exchange to the same gateway or to a different one, and includes a 413 ticket in the first message. A client MAY initiate a regular (non- 414 ticket-based) IKEv2 exchange even if it is in possession of a valid 415 ticket. A client MUST NOT present a ticket after the ticket's 416 lifetime has expired. 418 It is up to the client's local policy to decide when the 419 communication with the IKEv2 responder is seen as interrupted and a 420 new exchange needs to be initiated and the session resumption 421 procedure to be initiated. 423 Tickets are intended for one-time use: a client MUST NOT reuse a 424 ticket, either with the same or with a different gateway. A gateway 425 SHOULD reject a reused ticket. Note however that a gateway can elect 426 not to retain a list of already-used tickets. Potential replay 427 attacks on such gateways are mitigated by the cookie mechanism 428 described in Section 4.2.2. 430 This document specifies a new IKEv2 exchange type called 431 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 432 somewhat similar to the IKE_AUTH exchange, and results in the 433 creation of a Child SA. The client SHOULD NOT use this exchange type 434 unless it knows that the gateway supports it, either through 435 configuration, by out-of-band means or by using the Gateway List 436 provision. 438 Initiator Responder 439 ----------- ----------- 440 HDR, Ni, N(TICKET_OPAQUE), [N+,] 441 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 443 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. 445 See Section 4.2.1 for details on computing the protected (SK) 446 payload. 448 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 449 payload it MUST perform one of the following steps if it supports the 450 extension defined in this document: 451 o If it is willing to accept the ticket, it responds as shown in 452 Figure 5. 453 o It responds with an unprotected N(TICKET_NACK) notification, if it 454 rejects the ticket for any reason. In that case, the initiator 455 should re-initiate a regular IKE exchange. One such case is when 456 the responder receives a ticket for an IKE SA that has previously 457 been terminated on the responder itself, which may indicate 458 inconsistent state between the IKEv2 initiator and the responder. 459 However, a responder is not required to maintain the state for 460 terminated sessions. 461 o When the responder receives a ticket for an IKE SA that is still 462 active and if the responder accepts it, then the old SAs SHOULD be 463 silently deleted without sending a DELETE informational exchange. 465 Initiator Responder 466 ----------- ----------- 467 <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 468 [CP(CFG_REPLY)]} 470 Figure 5: IKEv2 Responder accepts the ticket 472 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 474 The SK payload is protected using the cryptographic parameters 475 derived from the ticket, see Section 4.2.1 below. 477 At this point a new IKE SA is created by both parties, see 478 Section 4.6. This is followed by normal derivation of a child SA, 479 per Sec. 2.17 of [RFC4306]. 481 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 483 The two messages of this exchange are protected by a "subset" IKE SA. 484 The key material is derived from the ticket, as follows: 486 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 488 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 489 from the ticket. Ni guarantees freshness of the key material. SK_d2 490 is used later to derive the new IKE SA, see Section 4.6. 492 See [RFC4306] for the notation. "prf" is determined from the SA value 493 in the ticket. 495 4.2.2. Presenting a Ticket: The DoS Case 497 When receiving the first message of the IKE_SESSION_RESUME exchange, 498 the gateway may decide that it is under a denial-of-service attack. 499 In such a case, the gateway SHOULD defer the establishment of session 500 state until it has verified the identity of the client. We use a 501 variation of the IKEv2 Cookie mechanism, where the cookie is 502 protected. 504 In the two messages that follow, the gateway responds that it is 505 unwilling to resume the session until the client is verified, and the 506 client resubmits its first message, this time with the cookie: 508 Initiator Responder 509 ----------- ----------- 510 <-- HDR, SK{N(COOKIE)} 511 HDR, Ni, N(TICKET_OPAQUE), [N+,] 512 SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> 514 Assuming the cookie is correct, the gateway now replies normally. 516 This now becomes a 4-message exchange. The entire exchange is 517 protected as defined in Section 4.2.1. 519 See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding 520 the usage and syntax of the cookie. Note that the cookie is 521 completely independent of the IKEv2 ticket. 523 4.2.3. Requesting a ticket during resumption 525 When resuming a session, a client will typically request a new ticket 526 immediately, so it is able to resume the session again in the case of 527 a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) 528 and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as 529 protected payloads to the IKE_SESSION_RESUME exchange. 531 The returned ticket (if any) will correspond to the IKE SA created 532 per the rules described in Section 4.6. 534 4.3. IKE Notifications 536 This document defines a number of notifications. The notification 537 numbers are TBA by IANA. 539 +---------------------+--------+-----------------+ 540 | Notification Name | Number | Data | 541 +---------------------+--------+-----------------+ 542 | TICKET_OPAQUE | TBA1 | See Section 4.4 | 543 | TICKET_REQUEST | TBA2 | None | 544 | TICKET_ACK | TBA3 | None | 545 | TICKET_NACK | TBA4 | None | 546 | TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 | 547 +---------------------+--------+-----------------+ 549 4.4. TICKET_OPAQUE Notify Payload 551 The data for the TICKET_OPAQUE Notify payload consists of the Notify 552 message header, a lifetime field and the ticket itself. The four 553 octet lifetime field contains the number of seconds until the ticket 554 expires as an unsigned integer. Section 5.2 describes a possible 555 ticket format, and Section 5.3 offers further guidelines regarding 556 the ticket's lifetime. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 ! Next Payload !C! Reserved ! Payload Length ! 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 ! Lifetime ! 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 ! ! 568 ~ Ticket ~ 569 ! ! 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 6: TICKET_OPAQUE Notify Payload 574 4.5. TICKET_GATEWAY_LIST Notify Payload 576 The TICKET_GATEWAY_LIST Notify payload contains the Notify payload 577 header followed by a sequence of one or more gateway identifiers, 578 each of the format depicted in Figure 8. 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 ! Next Payload !C! Reserved ! Payload Length ! 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 ! ! 588 ~ Gateway Identifier List ~ 589 ! ! 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 7: TICKET_GATEWAY_LIST Notify Payload 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 ! ID Type ! Reserved ! Length ! 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 ! ! 600 ~ Identification Data ~ 601 ! ! 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 8: Gateway Identifier for One Gateway 606 ID Type: 608 The ID Type contains a restricted set of the IKEv2 ID payloads 609 (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR, 610 ID_IPV6_ADDR, ID_FQDN and the various reserved values. 612 Reserved: 614 This field must be sent as 0 and must be ignored when received. 616 Length: 618 The length field indicates the total size of the Identification 619 data. 621 Identification Data: 623 The Identification Data field is of variable length and depends on 624 the ID type. The length is not necessarily a multiple of 4. 626 4.6. Processing Guidelines for IKE SA Establishment 628 When a ticket is presented, the gateway parses the ticket to retrieve 629 the state of the old IKE SA, and the client retrieves this state from 630 its local store. Both peers now create state for the new IKE SA as 631 follows: 633 o The SA value (transforms etc.) is taken directly from the ticket. 634 o The sequence numbers are reset to 0. 635 o The IDi value is obtained from the ticket. 636 o The IDr value is obtained from the new exchange. The gateway MAY 637 make policy decisions based on the IDr value encoded in the 638 ticket. 640 o The SPI values are created anew, similarly to a regular IKE 641 exchange. SPI values from the ticket SHOULD NOT be reused. This 642 restriction is to avoid problems caused by collisions with other 643 SPI values used already by the initiator/responder. The SPI value 644 should only be reused if collision avoidance can be ensured 645 through other means. 647 The cryptographic material is refreshed based on the ticket and the 648 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 649 value is derived as follows: 651 SKEYSEED = prf(SK_d2, Ni | Nr) 653 where SK_d2 was computed earlier (Section 4.2.1). 655 The keys are derived as follows, unchanged from IKEv2: 657 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 658 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 660 where SPIi, SPIr are the SPI values created in the new IKE exchange. 662 See [RFC4306] for the notation. "prf" is determined from the SA value 663 in the ticket. 665 5. The IKE Ticket 667 This section lists the required contents of the ticket, and 668 recommends a non-normative format. This is followed by a discussion 669 of the ticket's lifecycle. 671 5.1. Ticket Contents 673 The ticket MUST encode at least the following state from an IKE SA. 674 These values MUST be encrypted and authenticated. 676 o IDi, IDr. 677 o SPIi, SPIr. 678 o SAr (the accepted proposal). 679 o SK_d. 681 In addition, the ticket MUST encode a protected ticket expiration 682 value. 684 5.2. Ticket Format 686 This document does not specify a mandatory-to-implement or a 687 mandatory-to-use ticket format. The following format is RECOMMENDED, 688 if interoperability between gateways is desired. 690 struct { 691 [authenticated] struct { 692 octet format_version; // 1 for this version of the protocol 693 octet reserved[3]; // sent as 0, ignored by receiver. 694 octet key_id[8]; // arbitrary byte string 695 opaque IV[0..255]; // actual length (possibly 0) depends 696 // on the encryption algorithm 698 [encrypted] struct { 699 opaque IDi, IDr; // the full payloads 700 octet SPIi[8], SPIr[8]; 701 opaque SA; // the full SAr payload 702 octet SK_d[0..255]; // actual length depends on SA value 703 int32 expiration; // an absolute time value, seconds 704 // since Jan. 1, 1970 705 } ikev2_state; 706 } protected_part; 707 opaque MAC[0..255]; // the length (possibly 0) depends 708 // on the integrity algorithm 709 } ticket; 711 Note that the key defined by "key_id" determines the encryption and 712 authentication algorithms used for this ticket. Those algorithms are 713 unrelated to the transforms defined by the SA payload. 715 The reader is referred to a recent draft 716 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 717 identical) ticket format, and discusses related security 718 considerations in depth. 720 5.3. Ticket Identity and Lifecycle 722 Each ticket is associated with a single IKE SA. In particular, when 723 an IKE SA is deleted, the client MUST delete its stored ticket. 725 A ticket is therefore associated with the tuple (IDi, IDr). The 726 client MAY however use a ticket to approach other gateways that are 727 willing to accept it. How a client discovers such gateways is 728 outside the scope of this document. 730 The lifetime of the ticket carried in the N(TICKET_OPAQUE) 731 notification should be the minimum of the IKE SA lifetime (per the 732 gateway's local policy) and its re-authentication time, according to 733 [RFC4478]. Even if neither of these are enforced by the gateway, a 734 finite lifetime MUST be specified for the ticket. 736 5.4. Exchange of Ticket-Protecting Keys 738 This document does not define an interoperable mechanism for the 739 generation and distribution of the keys that protect IKE keys. Such 740 a mechanism can be developed, based on the GDOI group key exchange 741 protocol [RFC3547]. There is on-going work to enable the generation 742 of non-IPsec keys by means of GDOI, e.g. to provide RSVP router 743 groups with a single key [I-D.weis-gdoi-for-rsvp]. This work can be 744 generalized for our purposes. We note that there are no significant 745 performance requirements on such a protocol, as key rollover can be 746 at a daily or even more leisurely rate. 748 6. IANA Considerations 750 This document requires a number of IKEv2 notification status types in 751 Section 4.3, to be registered by IANA. The corresponding registry 752 was established by IANA. 754 The document defines a new IKEv2 exchange in Section 4.2. The 755 corresponding registry was established by IANA. 757 7. Security Considerations 759 This section addresses security issues related to the usage of a 760 ticket. 762 7.1. Stolen Tickets 764 An eavesdropper or man-in-the-middle may try to obtain a ticket and 765 use it to establish a session with the IKEv2 responder. This can 766 happen in different ways: by eavesdropping on the initial 767 communication and copying the ticket when it is granted and before it 768 is used, or by listening in on a client's use of the ticket to resume 769 a session. However, since the ticket's contents is encrypted and the 770 attacker does not know the corresponding secret key (specifically, 771 SK_d), a stolen ticket cannot be used by an attacker to resume a 772 session. An IKEv2 responder MUST use strong encryption and integrity 773 protection of the ticket to prevent an attacker from obtaining the 774 ticket's contents, e.g., by using a brute force attack. 776 7.2. Forged Tickets 778 A malicious user could forge or alter a ticket in order to resume a 779 session, to extend its lifetime, to impersonate as another user, or 780 to gain additional privileges. This attack is not possible if the 781 ticket is protected using a strong integrity protection algorithm. 783 7.3. Denial of Service Attacks 785 The key_id field defined in the recommended ticket format helps the 786 server efficiently reject tickets that it did not issue. However, an 787 adversary could generate and send a large number of tickets to a 788 gateway for verification. To minimize the possibility of such denial 789 of service, ticket verification should be lightweight (e.g., using 790 efficient symmetric key cryptographic algorithms). 792 7.4. Ticket Protection Key Management 794 A full description of the management of the keys used to protect the 795 ticket is beyond the scope of this document. A list of RECOMMENDED 796 practices is given below. 797 o The keys should be generated securely following the randomness 798 recommendations in [RFC4086]. 799 o The keys and cryptographic protection algorithms should be at 800 least 128 bits in strength. 801 o The keys should not be used for any other purpose than generating 802 and verifying tickets. 803 o The keys should be changed regularly. 804 o The keys should be changed if the ticket format or cryptographic 805 protection algorithms change. 807 7.5. Ticket Lifetime 809 An IKEv2 responder controls the lifetime of a ticket, based on the 810 operational and security requirements of the environment in which it 811 is deployed. The responder provides information about the ticket 812 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 814 An IKEv2 client may present a ticket in its possession to a gateway, 815 even if the IKE SA associated with this ticket had previously been 816 terminated by another gateway (the gateway that originally provided 817 the ticket). Where such usage is against the local security policy, 818 an Invalid Ticket List (ITL) may be used, see 819 [I-D.rescorla-stateless-tokens]. Management of such lists is outside 820 the scope of the current document. Note that a policy that requires 821 tickets to have shorter lifetimes (e.g., 1 hour) significantly 822 mitigates this risk. 824 7.6. Alternate Ticket Formats and Distribution Schemes 826 If the ticket format or distribution scheme defined in this document 827 is not used, then great care must be taken in analyzing the security 828 of the solution. In particular, if confidential information, such as 829 a secret key, is transferred to the client, it MUST be done using 830 secure communication to prevent attackers from obtaining or modifying 831 the key. Also, the ticket MUST have its integrity and 832 confidentiality protected with strong cryptographic techniques to 833 prevent a breach in the security of the system. 835 7.7. Identity Privacy, Anonymity, and Unlinkability 837 This document mandates that the content of the ticket MUST be 838 encrypted in order to avoid leakage of information, such as the 839 identities of an IKEv2 initiator and a responder. Thus, it prevents 840 the disclosure of potentially sensitive information carried within 841 the ticket. 843 When an IKEv2 initiator presents the ticket as part of the 844 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 845 exchange. Although the ticket itself is encrypted there might still 846 be a possibility for an on-path adversary to observe multiple 847 exchange handshakes where the same ticket is used and therefore to 848 conclude that they belong to the same communication end points. 849 Administrators that use the ticket mechanism described in this 850 document should be aware that unlinkability may not be provided by 851 this mechanism. Note, however, that IKEv2 does not provide active 852 user identity confidentiality for the IKEv2 initiator either. 854 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange 856 A major design goal of this protocol extension has been the two- 857 message exchange for session resumption. There is a tradeoff between 858 this abbreviated exchange and replay protection. It is RECOMMENDED 859 that the gateway should cache tickets, and reject replayed ones. 860 However some gateways may not do that in order to reduce state size. 861 In addition, an adversary may replay a ticket last presented to 862 gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2) 863 mitigates both scenarios by ensuring that the client presenting the 864 ticket is indeed its "owner": the client can be required by the 865 gateway to prove that it knows the ticket's secret, before any state 866 is committed on the gateway. Note that this is a stronger guarantee 867 than the regular IKE cookie mechanism, which only proves IP return 868 routability of the client. This is enabled by including the cookie 869 in the protected portion of the message. 871 For performance reasons, the cookie mechanism is optional, and 872 invoked by the gateway only when it suspects that it is the subject 873 of a denial-of-service attack. 875 In any case, a ticket replayed by an adversary only causes partial 876 IKE state to be created on the gateway. The IKE exchange cannot be 877 completed and an IKE SA cannot be created unless the client knows the 878 ticket's secret values. 880 8. Acknowledgements 882 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 883 Yoav Nir and Tero Kivinen for their many helpful comments. 885 9. References 887 9.1. Normative References 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, March 1997. 892 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 893 RFC 4306, December 2005. 895 9.2. Informative References 897 [I-D.friedman-ike-short-term-certs] 898 Friedman, A., "Short-Term Certificates", 899 draft-friedman-ike-short-term-certs-02 (work in progress), 900 June 2007. 902 [I-D.rescorla-stateless-tokens] 903 Rescorla, E., "How to Implement Secure (Mostly) Stateless 904 Tokens", draft-rescorla-stateless-tokens-01 (work in 905 progress), March 2007. 907 [I-D.vidya-ipsec-failover-ps] 908 Narayanan, V., "IPsec Gateway Failover and Redundancy - 909 Problem Statement and Goals", 910 draft-vidya-ipsec-failover-ps-02 (work in progress), 911 December 2007. 913 [I-D.weis-gdoi-for-rsvp] 914 Weis, B., "Group Domain of Interpretation (GDOI) support 915 for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress), 916 February 2008. 918 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 919 Group Domain of Interpretation", RFC 3547, July 2003. 921 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 922 Requirements for Security", BCP 106, RFC 4086, June 2005. 924 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 925 Internet Protocol", RFC 4301, December 2005. 927 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 928 (IKEv2) Protocol", RFC 4478, April 2006. 930 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 931 "Transport Layer Security (TLS) Session Resumption without 932 Server-Side State", RFC 4507, May 2006. 934 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 935 (MOBIKE)", RFC 4555, June 2006. 937 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 938 Implementation Guidelines", RFC 4718, October 2006. 940 Appendix A. Related Work 942 [I-D.friedman-ike-short-term-certs] is on-going work that discusses 943 the use of short-term certificates for client re-authentication. It 944 is similar to the ticket approach described in this document in that 945 they both require enhancements to IKEv2 to allow information request, 946 e.g., for a certificate or a ticket. However, the changes required 947 by the former are fewer since an obtained certificate is valid for 948 any IKE responder that is able to verify them. On the other hand, 949 short-term certificates, while eliminating the usability issues of 950 user re-authentication, do not reduce the amount of effort performed 951 by the gateway in failover situations. 953 Appendix B. Change Log 955 B.1. -03 957 Removed counter mechanism. Added an optional anti-DoS mechanism, 958 based on IKEv2 cookies (removed previous discussion of cookies). 959 Clarified that gateways may support reallocation of same IP address, 960 if provided by network. Proposed a solution outline to the problem 961 of key exchange for the keys that protect tickets. Added fields to 962 the ticket to enable interoperability. Removed incorrect MOBIKE 963 notification. 965 B.2. -02 967 Clarifications on generation of SPI values, on the ticket's lifetime 968 and on the integrity protection of the anti-replay counter. 969 Eliminated redundant SPIs from the notification payloads. 971 B.3. -01 973 Editorial review. Removed 24-hour limitation on ticket lifetime, 974 lifetime is up to local policy. 976 B.4. -00 978 Initial version. This draft is a selective merge of 979 draft-sheffer-ike-session-resumption-00 and 980 draft-dondeti-ipsec-failover-sol-00. 982 Authors' Addresses 984 Yaron Sheffer 985 Check Point Software Technologies Ltd. 986 5 Hasolelim St. 987 Tel Aviv 67897 988 Israel 990 Email: yaronf@checkpoint.com 992 Hannes Tschofenig 993 Nokia Siemens Networks 994 Otto-Hahn-Ring 6 995 Munich, Bavaria 81739 996 Germany 998 Email: Hannes.Tschofenig@nsn.com 999 URI: http://www.tschofenig.priv.at 1001 Lakshminath Dondeti 1002 QUALCOMM, Inc. 1003 5775 Morehouse Dr 1004 San Diego, CA 1005 USA 1007 Phone: +1 858-845-1267 1008 Email: ldondeti@qualcomm.com 1009 Vidya Narayanan 1010 QUALCOMM, Inc. 1011 5775 Morehouse Dr 1012 San Diego, CA 1013 USA 1015 Phone: +1 858-845-2483 1016 Email: vidyan@qualcomm.com 1018 Full Copyright Statement 1020 Copyright (C) The IETF Trust (2008). 1022 This document is subject to the rights, licenses and restrictions 1023 contained in BCP 78, and except as set forth therein, the authors 1024 retain all their rights. 1026 This document and the information contained herein are provided on an 1027 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1028 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1029 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1030 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1031 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1032 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1034 Intellectual Property 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed to 1038 pertain to the implementation or use of the technology described in 1039 this document or the extent to which any license under such rights 1040 might or might not be available; nor does it represent that it has 1041 made any independent effort to identify any such rights. Information 1042 on the procedures with respect to rights in RFC documents can be 1043 found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use of 1048 such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository at 1050 http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at 1056 ietf-ipr@ietf.org.