idnits 2.17.00 (12 Aug 2021) /tmp/idnits17279/draft-sheffer-ipsec-failover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 917. 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 (October 18, 2007) is 5328 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 358, but not defined == Missing Reference: 'TSi' is mentioned on line 450, but not defined == Missing Reference: 'TSr' is mentioned on line 450, but not defined -- Looks like a reference, but probably isn't: '16' on line 605 ** 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: April 20, 2008 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 October 18, 2007 11 IPsec Gateway Failover Protocol 12 draft-sheffer-ipsec-failover-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 20, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Internet Key Exchange version 2 (IKEv2) protocol is 46 computationally intensive with respect to the number of round-trips 47 required and cryptographic operations involved. In remote access 48 situations, the Extensible Authentication Protocol is used for 49 authentication, which adds additional computational intensity. 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 . . . . . . . . . . . . . 16 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. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 111 Intellectual Property and Copyright Statements . . . . . . . . . . 22 113 1. Introduction 115 The Internet Key Exchange version 2 (IKEv2) protocol is 116 computationally intensive with respect to the number of round-trips 117 required and cryptographic operations involved. In particular the 118 Extensible Authentication Protocol is used for authentication in 119 remote access cases, which adds additional computational intensity. 121 To re-establish security associations (SA) upon a failure recovery 122 condition is time-consuming, especially when an IPsec peer, such as a 123 VPN gateway, needs to re-establish a large number of SAs with various 124 end points. A high number of concurrent sessions might cause 125 additional problems for an IPsec peer. 127 In many failure cases it would be useful to provide an efficient way 128 to resume an interrupted IKE/IPsec session. This document proposes 129 an extension to IKEv2 that allows a client to re-establish an IKE SA 130 with a gateway in a highly efficient manner, utilizing a previously 131 established IKE SA. 133 A client can reconnect to a gateway from which it was disconnected, 134 or alternatively migrate to another gateway that is associated with 135 the previous one. This document proposes to maintain an IKEv2 state 136 in a "ticket", an opaque data structure created and used by a server 137 and stored by a client, which the client cannot understand or tamper 138 with. The IKEv2 protocol needs to be extended to allow a client to 139 request and present a ticket. When two gateways mutually trust each 140 other, one can accept a ticket generated by the other. 142 This approach is similar to the one taken by TLS session resumption 143 [RFC4507] with the required adaptations for IKEv2, e.g., to 144 accommodate the two-phase protocol structure. We have borrowed 145 heavily from that specification. 147 1.1. Goals 149 The high-level goal of this extension is to provide an IPsec failover 150 solution, according to the requirements defined in 151 [I-D.vidya-ipsec-failover-ps]. 153 Specifically, the proposed extension should allow IPsec sessions to 154 be recovered from failures in remote access scenarios, in a more 155 efficient manner than the basic IKE solution. This efficiency is 156 primarily on the gateway side, since the gateway might have to deal 157 with many thousands of concurrent requests. We should enable the 158 following cases: 160 o Failover from one gateway to another, where the two gateways do 161 not share state but do have mutual trust. For example, the 162 gateways may be operated by the same provider and share the same 163 keying materials to access an encrypted ticket. 164 o Recovery from an intermittent connectivity failure ("network 165 reboot"), where clients reconnect into the same gateway. In this 166 case the gateway would typically had detected the clients' absence 167 and removed the state associated with them. 168 o Recovery from a gateway restart, where clients reconnect into the 169 same gateway. 171 The proposed solution should additionally meet the following goals: 173 o Using only symmetric cryptography to minimize CPU consumption. 174 o Allowing a gateway to push state to clients. 175 o Providing cryptographic agility. 176 o Having no negative impact on IKEv2 security features. 177 Specifically, the solution must not introduce new security 178 vulnerabilities, such as denial-of-service. 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. 185 o Establishing trust among gateways. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 This document uses terminology defined in [RFC4301], [RFC4306], and 194 [RFC4555]. In addition, this document uses the following terms: 196 Secure domain: A secure domain comprises a set of gateways that are 197 able to resume an IKEv2 session that may have been established any 198 other gateway within the domain. All the gateways in the secure 199 domain are expected to share a security association -- either with 200 each other or through a trusted third party -- so they can verify 201 the validity of the ticket and can extract the IKEv2 policy and 202 session key material from the ticket. 204 IKEv2 ticket: An IKEv2 ticket is a data structure that contains all 205 the necessary information that allows any gateway within the same 206 secure domain as the gateway that created the ticket to verify the 207 validity of the ticket and extract IKEv2 policy and session keys 208 to re-establish an IKEv2 session. 209 Stateless failover: When the IKEv2 session state is stored at the 210 client, the infrastructure 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. Note that even in this case, a small 217 amount of information (the "handle") needs to be stored on the 218 client. 220 3. Usage Scenarios 222 This specification envisions two usage scenarios for efficient IKEv2 223 and IPsec SA session re-establishment: The first is similar to the 224 use case specified in Section 1.1.3 of the IKEv2 specification 225 [RFC4306], where IPsec tunnel mode is to establish a secure channel 226 between a remote access client and a gateway; the traffic flow may be 227 between the client and entities beyond the gateway. The second use 228 case is somewhat different from any of the use cases defined in the 229 IKEv2 specification: at the IP layer, two endpoints use transport (or 230 tunnel) mode to communicate between themselves. The two endpoints 231 have a client-server relationship with respect to a protocol that 232 runs using the protections afforded by the IPsec SA. 234 3.1. Recovering from a Remote Access Gateway Failover 235 (a) 237 +-+-+-+-+-+ +-+-+-+-+-+ 238 ! ! IKEv2/IKEv2-EAP ! ! Protected 239 ! Remote !<------------------------>! Remote ! Subnet 240 ! Access ! ! Access !<--- and/or 241 ! Client !<------------------------>! Gateway ! Internet 242 ! ! IPsec tunnel ! ! 243 +-+-+-+-+-+ +-+-+-+-+-+ 245 (b) 247 +-+-+-+-+-+ +-+-+-+-+-+ 248 ! ! IKE_SESSION_RESUME ! ! 249 ! Remote !<------------------------>! New/Old ! 250 ! Access ! ! Gateway ! 251 ! Client !<------------------------>! ! 252 ! ! IPsec tunnel ! ! 253 +-+-+-+-+-+ +-+-+-+-+-+ 255 Figure 1: Remote Access Gateway Failure 257 In this scenario, an endhost (an entity with a host implementation of 258 IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a gateway 259 in a remote network using IKEv2. The endhost in this scenario is 260 sometimes referred to as a remote access client. When the remote 261 gateway fails, all the clients associated with the gateway either 262 need to re-establish IKEv2 sessions with another gateway within the 263 same secure domain of the original gateway, or with the original 264 gateway if the server is back online soon. 266 The clients may choose to establish IPsec SAs using a full IKEv2 267 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). 269 In this scenario, the client needs to get an IP address from the 270 remote network so that traffic can be encapsulated by the remote 271 access gateway before reaching the client. In the initial exchange, 272 the gateway may acquire IP addresses from the address pool of a local 273 DHCP server. The new gateway that a client gets associated may not 274 receive addresses from the same address pool. Thus, the session 275 resumption protocol needs to be able to support for new IP address 276 assignment. 278 3.2. Recovering from an Application Server Failover 280 (a) 282 +-+-+-+-+-+ +-+-+-+-+-+ 283 ! App. ! IKEv2/IKEv2-EAP ! App. ! 284 ! Client !<------------------------>! Server ! 285 ! & ! ! & ! 286 ! IPsec !<------------------------>! IPsec ! 287 ! host ! IPsec transport/ ! host ! 288 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 290 (b) 292 +-+-+-+-+-+ +-+-+-+-+-+ 293 ! App. ! IKE_SESSION_RESUME ! New ! 294 ! Client !<------------------------>! Server ! 295 ! & ! ! & ! 296 ! IPsec !<------------------------>! IPsec ! 297 ! host ! IPsec transport/ ! host ! 298 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 300 Figure 2: Application Server Failover 302 The second usage scenario is as follows: two entities with IPsec host 303 implementations establish an IPsec transport or tunnel mode SA 304 between themselves; this is similar to the model described in Section 305 1.1.2. of [RFC4306]. At the application level, one of the entities 306 is always the client and the other is a server. From that view 307 point, the IKEv2 exchange is always initiated by the client. This 308 allows the Initiator (the client) to authenticate itself using EAP, 309 as long as the Responder (or the application server) allows it. 311 If the application server fails, the client may find other servers 312 within the same secure domain for service continuity. It may use a 313 full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- 314 establish the IPsec SAs for secure communication required by the 315 application layer signaling. 317 The client-server relationship at the application layer ensures that 318 one of the entities in this usage scenario is unambiguously always 319 the Initiator and the other the Responder. This role determination 320 also allows the Initiator to request an address in the Responder's 321 network using the Configuration Payload mechanism of the IKEv2 322 protocol. If the client has thus received an address during the 323 initial IKEv2 exchange, when it associates with a new server upon 324 failure of the original server, it needs to request an address, 325 specifying its assigned address. The server may allow the client to 326 use the original address or if it is not permitted to use that 327 address, assigns a new address. 329 4. Protocol Details 331 This section provides protocol details and contains the normative 332 parts. This document defines two protocol exchanges, namely 333 requesting a ticket and presenting a ticket. Section 4.1 describes 334 the procedure to request a ticket and Section 4.2 illustrates how to 335 present a ticket. 337 4.1. Requesting a Ticket 339 A client MAY request a ticket in the following exchanges: 341 o In an IKE_AUTH exchange, as shown in the example message exchange 342 in Figure 3 below. 343 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 344 o In an Informational exchange, if the gateway previously replied 345 with an N(TICKET_ACK) instead of providing a ticket. 346 o In an Informational exchange, when the ticket lifetime is about to 347 expire. 348 o In an IKE_SESSION_RESUME exchange, see Section 4.2.2. 350 Normally, a client requests a ticket in the third message of an IKEv2 351 exchange (the first of IKE_AUTH). Figure 3 shows the message 352 exchange for this typical case. 354 Initiator Responder 355 ----------- ----------- 356 HDR, SAi1, KEi, Ni --> 358 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 360 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 361 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 363 Figure 3: Example Message Exchange for Requesting a Ticket 365 The notification payloads are described in Section 4.3. The above is 366 an example, and IKEv2 allows a number of variants on these messages. 367 A complete description of IKEv2 can be found in [RFC4718]. 369 When an IKEv2 responder receives a request for a ticket using the 370 N(TICKET_REQUEST) payload it MUST perform one of the following 371 operations if it supports the extension defined in this document: 372 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 373 payload in a subsequent message towards the IKEv2 initiator. This 374 is shown in Figure 4. 375 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 376 ticket for some reason. 377 o it returns an N(TICKET_ACK), if it cannot grant a ticket 378 immediately, e.g., due to packet size limitations. In this case 379 the client MAY request a ticket later using an Informational 380 exchange, at any time during the lifetime of the IKE SA. 382 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 383 accept the requested ticket. The ticket may be used later with an 384 IKEv2 responder which supports this extension. Figure 4 shows how 385 the initiator receives the ticket. 387 Initiator Responder 388 ----------- ----------- 389 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 390 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 392 Figure 4: Receiving a Ticket 394 4.2. Presenting a Ticket 396 Following a communication failure, a client re-initiates an IKE 397 exchange to the same gateway or to a different one, and includes a 398 ticket in the first message. A client MAY initiate a regular (non- 399 ticket-based) IKEv2 exchange even if it is in possession of a valid 400 ticket. A client MUST NOT present a ticket after the ticket's 401 lifetime has expired. 403 It is purely a local decision of the client when and based on what 404 information to decide that a communication failure has happened and 405 that a new exchange including the ticket is needed. 407 We specify a new IKEv2 exchange type called IKE_SESSION_RESUME whose 408 value is TBA by IANA. This exchange is somewhat similar to the 409 IKE_AUTH exchange, and results in the creation of a Child SA. The 410 client MUST NOT use this exchange unless it knows that the gateway 411 supports failover, either through configuration or by using the 412 Gateway List provision. 414 Initiator Responder 415 ----------- ----------- 416 HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,] 417 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)] 418 [, N(UPDATE_SA_ADDRESSES)]} --> 420 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. 422 See Section 4.2.1 for details on computing the protected (SK) 423 payload. 425 The client MUST increment the counter value each time it uses this 426 same ticket to resume the session. When the gateway receives a 427 resumption request for a ticket it has seen in the past, it MUST 428 reject the request unless the counter value is larger than its 429 previous value. 431 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 432 payload it MUST perform one of the following steps if it supports the 433 extension defined in this document: 434 o If it is willing to accept the ticket, it responds as shown in 435 Figure 6. 436 o It responds with an unprotected N(TICKET_NACK) notification, if it 437 rejects the ticket for any reason. In that case, the initiator 438 should re-initiate a regular IKE exchange. One such case is when 439 the responder receives a ticket for an IKE SA that has previously 440 been terminated on the responder itself, which may indicate 441 inconsistent state between the IKEv2 initiator and the responder. 442 However a responder is not required to maintain the state for 443 terminated sessions. 444 o If the responder receives a ticket for an IKE SA that is still 445 active and accepts it, it SHOULD silently delete the old SA 446 without sending a DELETE Informational exchange. 448 Initiator Responder 449 ----------- ----------- 450 HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 451 [CP(CFG_REPLY)]} 453 Figure 6: IKEv2 Responder accepts the ticket 455 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 457 The SK payload is protected using the cryptographic parameters 458 derived from the ticket, see Section 4.2.1 below. 460 At this point a new IKE SA is created by both parties, see 461 Section 4.5. This is followed by normal derivation of a child SA, 462 per Sec. 2.17 of [RFC4306]. 464 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 466 The two messages of this exchange are protected by a "subset" IKE SA. 467 The key material is derived from the ticket, as follows: 469 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 471 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 472 from the ticket. Ni guarantees freshness of the key material. SK_d2 473 is used later to derive the new IKE SA, see Section 4.5. 475 See [RFC4306] for the notation. "prf" is determined from the SA value 476 in the ticket. 478 4.2.2. Requesting a ticket during resumption 480 When resuming a session, a client will typically request a new ticket 481 immediately, so it is able to resume the session again in the case of 482 a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) 483 and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as 484 protected payloads to the IKE_SESSION_RESUME exchange. 486 The returned ticket (if any) will correspond to the IKE SA created 487 per the rules described in Section 4.5. 489 4.3. IKE Notifications 491 This document defines a number of notifications. The notification 492 numbers are TBA by IANA. 494 +---------------------+--------+-----------------+ 495 | Notification Name | Number | Data | 496 +---------------------+--------+-----------------+ 497 | TICKET_OPAQUE | TBA1 | See below | 498 | TICKET_REQUEST | TBA2 | None | 499 | TICKET_ACK | TBA3 | None | 500 | TICKET_NACK | TBA4 | None | 501 | TICKET_COUNTER | TBA5 | See below | 502 | TICKET_GATEWAY_LIST | TBA6 | See Section 4.4 | 503 +---------------------+--------+-----------------+ 505 The data for the TICKET_OPAQUE notification consists of a lifetime 506 duration in seconds (4 octets, denoting the time until the ticket 507 expires), followed by the ticket content. See Section 5.2 for a 508 recommended ticket format, and Section 5.3 for further guidelines 509 regarding the ticket's lifetime. 511 The data for TICKET_COUNTER consists of a single octet, treated as an 512 unsigned integer. 514 4.4. Gateway List 516 The gateway list is a sequence of zero or more gateway identifiers, 517 each of the following format: 519 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ! ID Type ! Reserved ! Length ! 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 ! Identifier Value ! 525 ! ! 526 ! ... ! 527 ! ! 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 8: Gateway Identifier Syntax 532 ID Type - see allowed values below. 534 Reserved - must be sent as 0, ignored when received. 536 Length - the length in octets of the identifier value. 538 Identifier Value - variable length. The actual length depends on the 539 ID type. The length is not necessarily a multiple of 4. 541 The values and semantics of identifiers follow those of IKEv2 ID 542 payloads ([RFC4306], Sec. 3.5). Allowed ID types are: ID_IPV4_ADDR, 543 ID_IPV6_ADDR, ID_FQDN and the various reserved values. 545 4.5. Processing Guidelines for IKE SA Establishment 547 When a ticket is presented, the gateway parses the ticket to retrieve 548 the state of the old IKE SA, and the client retrieves this state from 549 its local store. Both peers now create state for the new IKE SA as 550 follows: 552 o The SA value (transforms etc.) is taken directly from the ticket. 553 o The sequence numbers are reset to 0. 554 o The IDi value is obtained from the ticket. 555 o The IDr value is obtained from the new exchange. The gateway MAY 556 make policy decisions based on the IDr value encoded in the 557 ticket. 558 o The SPI values are created anew, similarly to a regular IKE 559 exchange. SPI values from the ticket MUST NOT be reused. 561 The cryptographic material is refreshed based on the ticket and the 562 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 563 value is derived as follows: 565 SKEYSEED = prf(SK_d2, Ni | Nr) 567 where SK_d2 was computed earlier (Section 4.2.1). 569 The keys are derived as follows, unchanged from IKEv2: 571 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 572 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 574 where SPIi, SPIr are the SPI values created in the new IKE exchange. 576 See [RFC4306] for the notation. "prf" is determined from the SA value 577 in the ticket. 579 5. The IKE Ticket 581 This section lists the required contents of the ticket, and 582 recommends a non-normative format. This is followed by a discussion 583 of the ticket's lifecycle. 585 5.1. Ticket Contents 587 The ticket MUST encode at least the following state from an IKE SA. 588 These values MUST be encrypted and authenticated. 590 o IDi, IDr. 591 o SPIi, SPIr. 592 o SAr (the accepted proposal). 593 o SK_d. 595 In addition, the ticket MUST encode a protected ticket expiration 596 value. 598 5.2. Ticket Format 600 This document does not specify a ticket format. The following format 601 (this entire current section) is a RECOMMENDED implementation. The 602 client SHOULD NOT attempt to decode the ticket. 604 struct { 605 opaque key_name[16]; // ASCII, null-terminated 606 opaque IV[0..255]; // the length (possibly 0) depends 607 // on the encryption algorithm 609 [protected] struct { 610 opaque IDi, IDr; // the full payloads 611 opaque SPIi, SPIr; 612 opaque SA; // the full payload, returned as SAr 613 opaque SK_d; 614 opaque expiration; // an absolute time value 615 } ikev2_state; // encrypted and authenticated 616 opaque MAC[0..255]; // the length (possibly 0) depends 617 // on the integrity algorithm 618 } ticket; 620 Note that the key defined by "key_name" determines the encryption and 621 authentication algorithms used for this ticket. Those algorithms are 622 unrelated to the transforms defined by the SA payload. 624 The reader is referred to a recent draft 625 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 626 identical) ticket format, and discusses related security 627 considerations in depth. 629 5.3. Ticket Identity and Lifecycle 631 Each ticket is associated with a single IKE SA. In particular, when 632 an IKE SA is deleted, the client MUST delete its stored ticket. 634 A ticket is therefore associated with the tuple (IDi, IDr). The 635 client MAY however use a ticket to approach other gateways that are 636 willing to accept it. How a client discovers such gateways is 637 outside the scope of this document. 639 The lifetime included with the ticket in the N(TICKET_OPAQUE) 640 notification should be the minimum of the IKE SA lifetime (per the 641 gateway's local policy) and its re-authentication time, according to 642 [RFC4478]. Even if neither of these is enforced by the gateway, a 643 finite lifetime MUST be specified for the ticket and SHOULD be less 644 than 24 hours. 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. However, 664 since the ticket is encrypted and the attacker does not know the 665 corresponding secret key (specifically, SK_d), a stolen ticket cannot 666 be used by an attacker to resume a session. An IKEv2 responder MUST 667 use strong encryption and integrity protection for the ticket to 668 prevent an attacker from obtaining the ticket's contents, e.g., by 669 using a brute force attack. 671 7.2. Forged Tickets 673 A malicious user could forge or alter a ticket in order to resume a 674 session, to extend its lifetime, to impersonate as another user, or 675 to gain additional privileges. This attack is not possible if the 676 ticket is protected using a strong integrity protection algorithm 677 such as a keyed HMAC-SHA1. 679 7.3. Denial of Service Attacks 681 The key_name field defined in the recommended ticket format helps the 682 server efficiently reject tickets that it did not issue. However, an 683 adversary could generate and send a large number of tickets to a 684 gateway for verification. To minimize the possibility of such denial 685 of service, ticket verification should be lightweight (e.g., using 686 efficient symmetric key cryptographic algorithms). See also 687 Section 7.8. 689 7.4. Ticket Protection Key Management 691 A full description of the management of the keys used to protect the 692 ticket is beyond the scope of this document. A list of RECOMMENDED 693 practices is given below. 694 o The keys should be generated securely following the randomness 695 recommendations in [RFC4086]. 696 o The keys and cryptographic protection algorithms should be at 697 least 128 bits in strength. 698 o The keys should not be used for any other purpose than generating 699 and verifying tickets. 700 o The keys should be changed regularly. 701 o The keys should be changed if the ticket format or cryptographic 702 protection algorithms change. 704 7.5. Ticket Lifetime 706 An IKEv2 responder controls the lifetime of a ticket, based on the 707 operational and security requirements of the environment in which it 708 is deployed. The responder provides information about the ticket 709 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 711 An IKEv2 client may present a ticket in its possession to a gateway, 712 even if the IKE SA associated with this ticket had previously been 713 terminated by another gateway (the gateway that originally provided 714 the ticket). Where such usage is against the local security policy, 715 an Invalid Ticket List (ITL) may be used, see 716 [I-D.rescorla-stateless-tokens]. Management of such lists is outside 717 the scope of the current document. Note that a policy that requires 718 tickets to have shorter lifetimes (e.g., 1 hour) significantly 719 mitigates this risk. 721 7.6. Alternate Ticket Formats and Distribution Schemes 723 If the ticket format or distribution scheme defined in this document 724 is not used, then great care must be taken in analyzing the security 725 of the solution. In particular, if confidential information, such as 726 a secret key, is transferred to the client, it MUST be done using 727 secure communication to prevent attackers from obtaining or modifying 728 the key. Also, the ticket MUST have its integrity and 729 confidentiality protected with strong cryptographic techniques to 730 prevent a breach in the security of the system. 732 7.7. Identity Privacy, Anonymity, and Unlinkability 734 This document mandates that the content of the ticket MUST be 735 encrypted in order to avoid leakage of information, such as the 736 identities of an IKEv2 initiator and a responder. Thus, it prevents 737 the disclosure of potentially sensitive information carried within 738 the ticket. 740 When an IKEv2 initiator presents the ticket as part of the first 741 message of the IKE_SA_INIT exchange, confidentiality is not provided 742 for the exchange. Although the ticket itself is encrypted there 743 might still be a possibility for an on-path adversary to observe 744 multiple exchange handshakes where the same ticket is used and 745 therefore to conclude that they belong to the same communication end 746 points. Administrators that use the ticket mechanism described in 747 this document should be aware that unlinkability may not be provided 748 by this mechanism. Note, however, that IKEv2 does not provide active 749 user identity confidentiality for the IKEv2 initiator either. 751 7.8. Usage of IKE Cookies 753 The extension specified in this document eliminates most potential 754 denial-of-service attacks that the cookie mechanism aims to solve. 755 However, memory exhaustion remains possible. Therefore the cookie 756 mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the 757 gateway for the IKE_SESSION_RESUME exchange described in Section 4.2. 759 7.9. Replay protection in the IKE_SESSION_RESUME EXCHANGE 761 A major design goal of the current protocol has been the two-message 762 exchange for session resumption. There is a tradeoff between this 763 abbreviated exchange and replay protection. Using our counter-based 764 solution, an attacker cannot replay a ticket to a gateway that had 765 seen this same ticket before. However the attacker can attempt to 766 replay a ticket to another gateway, and create intermittent IKE state 767 (but no successful establishment of an IKE SA). The standard Cookie 768 mechanism can be used to mitigate this risk. 770 8. Acknowledgements 772 We would like to thank Paul Hoffman, Pasi Eronen and Yoav Nir for 773 their review of earlier drafts. 775 9. References 777 9.1. Normative References 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 783 RFC 4306, December 2005. 785 9.2. Informative References 787 [I-D.friedman-ike-short-term-certs] 788 Friedman, A., "Short-Term Certificates", 789 draft-friedman-ike-short-term-certs-02 (work in progress), 790 June 2007. 792 [I-D.rescorla-stateless-tokens] 793 Rescorla, E., "How to Implement Secure (Mostly) Stateless 794 Tokens", draft-rescorla-stateless-tokens-01 (work in 795 progress), March 2007. 797 [I-D.vidya-ipsec-failover-ps] 798 Narayanan, V., "IPsec Gateway Failover and Redundancy - 799 Problem Statement and Goals", 800 draft-vidya-ipsec-failover-ps-02 (work in progress), 801 May 2007. 803 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 804 Requirements for Security", BCP 106, RFC 4086, June 2005. 806 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 807 Internet Protocol", RFC 4301, December 2005. 809 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 810 (IKEv2) Protocol", RFC 4478, April 2006. 812 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 813 "Transport Layer Security (TLS) Session Resumption without 814 Server-Side State", RFC 4507, May 2006. 816 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 817 (MOBIKE)", RFC 4555, June 2006. 819 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 820 Implementation Guidelines", RFC 4718, October 2006. 822 Appendix A. Related Work 824 [I-D.friedman-ike-short-term-certs] is on-going work that discusses 825 the use of short-term certificates for client re-authentication. It 826 is similar to the ticket approach described in this document in that 827 they both require enhancements to IKEv2 to allow information request, 828 e.g., for a certificate or a ticket. However, the changes required 829 by the former are fewer since an obtained certificate is valid for 830 any IKE responder that is able to verify them. On the other hand, 831 short-term certificates, while eliminating the usability issues of 832 user re-authentication, do not reduce the amount of effort performed 833 by the gateway in failover situations. 835 Appendix B. Change Log 837 B.1. -00 839 Initial version. This draft is a selective merge of 840 draft-sheffer-ike-session-resumption-00 and 841 draft-dondeti-ipsec-failover-sol-00. 843 Authors' Addresses 845 Yaron Sheffer 846 Check Point Software Technologies Ltd. 847 5 Hasolelim st. 848 Tel Aviv 67897 849 Israel 851 Email: yaronf@checkpoint.com 853 Hannes Tschofenig 854 Nokia Siemens Networks 855 Otto-Hahn-Ring 6 856 Munich, Bavaria 81739 857 Germany 859 Email: Hannes.Tschofenig@nsn.com 860 URI: http://www.tschofenig.com 862 Lakshminath Dondeti 863 QUALCOMM, Inc. 864 5775 Morehouse Dr 865 San Diego, CA 866 USA 868 Phone: +1 858-845-1267 869 Email: ldondeti@qualcomm.com 870 Vidya Narayanan 871 QUALCOMM, Inc. 872 5775 Morehouse Dr 873 San Diego, CA 874 USA 876 Phone: +1 858-845-2483 877 Email: vidyan@qualcomm.com 879 Full Copyright Statement 881 Copyright (C) The IETF Trust (2007). 883 This document is subject to the rights, licenses and restrictions 884 contained in BCP 78, and except as set forth therein, the authors 885 retain all their rights. 887 This document and the information contained herein are provided on an 888 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 889 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 890 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 891 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 892 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 893 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 895 Intellectual Property 897 The IETF takes no position regarding the validity or scope of any 898 Intellectual Property Rights or other rights that might be claimed to 899 pertain to the implementation or use of the technology described in 900 this document or the extent to which any license under such rights 901 might or might not be available; nor does it represent that it has 902 made any independent effort to identify any such rights. Information 903 on the procedures with respect to rights in RFC documents can be 904 found in BCP 78 and BCP 79. 906 Copies of IPR disclosures made to the IETF Secretariat and any 907 assurances of licenses to be made available, or the result of an 908 attempt made to obtain a general license or permission for the use of 909 such proprietary rights by implementers or users of this 910 specification can be obtained from the IETF on-line IPR repository at 911 http://www.ietf.org/ipr. 913 The IETF invites any interested party to bring to its attention any 914 copyrights, patents or patent applications, or other proprietary 915 rights that may cover technology that may be required to implement 916 this standard. Please address the information to the IETF at 917 ietf-ipr@ietf.org. 919 Acknowledgment 921 Funding for the RFC Editor function is provided by the IETF 922 Administrative Support Activity (IASA).