Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track 7 October 2024 Expires: 10 April 2025 Revised Cookie Processing in the IKEv2 Protocol draft-smyslov-ipsecme-ikev2-cookie-revised-08 Abstract This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Smyslov Expires 10 April 2025 [Page 1] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2 3. Using Cookies in IKEv2 . . . . . . . . . . . . . . . . . . . 3 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 5. Revised Cookie Processing . . . . . . . . . . . . . . . . . . 6 5.1. Negotiation of Revised Cookie Processing . . . . . . . . 7 5.2. Processing of REVISED_COOKIE Notification . . . . . . . . 7 5.3. Changes in AUTH Payload Calculation . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Internet Key Exchange protocol Version 2 (IKEv2) described in [RFC7296] includes mechanism to defend against DoS attacks. The mechanism is based on cookie which a responder can request an initiator to return in a subsequent request. This allows the responder to avoid creating state until it is sure that the initiator's IP address is not spoofed. The cookie mechanism is optional and it is up to the responder whether to use it or not. When the cookie mechanism is used in networks with high probability of packets loss and/or reordering, it is possible that peers end up with different views on whether cookies were used or not or which content the used cookie had. Since cookie, if used, is a part of an IKEv2 message that is included into calculation of authentication data by both peers, the different views leads to the situation when peers erroneously fail to authenticate each other. This specification revises processing of cookies in IKEv2 in such a way that peers supporting it exclude cookies from the data to be authenticated. This allows them to complete authentication even in the situation described above. 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Smyslov Expires 10 April 2025 [Page 2] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 3. Using Cookies in IKEv2 Section 2.6 of [RFC7296] specifies that when a responder detects a large number of half-open IKE SAs, it SHOULD reply to an IKE_SA_INIT request with a response containing the COOKIE notification and If an IKE_SA_INIT response includes the COOKIE notification, the initiator MUST then retry the IKE_SA_INIT request, including the received COOKIE notification as the very first payload in it and retaining all other payloads intact. This process is illustrated in Figure 1. Initiator Responder ----------- ----------- send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp1: <-- HDR, N(COOKIE,c) recv resp1, send req2: HDR, N(COOKIE,c), SAi1, KEi, Ni --> recv req2, send resp2: <-- HDR, SAr1, KEr, Nr recv resp2 Figure 1 Note, that the responder creates no state when it sends message resp1. This is achieved due to the way cookies are generated. A good way to generate a cookie is described in Section 2.6 of [RFC7296]: Cookie = | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder which is periodically changed. [RFC7296] advises the responder to change the value of frequently, especially if under attack. Later in the IKE_AUTH exchange the IKE_SA_INIT messages are authenticated by including their content intact into the data that is signed (or MAC'ed) using peers' credentials (see Section 2.15 of [RFC7296] for details). 4. Problem Description To successfully complete authentication it is important that both peers use the same content of the IKE_SA_INIT messages when calculating authentication data. However, when cookies are employed, the IKE_SA_INIT request is sent at least twice with different content. Section 2.15. of [RFC7296] states that if the first message of the IKE_SA_INIT exchange is sent multiple times with different Smyslov Expires 10 April 2025 [Page 3] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 content (e.g. with a cookie), it is the latest version of the message that is used for authentication. However, in situations when network packets can be lost and/or reordered, peers may end up with different views on what is "the latest version of the message". Two examples of such situations are shown below. Consider a situation when at the time the initiator starts creating IKE SA by sending req1 message the responder thinks it's under attack and responds with a resp2 message containing cookie request. However, this message is delayed in the network. Initiator Responder ----------- ----------- send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp1: (delayed) <-- HDR, N(COOKIE,c) Since the initiator hasn't received any response, it retransmits the initial request message req1 after some time. During this time the situation on the responder has changed and it doesn't think it's under attack anymore, so it responds with resp2 message and considers the IKE_SA_INIT exchange completed. This message is also delayed in the network. Initiator Responder ----------- ----------- re-send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp2: (delayed) <-- HDR, SAr1, KEr, Nr After some time the initiator eventually receives the first initiator's response resp1, which contains cookie request. It is the first response the initiator receives from the responder, so it re- sends the request adding the received cookie into it (req2). However, this message is lost and never reaches the responder. Shortly after sending req2 the initiator receives resp2 message. Initiator Responder ----------- ----------- recv resp1, send req2: HDR, N(COOKIE,c), SAi1, KEi, Ni --> (lost) recv resp2 Smyslov Expires 10 April 2025 [Page 4] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 At this point both peers have completed the IKE_SA_INIT exchange and the KE_AUTH exchange is ready to start. However, the peers have different opinions on what the latest IKE_SA_INIT request message was - the initiator thinks it was req2, while the responder thinks it was req1. As a result - the authentication in the IKE_AUTH exchange will fail. Let's consider another possible sequence, that leads to the same result. As with the previous example the initiator starts creating IKE SA by sending req1 message. The responder thinks it's under attack and responds with a resp1 message containing cookie request with cookie c1. However, this message is delayed in the network. Initiator Responder ----------- ----------- send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp1: (delayed) <-- HDR, N(COOKIE, c1) As with the first example, the initiator hasn't received any response and retransmits its initial request message req1 after some time. It happens that within this time the value of has changed (note, that [RFC7296] advises to do it frequently, especially when under attack). Since the responder cannot verify cookie c1 and it still thinks it is under attack, it acts as if req1 contains no cookie and sends back resp2 message also containing cookie request, with a new cookie c2 (that was calculated using the same input data and the new value of ). Initiator Responder ----------- ----------- re-send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp2: <-- HDR, N(COOKIE, c2) This message is not delayed, it reaches the initiator and the initiator sends a new request req2 containing cookie c2. The responder receives this message and successfully verifies the cookie using its current value of . Since the cookie verification is successfull, the responder sends back resp3 message and considers the IKE_SA_INIT exchange completed. However, resp3 message is delayed. Smyslov Expires 10 April 2025 [Page 5] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 Initiator Responder ----------- ----------- recv resp2, send req2: HDR, N(COOKIE, c2), SAi1, KEi, Ni --> recv req2, send resp3: (delayed) <-- HDR, SAr1, KEr, Nr After some time the initiator eventually receives resp1 message, which was delayed. This message contains another value of cookie - c1. Since this message was received later than resp2 message, the initiator thinks the value c1 is fresher than c2 and sends a new request message req3 now with c1 cookie. This message is lost in the network and never reaches the responder. Shortly after sending req3 the initiator receives resp3 message. Initiator Responder ----------- ----------- recv resp1, send req3: HDR, N(COOKIE, c1), SAi1, KEi, Ni --> (lost) recv resp3 As with the first example, at this point both peers have completed the IKE_SA_INIT exchange and are ready for the KE_AUTH exchange. However, the peers again have different opinions on what the latest IKE_SA_INIT request message was - the initiator thinks it was req3, while the responder thinks it was req2. As a result - the authentication in the IKE_AUTH exchange will fail as with the previous example. The root of this problem is that the initial request can be re-sent several times with different content depending on the responder's current state, which can change over time. Note, that this situation is generally not possible with the INVALID_KE_PAYLOAD notification, even that in this case the request is also sent several times. This is because the responder will always either require changing Key Exchange method or not, so it is not possible that eventually peers end up with different opinions on what Key Exchange method was negotiated in the IKE_SA_INIT exchange. 5. Revised Cookie Processing This specification proposes to solve the problem by excluding cookie content from data to be authenticated. The rationale for this is that cookie must be verified by the responder independently at the time it is received in the IKE_SA_INIT request, so there is no need to authenticate it. Smyslov Expires 10 April 2025 [Page 6] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 5.1. Negotiation of Revised Cookie Processing For the purpose of using revised cookie processing a new Status Type notify REVISED_COOKIE is defined. Its Notify Message Type is , Protocol ID and SPI Size are both set to 0. The responder includes an empty REVISED_COOKIE notification whenever it sends a response containing COOKIE notification. If the initiator doesn't support this extension it will ignore this notification and continues as described in [RFC7296]. In case the initiator supports revised cookie processing it will re-send its initial request including the received cookie, but placing the cookie data into the REVISED_COOKIE notification instead of COOKIE notification. Initiator Responder ----------- ----------- send req1: HDR, SAi1, KEi, Ni --> recv req1, send resp1: HDR, N(COOKIE,c), <-- N(REVISED_COOKIE) recv resp1, send req2: HDR, N(REVISED_COOKIE,c), SAi1, KEi, Ni --> recv req2, send resp2: <-- HDR, SAr1, KEr, Nr recv resp2 Figure 2 5.2. Processing of REVISED_COOKIE Notification If the responder has sent the REVISED_COOKIE notification in the message requesting cookie it should be prepared to receive the re- sent IKE_SA_INIT request with the REVISED_COOKIE notification containing the cookie and with no COOKIE notification. Processing of the REVISED_COOKIE notification by the responder MUST be identical to the processing of COOKIE notification which is described in Sections 2.6 and 2.7 of [RFC7296]. 5.3. Changes in AUTH Payload Calculation In the subsequent IKE_AUTH exchange peers authenticate each other by signing (or MAC'ing) blobs of data. These blobs are defined in Section 2.15 of [RFC7296]. In particular, initiator's blob is defined as follows: Smyslov Expires 10 April 2025 [Page 7] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) Figure 3 In Figure 3 RealMessage1 is the latest version of the IKE_SA_INIT request message. If the very first payload in RealMessage1 is the REVISED_COOKIE notify, then InitiatorSignedOctets are computed as shown in Figure 4. In particular: 1. The content of the REVISED_COOKIE notify payload is eliminated from the message; 2. The Next Payload field in the IKE Header is set to the value of the Next Payload field in the header of eliminated payload; 3. The length of the eliminated payload (indicated in the Length field in its header) is subtracted from the Length field in the IKE Header. InitiatorSignedOctets = PseudoMessage1 | NonceRData | MACedIDForI RealMessage1 = RealIKEHDR | NotifyREVISED_COOKIE | RestOfMessage1 NotifyREVISED_COOKIE = NextPld | 0 | PldLength | RestOfNotifyCOOKIE GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | HdrNextPld | . . . | MsgLength PseudoKEHDR = SPIi | SPIr | NewHdrNextPld | . . . | NewMsgLength NewHdrNextPld = NextPld NewMsgLength = MsgLength - PldLength PseudoMessage1 = PseudoIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) Figure 4 Smyslov Expires 10 April 2025 [Page 8] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 In brief, if RealMessage1 doesn't contain the REVISED_COOKIE notification then it is used in the authentication as is (Figure 3). Otherwise a new pseudo message PseudoMessage1 is used which is constructed from RealMessage1 as if it doesn't contain the REVISED_COOKIE notification (Figure 4). This modification excludes Notify payload containing cookie from the input to the AUTH payload calculation, thus solving the problem described in Section 4. 6. Security Considerations This extension modifies the way IKE initiator is authenticated to the IKE responder. In particular, the cookie, created by the responder and returned by the initiator in the IKE_SA_INIT request is excluded from the data to be authenticated. IKEv2 specification requires that cookie (if present in the request) be verified by the responder at the early stage of the IKE_SA_INIT request message processing. If this verification fails, then the responder must act as if no cookie were present (see Section 2.6 of [RFC7296]), which in most cases results in requesting a new cookie. An adversary that is able to modify cookie content (or remove it from the request) will get no new advantages if this extension is used: either the responder requests a new cookie, or it doesn't care about the cookie at the moment and the IKE_SA_INIT exchange succeeded with invalid cookie. In the later case if revised cookie processing is used the subsequent IKE_AUTH exchange will also succeed and IKE SA will be created, which is different from the current situation, when authentication will fail in the IKE_AUTH if cookie is changed by the attacker. Excluding cookie from the data to be authenticated doesn't degrade security properties of IKEv2, because the content of the cookie is generated by the responder and must be verified by the responder well before the authentication takes place. The initiator doesn't participate in generation of cookie, it only returns it back as a blob. Compared to the current processing of cookie the difference caused by the revised processing in a situation when an attacker changes cookie in the IKE_SA_INIT request is that IKE SA will still be created (provided no other obstacles exists), but only if the responder at the moment doesn't care about validity of the received cookie (it means that it is not under attack). 7. IANA Considerations This document defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: Smyslov Expires 10 April 2025 [Page 9] Internet-Draft Revised Cookie Processing in IKEv2 October 2024 REVISED_COOKIE 8. Acknowledgements Author is grateful to Tero Kivinen and Wei Pan for sharing their thoughts about this problem and potential ways to solve it. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires 10 April 2025 [Page 10]