idnits 2.17.1 draft-smyslov-ipsecme-ikev2-cookie-revised-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 18, 2021) is 921 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track October 18, 2021 5 Expires: April 21, 2022 7 Revised Cookie Processing in the IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-cookie-revised-02 10 Abstract 12 This document defines a revised processing of cookies in the Internet 13 Key Exchange protocol Version 2 (IKEv2). It is intended to solve a 14 problem in IKEv2 when due to packets loss and reordering peers may 15 erroneously fail to authenticate each other when cookies are used in 16 the initial IKEv2 exchange. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 21, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2 54 3. Using Cookies in IKEv2 . . . . . . . . . . . . . . . . . . . 3 55 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 56 5. Revised Cookie Processing . . . . . . . . . . . . . . . . . . 6 57 5.1. Negotiation of Revised Cookie Processing . . . . . . . . 6 58 5.2. Processing of REVISED_COOKIE Notification . . . . . . . . 7 59 5.3. Changes in AUTH Payload Calculation . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 The Internet Key Exchange protocol Version 2 (IKEv2) described in 69 [RFC7296] includes mechanism to defend against DoS attacks. The 70 mechanism is based on cookie which a responder can request an 71 initiator to return in a subsequent request. This allows the 72 responder avoid creating state until it is sure that the initiator's 73 IP address is not spoofed. The cookie mechanism is optional and it 74 is up to the responder whether to use it or not. 76 When cookie mechanism is used in networks with high probability of 77 packets loss and reordering, it is possible that peers end up with 78 different views on whether cookies were used or not or which content 79 the used cookie had. Since cookie, if used, is a part of an IKEv2 80 message that is included into calculation of authentication data by 81 both peers, the different views leads to the situation when peers 82 erroneously fail to authenticate each other. 84 This specification revises processing of cookies in IKEv2 in such a 85 way that peers supporting it exclude cookies from data to be 86 authenticated. This allows them to complete authentication even in 87 the situation described above. 89 2. Terminology and Notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. Using Cookies in IKEv2 99 Section 2.6 of [RFC7296] specifies that when a responder detects a 100 large number of half-open IKE SAs, it SHOULD reply to an IKE_SA_INIT 101 request with a response containing the COOKIE notification and If an 102 IKE_SA_INIT response includes the COOKIE notification, the initiator 103 MUST then retry the IKE_SA_INIT request, and include the COOKIE 104 notification containing the received data as the very first payload 105 in it, retaining all other payloads intact. This process is 106 illustrated in Figure 1. 108 Initiator Responder 109 ----------- ----------- 110 send req1: 111 HDR, SAi1, KEi, Ni --> recv req1, send resp1: 112 <-- HDR, N(COOKIE,c) 113 recv resp1, send req2: 114 HDR, N(COOKIE,c), 115 SAi1, KEi, Ni --> recv req2, send resp2: 116 <-- HDR, SAr1, KEr, Nr 117 recv resp2 119 Figure 1 121 Note, that the responder saves no state when it sends message resp1. 122 This is achieved due to the way cookies are generated. A good way to 123 generate a cookie is described in Section 2.6 of [RFC7296]: 125 Cookie = | Hash(Ni | IPi | SPIi | ) 127 where is a randomly generated secret known only to the 128 responder which is periodically changed. [RFC7296] advises the 129 responder to change the value of frequently, especially if 130 under attack. 132 Later in the IKE_AUTH exchange the IKE_SA_INIT messages are 133 authenticated by including their content intact into the data that is 134 signed (or MAC'ed) using peers' credentials (see Section 2.15 of 135 [RFC7296] for details). 137 4. Problem Description 139 To successfully complete authentication it is important that both 140 peers use the same content of the IKE_SA_INIT messages when 141 calculating authentication data. However, when cookies are employed, 142 the IKE_SA_INIT request is sent at least twice with different 143 content. Section 2.15. of [RFC7296] states that if the first message 144 of the IKE_SA_INIT exchange is sent multiple times with different 145 content (e.g. with a cookie), it is the latest version of the message 146 that is used for authentication. However, in situations when network 147 packets can be lost and reordered peers may end up with different 148 views on what is "the latest version of the message". Two examples 149 of such situations are shown below. 151 Consider a situation when at the time the initiator starts creating 152 IKE SA by sending req1 message the responder thinks it's under attack 153 and responds with a resp2 message containing cookie request. 154 However, this message is delayed in the network. 156 Initiator Responder 157 ----------- ----------- 158 send req1: 159 HDR, SAi1, KEi, Ni --> recv req1, send resp1: 160 (delayed) <-- HDR, N(COOKIE,c) 162 Since the initiator hasn't received any response, it retransmits its 163 initial request message req1 after some time. During this time the 164 situation on the responder has changed and it doesn't think it's 165 under attack anymore, so it responds with resp2 message and considers 166 the IKE_SA_INIT exchange completed. This message is also delayed in 167 the network. 169 Initiator Responder 170 ----------- ----------- 171 re-send req1: 172 HDR, SAi1, KEi, Ni --> recv req1, send resp2: 173 (delayed) <-- HDR, SAr1, KEr, Nr 175 After some time the initiator eventually receives the first 176 initiator's response resp1, which contains cookie request. It is the 177 first response the initiator receives from the responder, so it re- 178 sends the request adding the received cookie into it (req2). 179 However, this message is lost and never reaches the responder. 180 Shortly after sending req2 the initiator receives resp2 message. 182 Initiator Responder 183 ----------- ----------- 184 recv resp1, send req2: 185 HDR, N(COOKIE,c), 186 SAi1, KEi, Ni --> (lost) 187 recv resp2 189 At this point both peers have completed the IKE_SA_INIT exchange and 190 the KE_AUTH exchange is ready to start. However, the peers have 191 different opinions on what the latest IKE_SA_INIT request message was 192 - the initiator thinks it was req2, while the responder thinks it was 193 req1. As a result - the authentication in the IKE_AUTH exchange will 194 fail. 196 Let's consider another possible sequence, that leads to the same 197 result. As with the previous example the initiator starts creating 198 IKE SA by sending req1 message. The responder thinks it's under 199 attack and responds with a resp2 message containing cookie request 200 with cookie c1. However, this message is delayed in the network. 202 Initiator Responder 203 ----------- ----------- 204 send req1: 205 HDR, SAi1, KEi, Ni --> recv req1, send resp1: 206 (delayed) <-- HDR, N(COOKIE, c1) 208 As with the first example, the initiator hasn't received any response 209 and retransmits its initial request message req1 after some time. It 210 happens that within this time the value of has changed 211 (note, that [RFC7296] advises to do it frequently, especially when 212 under attack). Since the responder cannot verify cookie c1 and it 213 still thinks it is under attack, it acts as if req1 contains no 214 cookie and sends back resp2 message also containing cookie request, 215 with a new cookie c2 (that was calculated using the same input data 216 and the new value of ). 218 Initiator Responder 219 ----------- ----------- 220 re-send req1: 221 HDR, SAi1, KEi, Ni --> recv req1, send resp2: 222 <-- HDR, N(COOKIE, c2) 224 This message is not delayed, it reaches the initiator and the 225 initiator sends a new request req2 containing cookie c2. The 226 responder receives this message and successfully verifies the cookie 227 using its current value of . Since the cookie verification 228 is successfull, the responder sends back resp3 message and considers 229 the IKE_SA_INIT exchange completed. However, resp3 message is 230 delayed. 232 Initiator Responder 233 ----------- ----------- 234 recv resp2, send req2: 235 HDR, N(COOKIE, c2), 236 SAi1, KEi, Ni --> recv req2, send resp3: 237 (delayed) <-- HDR, SAr1, KEr, Nr 239 After some time the initiator eventually receives resp1 message, 240 which was delayed. This message contains another value of cookie - 241 c1. Since this message was received later than resp2 message, the 242 initiator thinks the value c1 is fresher than c2 and sends a new 243 request message req3 now with c1 cookie. This message is lost in the 244 network and never reaches the responder. Shortly after sending req3 245 the initiator receives resp3 message. 247 Initiator Responder 248 ----------- ----------- 249 recv resp1, send req3: 250 HDR, N(COOKIE, c1), 251 SAi1, KEi, Ni --> (lost) 252 recv resp3 254 As with the first example, at this point both peers have completed 255 the IKE_SA_INIT exchange and are ready for the KE_AUTH exchange. 256 However, the peers again have different opinions on what the latest 257 IKE_SA_INIT request message was - the initiator thinks it was req3, 258 while the responder thinks it was req2. As a result - the 259 authentication in the IKE_AUTH exchange will fail as with the 260 previous example. 262 The root of this problem is that the initial request can be re-sent 263 several times with different content depending on the responder's 264 current state, which can change over time. Note, that this situation 265 is generally not possible with the INVALID_KE_PAYLOAD notification, 266 even that in this case the request is also sent several times. This 267 is because the responder will always either require changing Key 268 Exchange method or not, so it is not possible that eventually peers 269 end up with different opinions on what Key Exchange method was 270 negotiated in the IKE_SA_INIT exchange. 272 5. Revised Cookie Processing 274 This specification proposes to solve the problem by excluding cookie 275 content from data to be authenticated. The rationale for this is 276 that cookie must be verified by the responder independently at the 277 time it is received in the IKE_SA_INIT request, so there is no need 278 to authenticate it. 280 5.1. Negotiation of Revised Cookie Processing 282 For the purpose of using revised cookie processing a new Status Type 283 notify REVISED_COOKIE is defined. Its Notify Message Type is , Protocol ID and SPI Size are both set to 0. The responder 285 includes an empty REVISED_COOKIE notification whenever it sends a 286 response containing COOKIE notification. If the initiator doesn't 287 support this extension it will ignore this notification and continues 288 as described in [RFC7296]. In case the initiator supports revised 289 cookie processing it will re-send its initial request including the 290 received cookie, but placing the cookie data into the REVISED_COOKIE 291 notification instead of COOKIE notification. 293 Initiator Responder 294 ----------- ----------- 295 send req1: 296 HDR, SAi1, KEi, Ni --> recv req1, send resp1: 297 HDR, N(COOKIE,c), 298 <-- N(REVISED_COOKIE) 299 recv resp1, send req2: 300 HDR, N(REVISED_COOKIE,c), 301 SAi1, KEi, Ni --> recv req2, send resp2: 302 <-- HDR, SAr1, KEr, Nr 303 recv resp2 305 Figure 2 307 5.2. Processing of REVISED_COOKIE Notification 309 If the responder has sent the REVISED_COOKIE notification in the 310 message requesting cookie it should be prepared to receive the re- 311 sent IKE_SA_INIT request with the REVISED_COOKIE notification 312 containing the cookie and with no COOKIE notification. Processing of 313 the REVISED_COOKIE notification by the responder MUST be identical to 314 the processing of COOKIE notification which is described in Sections 315 2.6 and 2.7 of [RFC7296]. 317 5.3. Changes in AUTH Payload Calculation 319 In the subsequent IKE_AUTH exchange peers authenticate each other by 320 signing (or MAC'ing) blobs of data. These blobs are defined in 321 Section 2.15 of [RFC7296]. In particular, initiator's blob is 322 defined as follows: 324 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 325 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 326 RealIKEHDR = SPIi | SPIr | . . . | Length 327 RealMessage1 = RealIKEHDR | RestOfMessage1 328 NonceRPayload = PayloadHeader | NonceRData 329 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 330 RestOfInitIDPayload = IDType | RESERVED | InitIDData 331 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 333 Figure 3 335 In Figure 3 RealMessage1 is the latest version of the IKE_SA_INIT 336 request message. 338 If the very first payload in RealMessage1 is the REVISED_COOKIE 339 notify, then InitiatorSignedOctets are computed as shown in Figure 4. 340 In particular: 342 1. The content of the REVISED_COOKIE notify payload is eliminated 343 from the message; 345 2. The Next Payload field in the IKE Header is set to the value of 346 the Next Payload field in the header of eliminated payload; 348 3. The length of the eliminated payload (indicated in the Length 349 field in its header) is subtracted from the Length field in the 350 IKE Header. 352 InitiatorSignedOctets = PseudoMessage1 | NonceRData | MACedIDForI 353 RealMessage1 = RealIKEHDR | NotifyREVISED_COOKIE | RestOfMessage1 354 NotifyREVISED_COOKIE = NextPld | 0 | PldLength | RestOfNotifyCOOKIE 355 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 356 RealIKEHDR = SPIi | SPIr | HdrNextPld | . . . | MsgLength 357 PseudoKEHDR = SPIi | SPIr | NewHdrNextPld | . . . | NewMsgLength 358 NewHdrNextPld = NextPld 359 NewMsgLength = MsgLength - PldLength 360 PseudoMessage1 = PseudoIKEHDR | RestOfMessage1 361 NonceRPayload = PayloadHeader | NonceRData 362 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 363 RestOfInitIDPayload = IDType | RESERVED | InitIDData 364 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 366 Figure 4 368 In brief, if RealMessage1 doesn't contain the REVISED_COOKIE 369 notification then it is used in the authentication as is (Figure 3). 370 Otherwise a new pseudo message PseudoMessage1 is used which is 371 constructed from RealMessage1 as if it doesn't contain the 372 REVISED_COOKIE notification (Figure 4). 374 This modification excludes Notify payload containing cookie from the 375 input to the AUTH payload calculation, thus solving the problem 376 described in Section 4. 378 6. Security Considerations 380 This extension modifies the way IKE initiator is authenticated to the 381 IKE responder. In particular, the cookie, created by the responder 382 and returned by the initiator in the IKE_SA_INIT request is excluded 383 from the data to be authenticated. IKEv2 specification requires that 384 cookie (if present in the request) be verified by the responder at 385 the early stage of the IKE_SA_INIT request message processing. If 386 this verification fails, then the responder must act as if no cookie 387 were present (see Section 2.6 of [RFC7296]), which in most cases 388 results in requesting a new cookie. An adversary that is able to 389 modify cookie content (or remove it from the request) will get no new 390 advantages if this extension is used: either the responder requests a 391 new cookie, or it doesn't care about the cookie at the moment and the 392 IKE_SA_INIT exchange succeeded with invalid cookie. In the later 393 case if revised cookie processing is used the subsequent IKE_AUTH 394 exchange will also succeed and IKE SA will be created, which is 395 different from the current situation, when authentication will fail 396 in the IKE_AUTH if cookie is changed by the attacker. 398 Excluding cookie from the data to be authenticated doesn't degrade 399 security properties of IKEv2, because the content of the cookie is 400 generated by the responder and must be verified by the responder well 401 before the authentication takes place. The initiator doesn't 402 participate in generation of cookie, it only returns it back as a 403 blob. 405 Compared to the current processing of cookie the difference caused by 406 the revised processing in a situation when an attacker changes cookie 407 in the IKE_SA_INIT request is that IKE SA will still be created 408 (provided no other obstacles exists), but only if the responder at 409 the moment doesn't care about validity of the received cookie (it 410 means that it is not under attack). 412 7. IANA Considerations 414 This document defines a new Notify Message Types in the "Notify 415 Message Types - Status Types" registry: 417 REVISED_COOKIE 419 8. Acknowledgements 421 Author is grateful to Tero Kivinen and Wei Pan for sharing their 422 thoughts about this problem and potential ways to solve it. 424 9. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 436 Kivinen, "Internet Key Exchange Protocol Version 2 437 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 438 2014, . 440 Author's Address 442 Valery Smyslov 443 ELVIS-PLUS 444 PO Box 81 445 Moscow (Zelenograd) 124460 446 RU 448 Phone: +7 495 276 0211 449 Email: svan@elvis.ru