Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-downgrade-prevention-00

Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Standards Track                               C. Patton
Expires: 9 April 2026                                         Cloudflare
                                                          6 October 2025

   Prevention Downgrade Attacks on the Internet Key Exchange Protocol
                           Version 2 (IKEv2)
            draft-ietf-ipsecme-ikev2-downgrade-prevention-00

Abstract

   This document describes an extension to the Internet Key Exchange
   protocol version 2 (IKEv2) that aims to prevent some kinds of
   downgrade attacks on this protocol by having the peers confirm they
   have participated in the same conversation.

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 9 April 2026.

Copyright Notice

   Copyright (c) 2025 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 & Patton          Expires 9 April 2026                  [Page 1]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   2
   3.  Authentication in IKEv2 . . . . . . . . . . . . . . . . . . .   2
   4.  Downgrade Attacks Description . . . . . . . . . . . . . . . .   3
   5.  Downgrade Attacks Prevention  . . . . . . . . . . . . . . . .   5
   6.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Interaction with other IKEv2 Extensions . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Internet Key Exchange version 2 protocol (IKEv2) defined in
   [RFC7296] provides authenticated key exchange in the IP Security
   (IPsec) architecture.  The cryptographic design of IKEv2 is based on
   SIGMA protocol defined in [SIGMA].  The protocol allows peers to
   mutually authenticate themselves and to derive session keys that are
   used to protect traffic.

   (RFC EDITOR: Please remove this paragraph.)  This document is being
   developed at https://github.com/smyslov/ikev2-downgrade-prevention.

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.

   It is assumed that readers are familiar with the IKEv2 protocol
   [RFC7296].

3.  Authentication in IKEv2

   The details of how authentication is performed in IKEv2 are defined
   in Section 2.15 of [RFC7296].  Peers sign (or MAC) some blobs that
   consist of various parts of protocol data (see also [SIGMA] for the
   rationale).  The definition of these blobs is provided below for
   convenience.

Smyslov & Patton          Expires 9 April 2026                  [Page 2]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

      The initiator's signed octets can be described as:

      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)

      The responder's signed octets can be described as:

      ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
      GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
      RealIKEHDR =  SPIi | SPIr |  . . . | Length
      RealMessage2 = RealIKEHDR | RestOfMessage2
      NonceIPayload = PayloadHeader | NonceIData
      ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
      RestOfRespIDPayload = IDType | RESERVED | RespIDData
      MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

   In particular, the initiator authenticates the IKE_SA_INIT request
   (RealMessage1) and the responder authenticates the IKE_SA_INIT
   response (RealMessage2).  Thus, each side authenticates only the
   initial message it has sent and not the initial message it has
   received.

4.  Downgrade Attacks Description

   The way authentication is performed in IKEv2 allows at least two
   kinds of downgrade attacks.  The first of these is a key-compromise
   impersonation (KCI) attack and requires a set of preconditions that
   are not common, but still not unrealistic.  In particular:

   1.  The attacker must be on the path with the ability to intercept
       communications between the peers and to modify their messages.

   2.  Security policies for both initiator and responder must include
       both "strong" and "weak" key exchange methods (with some
       definition of "strong" and "weak") and the attacker must be able
       to break "weak" key exchange methods in real time.

   3.  The attacker must either have a long-term authentication key for
       one of the peers or must be able to break authentication
       algorithm used by one of the peers in real time.

Smyslov & Patton          Expires 9 April 2026                  [Page 3]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

   Having these preconditions the goal of the attacker is to eavesdrop
   on communication between the peers.  While the attack requires
   impersonating one of these peers to the other, impersonation is not
   its primary goal.

   In case the attacker knows the initiator's long-term authentication
   key, the attack can be mount as follows.

   1.  The initiator sends the IKE_SA_INIT request message with a list
       of proposed algorithms that includes both "weak" and "strong" key
       exchange methods.

   2.  The attacker intercepts this message and re-injects a modified
       message without "strong" key exchange methods.  Note that this
       may require an additional step for the attack to succeed if the
       initiator includes a public key for a "strong" key exchange
       method in the request.  In this case the attacker intercepts this
       message and responds with the INVALID_KE_PAYLOAD notification
       indicating that the initiator must include public key for a
       "weak" key exchange method.  Then this message is intercepted and
       re-injected without "strong" key exchange methods.

   3.  The responder receives this message and selects one of the "weak"
       key exchange methods (since the message does not include any
       "strong" ones), then it sends back a response message, which the
       attacker allows to pass through without modifications.

   4.  Since the attacker has seen both public keys and can break the
       selected "weak" key exchange method in real time, it calculates
       the SK_* session keys that allow the attacker to read and modify
       the content of the encrypted IKE messages.

   5.  The initiator receives the IKE_SA_INIT response message, accepts
       the responder's selected algorithms, including the "weak" key
       exchange method (since it is allowed by its policy), and starts
       the IKE_AUTH exchange.  It computes the AUTH payload, thus
       authenticating the IKE_SA_INIT request message it has sent.

   6.  The attacker intercepts this message, decrypts it and modifies
       the AUTH payload so that it allegedly authenticates the
       IKE_SA_INIT request message that was modified and injected by the
       attacker.  The attacker is able to do this because it knows the
       session keys and the initiator's long-term authentication key.

   7.  The responder receives this message, verifies the AUTH payload
       and sends back the IKE_AUTH response message, which the attacker
       allows to pass through.

