RFC 9593

Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published July 2024, from ietf

💖 Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2) ✨

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • RFC number: 9593 🎀
  • Author: V. Smyslov, ELVIS-PLUS 👑
  • Category: Standards Track 💅
  • Date: July 2024 🦋
  • ISSN: 2070-1721 🌈
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈

Abstract ✨

okay so this one is about letting IKEv2 peers say out loud which authentication methods they can actually use 🫶 it's a mechanism that lets implementations tell their partners the list of methods they support while they're setting up IKEv2 Security Associations (SAs) 💜 it's basically the fix for when two partners each have several credentials of different types for proving who they are to each other, and it's giving interoperability glow-up 🔥

Status of This Memo 🌸

this one is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) 🎀 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ if you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9593 🦋

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) as they stand on the date of publication 🧚 please actually read those, bestie, because they explain your rights and restrictions for this document 🙈 also, any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Revised BSD License ⚠️

Table of Contents 🍓

   1.  Introduction
   2.  Terminology and Notation
   3.  Protocol Details
     3.1.  Exchanges
     3.2.  SUPPORTED_AUTH_METHODS Notify Message Type
       3.2.1.  2-Octet Announcement
       3.2.2.  3-Octet Announcement
       3.2.3.  Multi-octet Announcement
   4.  Interaction with IKEv2 Extensions concerning Authentication
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Examples of Announcing Supported Authentication
           Methods
     A.1.  No Need to Use the IKE_INTERMEDIATE Exchange
     A.2.  With Use of the IKE_INTERMEDIATE Exchange
   Acknowledgments
   Author's Address

1. Introduction 🧚

okay so IKEv2, which is defined in [RFC7296], is the thing that does authenticated key exchange in IPsec 🔐 the big difference from its predecessor IKEv1 (defined in [RFC2409]) is that IKEv2 has no mechanism for the peers to negotiate which authentication method they'll use to authenticate each other 💅 instead, each peer just picks whatever method it thinks is appropriate based on the credentials it has, and honestly that's giving vibes of "trust me bro" 😭

this works pretty well when there's no confusion about which credentials to use 💖 the drama starts when one peer has several credentials of different types configured but the other peer only supports some of them 💀 there's also the case where one single credential can produce different types of authentication tokens, like signatures in different formats 👀 IKEv2 requires that each peer use exactly one authentication method, and it doesn't give peers a way to tell each other which methods they support 🙈 so the peer that supports a wider range of methods (or token formats) could accidentally pick one the other side doesn't support, and then the SA setup just... doesn't happen 😭

new post-quantum signature algorithms might bring extra challenges too, especially if so-called hybrid schemes get used (e.g., see [COMPOSITE-SIGS]) 🌈

so this specification adds an extension to IKEv2 that lets peers announce their supported authentication methods ✨ that way there's way less risk of SA establishment failing when there are several ways for the peers to authenticate themselves 🦋

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 📚 so those capitalized words are the official vibes, and lowercase ones are just regular English 💅

3. Protocol Details 💜

when a party is setting up an IKE SA, it may send its peer a list of the authentication methods it supports and is configured to use 🫶 to make that happen, this specification introduces a brand new Notify Message Type called SUPPORTED_AUTH_METHODS 🔥 the Notify payload carrying this Notify Message Type is what conveys the sending party's supported authentication methods 🎀

here's the extra spice: the sending party can also say that some of its authentication methods are only for use with particular trust anchors 👑 the receiving party can use that info when picking an algorithm for its authentication (the algorithm used to calculate the AUTH payload) if there are several alternatives available 🧠 and to make life easier for the receiver when it's linking the announced methods to the trust anchors, the protocol makes sure the SUPPORTED_AUTH_METHODS notification always shows up in the same message as the CERTREQ payload 🌸 no splitting them up, bestie 🙅‍♀️

3.1. Exchanges ✨

Okay bestie, so the initiator kicks things off with the IKE_SA_INIT exchange like normal 💅 If the responder is down to use this extension, it adds a brand new notification called SUPPORTED_AUTH_METHODS to the IKE_SA_INIT response 🎀 That notification carries a list of the authentication methods the responder supports, ordered by preference 👑

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

Figure 1: The IKE_SA_INIT Exchange

If the initiator doesn't support this extension, it ignores the received notification as an unknown status notify 🙈

Regardless of whether the notification is received, if the initiator supports and is willing to use this extension, it puts the SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request, listing the authentication methods it supports, ordered by preference 🦋

   Initiator                              Responder
   -----------                            -----------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
   [IDr,] AUTH, SAi2, TSi, TSr,
   [N(SUPPORTED_AUTH_METHODS)(...)] }  -->
                                      <-- HDR, SK {IDr, [CERT,]
                                               AUTH, SAr2, TSi, TSr }

