idnits 2.17.00 (12 Aug 2021) /tmp/idnits17612/draft-sheffer-ipsec-failover-01.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 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 924. 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 (November 15, 2007) is 5300 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 359, but not defined == Missing Reference: 'TSi' is mentioned on line 451, but not defined == Missing Reference: 'TSr' is mentioned on line 451, but not defined -- Looks like a reference, but probably isn't: '16' on line 606 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4507 (Obsoleted by RFC 5077) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Experimental H. Tschofenig 5 Expires: May 18, 2008 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 November 15, 2007 11 IPsec Gateway Failover Protocol 12 draft-sheffer-ipsec-failover-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 18, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Internet Key Exchange version 2 (IKEv2) protocol has 46 computational and communication overhead with respect to the number 47 of round-trips required and cryptographic operations involved. In 48 remote access situations, the Extensible Authentication Protocol is 49 used for authentication, which adds additional latency. 51 To re-establish security associations (SA) upon a failure recovery 52 condition is time consuming, especially when an IPsec peer, such as a 53 VPN gateway, needs to re-establish a large number of SAs with various 54 end points. A high number of concurrent sessions might cause 55 additional problems for an IPsec peer during SA re-establishment. 57 In many failure cases it would be useful to provide an efficient way 58 to resume an interrupted IKE/IPsec session. This document proposes 59 an extension to IKEv2 that allows a client to re-establish an IKE SA 60 with a gateway in a highly efficient manner, utilizing a previously 61 established IKE SA. 63 A client can reconnect to a gateway from which it was disconnected, 64 or alternatively migrate to another gateway that is associated with 65 the previous one. The proposed approach conveys IKEv2 state 66 information, in the form of an encrypted ticket, to a VPN client that 67 is later presented to the VPN gateway for re-authentication. An 68 encrypted ticket cannot be decrypted by a VPN client but allows a VPN 69 gateway to restore state for faster session state setup. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6 79 3.2. Recovering from an Application Server Failover . . . . . . 8 80 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9 82 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 83 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12 84 4.2.2. Requesting a ticket during resumption . . . . . . . . 12 85 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 12 86 4.4. Gateway List . . . . . . . . . . . . . . . . . . . . . . . 13 87 4.5. Processing Guidelines for IKE SA Establishment . . . . . . 13 88 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 14 89 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 14 90 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 15 91 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 15 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 16 95 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 16 96 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 16 97 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 17 98 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 17 99 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 17 100 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 17 101 7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 18 102 7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE . . . 18 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 107 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 19 108 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 109 B.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 B.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 112 Intellectual Property and Copyright Statements . . . . . . . . . . 22 114 1. Introduction 116 The Internet Key Exchange version 2 (IKEv2) protocol has 117 computational and communication overhead with respect to the number 118 of round-trips required and cryptographic operations involved. In 119 particular the Extensible Authentication Protocol is used for 120 authentication in remote access cases, which adds additional latency. 122 To re-establish security associations (SA) upon a failure recovery 123 condition is time-consuming, especially when an IPsec peer, such as a 124 VPN gateway, needs to re-establish a large number of SAs with various 125 end points. A high number of concurrent sessions might cause 126 additional problems for an IPsec peer. 128 In many failure cases it would be useful to provide an efficient way 129 to resume an interrupted IKE/IPsec session. This document proposes 130 an extension to IKEv2 that allows a client to re-establish an IKE SA 131 with a gateway in a highly efficient manner, utilizing a previously 132 established IKE SA. 134 A client can reconnect to a gateway from which it was disconnected, 135 or alternatively migrate to another gateway that is associated with 136 the previous one. This document proposes to maintain an IKEv2 state 137 in a "ticket", an opaque data structure created and used by a server 138 and stored by a client, which the client cannot understand or tamper 139 with. The IKEv2 protocol needs to be extended to allow a client to 140 request and present a ticket. When two gateways mutually trust each 141 other, one can accept a ticket generated by the other. 143 This approach is similar to the one taken by TLS session resumption 144 [RFC4507] with the required adaptations for IKEv2, e.g., to 145 accommodate the two-phase protocol structure. We have borrowed 146 heavily from that specification. 148 1.1. Goals 150 The high-level goal of this extension is to provide an IPsec failover 151 solution, according to the requirements defined in 152 [I-D.vidya-ipsec-failover-ps]. 154 Specifically, the proposed extension should allow IPsec sessions to 155 be recovered from failures in remote access scenarios, in a more 156 efficient manner than the basic IKE solution. This efficiency is 157 primarily on the gateway side, since the gateway might have to deal 158 with many thousands of concurrent requests. We should enable the 159 following cases: 161 o Failover from one gateway to another, where the two gateways do 162 not share state but do have mutual trust. For example, the 163 gateways may be operated by the same provider and share the same 164 keying materials to access an encrypted ticket. 165 o Recovery from an intermittent connectivity failure ("network 166 reboot"), where clients reconnect into the same gateway. In this 167 case, the gateway would typically have detected the clients' 168 absence and removed the state associated with them. 169 o Recovery from a gateway restart, where clients reconnect into the 170 same gateway. 172 The proposed solution should additionally meet the following goals: 174 o Using only symmetric cryptography to minimize CPU consumption. 175 o Allowing a gateway to push state to clients. 176 o Providing cryptographic agility. 177 o Having no negative impact on IKEv2 security features. 178 Specifically, the solution must not introduce new security 179 vulnerabilities, such as denial-of-service. 181 1.2. Non-Goals 183 The following are non-goals of this solution: 184 o Providing load balancing among gateways. 185 o Specifying how a client detects the need for a failover. 186 o Establishing trust among gateways. 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 the gateways in the 200 secure domain are expected to share a security association - 201 either with each other or through a trusted third party - so that 202 they can verify the validity of the ticket and can extract the 203 IKEv2 policy and session key material from the ticket. 205 IKEv2 ticket: An IKEv2 ticket is a data structure that contains all 206 the necessary information that allows any gateway within the same 207 secure domain as the gateway that created the ticket to verify the 208 validity of the ticket and extract IKEv2 policy and session keys 209 to re-establish an IKEv2 session. 210 Stateless failover: When the IKEv2 session state is stored at the 211 client, the infrastructure is "stateless" until the client 212 restores the SA with one of the gateways within the secure domain; 213 thus, we refer to SA resumption with SA storage at the client as 214 stateless session resumption. 215 Stateful failover: When the infrastructure maintains IKEv2 session 216 state, we refer to the process of IKEv2 SA re-establishment as 217 stateful session resumption. Note that even in this case, a small 218 amount of information (the "handle") needs to be stored on the 219 client. 221 3. Usage Scenarios 223 This specification envisions two usage scenarios for efficient IKEv2 224 and IPsec SA session re-establishment: The first is similar to the 225 use case specified in Section 1.1.3 of the IKEv2 specification 226 [RFC4306], where IPsec tunnel mode is to establish a secure channel 227 between a remote access client and a gateway; the traffic flow may be 228 between the client and entities beyond the gateway. The second use 229 case is somewhat different from any of the use cases defined in the 230 IKEv2 specification: at the IP layer, two endpoints use transport (or 231 tunnel) mode to communicate between themselves. The two endpoints 232 have a client-server relationship with respect to a protocol that 233 runs using the protections afforded by the 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 3.2. Recovering from an Application Server Failover 281 (a) 283 +-+-+-+-+-+ +-+-+-+-+-+ 284 ! App. ! IKEv2/IKEv2-EAP ! App. ! 285 ! Client !<------------------------>! Server ! 286 ! & ! ! & ! 287 ! IPsec !<------------------------>! IPsec ! 288 ! host ! IPsec transport/ ! host ! 289 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 291 (b) 293 +-+-+-+-+-+ +-+-+-+-+-+ 294 ! App. ! IKE_SESSION_RESUME ! New ! 295 ! Client !<------------------------>! Server ! 296 ! & ! ! & ! 297 ! IPsec !<------------------------>! IPsec ! 298 ! host ! IPsec transport/ ! host ! 299 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 301 Figure 2: Application Server Failover 303 The second usage scenario is as follows: two entities with IPsec host 304 implementations establish an IPsec transport or tunnel mode SA 305 between themselves; this is similar to the model described in Section 306 1.1.2. of [RFC4306]. At the application level, one of the entities 307 is always the client and the other is a server. From that view 308 point, the IKEv2 exchange is always initiated by the client. This 309 allows the Initiator (the client) to authenticate itself using EAP, 310 as long as the Responder (or the application server) allows it. 312 If the application server fails, the client may find other servers 313 within the same secure domain for service continuity. It may use a 314 full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- 315 establish the IPsec SAs for secure communication required by the 316 application layer signaling. 318 The client-server relationship at the application layer ensures that 319 one of the entities in this usage scenario is unambiguously always 320 the Initiator and the other the Responder. This role determination 321 also allows the Initiator to request an address in the Responder's 322 network using the Configuration Payload mechanism of the IKEv2 323 protocol. If the client has thus received an address during the 324 initial IKEv2 exchange, when it associates with a new server upon 325 failure of the original server, it needs to request an address, 326 specifying its assigned address. The server may allow the client to 327 use the original address or if it is not permitted to use that 328 address, assign a new address. 330 4. Protocol Details 332 This section provides protocol details and contains the normative 333 parts. This document defines two protocol exchanges, namely 334 requesting a ticket and presenting a ticket. Section 4.1 describes 335 the procedure to request a ticket and Section 4.2 illustrates how to 336 present a ticket. 338 4.1. Requesting a Ticket 340 A client MAY request a ticket in the following exchanges: 342 o In an IKE_AUTH exchange, as shown in the example message exchange 343 in Figure 3 below. 344 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 345 o In an Informational exchange, if the gateway previously replied 346 with an N(TICKET_ACK) instead of providing a ticket. 347 o In an Informational exchange, when the ticket lifetime is about to 348 expire. 349 o In an IKE_SESSION_RESUME exchange, see Section 4.2.2. 351 Normally, a client requests a ticket in the third message of an IKEv2 352 exchange (the first of IKE_AUTH). Figure 3 shows the message 353 exchange for this typical case. 355 Initiator Responder 356 ----------- ----------- 357 HDR, SAi1, KEi, Ni --> 359 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 361 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 362 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 364 Figure 3: Example Message Exchange for Requesting a Ticket 366 The notification payloads are described in Section 4.3. The above is 367 an example, and IKEv2 allows a number of variants on these messages. 368 A complete description of IKEv2 can be found in [RFC4718]. 370 When an IKEv2 responder receives a request for a ticket using the 371 N(TICKET_REQUEST) payload it MUST perform one of the following 372 operations if it supports the extension defined in this document: 373 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 374 payload in a subsequent message towards the IKEv2 initiator. This 375 is shown in Figure 4. 376 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 377 ticket for some reason. 378 o it returns an N(TICKET_ACK), if it cannot grant a ticket 379 immediately, e.g., due to packet size limitations. In this case 380 the client MAY request a ticket later using an Informational 381 exchange, at any time during the lifetime of the IKE SA. 383 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 384 accept the requested ticket. The ticket may be used later with an 385 IKEv2 responder which supports this extension. Figure 4 shows how 386 the initiator receives the ticket. 388 Initiator Responder 389 ----------- ----------- 390 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 391 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 393 Figure 4: Receiving a Ticket 395 4.2. Presenting a Ticket 397 Following a communication failure, a client re-initiates an IKE 398 exchange to the same gateway or to a different one, and includes a 399 ticket in the first message. A client MAY initiate a regular (non- 400 ticket-based) IKEv2 exchange even if it is in possession of a valid 401 ticket. A client MUST NOT present a ticket after the ticket's 402 lifetime has expired. 404 It is purely a local decision of the client when and based on what 405 information to decide that a communication failure has happened and 406 that a new exchange including the ticket is needed. 408 We specify a new IKEv2 exchange type called IKE_SESSION_RESUME whose 409 value is TBA by IANA. This exchange is somewhat similar to the 410 IKE_AUTH exchange, and results in the creation of a Child SA. The 411 client MUST NOT use this exchange unless it knows that the gateway 412 supports failover, either through configuration, by out-of-band means 413 or by using the Gateway List provision. 415 Initiator Responder 416 ----------- ----------- 417 HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,] 418 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)] 419 [, N(UPDATE_SA_ADDRESSES)]} --> 421 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. 423 See Section 4.2.1 for details on computing the protected (SK) 424 payload. 426 The client MUST increment the counter value each time it uses this 427 same ticket to resume the session. When the gateway receives a 428 resumption request for a ticket it has seen in the past, it MUST 429 reject the request unless the counter value is larger than its 430 previous value. 432 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 433 payload it MUST perform one of the following steps if it supports the 434 extension defined in this document: 435 o If it is willing to accept the ticket, it responds as shown in 436 Figure 6. 437 o It responds with an unprotected N(TICKET_NACK) notification, if it 438 rejects the ticket for any reason. In that case, the initiator 439 should re-initiate a regular IKE exchange. One such case is when 440 the responder receives a ticket for an IKE SA that has previously 441 been terminated on the responder itself, which may indicate 442 inconsistent state between the IKEv2 initiator and the responder. 443 However, a responder is not required to maintain the state for 444 terminated sessions. 445 o If the responder receives a ticket for an IKE SA that is still 446 active and accepts it, it SHOULD silently delete the old SA 447 without sending a DELETE Informational exchange. 449 Initiator Responder 450 ----------- ----------- 451 <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 452 [CP(CFG_REPLY)]} 454 Figure 6: IKEv2 Responder accepts the ticket 456 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 458 The SK payload is protected using the cryptographic parameters 459 derived from the ticket, see Section 4.2.1 below. 461 At this point a new IKE SA is created by both parties, see 462 Section 4.5. This is followed by normal derivation of a child SA, 463 per Sec. 2.17 of [RFC4306]. 465 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 467 The two messages of this exchange are protected by a "subset" IKE SA. 468 The key material is derived from the ticket, as follows: 470 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 472 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 473 from the ticket. Ni guarantees freshness of the key material. SK_d2 474 is used later to derive the new IKE SA, see Section 4.5. 476 See [RFC4306] for the notation. "prf" is determined from the SA value 477 in the ticket. 479 4.2.2. Requesting a ticket during resumption 481 When resuming a session, a client will typically request a new ticket 482 immediately, so it is able to resume the session again in the case of 483 a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) 484 and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as 485 protected payloads to the IKE_SESSION_RESUME exchange. 487 The returned ticket (if any) will correspond to the IKE SA created 488 per the rules described in Section 4.5. 490 4.3. IKE Notifications 492 This document defines a number of notifications. The notification 493 numbers are TBA by IANA. 495 +---------------------+--------+-----------------+ 496 | Notification Name | Number | Data | 497 +---------------------+--------+-----------------+ 498 | TICKET_OPAQUE | TBA1 | See below | 499 | TICKET_REQUEST | TBA2 | None | 500 | TICKET_ACK | TBA3 | None | 501 | TICKET_NACK | TBA4 | None | 502 | TICKET_COUNTER | TBA5 | See below | 503 | TICKET_GATEWAY_LIST | TBA6 | See Section 4.4 | 504 +---------------------+--------+-----------------+ 506 The data for the TICKET_OPAQUE notification consists of a lifetime 507 duration in seconds (4 octets, denoting the time until the ticket 508 expires), followed by the ticket content. See Section 5.2 for a 509 recommended ticket format, and Section 5.3 for further guidelines 510 regarding the ticket's lifetime. 512 The data for TICKET_COUNTER consists of a single octet, treated as an 513 unsigned integer. 515 4.4. Gateway List 517 The gateway list is a sequence of zero or more gateway identifiers, 518 each of the following format: 520 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 ! ID Type ! Reserved ! Length ! 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 ! Identifier Value ! 526 ! ! 527 ! ... ! 528 ! ! 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 8: Gateway Identifier Syntax 533 ID Type - see allowed values below. 535 Reserved - must be sent as 0, ignored when received. 537 Length - the length in octets of the identifier value. 539 Identifier Value - variable length. The actual length depends on the 540 ID type. The length is not necessarily a multiple of 4. 542 The values and semantics of identifiers follow those of IKEv2 ID 543 payloads ([RFC4306], Sec. 3.5). Allowed ID types are: ID_IPV4_ADDR, 544 ID_IPV6_ADDR, ID_FQDN and the various reserved values. 546 4.5. Processing Guidelines for IKE SA Establishment 548 When a ticket is presented, the gateway parses the ticket to retrieve 549 the state of the old IKE SA, and the client retrieves this state from 550 its local store. Both peers now create state for the new IKE SA as 551 follows: 553 o The SA value (transforms etc.) is taken directly from the ticket. 554 o The sequence numbers are reset to 0. 555 o The IDi value is obtained from the ticket. 556 o The IDr value is obtained from the new exchange. The gateway MAY 557 make policy decisions based on the IDr value encoded in the 558 ticket. 559 o The SPI values are created anew, similarly to a regular IKE 560 exchange. SPI values from the ticket SHOULD NOT be reused. 562 The cryptographic material is refreshed based on the ticket and the 563 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 564 value is derived as follows: 566 SKEYSEED = prf(SK_d2, Ni | Nr) 568 where SK_d2 was computed earlier (Section 4.2.1). 570 The keys are derived as follows, unchanged from IKEv2: 572 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 573 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 575 where SPIi, SPIr are the SPI values created in the new IKE exchange. 577 See [RFC4306] for the notation. "prf" is determined from the SA value 578 in the ticket. 580 5. The IKE Ticket 582 This section lists the required contents of the ticket, and 583 recommends a non-normative format. This is followed by a discussion 584 of the ticket's lifecycle. 586 5.1. Ticket Contents 588 The ticket MUST encode at least the following state from an IKE SA. 589 These values MUST be encrypted and authenticated. 591 o IDi, IDr. 592 o SPIi, SPIr. 593 o SAr (the accepted proposal). 594 o SK_d. 596 In addition, the ticket MUST encode a protected ticket expiration 597 value. 599 5.2. Ticket Format 601 This document does not specify a ticket format. The following format 602 (this entire current section) is a RECOMMENDED implementation. The 603 client SHOULD NOT attempt to decode the ticket. 605 struct { 606 opaque key_name[16]; // ASCII, null-terminated 607 opaque IV[0..255]; // the length (possibly 0) depends 608 // on the encryption algorithm 610 [encrypted] struct { 611 opaque IDi, IDr; // the full payloads 612 opaque SPIi, SPIr; 613 opaque SA; // the full payload, returned as SAr 614 opaque SK_d; 615 opaque expiration; // an absolute time value 616 } ikev2_state; // encrypted and authenticated 617 opaque MAC[0..255]; // the length (possibly 0) depends 618 // on the integrity algorithm 619 } ticket; 621 Note that the key defined by "key_name" determines the encryption and 622 authentication algorithms used for this ticket. Those algorithms are 623 unrelated to the transforms defined by the SA payload. 625 The reader is referred to a recent draft 626 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 627 identical) ticket format, and discusses related security 628 considerations in depth. 630 5.3. Ticket Identity and Lifecycle 632 Each ticket is associated with a single IKE SA. In particular, when 633 an IKE SA is deleted, the client MUST delete its stored ticket. 635 A ticket is therefore associated with the tuple (IDi, IDr). The 636 client MAY however use a ticket to approach other gateways that are 637 willing to accept it. How a client discovers such gateways is 638 outside the scope of this document. 640 The lifetime included with the ticket in the N(TICKET_OPAQUE) 641 notification should be the minimum of the IKE SA lifetime (per the 642 gateway's local policy) and its re-authentication time, according to 643 [RFC4478]. Even if neither of these is enforced by the gateway, a 644 finite lifetime MUST be specified for the ticket. 646 6. IANA Considerations 648 This document requires a number of IKEv2 notification status types in 649 Section 4.3, to be registered by IANA. The corresponding registry 650 was established by IANA. 652 The document defines a new IKEv2 exchange in Section 4.2. The 653 corresponding registry was established by IANA. 655 7. Security Considerations 657 This section addresses security issues related to the usage of a 658 ticket. 660 7.1. Stolen Tickets 662 An eavesdropper or man-in-the-middle may try to obtain a ticket and 663 use it to establish a session with the IKEv2 responder. This can 664 happen in different ways: by eavesdropping on the initial 665 communication and copying the ticket when it is granted and before it 666 is used, or by listening in on a client's use of the ticket to resume 667 a session. However, since the ticket's contents is encrypted and the 668 attacker does not know the corresponding secret key (specifically, 669 SK_d), a stolen ticket cannot be used by an attacker to resume a 670 session. An IKEv2 responder MUST use strong encryption and integrity 671 protection of the ticket to prevent an attacker from obtaining the 672 ticket's contents, e.g., by using a brute force attack. 674 7.2. Forged Tickets 676 A malicious user could forge or alter a ticket in order to resume a 677 session, to extend its lifetime, to impersonate as another user, or 678 to gain additional privileges. This attack is not possible if the 679 ticket is protected using a strong integrity protection algorithm. 681 7.3. Denial of Service Attacks 683 The key_name field defined in the recommended ticket format helps the 684 server efficiently reject tickets that it did not issue. However, an 685 adversary could generate and send a large number of tickets to a 686 gateway for verification. To minimize the possibility of such denial 687 of service, ticket verification should be lightweight (e.g., using 688 efficient symmetric key cryptographic algorithms). See also 689 Section 7.8. 691 7.4. Ticket Protection Key Management 693 A full description of the management of the keys used to protect the 694 ticket is beyond the scope of this document. A list of RECOMMENDED 695 practices is given below. 696 o The keys should be generated securely following the randomness 697 recommendations in [RFC4086]. 698 o The keys and cryptographic protection algorithms should be at 699 least 128 bits in strength. 700 o The keys should not be used for any other purpose than generating 701 and verifying tickets. 702 o The keys should be changed regularly. 703 o The keys should be changed if the ticket format or cryptographic 704 protection algorithms change. 706 7.5. Ticket Lifetime 708 An IKEv2 responder controls the lifetime of a ticket, based on the 709 operational and security requirements of the environment in which it 710 is deployed. The responder provides information about the ticket 711 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 713 An IKEv2 client may present a ticket in its possession to a gateway, 714 even if the IKE SA associated with this ticket had previously been 715 terminated by another gateway (the gateway that originally provided 716 the ticket). Where such usage is against the local security policy, 717 an Invalid Ticket List (ITL) may be used, see 718 [I-D.rescorla-stateless-tokens]. Management of such lists is outside 719 the scope of the current document. Note that a policy that requires 720 tickets to have shorter lifetimes (e.g., 1 hour) significantly 721 mitigates this risk. 723 7.6. Alternate Ticket Formats and Distribution Schemes 725 If the ticket format or distribution scheme defined in this document 726 is not used, then great care must be taken in analyzing the security 727 of the solution. In particular, if confidential information, such as 728 a secret key, is transferred to the client, it MUST be done using 729 secure communication to prevent attackers from obtaining or modifying 730 the key. Also, the ticket MUST have its integrity and 731 confidentiality protected with strong cryptographic techniques to 732 prevent a breach in the security of the system. 734 7.7. Identity Privacy, Anonymity, and Unlinkability 736 This document mandates that the content of the ticket MUST be 737 encrypted in order to avoid leakage of information, such as the 738 identities of an IKEv2 initiator and a responder. Thus, it prevents 739 the disclosure of potentially sensitive information carried within 740 the ticket. 742 When an IKEv2 initiator presents the ticket as part of the 743 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 744 exchange. Although the ticket itself is encrypted there might still 745 be a possibility for an on-path adversary to observe multiple 746 exchange handshakes where the same ticket is used and therefore to 747 conclude that they belong to the same communication end points. 748 Administrators that use the ticket mechanism described in this 749 document should be aware that unlinkability may not be provided by 750 this mechanism. Note, however, that IKEv2 does not provide active 751 user identity confidentiality for the IKEv2 initiator either. 753 7.8. Usage of IKE Cookies 755 The extension specified in this document eliminates most potential 756 denial-of-service attacks that the cookie mechanism aims to solve. 757 However, memory exhaustion remains possible. Therefore the cookie 758 mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the 759 gateway for the IKE_SESSION_RESUME exchange described in Section 4.2. 761 7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE 763 A major design goal of the current protocol has been the two-message 764 exchange for session resumption. There is a tradeoff between this 765 abbreviated exchange and replay protection. Using our counter-based 766 solution, an attacker cannot replay a ticket to a gateway that had 767 seen this same ticket before. However the attacker can attempt to 768 replay a ticket to another gateway, and create intermittent IKE state 769 (but no successful establishment of an IKE SA). The standard Cookie 770 mechanism can be used to mitigate this risk. 772 8. Acknowledgements 774 We would like to thank Paul Hoffman, Pasi Eronen and Yoav Nir for 775 their review of earlier drafts. 777 9. References 779 9.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 785 RFC 4306, December 2005. 787 9.2. Informative References 789 [I-D.friedman-ike-short-term-certs] 790 Friedman, A., "Short-Term Certificates", 791 draft-friedman-ike-short-term-certs-02 (work in progress), 792 June 2007. 794 [I-D.rescorla-stateless-tokens] 795 Rescorla, E., "How to Implement Secure (Mostly) Stateless 796 Tokens", draft-rescorla-stateless-tokens-01 (work in 797 progress), March 2007. 799 [I-D.vidya-ipsec-failover-ps] 800 Narayanan, V., "IPsec Gateway Failover and Redundancy - 801 Problem Statement and Goals", 802 draft-vidya-ipsec-failover-ps-02 (work in progress), 803 May 2007. 805 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 806 Requirements for Security", BCP 106, RFC 4086, June 2005. 808 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 809 Internet Protocol", RFC 4301, December 2005. 811 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 812 (IKEv2) Protocol", RFC 4478, April 2006. 814 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 815 "Transport Layer Security (TLS) Session Resumption without 816 Server-Side State", RFC 4507, May 2006. 818 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 819 (MOBIKE)", RFC 4555, June 2006. 821 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 822 Implementation Guidelines", RFC 4718, October 2006. 824 Appendix A. Related Work 826 [I-D.friedman-ike-short-term-certs] is on-going work that discusses 827 the use of short-term certificates for client re-authentication. It 828 is similar to the ticket approach described in this document in that 829 they both require enhancements to IKEv2 to allow information request, 830 e.g., for a certificate or a ticket. However, the changes required 831 by the former are fewer since an obtained certificate is valid for 832 any IKE responder that is able to verify them. On the other hand, 833 short-term certificates, while eliminating the usability issues of 834 user re-authentication, do not reduce the amount of effort performed 835 by the gateway in failover situations. 837 Appendix B. Change Log 839 B.1. -01 841 Editorial review. Removed 24-hour limitation on ticket lifetime, 842 lifetime is up to local policy. 844 B.2. -00 846 Initial version. This draft is a selective merge of 847 draft-sheffer-ike-session-resumption-00 and 848 draft-dondeti-ipsec-failover-sol-00. 850 Authors' Addresses 852 Yaron Sheffer 853 Check Point Software Technologies Ltd. 854 5 Hasolelim St. 855 Tel Aviv 67897 856 Israel 858 Email: yaronf@checkpoint.com 860 Hannes Tschofenig 861 Nokia Siemens Networks 862 Otto-Hahn-Ring 6 863 Munich, Bavaria 81739 864 Germany 866 Email: Hannes.Tschofenig@nsn.com 867 URI: http://www.tschofenig.com 868 Lakshminath Dondeti 869 QUALCOMM, Inc. 870 5775 Morehouse Dr 871 San Diego, CA 872 USA 874 Phone: +1 858-845-1267 875 Email: ldondeti@qualcomm.com 877 Vidya Narayanan 878 QUALCOMM, Inc. 879 5775 Morehouse Dr 880 San Diego, CA 881 USA 883 Phone: +1 858-845-2483 884 Email: vidyan@qualcomm.com 886 Full Copyright Statement 888 Copyright (C) The IETF Trust (2007). 890 This document is subject to the rights, licenses and restrictions 891 contained in BCP 78, and except as set forth therein, the authors 892 retain all their rights. 894 This document and the information contained herein are provided on an 895 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 896 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 897 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 898 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 899 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 900 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 902 Intellectual Property 904 The IETF takes no position regarding the validity or scope of any 905 Intellectual Property Rights or other rights that might be claimed to 906 pertain to the implementation or use of the technology described in 907 this document or the extent to which any license under such rights 908 might or might not be available; nor does it represent that it has 909 made any independent effort to identify any such rights. Information 910 on the procedures with respect to rights in RFC documents can be 911 found in BCP 78 and BCP 79. 913 Copies of IPR disclosures made to the IETF Secretariat and any 914 assurances of licenses to be made available, or the result of an 915 attempt made to obtain a general license or permission for the use of 916 such proprietary rights by implementers or users of this 917 specification can be obtained from the IETF on-line IPR repository at 918 http://www.ietf.org/ipr. 920 The IETF invites any interested party to bring to its attention any 921 copyrights, patents or patent applications, or other proprietary 922 rights that may cover technology that may be required to implement 923 this standard. Please address the information to the IETF at 924 ietf-ipr@ietf.org. 926 Acknowledgment 928 Funding for the RFC Editor function is provided by the IETF 929 Administrative Support Activity (IASA).