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