Smyslov & Patton          Expires 9 April 2026                  [Page 4]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

   8.  At this point the peers have established a connection using the
       "weak" key exchange method.  Note, that this is allowed by their
       security policies, but without the attacker's intervention they
       would have used a more secure "strong" key exchange method.  The
       attacker essentially forced the peers to use a "weak" method that
       it is able to break, thus downgrading the security properties of
       the connection so that it can read the peers' communication.

   A variant of this attack can be mounted if the attacker has a long-
   term authentication key for the responder.  In this case the attacker
   cannot change the algorithms selected by the responder, but still may
   be able to force peers not to use some protocol extensions, in
   particular those that are initially proposed by the responder.

   The second type of attack is an identity misbinding attack described
   in [DOWNGRADE].  The attacker's goal is once again to eavesdrop on
   the communication between two peers, but unlike the KCI attack, it
   does not need to compromise one of the peers.  Instead, the attacker
   only needs to know the long-term authentication key of some party one
   of the peers is configured to communicate with.

   In particular, suppose the attacker wants to eavesdrop on
   communication between initiator I and responder R and has access to
   the long-term authentication key of initiator A.  The attack works
   exactly the same way as the previous one, with one exception: after
   decrypting and modifying I's AUTH payload, it authenticates the
   modified AUTH payload with A's long-term authentication key instead
   of I's.  At the end of the attack, initiator I will believe it has
   established a connection with responder R, but responder R will
   believe it has established a connection with initiator A (whose
   authentication key is known to the attacker).  Nevertheless, the
   attacker will be able to read the encrypted messages sent between I
   and R.

   Both the KCI and identity misbinding attacks can also be mounted on
   the hybrid post-quantum key exchange defined in [RFC9370], where an
   attacker able to break traditional key exchange method (e.g. by means
   of a quantum computer) prevents peers from executing additional
   quantum resistant key exchange method(s).

5.  Downgrade Attacks Prevention

   This document defines an IKEv2 extension that aims to detect attempts
   to mount the downgrade attacks described in Section 4.  If both peers
   support this extension and are configured to use it and if at least
   one non-compromised authentication key is used by the peers in the
   protocol run then:

Smyslov & Patton          Expires 9 April 2026                  [Page 5]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

   *  An attacker cannot fool any protocol participant that its peer
      does not support this extension without being detected.

   *  An attacker cannot modify the IKE_SA_INIT messages without being
      detected.

   If this extension is not supported by both peers, then the protocol
   runs as defined in [RFC7296].

   The idea is that both the IKE_SA_INIT request and the IKE_SA_INIT
   response messages must be directly authenticated by both peers.
   Thus, if at least one non-compromised key is used in the IKE SA
   establishing, then any modification of the IKE_SA_INIT messages will
   be detected.  In essence, the peers use this extension to confirm
   they have had the same conversation, a property enjoyed by many
   modern authenticated key exchange protocols that may have other
   benefits beyond downgrade protection, like TLS 1.3 [RFC8446].