Figure 2: The IKE_AUTH Exchange

Because the responder sends the SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT exchange, it must take into account that the response message could grow so much that the IP fragmentation might take place 😭

When all of these are true:

  • the SUPPORTED_AUTH_METHODS notification to be included is so large, that the responder suspects that IP fragmentation of the resulting IKE_SA_INIT response message may happen;
  • both peers support the IKE_INTERMEDIATE exchange, defined in [RFC9242] (i.e., the responder has received and is going to send the INTERMEDIATE_EXCHANGE_SUPPORTED notification);

then the responder MAY choose not to send an actual list of the supported authentication methods in the IKE_SA_INIT exchange and instead ask the initiator to start the IKE_INTERMEDIATE exchange for the list to be sent in. This would allow using IKE fragmentation [RFC7383] for long messages (which cannot be used in the IKE_SA_INIT exchange), thus avoiding IP fragmentation. In this case, the responder includes a SUPPORTED_AUTH_METHODS notification containing no data in the IKE_SA_INIT response. 🧚

If the initiator receives the empty SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT exchange, it means that the responder is going to send the list of the supported authentication methods in the IKE_INTERMEDIATE exchange. If this exchange is to be initiated anyway for some other reason, then the responder MAY use it to send the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator MAY start the IKE_INTERMEDIATE exchange for this sole purpose by sending an empty IKE_INTERMEDIATE request. The initiator MAY also indicate its identity (and possibly the perceived responder's identity too) by including the IDi payload (possibly along with the IDr payload) in the IKE_INTERMEDIATE request. This information could help the responder to send back only those authentication methods that are configured to be used for authentication of this particular initiator. If these payloads are sent, they MUST be identical to the IDi/IDr payloads sent later in the IKE_AUTH request. 🫶

If the responder has sent any CERTREQ payload in the IKE_SA_INIT, then it SHOULD resend the same payload(s) in the IKE_INTERMEDIATE response containing the SUPPORTED_AUTH_METHODS notification if any of the included Announcements has a non-zero Cert Link field (see Sections 3.2.2 and 3.2.3). This requirement allows peers to have a list of Announcements and a list of CAs in the same message, which simplifies their linking. Note that this requirement is always fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges. However, if for any reason the responder doesn't resend CERTREQ payload(s) in the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort negotiation. Instead, the initiator MAY either link the Announcements to the CAs received in the IKE_SA_INIT response, or it MAY ignore the Announcements containing links to CAs. 🌸

If multiple IKE_INTERMEDIATE exchanges take place during IKE SA establishments, it is RECOMMENDED that the responder use the last IKE_INTERMEDIATE exchange (the one just before IKE_AUTH) to send the list of supported authentication methods. However, it is not always possible for the responder to know how many IKE_INTERMEDIATE exchanges the initiator will use. In this case the responder MAY send the list in any IKE_INTERMEDIATE exchange. If the initiator sends IDi/IDr in an IKE_INTERMEDIATE request, then it is RECOMMENDED that the responder sends back the list of authentication methods in the response. 🍓

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

   HDR, SK {..., [IDi, [IDr,]]}  -->
                                      <-- HDR, SK {..., [CERTREQ,]
                                      [N(SUPPORTED_AUTH_METHODS)(...)] }

   HDR, SK {IDi, [CERT,] [CERTREQ,]
   [IDr,] AUTH, SAi2, TSi, TSr,
   [N(SUPPORTED_AUTH_METHODS)(...)] }  -->
                                      <-- HDR, SK {IDr, [CERT,]
                                               AUTH, SAr2, TSi, TSr }

Figure 3: Using the IKE_INTERMEDIATE Exchange for Sending Authentication Methods

Note that sending the SUPPORTED_AUTH_METHODS notification and using information obtained from it are optional for both the initiator and the responder. If multiple SUPPORTED_AUTH_METHODS notifications are included in a message, all their announcements form a single ordered list, unless overridden by other extension (see Section 4). ✨

3.2. SUPPORTED_AUTH_METHODS Notify Message Type 💜

The format of the SUPPORTED_AUTH_METHODS Notify payload is shown below. 👀

                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |   SPI Size    |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~          List of Supported Auth Methods Announcements         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: SUPPORTED_AUTH_METHODS Notify Payload Format

The Notify payload format is defined in Section 3.10 of [RFC7296]. When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the Protocol ID field is set to 0, the SPI Size is set to 0 (meaning there is no SPI field), and the Notify Message Type is set to 16443. 🔥

Notification data contains the list of supported authentication methods announcements. Each individual announcement is a variable-size data blob whose format depends on the announced authentication method. The blob always starts with an octet containing the length of the blob followed by an octet containing the authentication method. Authentication methods are represented as values from the "IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. The meaning of the remaining octets of the blob, if any, depends on the authentication method. Note that, for the currently defined authentication methods, the length octet fully defines both the format and the semantics of the blob. 🌈

If more authentication methods are defined in the future, the corresponding documents must describe the semantics of the announcements for these methods. Implementations MUST ignore announcements whose semantics they don't understand. 🙅‍♀️

3.2.1. 2-Octet Announcement 🎀

If the announcement contains an authentication method that is not concerned with public key cryptography, then the following format is used.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length (=2)  |  Auth Method  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: 2-Octet Announcement Format

  • Length: Length of the blob in octets; must be 2 for this case.
  • Auth Method: Announced authentication method.

This format is applicable for the authentication methods "Shared Key Message Integrity Code" (2) and "NULL Authentication" (13). Note that the authentication method "Generic Secure Password Authentication Method" (12) would also fall in this category; however, it is negotiated separately (see [RFC6467]), and for this reason there is no point to announce it via this mechanism. See also Section 4. 🦋

3.2.2. 3-Octet Announcement 💖

If the announcement contains an authentication method that is concerned with public key cryptography, then the following format is used. This format allows linking the announcement with a particular trust anchor from the Certificate Request payload. 🔐

                        1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length (=3)  |  Auth Method  |   Cert Link   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: 3-Octet Announcement Format

  • Length: Length of the blob in octets; must be 3 for this case.
  • Auth Method: Announced authentication method.
  • Cert Link: Links this announcement with a particular CA.

If the Cert Link field contains a non-zero value N, it means that the announced authentication method is intended to be used only with the N-th trust anchor (CA certificate) from the Certificate Request payload(s) sent by this peer. If it is zero, then this authentication method may be used with any CA. If multiple CERTREQ payloads were sent, the CAs from all of them are treated as a single list for the purpose of the linking. If no Certificate Request payload were received, the content of this field MUST be ignored and treated as zero. 🎯

This format is applicable for the authentication methods "RSA Digital Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the P-521 curve" (11). Note, however, that these authentication methods are currently superseded by the "Digital Signature" (14) authentication method, which has a different announcement format, described below. 👑

3.2.3. Multi-octet Announcement 🎀

okay so this format is only used with the "Digital Signature" (14) authentication method rn 💅 here's what it looks like:

                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length (>3)  |  Auth Method  |   Cert Link   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   ~                      AlgorithmIdentifier                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Multi-octet Announcement Format

let's break down the fields 🧚

  • Length: the length of the blob in octets. in this case it must be greater than 3 🌸
  • Auth Method: the announced authentication method. at the time this doc was written, only value 14 ("Digital Signature") is allowed 💜
  • Cert Link: links this announcement with a particular CA. see Section 3.2.2 for the deets 🔗
  • AlgorithmIdentifier: a variable-length ASN.1 object, encoded using Distinguished Encoding Rules (DER) [X.690]. it identifies the signature algorithm (see Section 4.1.1.2 of [RFC5280]) 🦋

the "Digital Signature" authentication method, defined in [RFC7427], supersedes previously defined signature authentication methods 👑 so the real authentication algorithm gets identified through that AlgorithmIdentifier ASN.1 object. Appendix A of [RFC7427] has examples of commonly used ASN.1 objects if you want to see them in action ✨

4. Interaction with IKEv2 Extensions concerning Authentication ✨

okay so generally in IKEv2, each party decides on its own how it authenticates itself to the peer 💅 which means the authentication methods the peers pick don't have to match. BUT some IKEv2 extensions break this rule 😭

the big one is "Secure Password Framework for Internet Key Exchange Version 2" [RFC6467]. it defines a framework for using secure password authentication in IKEv2 🔐 here's how it goes: the peers negotiate one of the secure password methods during the IKE_SA_INIT exchange. the initiator sends a list of supported methods in the request, and the responder picks one of them and sends it back in the response 🫶

if the peers go with secure password authentication, then the selected method is used by both the initiator and the responder, and no other authentication methods are involved 🙈 so there's literally no point in announcing supported authentication methods in that case. which means that if the peers choose secure password authentication, they MUST NOT send the SUPPORTED_AUTH_METHODS notification. no exceptions bestie 🚫

now, when the peers are going to use Multiple Authentication Exchanges [RFC4739], they MAY include multiple SUPPORTED_AUTH_METHODS notifications instead of just one 🌈 each one carries the authentication methods for a specific authentication round. the notifications get included in the order of preference for performing those rounds 🍓

5. IANA Considerations 🌸

okay so this doc defines a new type in the "IKEv2 Notify Message Status Types" registry. here's the entry:

         +=======+============================+===========+
         | Value | Notify Message Status Type | Reference |
         +=======+============================+===========+
         | 16443 | SUPPORTED_AUTH_METHODS     | RFC 9593  |
         +-------+----------------------------+-----------+

                              Table 1

6. Security Considerations 💀

okay this section is SERIOUS bestie, so pay attention 🚨

security considerations for the IKEv2 protocol are discussed in [RFC7296]. and the security properties of different authentication methods vary a LOT 😭 so go check the corresponding documents listed in the "IKEv2 Authentication Method" registry on [IKEV2-IANA] for the security discussion of each method.

announcing authentication methods gives an eavesdropper extra info about the peers' capabilities 👀 and it gets worse: if a peer advertises "NULL Authentication" along with other methods, then an active on-path attacker can push peers toward NULL authentication just by removing all the other announcements 💀 technically this is not a real "downgrade" attack, since authentication methods in IKEv2 are not negotiated. and in this case, NULL authentication should be allowed by local security policy anyway 🙃

same vibe here: if an on-path attacker can break some of the announced authentication methods online, then the attacker can nudge peers toward one of those weaker methods by removing all the other announcements. and if that works, the attacker can then perform a person-in-the-middle attack 😱🔥

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. Examples of Announcing Supported Authentication Methods 🦋

this appendix has some examples of announcing auth methods 🎀 it's purely informative, so if it ever disagrees with the body of this document, the body wins 💅 also, some payloads that aren't relevant to this spec may be left out to keep things short.

A.1. No Need to Use the IKE_INTERMEDIATE Exchange

this one shows the situation where the SUPPORTED_AUTH_METHODS Notify payload fits inside the IKE_SA_INIT message, so the IKE_INTERMEDIATE exchange isn't needed 🙌 the responder announces that it supports the "Shared Key Message Integrity Code" and "NULL Authentication" methods. the initiator tells the responder it only supports the "Shared Key Message Integrity Code" method 🔑

   Initiator                              Responder
   -----------                            -----------
                        IKE_SA_INIT
   HDR, SAi1, KEi, Ni -->
                                      <-- HDR, SAr1, KEr, Nr,
                                          N(SUPPORTED_AUTH_METHODS(
                                          PSK, NULL))

                         IKE_AUTH
   HDR, SK {IDi,
   AUTH, SAi2, TSi, TSr,
   N(SUPPORTED_AUTH_METHODS(PSK))}  -->
                                      <-- HDR, SK {IDr,
                                          AUTH, SAr2, TSi, TSr}

A.2. With Use of the IKE_INTERMEDIATE Exchange

this example is for when the IKE_INTERMEDIATE exchange IS used 🔥 the responder announces that it supports the "Digital signature" method using the RSASSA-PSS algorithm with CA1 and CA2, plus the same method using the ECDSA algorithm with CA3. the initiator only supports the "Digital signature" method using the RSASSA-PSS algorithm, with no link to a particular CA 💜

   Initiator                              Responder
   -----------                            -----------
                        IKE_SA_INIT
   HDR, SAi1, KEi, Ni,
   N(SIGNATURE_HASH_ALGORITHMS) -->
                                      <-- HDR, SAr1, KEr, Nr,
                                          CERTREQ(CA1, CA2, CA3),
                                          N(SIGNATURE_HASH_ALGORITHMS),
                                          N(SUPPORTED_AUTH_METHODS())

                      IKE_INTERMEDIATE
   HDR, SK {..., IDi]}  -->
                                      <-- HDR, SK {...,
                                          CERTREQ(CA1, CA2, CA3),
                                          N(SUPPORTED_AUTH_METHODS(
                                          SIGNATURE(RSASSA-PSS:1),
                                          SIGNATURE(RSASSA-PSS:2),
                                          SIGNATURE(ECDSA:3)))}

                         IKE_AUTH
   HDR, SK {IDi, CERT, CERTREQ(CA2),
   AUTH, SAi2, TSi, TSr,
   N(SUPPORTED_AUTH_METHODS(
   SIGNATURE(RSASSA-PSS:0)))}  -->
                                      <-- HDR, SK {IDr, CERT,
                                          AUTH, SAr2, TSi, TSr}

Acknowledgments 🫶

the author would like to thank Paul Wouters for his super valuable comments and proposals 💖 the author is also grateful to Daniel Van Geest, who made proposals for protocol improvement. Reese Enghardt and Rifaat Shekh-Yusef helped make the document clearer ✨

Author's Address 🌈

   Valery Smyslov
   ELVIS-PLUS
   PO Box 81
   Moscow (Zelenograd)
   124460
   Russian Federation
   Phone: +7 495 276 0211
   Email: svan@elvis.ru
📦 where this page comes from