ELVIS-PLUS

PO Box 81 Moscow (Zelenograd) 124460 Russian Federation +7 495 276 0211 svan@elvis.ru

SEC ipsecme signature digital signature credentials intermediate exchange This specification defines a mechanism that allows implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Associations (SAs). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different types for authenticating each other.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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.

Table of Contents

• .  Introduction
• .  Terminology and Notation
• .  Protocol Details
  • .  Exchanges
  • .  SUPPORTED_AUTH_METHODS Notify Message Type
    • .  2-Octet Announcement
    • .  3-Octet Announcement
    • .  Multi-octet Announcement
• .  Interaction with IKEv2 Extensions concerning Authentication
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Examples of Announcing Supported Authentication Methods
  • .  No Need to Use the IKE_INTERMEDIATE Exchange
  • .  With Use of the IKE_INTERMEDIATE Exchange
• Acknowledgments
• Author's Address

Introduction The Internet Key Exchange Protocol Version 2 (IKEv2), defined in , performs authenticated key exchange in IPsec. IKEv2, unlike its predecessor IKEv1, defined in , doesn't include a mechanism to negotiate an authentication method that the peers would use to authenticate each other. It is assumed that each peer selects whichever authentication method it thinks is appropriate, depending on authentication credentials it has. This approach generally works well when there is no ambiguity in selecting authentication credentials. SA establishment failure between peers may occur when there are several credentials of different types configured on one peer, while only some of them are supported on the other peer. Another problem situation is when a single credential may be used to produce different types of authentication tokens (e.g., signatures of different formats). Since IKEv2 requires that each peer use exactly one authentication method, and it doesn't provide means for peers to indicate to the other side which authentication methods they support, the peer that supports a wider range of authentication methods (or authentication token formats) could improperly select a method (or format) that is not supported by the other side. Emerging post-quantum signature algorithms may bring additional challenges for implementations, especially if so-called hybrid schemes are used (e.g., see ). This specification defines an extension to the IKEv2 protocol that allows peers to announce their supported authentication methods, thus decreasing risks of SA establishment failure in situations when there are several ways for the peers to authenticate themselves.

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 when, and only when, they appear in all capitals, as shown here.

Protocol Details When establishing an IKE SA, each party may send to its peer a list of the authentication methods it supports and is configured to use. For this purpose, this specification introduces a new Notify Message Type SUPPORTED_AUTH_METHODS. The Notify payload with this Notify Message Type is utilized to convey the supported authentication methods of the party sending it. The sending party may additionally specify that some of the authentication methods are only for use with the particular trust anchors. The receiving party may take this information into consideration when selecting an algorithm for its authentication (i.e., the algorithm used for calculation of the AUTH payload) if several alternatives are available. To simplify the receiver's task of linking the announced authentication methods with the trust anchors, the protocol ensures that the SUPPORTED_AUTH_METHODS notification is always co-located with the CERTREQ payload in the same message.

Exchanges The initiator starts the IKE_SA_INIT exchange as usual. If the responder is willing to use this extension, it includes a new notification SUPPORTED_AUTH_METHODS in the IKE_SA_INIT response message. This notification contains a list of authentication methods supported by the responder, ordered by their preference.

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

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 includes the SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request message, with a list of authentication methods supported by the initiator, ordered by their preference.

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

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.

• 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 (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 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 and ). 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.

Using the IKE_INTERMEDIATE Exchange for Sending Authentication Methods 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 }

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 ).

SUPPORTED_AUTH_METHODS Notify Message Type The format of the SUPPORTED_AUTH_METHODS Notify payload is shown below.

SUPPORTED_AUTH_METHODS Notify Payload Format 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Notify payload format is defined in . 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 . 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.

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

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

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 ), and for this reason there is no point to announce it via this mechanism. See also .

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.

3-Octet Announcement Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

Multi-octet Announcement The following format is currently used only with the "Digital Signature" (14) authentication method.

Multi-octet Announcement Format 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length:

Length of the blob in octets; must be greater than 3 for this case.

Auth Method:

Announced authentication method. At the time of writing this document, only value 14 ("Digital Signature") is allowed.

Cert Link:

Links this announcement with a particular CA; see for details.

AlgorithmIdentifier:

The variable-length ASN.1 object that is encoded using Distinguished Encoding Rules (DER) and identifies the signature algorithm (see ).

The "Digital Signature" authentication method, defined in , supersedes previously defined signature authentication methods. In this case, the real authentication algorithm is identified via AlgorithmIdentifier ASN.1 object. contains examples of commonly used ASN.1 objects.

Interaction with IKEv2 Extensions concerning Authentication Generally in IKEv2 each party independently determines the way it authenticates itself to the peer. In other words, authentication methods selected by the peers need not be the same. However, some IKEv2 extensions break this rule. The prominent example is "Secure Password Framework for Internet Key Exchange Version 2" , which defines a framework for using secure password authentication in IKEv2. With this framework, peers negotiate using one of the secure password methods in 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 peers negotiate secure password authentication, then the selected method is used by both initiator and responder, and no other authentication methods are involved. For this reason, there is no point to announce supported authentication methods in this case. Thus, if the peers choose to go with secure password authentication, they MUST NOT send the SUPPORTED_AUTH_METHODS notification. In the situation when peers are going to use Multiple Authentication Exchanges , they MAY include multiple SUPPORTED_AUTH_METHODS notifications (instead of one), each containing authentication methods appropriate for each authentication round. The notifications are included in the order of the preference of performing authentication rounds.

IANA Considerations This document defines a new type in the "IKEv2 Notify Message Status Types" registry:

Value	Notify Message Status Type	Reference
16443	SUPPORTED_AUTH_METHODS	RFC 9593

Security Considerations Security considerations for the IKEv2 protocol are discussed in . Security properties of different authentication methods vary. Refer to corresponding documents, listed in the "IKEv2 Authentication Method" registry on for discussion of security properties of each authentication method. Announcing authentication methods gives an eavesdropper additional information about peers' capabilities. If a peer advertises "NULL Authentication" along with other methods, then an active on-path attacker can encourage peers to use NULL authentication by removing all other announcements. Note that 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. Similarly, if an on-path attacker can break some of the announced authentication methods online, then the attacker can encourage peers to use one of these weaker methods by removing all other announcements, and if this succeeds, then perform a person-in-the-middle attack.

References Normative References IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. ITU-T Informative References Entrust Limited Entrust Limited CableLabs D-Trust GmbH Work in Progress This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. This memo defines an Experimental Protocol for the Internet community. This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods. This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.

Examples of Announcing Supported Authentication Methods This appendix shows some examples of announcing authentication methods. This appendix is purely informative; if it disagrees with the body of this document, the other text is considered correct. Note that some payloads that are not relevant to this specification may be omitted for brevity.

No Need to Use the IKE_INTERMEDIATE Exchange This example illustrates the situation when the SUPPORTED_AUTH_METHODS Notify payload fits into the IKE_SA_INIT message, and thus the IKE_INTERMEDIATE exchange is not needed. In this scenario, the responder announces that it supports the "Shared Key Message Integrity Code" and the "NULL Authentication" authentication methods. The initiator informs the responder that it supports only the "Shared Key Message Integrity Code" authentication 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}

With Use of the IKE_INTERMEDIATE Exchange This example illustrates the situation when the IKE_INTERMEDIATE exchange is used. In this scenario, the responder announces that it supports the "Digital signature" authentication method using the RSASSA-PSS algorithm with CA1 and CA2 and the same method using the ECDSA algorithm with CA3. The initiator supports only the "Digital signature" authentication 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 for his valuable comments and proposals. The author is also grateful to , who made proposals for protocol improvement. and contributed to the clarity of the document.

Author's Address ELVIS-PLUS

PO Box 81 Moscow (Zelenograd) 124460 Russian Federation +7 495 276 0211 svan@elvis.ru