idnits 2.17.00 (12 Aug 2021) /tmp/idnits16849/draft-sheffer-ipsec-failover-02.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 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1006. 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 365, but not defined == Missing Reference: 'TSi' is mentioned on line 459, but not defined == Missing Reference: 'TSr' is mentioned on line 459, but not defined -- Looks like a reference, but probably isn't: '16' on line 673 ** 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-02.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 roundstrips and 50 therefore latency. 52 To re-establish security associations (SA) upon a failure recovery 53 condition is time consuming, especially when an IPsec peer, such as a 54 VPN gateway, needs to re-establish a large number of SAs with various 55 end points. A high number of concurrent sessions might cause 56 additional problems for an IPsec peer during SA re-establishment. 58 In many failure cases it would be useful to provide an efficient way 59 to resume an interrupted IKE/IPsec session. This document proposes 60 an extension to IKEv2 that allows a client to re-establish an IKE SA 61 with a gateway in a highly efficient manner, utilizing a previously 62 established IKE SA. 64 A client can reconnect to a gateway from which it was disconnected, 65 or alternatively migrate to another gateway that is associated with 66 the previous one. The proposed approach conveys IKEv2 state 67 information, in the form of an encrypted ticket, to a VPN client that 68 is later presented to the VPN gateway for re-authentication. The 69 encrypted ticket can only be decrypted by the VPN gateway in order to 70 restore state for faster session setup. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6 80 3.2. Recovering from an Application Server Failover . . . . . . 8 81 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 82 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9 83 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 84 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12 85 4.2.2. Requesting a ticket during resumption . . . . . . . . 12 86 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 12 87 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 13 88 4.5. TICKET_COUNTER Notify Payload . . . . . . . . . . . . . . 13 89 4.6. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14 90 4.7. Processing Guidelines for IKE SA Establishment . . . . . . 15 91 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16 92 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16 93 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 16 94 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 17 98 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18 99 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 100 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 18 101 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 18 102 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 19 103 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 19 104 7.8. Usage of IKE Cookies . . . . . . . . . . . . . . . . . . . 19 105 7.9. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 19 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 109 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 110 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 21 111 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 112 B.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 113 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 114 B.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 116 Intellectual Property and Copyright Statements . . . . . . . . . . 23 118 1. Introduction 120 The Internet Key Exchange version 2 (IKEv2) protocol has 121 computational and communication overhead with respect to the number 122 of round-trips required and cryptographic operations involved. In 123 particular the Extensible Authentication Protocol is used for 124 authentication in remote access cases, which adds additional latency. 126 To re-establish security associations (SA) upon a failure recovery 127 condition is time-consuming, especially when an IPsec peer, such as a 128 VPN gateway, needs to re-establish a large number of SAs with various 129 end points. A high number of concurrent sessions might cause 130 additional problems for an IPsec peer. 132 In many failure cases it would be useful to provide an efficient way 133 to resume an interrupted IKE/IPsec session. This document proposes 134 an extension to IKEv2 that allows a client to re-establish an IKE SA 135 with a gateway in a highly efficient manner, utilizing a previously 136 established IKE SA. 138 A client can reconnect to a gateway from which it was disconnected, 139 or alternatively migrate to another gateway that is associated with 140 the previous one. This document proposes to maintain IKEv2 state in 141 a "ticket", an opaque data structure created and used by a server and 142 stored by a client, which the client cannot understand or tamper 143 with. The IKEv2 protocol needs to be extended to allow a client to 144 request and present a ticket. When two gateways mutually trust each 145 other, one can accept a ticket generated by the other. 147 This approach is similar to the one taken by TLS session resumption 148 [RFC4507] with the required adaptations for IKEv2, e.g., to 149 accommodate the two-phase protocol structure. We have borrowed 150 heavily from that specification. 152 1.1. Goals 154 The high-level goal of this extension is to provide an IPsec failover 155 solution, according to the requirements defined in 156 [I-D.vidya-ipsec-failover-ps]. 158 Specifically, the proposed extension should allow IPsec sessions to 159 be recovered from failures in remote access scenarios, in a more 160 efficient manner than the basic IKE solution. This efficiency is 161 primarily on the gateway side, since the gateway might have to deal 162 with many thousands of concurrent requests. We should enable the 163 following cases: 165 o Failover from one gateway to another, where the two gateways do 166 not share state but do have mutual trust. For example, the 167 gateways may be operated by the same provider and share the same 168 keying materials to access an encrypted ticket. 169 o Recovery from an intermittent connectivity, where clients 170 reconnect into the same gateway. In this case, the gateway would 171 typically have detected the clients' absence and removed the state 172 associated with them. 173 o Recovery from a gateway restart, where clients reconnect into the 174 same gateway. 176 The proposed solution should additionally meet the following goals: 178 o Using only symmetric cryptography to minimize CPU consumption. 179 o Allowing a gateway to push state to clients. 180 o Providing cryptographic agility. 181 o Having no negative impact on IKEv2 security features. 182 Specifically, the solution must not introduce new security 183 vulnerabilities, such as vulnerabilities to denial-of-service 184 attacks. 186 1.2. Non-Goals 188 The following are non-goals of this solution: 189 o Providing load balancing among gateways. 190 o Specifying how a client detects the need for a failover. 191 o Establishing trust among gateways. 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 This document uses terminology defined in [RFC4301], [RFC4306], and 200 [RFC4555]. In addition, this document uses the following terms: 202 Secure domain: A secure domain comprises a set of gateways that are 203 able to resume an IKEv2 session that may have been established by 204 any other gateway within the domain. All gateways in the secure 205 domain are expected to share a security association - either with 206 each other or through a trusted third party - so that they can 207 verify the validity of the ticket and can extract the IKEv2 policy 208 and session key material from the ticket. 210 IKEv2 ticket: An IKEv2 ticket is a data structure that contains all 211 the necessary information that allows any gateway within the same 212 secure domain as the gateway that created the ticket to verify the 213 validity of the ticket and extract IKEv2 policy and session keys 214 to re-establish an IKEv2 session. 215 Stateless failover: When the IKEv2 session state is stored at the 216 client, the IKEv2 responder is "stateless" until the client 217 restores the SA with one of the gateways within the secure domain; 218 thus, we refer to SA resumption with SA storage at the client as 219 stateless session resumption. 220 Stateful failover: When the infrastructure maintains IKEv2 session 221 state, we refer to the process of IKEv2 SA re-establishment as 222 stateful session resumption. 224 3. Usage Scenarios 226 This specification envisions two usage scenarios for efficient IKEv2 227 and IPsec SA session re-establishment. 229 The first is similar to the use case specified in Section 1.1.3 of 230 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 231 used to establish a secure channel between a remote access client and 232 a gateway; the traffic flow may be between the client and entities 233 beyond the gateway. 235 The second use case focuses on the usage of transport (or tunnel) 236 mode to secure the communicate between two end points (e.g., two 237 servers). The two endpoints have a client-server relationship with 238 respect to a protocol that runs using the protections afforded by the 239 IPsec SA. 241 3.1. Recovering from a Remote Access Gateway Failover 242 (a) 244 +-+-+-+-+-+ +-+-+-+-+-+ 245 ! ! IKEv2/IKEv2-EAP ! ! Protected 246 ! Remote !<------------------------>! Remote ! Subnet 247 ! Access ! ! Access !<--- and/or 248 ! Client !<------------------------>! Gateway ! Internet 249 ! ! IPsec tunnel ! ! 250 +-+-+-+-+-+ +-+-+-+-+-+ 252 (b) 254 +-+-+-+-+-+ +-+-+-+-+-+ 255 ! ! IKE_SESSION_RESUME ! ! 256 ! Remote !<------------------------>! New/Old ! 257 ! Access ! ! Gateway ! 258 ! Client !<------------------------>! ! 259 ! ! IPsec tunnel ! ! 260 +-+-+-+-+-+ +-+-+-+-+-+ 262 Figure 1: Remote Access Gateway Failure 264 In this scenario, an end-host (an entity with a host implementation 265 of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a 266 gateway in a remote network using IKEv2. The end-host in this 267 scenario is sometimes referred to as a remote access client. When 268 the remote gateway fails, all the clients associated with the gateway 269 either need to re-establish IKEv2 sessions with another gateway 270 within the same secure domain of the original gateway, or with the 271 original gateway if the server is back online soon. 273 The clients may choose to establish IPsec SAs using a full IKEv2 274 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). 276 In this scenario, the client needs to get an IP address from the 277 remote network so that traffic can be encapsulated by the remote 278 access gateway before reaching the client. In the initial exchange, 279 the gateway may acquire IP addresses from the address pool of a local 280 DHCP server. The new gateway that a client gets associated may not 281 receive addresses from the same address pool. Thus, the session 282 resumption protocol needs to support the assignment of a new IP 283 address. 285 3.2. Recovering from an Application Server Failover 287 (a) 289 +-+-+-+-+-+ +-+-+-+-+-+ 290 ! App. ! IKEv2/IKEv2-EAP ! App. ! 291 ! Client !<------------------------>! Server ! 292 ! & ! ! & ! 293 ! IPsec !<------------------------>! IPsec ! 294 ! host ! IPsec transport/ ! host ! 295 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 297 (b) 299 +-+-+-+-+-+ +-+-+-+-+-+ 300 ! App. ! IKE_SESSION_RESUME ! New ! 301 ! Client !<------------------------>! Server ! 302 ! & ! ! & ! 303 ! IPsec !<------------------------>! IPsec ! 304 ! host ! IPsec transport/ ! host ! 305 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 307 Figure 2: Application Server Failover 309 The second usage scenario is as follows: two entities with IPsec host 310 implementations establish an IPsec transport or tunnel mode SA 311 between themselves; this is similar to the model described in Section 312 1.1.2. of [RFC4306]. At the application level, one of the entities 313 is always the client and the other is a server. From that view 314 point, the IKEv2 exchange is always initiated by the client. This 315 allows the Initiator (the client) to authenticate itself using EAP, 316 as long as the Responder (or the application server) allows it. 318 If the application server fails, the client may find other servers 319 within the same secure domain for service continuity. It may use a 320 full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- 321 establish the IPsec SAs for secure communication required by the 322 application layer signaling. 324 The client-server relationship at the application layer ensures that 325 one of the entities in this usage scenario is unambiguously always 326 the Initiator and the other the Responder. This role determination 327 also allows the Initiator to request an address in the Responder's 328 network using the Configuration Payload mechanism of the IKEv2 329 protocol. If the client has thus received an address during the 330 initial IKEv2 exchange, when it associates with a new server upon 331 failure of the original server, it needs to request an address, 332 specifying its assigned address. The server may allow the client to 333 use the original address or if it is not permitted to use that 334 address, assign a new address. 336 4. Protocol Details 338 This section provides protocol details and contains the normative 339 parts. This document defines two protocol exchanges, namely 340 requesting a ticket and presenting a ticket. Section 4.1 describes 341 the procedure to request a ticket and Section 4.2 illustrates how to 342 present a ticket. 344 4.1. Requesting a Ticket 346 A client MAY request a ticket in the following exchanges: 348 o In an IKE_AUTH exchange, as shown in the example message exchange 349 in Figure 3 below. 350 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. 351 o In an Informational exchange, if the gateway previously replied 352 with an N(TICKET_ACK) instead of providing a ticket. 353 o In an Informational exchange, when the ticket lifetime is about to 354 expire. 355 o In an IKE_SESSION_RESUME exchange, see Section 4.2.2. 357 Normally, a client requests a ticket in the third message of an IKEv2 358 exchange (the first of IKE_AUTH). Figure 3 shows the message 359 exchange for this typical case. 361 Initiator Responder 362 ----------- ----------- 363 HDR, SAi1, KEi, Ni --> 365 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 367 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 368 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 370 Figure 3: Example Message Exchange for Requesting a Ticket 372 The notification payloads are described in Section 4.3. The above is 373 an example, and IKEv2 allows a number of variants on these messages. 374 A complete description of IKEv2 can be found in [RFC4718]. 376 When an IKEv2 responder receives a request for a ticket using the 377 N(TICKET_REQUEST) payload it MUST perform one of the following 378 operations if it supports the extension defined in this document: 379 o it creates a ticket and returns it with the N(TICKET_OPAQUE) 380 payload in a subsequent message towards the IKEv2 initiator. This 381 is shown in Figure 4. 382 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 383 ticket for some reason. 384 o it returns an N(TICKET_ACK), if it cannot grant a ticket 385 immediately, e.g., due to packet size limitations. In this case 386 the client MAY request a ticket later using an Informational 387 exchange, at any time during the lifetime of the IKE SA. 389 Provided the IKEv2 exchange was successful, the IKEv2 initiator can 390 accept the requested ticket. The ticket may be used later with an 391 IKEv2 responder which supports this extension. Figure 4 shows how 392 the initiator receives the ticket. 394 Initiator Responder 395 ----------- ----------- 396 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 397 TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} 399 Figure 4: Receiving a Ticket 401 4.2. Presenting a Ticket 403 Following a communication failure, a client re-initiates an IKE 404 exchange to the same gateway or to a different one, and includes a 405 ticket in the first message. A client MAY initiate a regular (non- 406 ticket-based) IKEv2 exchange even if it is in possession of a valid 407 ticket. A client MUST NOT present a ticket after the ticket's 408 lifetime has expired. 410 It is up to the client's local policy to decide when the 411 communication with the IKEv2 responder is seen as interrupted and a 412 new exchange needs to be initiated and the session resumption 413 procedure to be initiated. 415 This document specifies a new IKEv2 exchange type called 416 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 417 somewhat similar to the IKE_AUTH exchange, and results in the 418 creation of a Child SA. The client MUST NOT use this exchange unless 419 it knows that the gateway supports failover, either through 420 configuration, by out-of-band means or by using the Gateway List 421 provision. 423 Initiator Responder 424 ----------- ----------- 425 HDR, N(TICKET_COUNTER), Ni, N(TICKET_OPAQUE), [N+,] 426 SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)] 427 [, N(UPDATE_SA_ADDRESSES)]} --> 429 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. 431 See Section 4.2.1 for details on computing the protected (SK) 432 payload. 434 The client MUST increment the counter value each time it uses this 435 same ticket to resume the session. When the gateway receives a 436 resumption request for a ticket it has seen in the past, it MUST 437 reject the request unless the counter value is larger than its 438 previous value. 440 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 441 payload it MUST perform one of the following steps if it supports the 442 extension defined in this document: 443 o If it is willing to accept the ticket, it responds as shown in 444 Figure 6. 445 o It responds with an unprotected N(TICKET_NACK) notification, if it 446 rejects the ticket for any reason. In that case, the initiator 447 should re-initiate a regular IKE exchange. One such case is when 448 the responder receives a ticket for an IKE SA that has previously 449 been terminated on the responder itself, which may indicate 450 inconsistent state between the IKEv2 initiator and the responder. 451 However, a responder is not required to maintain the state for 452 terminated sessions. 453 o When the responder receives a ticket for an IKE SA that is still 454 active and if the responder accepts it, then the old SAs SHOULD be 455 silently deleted without sending a DELETE informational exchange. 457 Initiator Responder 458 ----------- ----------- 459 <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], 460 [CP(CFG_REPLY)]} 462 Figure 6: IKEv2 Responder accepts the ticket 464 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. 466 The SK payload is protected using the cryptographic parameters 467 derived from the ticket, see Section 4.2.1 below. 469 At this point a new IKE SA is created by both parties, see 470 Section 4.7. This is followed by normal derivation of a child SA, 471 per Sec. 2.17 of [RFC4306]. 473 4.2.1. Protection of the IKE_SESSION_RESUME Exchange 475 The two messages of this exchange are protected by a "subset" IKE SA. 476 The key material is derived from the ticket, as follows: 478 {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) 480 where SK_d_old is the SK_d value of the original IKE SA, as retrieved 481 from the ticket. Ni guarantees freshness of the key material. SK_d2 482 is used later to derive the new IKE SA, see Section 4.7. 484 See [RFC4306] for the notation. "prf" is determined from the SA value 485 in the ticket. 487 4.2.2. Requesting a ticket during resumption 489 When resuming a session, a client will typically request a new ticket 490 immediately, so it is able to resume the session again in the case of 491 a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) 492 and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as 493 protected payloads to the IKE_SESSION_RESUME exchange. 495 The returned ticket (if any) will correspond to the IKE SA created 496 per the rules described in Section 4.7. 498 4.3. IKE Notifications 500 This document defines a number of notifications. The notification 501 numbers are TBA by IANA. 503 +---------------------+--------+-----------------+ 504 | Notification Name | Number | Data | 505 +---------------------+--------+-----------------+ 506 | TICKET_OPAQUE | TBA1 | See Figure 8 | 507 | TICKET_REQUEST | TBA2 | None | 508 | TICKET_ACK | TBA3 | None | 509 | TICKET_NACK | TBA4 | None | 510 | TICKET_COUNTER | TBA5 | See Section 4.5 | 511 | TICKET_GATEWAY_LIST | TBA6 | See Section 4.6 | 512 +---------------------+--------+-----------------+ 514 4.4. TICKET_OPAQUE Notify Payload 516 The data for the TICKET_OPAQUE Notify payload consists of the Notify 517 message header, a lifetime field and the ticket itself. The four 518 octet lifetime field contains the number of seconds until the ticket 519 expires as an unsigned integer. Section 5.2 describes a possible 520 ticket format, and Section 5.3 offers further guidelines regarding 521 the ticket's lifetime. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 ! Next Payload !C! Reserved ! Payload Length ! 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ! Lifetime ! 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 ! ! 533 ~ Ticket ~ 534 ! ! 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 8: TICKET_OPAQUE Notify Payload 539 4.5. TICKET_COUNTER Notify Payload 541 The data for the TICKET_COUNTER Notify payload consists of the Notify 542 message header followed by a single octet, treated as an unsigned 543 integer as shown below. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 ! Next Payload !C! Reserved ! Payload Length ! 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 ! Counter ! 553 +-+-+-+-+-+-+-+-+ 555 Figure 9: TICKET_COUNTER Notify Payload 557 4.6. TICKET_GATEWAY_LIST Notify Payload 559 The TICKET_GATEWAY_LIST Notify payload contains the Notify payload 560 header followed by a sequence of one or more gateway identifiers, 561 each of the format depicted in Figure 11. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 ! Next Payload !C! Reserved ! Payload Length ! 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 ! ! 571 ~ Gateway Identifier List ~ 572 ! ! 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 10: TICKET_GATEWAY_LIST Notify Payload 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 ! ID Type ! Reserved ! Length ! 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 ! ! 583 ~ Identification Data ~ 584 ! ! 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 11: Gateway Identifier for One Gateway 589 ID Type: 591 The ID Type contains a restricted set of the IKEv2 ID payloads 592 (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR, 593 ID_IPV6_ADDR, ID_FQDN and the various reserved values. 595 Reserved: 597 This field must be sent as 0 and must be ignored when received. 599 Length: 601 The length field indicates the total size of the Identification 602 data. 604 Identification Data: 606 The Identification Data field is of variable length and depends on 607 the ID type. The length is not necessarily a multiple of 4. 609 4.7. Processing Guidelines for IKE SA Establishment 611 When a ticket is presented, the gateway parses the ticket to retrieve 612 the state of the old IKE SA, and the client retrieves this state from 613 its local store. Both peers now create state for the new IKE SA as 614 follows: 616 o The SA value (transforms etc.) is taken directly from the ticket. 617 o The sequence numbers are reset to 0. 618 o The IDi value is obtained from the ticket. 619 o The IDr value is obtained from the new exchange. The gateway MAY 620 make policy decisions based on the IDr value encoded in the 621 ticket. 622 o The SPI values are created anew, similarly to a regular IKE 623 exchange. SPI values from the ticket SHOULD NOT be reused. This 624 restriction is to avoid problems caused by collisions with other 625 SPI values used already by the initiator/responder. The SPI value 626 should only be reused if collision avoidance can be ensured 627 through other means. 629 The cryptographic material is refreshed based on the ticket and the 630 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 631 value is derived as follows: 633 SKEYSEED = prf(SK_d2, Ni | Nr) 635 where SK_d2 was computed earlier (Section 4.2.1). 637 The keys are derived as follows, unchanged from IKEv2: 639 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 640 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 642 where SPIi, SPIr are the SPI values created in the new IKE exchange. 644 See [RFC4306] for the notation. "prf" is determined from the SA value 645 in the ticket. 647 5. The IKE Ticket 649 This section lists the required contents of the ticket, and 650 recommends a non-normative format. This is followed by a discussion 651 of the ticket's lifecycle. 653 5.1. Ticket Contents 655 The ticket MUST encode at least the following state from an IKE SA. 656 These values MUST be encrypted and authenticated. 658 o IDi, IDr. 659 o SPIi, SPIr. 660 o SAr (the accepted proposal). 661 o SK_d. 663 In addition, the ticket MUST encode a protected ticket expiration 664 value. 666 5.2. Ticket Format 668 This document does not specify a mandatory-to-implement or a 669 mandatory-to-use ticket format. The following format illustrates a 670 potential ticket implementation. 672 struct { 673 opaque key_name[16]; // ASCII, null-terminated 674 opaque IV[0..255]; // the length (possibly 0) depends 675 // on the encryption algorithm 677 [encrypted] struct { 678 opaque IDi, IDr; // the full payloads 679 opaque SPIi, SPIr; 680 opaque SA; // the full payload, returned as SAr 681 opaque SK_d; 682 opaque expiration; // an absolute time value 683 } ikev2_state; // encrypted and authenticated 684 opaque MAC[0..255]; // the length (possibly 0) depends 685 // on the integrity algorithm 686 } ticket; 688 Note that the key defined by "key_name" determines the encryption and 689 authentication algorithms used for this ticket. Those algorithms are 690 unrelated to the transforms defined by the SA payload. 692 The reader is referred to a recent draft 693 [I-D.rescorla-stateless-tokens] that recommends a similar (but not 694 identical) ticket format, and discusses related security 695 considerations in depth. 697 5.3. Ticket Identity and Lifecycle 699 Each ticket is associated with a single IKE SA. In particular, when 700 an IKE SA is deleted, the client MUST delete its stored ticket. 702 A ticket is therefore associated with the tuple (IDi, IDr). The 703 client MAY however use a ticket to approach other gateways that are 704 willing to accept it. How a client discovers such gateways is 705 outside the scope of this document. 707 The lifetime of the ticket carried in the N(TICKET_OPAQUE) 708 notification should be the minimum of the IKE SA lifetime (per the 709 gateway's local policy) and its re-authentication time, according to 710 [RFC4478]. Even if neither of these are enforced by the gateway, a 711 finite lifetime MUST be specified for the ticket. 713 6. IANA Considerations 715 This document requires a number of IKEv2 notification status types in 716 Section 4.3, to be registered by IANA. The corresponding registry 717 was established by IANA. 719 The document defines a new IKEv2 exchange in Section 4.2. The 720 corresponding registry was established by IANA. 722 7. Security Considerations 724 This section addresses security issues related to the usage of a 725 ticket. 727 7.1. Stolen Tickets 729 An eavesdropper or man-in-the-middle may try to obtain a ticket and 730 use it to establish a session with the IKEv2 responder. This can 731 happen in different ways: by eavesdropping on the initial 732 communication and copying the ticket when it is granted and before it 733 is used, or by listening in on a client's use of the ticket to resume 734 a session. However, since the ticket's contents is encrypted and the 735 attacker does not know the corresponding secret key (specifically, 736 SK_d), a stolen ticket cannot be used by an attacker to resume a 737 session. An IKEv2 responder MUST use strong encryption and integrity 738 protection of the ticket to prevent an attacker from obtaining the 739 ticket's contents, e.g., by using a brute force attack. 741 7.2. Forged Tickets 743 A malicious user could forge or alter a ticket in order to resume a 744 session, to extend its lifetime, to impersonate as another user, or 745 to gain additional privileges. This attack is not possible if the 746 ticket is protected using a strong integrity protection algorithm. 748 7.3. Denial of Service Attacks 750 The key_name field defined in the recommended ticket format helps the 751 server efficiently reject tickets that it did not issue. However, an 752 adversary could generate and send a large number of tickets to a 753 gateway for verification. To minimize the possibility of such denial 754 of service, ticket verification should be lightweight (e.g., using 755 efficient symmetric key cryptographic algorithms). See also 756 Section 7.8. 758 7.4. Ticket Protection Key Management 760 A full description of the management of the keys used to protect the 761 ticket is beyond the scope of this document. A list of RECOMMENDED 762 practices is given below. 763 o The keys should be generated securely following the randomness 764 recommendations in [RFC4086]. 765 o The keys and cryptographic protection algorithms should be at 766 least 128 bits in strength. 767 o The keys should not be used for any other purpose than generating 768 and verifying tickets. 769 o The keys should be changed regularly. 770 o The keys should be changed if the ticket format or cryptographic 771 protection algorithms change. 773 7.5. Ticket Lifetime 775 An IKEv2 responder controls the lifetime of a ticket, based on the 776 operational and security requirements of the environment in which it 777 is deployed. The responder provides information about the ticket 778 lifetime to the IKEv2 initiator, allowing it to manage its tickets. 780 An IKEv2 client may present a ticket in its possession to a gateway, 781 even if the IKE SA associated with this ticket had previously been 782 terminated by another gateway (the gateway that originally provided 783 the ticket). Where such usage is against the local security policy, 784 an Invalid Ticket List (ITL) may be used, see 785 [I-D.rescorla-stateless-tokens]. Management of such lists is outside 786 the scope of the current document. Note that a policy that requires 787 tickets to have shorter lifetimes (e.g., 1 hour) significantly 788 mitigates this risk. 790 7.6. Alternate Ticket Formats and Distribution Schemes 792 If the ticket format or distribution scheme defined in this document 793 is not used, then great care must be taken in analyzing the security 794 of the solution. In particular, if confidential information, such as 795 a secret key, is transferred to the client, it MUST be done using 796 secure communication to prevent attackers from obtaining or modifying 797 the key. Also, the ticket MUST have its integrity and 798 confidentiality protected with strong cryptographic techniques to 799 prevent a breach in the security of the system. 801 7.7. Identity Privacy, Anonymity, and Unlinkability 803 This document mandates that the content of the ticket MUST be 804 encrypted in order to avoid leakage of information, such as the 805 identities of an IKEv2 initiator and a responder. Thus, it prevents 806 the disclosure of potentially sensitive information carried within 807 the ticket. 809 When an IKEv2 initiator presents the ticket as part of the 810 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 811 exchange. Although the ticket itself is encrypted there might still 812 be a possibility for an on-path adversary to observe multiple 813 exchange handshakes where the same ticket is used and therefore to 814 conclude that they belong to the same communication end points. 815 Administrators that use the ticket mechanism described in this 816 document should be aware that unlinkability may not be provided by 817 this mechanism. Note, however, that IKEv2 does not provide active 818 user identity confidentiality for the IKEv2 initiator either. 820 7.8. Usage of IKE Cookies 822 The extension specified in this document eliminates most potential 823 denial-of-service attacks that the cookie mechanism aims to solve. 824 However, memory exhaustion remains possible. Therefore the cookie 825 mechanism described in Section 2.6 of [RFC4306] MAY be invoked by the 826 gateway for the IKE_SESSION_RESUME exchange described in Section 4.2. 828 7.9. Replay Protection in the IKE_SESSION_RESUME Exchange 830 A major design goal of this protocol extension has been the two- 831 message exchange for session resumption. There is a tradeoff between 832 this abbreviated exchange and replay protection. Using the counter- 833 based replay protection solution, an attacker cannot replay a ticket 834 to a gateway that had seen the same ticket before. The counter value 835 that is incremented for each ticket usage by the client cannot be 836 modified by an adversary due to the integrity protection being 837 applied (see Section 4.2, and note that the SK payload integrity- 838 protects the entire message, per RFC 4306, Sec. 3.14). The gateway 839 must only store the most recent counter value once the verification 840 of the mssage and the ticket was successful. 842 However, the attacker can attempt to replay a ticket to another 843 gateway, and create intermittent IKE state (but no successful 844 establishment of an IKE SA). The standard IKE Cookie mechanism can 845 be used to mitigate this risk. 847 8. Acknowledgements 849 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler and 850 Yoav Nir for their review of earlier drafts. 852 9. References 854 9.1. Normative References 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 860 RFC 4306, December 2005. 862 9.2. Informative References 864 [I-D.friedman-ike-short-term-certs] 865 Friedman, A., "Short-Term Certificates", 866 draft-friedman-ike-short-term-certs-02 (work in progress), 867 June 2007. 869 [I-D.rescorla-stateless-tokens] 870 Rescorla, E., "How to Implement Secure (Mostly) Stateless 871 Tokens", draft-rescorla-stateless-tokens-01 (work in 872 progress), March 2007. 874 [I-D.vidya-ipsec-failover-ps] 875 Narayanan, V., "IPsec Gateway Failover and Redundancy - 876 Problem Statement and Goals", 877 draft-vidya-ipsec-failover-ps-02 (work in progress), 878 May 2007. 880 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 881 Requirements for Security", BCP 106, RFC 4086, June 2005. 883 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 884 Internet Protocol", RFC 4301, December 2005. 886 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 887 (IKEv2) Protocol", RFC 4478, April 2006. 889 [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 890 "Transport Layer Security (TLS) Session Resumption without 891 Server-Side State", RFC 4507, May 2006. 893 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 894 (MOBIKE)", RFC 4555, June 2006. 896 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 897 Implementation Guidelines", RFC 4718, October 2006. 899 Appendix A. Related Work 901 [I-D.friedman-ike-short-term-certs] is on-going work that discusses 902 the use of short-term certificates for client re-authentication. It 903 is similar to the ticket approach described in this document in that 904 they both require enhancements to IKEv2 to allow information request, 905 e.g., for a certificate or a ticket. However, the changes required 906 by the former are fewer since an obtained certificate is valid for 907 any IKE responder that is able to verify them. On the other hand, 908 short-term certificates, while eliminating the usability issues of 909 user re-authentication, do not reduce the amount of effort performed 910 by the gateway in failover situations. 912 Appendix B. Change Log 914 B.1. -02 916 Clarifications on generation of SPI values, on the ticket's lifetime 917 and on the integrity protection of the anti-replay counter. 918 Eliminated redundant SPIs from the notification payloads. 920 B.2. -01 922 Editorial review. Removed 24-hour limitation on ticket lifetime, 923 lifetime is up to local policy. 925 B.3. -00 927 Initial version. This draft is a selective merge of 928 draft-sheffer-ike-session-resumption-00 and 929 draft-dondeti-ipsec-failover-sol-00. 931 Authors' Addresses 933 Yaron Sheffer 934 Check Point Software Technologies Ltd. 935 5 Hasolelim St. 936 Tel Aviv 67897 937 Israel 939 Email: yaronf@checkpoint.com 941 Hannes Tschofenig 942 Nokia Siemens Networks 943 Otto-Hahn-Ring 6 944 Munich, Bavaria 81739 945 Germany 947 Email: Hannes.Tschofenig@nsn.com 948 URI: http://www.tschofenig.com 950 Lakshminath Dondeti 951 QUALCOMM, Inc. 952 5775 Morehouse Dr 953 San Diego, CA 954 USA 956 Phone: +1 858-845-1267 957 Email: ldondeti@qualcomm.com 959 Vidya Narayanan 960 QUALCOMM, Inc. 961 5775 Morehouse Dr 962 San Diego, CA 963 USA 965 Phone: +1 858-845-2483 966 Email: vidyan@qualcomm.com 968 Full Copyright Statement 970 Copyright (C) The IETF Trust (2007). 972 This document is subject to the rights, licenses and restrictions 973 contained in BCP 78, and except as set forth therein, the authors 974 retain all their rights. 976 This document and the information contained herein are provided on an 977 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 978 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 979 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 980 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 981 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 982 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 984 Intellectual Property 986 The IETF takes no position regarding the validity or scope of any 987 Intellectual Property Rights or other rights that might be claimed to 988 pertain to the implementation or use of the technology described in 989 this document or the extent to which any license under such rights 990 might or might not be available; nor does it represent that it has 991 made any independent effort to identify any such rights. Information 992 on the procedures with respect to rights in RFC documents can be 993 found in BCP 78 and BCP 79. 995 Copies of IPR disclosures made to the IETF Secretariat and any 996 assurances of licenses to be made available, or the result of an 997 attempt made to obtain a general license or permission for the use of 998 such proprietary rights by implementers or users of this 999 specification can be obtained from the IETF on-line IPR repository at 1000 http://www.ietf.org/ipr. 1002 The IETF invites any interested party to bring to its attention any 1003 copyrights, patents or patent applications, or other proprietary 1004 rights that may cover technology that may be required to implement 1005 this standard. Please address the information to the IETF at 1006 ietf-ipr@ietf.org. 1008 Acknowledgment 1010 Funding for the RFC Editor function is provided by the IETF 1011 Administrative Support Activity (IASA).