6.  Protocol Details

   The initiator supporting this extension includes a new status type
   notification IKE_SA_INIT_AUTH in the IKE_SA_INIT request message.
   The Notify Message Type for this notification is <TBA1 by IANA>,
   Protocol ID and SPI Size are both set to 0 and the notification data
   is empty.

   If the responder supports this extension then it also includes this
   notification in the response message regardless of whether it was
   received in the request or not.

   Initiator                       Responder
   ------------------------------------------------------------------
   HDR, SAi1, KEi, Ni,
        N(IKE_SA_INIT_AUTH)  --->
                             <---  HDR, SAr1, KEr, Nr, [CERTREQ,]
                                   N(IKE_SA_INIT_AUTH)

   If a peer sent and received the IKE_SA_INIT_AUTH notification, then
   it uses the modified construction of the blobs to be signed (or
   MAC'ed) compared to the definition from Section 2.15 of [RFC7296]:

   InitiatorSignedOctets = ZeroPrefix | RealMessage2
                           | RealMessage1 | NonceRData | MACedIDForI

   ResponderSignedOctets = ZeroPrefix | RealMessage1
                           | RealMessage2 | NonceIData | MACedIDForR

Smyslov & Patton          Expires 9 April 2026                  [Page 6]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

   where RealMessage1, RealMessage2, NonceIData, NonceRData, MACedIDForI
   and MACedIDForR are defined in Section 2.15 of [RFC7296], and
   ZeroPrefix is 8 octets of zero.  ZeroPrefix serves a role of a domain
   separator making the new authentication blobs always different from
   authentication blobs defined in [RFC7296], because in both
   RealMessage1 and RealMessage2 the first 8 octets constitute IKE
   Initiator's SPI that can never be zero.

7.  Interaction with other IKEv2 Extensions

   The IKE_INTERMEDIATE exchange defined in [RFC9242] also modifies
   blobs to be signed (or MAC'ed).  This modification is described in
   Section 3.3.2 of [RFC9242] and can be summarized as an addition of a
   new piece of data (IntAuth) to the end of the blobs from Section 2.15
   of [RFC7296].  If peers support extension defined in this document,
   then they MUST treat modified blobs to be signed (or MAC'ed) defined
   in Section 6 as replacements for blobs defined in Section 2.15 of
   [RFC7296], so that in case of IKE_INTERMEDIATE the IntAuth is added
   to these modified blobs.

   Note, that authentication of the IKE_INTERMEDIATE exchange includes
   messages sent in both directions, thus the attacker cannot change its
   messages without being detected.

8.  Security Considerations

   The IKEv2 extension defined in this document aims to protect against
   downgrade attacks on IKEv2.  It only provides this protection when
   both peers implement the extension.

   The attacks described in this document can also be mitigated by
   disabling support for weak key exchange methods.  Doing so is
   feasible when the peer is known out-of-band to support strong key
   exchange methods, but this information may not be available in all
   deployment scenarios for IKEv2.

   The attacks can also be mitigated by mixing a pre-shared key into the
   session key calculation.  An attacker that does not know this pre-
   shared key will be unable to decrypt even if it manages to downgrade
   the key exchange.  However, the use of a pre-shared key is negotiated
   by an extension [RFC8784], [I-D.ietf-ipsecme-ikev2-qr-alt], and this
   negotiation is itself subject to downgrade attack.  It is therefore
   necessary for each of the peers to mandate the use of a pre-shared
   key (and abort the connection if negotiation fails).

Smyslov & Patton          Expires 9 April 2026                  [Page 7]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

9.  IANA Considerations

   This document defines new Notify Message Type in the "IKEv2 Notify
   Message Status Types" registry:

   <TBA>       IKE_SA_INIT_AUTH

10.  Acknowledgements

   TODO

11.  References

11.1.  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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC9242]  Smyslov, V., "Intermediate Exchange in the Internet Key
              Exchange Protocol Version 2 (IKEv2)", RFC 9242,
              DOI 10.17487/RFC9242, May 2022,
              <https://www.rfc-editor.org/info/rfc9242>.

11.2.  Informative References

   [RFC9370]  Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
              Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
              Key Exchanges in the Internet Key Exchange Protocol
              Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
              2023, <https://www.rfc-editor.org/info/rfc9370>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Smyslov & Patton          Expires 9 April 2026                  [Page 8]
Internet-Draft        Downgrade Prevention in IKEv2         October 2025

   [RFC8784]  Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
              "Mixing Preshared Keys in the Internet Key Exchange
              Protocol Version 2 (IKEv2) for Post-quantum Security",
              RFC 8784, DOI 10.17487/RFC8784, June 2020,
              <https://www.rfc-editor.org/info/rfc8784>.

   [I-D.ietf-ipsecme-ikev2-qr-alt]
              Smyslov, V., "Mixing Preshared Keys in the
              IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of
              IKEv2 for Post-quantum Security", Work in Progress,
              Internet-Draft, draft-ietf-ipsecme-ikev2-qr-alt-10, 23 May
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ipsecme-ikev2-qr-alt-10>.

   [SIGMA]    Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to
              Authenticated Diffie-Hellman and Its Use in the IKE
              Protocols", Springer Berlin Heidelberg, Lecture Notes in
              Computer Science pp. 400-425,
              DOI 10.1007/978-3-540-45146-4_24, ISBN ["9783540406747",
              "9783540451464"], 2003,
              <https://doi.org/10.1007/978-3-540-45146-4_24>.

   [DOWNGRADE]
              Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M.,
              Zanella-Béguelin, S., and M. Green, "Downgrade Resilience
              in Key-Exchange Protocols", Cryptology ePrint
              Archive Paper 2016/072, January 2016,
              <https://ia.cr/2016/072>.

Authors' Addresses

   Valery Smyslov
   ELVIS-PLUS
   Russian Federation
   Email: svan@elvis.ru

   Christopher Patton
   Cloudflare
   Email: chrispatton+ietf@gmail.com

Smyslov & Patton          Expires 9 April 2026                  [Page 9]