rfc9593.original   rfc9593.txt 
Network Working Group V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Internet-Draft ELVIS-PLUS Request for Comments: 9593 ELVIS-PLUS
Intended status: Standards Track 18 April 2024 Category: Standards Track July 2024
Expires: 20 October 2024 ISSN: 2070-1721
Announcing Supported Authentication Methods in IKEv2 Announcing Supported Authentication Methods in the Internet Key Exchange
draft-ietf-ipsecme-ikev2-auth-announce-10 Protocol Version 2 (IKEv2)
Abstract Abstract
This specification defines a mechanism that allows the Internet Key This specification defines a mechanism that allows implementations of
Exchange version 2 (IKEv2) implementations to indicate the list of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the
supported authentication methods to their peers while establishing list of supported authentication methods to their peers while
IKEv2 Security Association (SA). This mechanism improves establishing IKEv2 Security Associations (SAs). This mechanism
interoperability when IKEv2 partners are configured with multiple improves interoperability when IKEv2 partners are configured with
credentials of different type to authenticate each other. multiple credentials of different types for authenticating each
other.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 October 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9593.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Details
3.1. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Exchanges
3.2. SUPPORTED_AUTH_METHODS Notify . . . . . . . . . . . . . . 6 3.2. SUPPORTED_AUTH_METHODS Notify Message Type
3.2.1. 2-octet Announcement . . . . . . . . . . . . . . . . 7 3.2.1. 2-Octet Announcement
3.2.2. 3-octet Announcement . . . . . . . . . . . . . . . . 8 3.2.2. 3-Octet Announcement
3.2.3. Multi-octet Announcement . . . . . . . . . . . . . . 8 3.2.3. Multi-octet Announcement
4. Interaction with IKEv2 Extensions concerning 4. Interaction with IKEv2 Extensions concerning Authentication
Authentication . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Examples of Announcing Supported Authentication Appendix A. Examples of Announcing Supported Authentication
Methods . . . . . . . . . . . . . . . . . . . . . . . . . 12 Methods
A.1. No Need to Use the IKE_INTERMEDIATE Exchange . . . . . . 13 A.1. No Need to Use the IKE_INTERMEDIATE Exchange
A.2. With Use of the IKE_INTERMEDIATE Exchange . . . . . . . . 13 A.2. With Use of the IKE_INTERMEDIATE Exchange
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgments
Author's Address
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol, defined in The Internet Key Exchange Protocol Version 2 (IKEv2), defined in
[RFC7296], performs authenticated key exchange in IPsec. IKEv2, [RFC7296], performs authenticated key exchange in IPsec. IKEv2,
unlike its predecessor IKEv1, defined in [RFC2409], doesn't include a unlike its predecessor IKEv1, defined in [RFC2409], doesn't include a
mechanism to negotiate an authentication method that the peers would mechanism to negotiate an authentication method that the peers would
use to authenticate each other. It is assumed that each peer selects use to authenticate each other. It is assumed that each peer selects
whatever authentication method it thinks is appropriate, depending on whichever authentication method it thinks is appropriate, depending
authentication credentials it has. on authentication credentials it has.
This approach generally works well when there is no ambiguity in This approach generally works well when there is no ambiguity in
selecting authentication credentials. SA establishment failure selecting authentication credentials. SA establishment failure
between peers may arise when there are several credentials of between peers may occur when there are several credentials of
different types configured on one peer, while only some of them are different types configured on one peer, while only some of them are
supported on the other peer. Another problem situation is when a supported on the other peer. Another problem situation is when a
single credential may be used to produce different types of single credential may be used to produce different types of
authentication tokens (e.g. signatures of different formats). Since authentication tokens (e.g., signatures of different formats). Since
IKEv2 requires that each peer uses exactly one authentication method IKEv2 requires that each peer use exactly one authentication method,
and doesn't provide means for peers to indicate to the other side and it doesn't provide means for peers to indicate to the other side
which authentication methods they support, it is possible that in which authentication methods they support, the peer that supports a
these situations the peer that supports wider range of authentication wider range of authentication methods (or authentication token
methods (or authentication token formats) improperly selects the formats) could improperly select a method (or format) that is not
method (or format) which is not supported by the other side. supported by the other side.
Emerging post-quantum signature algorithms may bring additional Emerging post-quantum signature algorithms may bring additional
challenges for implementations, especially if so-called hybrid challenges for implementations, especially if so-called hybrid
schemes are used (e.g. see [I-D.ounsworth-pq-composite-sigs]). schemes are used (e.g., see [COMPOSITE-SIGS]).
This specification defines an extension to the IKEv2 protocol that This specification defines an extension to the IKEv2 protocol that
allows peers to announce their supported authentication methods, thus allows peers to announce their supported authentication methods, thus
decreasing risks of SA establishment failure in situations when there decreasing risks of SA establishment failure in situations when there
are several ways for the peers to authenticate themselves. are several ways for the peers to authenticate themselves.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Details 3. Protocol Details
When establishing IKE SA each party may send a list of authentication When establishing an IKE SA, each party may send to its peer a list
methods it supports and is configured to use to its peer. For this of the authentication methods it supports and is configured to use.
purpose this specification introduces a new Notify Message Type For this purpose, this specification introduces a new Notify Message
SUPPORTED_AUTH_METHODS. The Notify payload with this Notify Message Type SUPPORTED_AUTH_METHODS. The Notify payload with this Notify
Type is utilized to convey the supported authentication methods of Message Type is utilized to convey the supported authentication
the party sending it. The sending party may additionally specify methods of the party sending it. The sending party may additionally
that some of the authentication methods are only for use with the specify that some of the authentication methods are only for use with
particular trust anchors. The receiving party may take this the particular trust anchors. The receiving party may take this
information into consideration when selecting an algorithm for its information into consideration when selecting an algorithm for its
authentication (i.e., the algorithm used for calculation of the AUTH authentication (i.e., the algorithm used for calculation of the AUTH
payload) if several alternatives are available. To simplify the payload) if several alternatives are available. To simplify the
receiver's task of linking the announced authentication methods with receiver's task of linking the announced authentication methods with
the trust anchors, the protocol ensures that the the trust anchors, the protocol ensures that the
SUPPORTED_AUTH_METHODS notification is always co-located with the SUPPORTED_AUTH_METHODS notification is always co-located with the
CERTREQ payload in the same message. CERTREQ payload in the same message.
3.1. Exchanges 3.1. Exchanges
skipping to change at page 4, line 26 skipping to change at line 166
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr, [IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } --> [N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr } AUTH, SAr2, TSi, TSr }
Figure 2: The IKE_AUTH Exchange Figure 2: The IKE_AUTH Exchange
Since the responder sends the SUPPORTED_AUTH_METHODS notification in Because the responder sends the SUPPORTED_AUTH_METHODS notification
the IKE_SA_INIT exchange, it must take care that the size of the in the IKE_SA_INIT exchange, it must take into account that the
response message wouldn't grow too much so that IP fragmentation response message could grow so much that the IP fragmentation might
takes place. If both of the following conditions are met: take place.
* the SUPPORTED_AUTH_METHODS notification to be included is so * the SUPPORTED_AUTH_METHODS notification to be included is so
large, that the responder suspects that IP fragmentation of the large, that the responder suspects that IP fragmentation of the
resulting IKE_SA_INIT response message may happen; resulting IKE_SA_INIT response message may happen;
* both peers support the IKE_INTERMEDIATE exchange, defined in * both peers support the IKE_INTERMEDIATE exchange, defined in
[RFC9242] (i.e. the responder has received and is going to send [RFC9242] (i.e., the responder has received and is going to send
the INTERMEDIATE_EXCHANGE_SUPPORTED notification); the INTERMEDIATE_EXCHANGE_SUPPORTED notification);
then the responder MAY choose not to send actual list of the then the responder MAY choose not to send an actual list of the
supported authentication methods in the IKE_SA_INIT exchange and supported authentication methods in the IKE_SA_INIT exchange and
instead ask the initiator to start the IKE_INTERMEDIATE exchange for instead ask the initiator to start the IKE_INTERMEDIATE exchange for
the list to be sent in. This would allow using IKE fragmentation 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 [RFC7383] for long messages (which cannot be used in the IKE_SA_INIT
exchange), thus avoiding IP fragmentation. In this case the exchange), thus avoiding IP fragmentation. In this case, the
responder includes SUPPORTED_AUTH_METHODS notification containing no responder includes a SUPPORTED_AUTH_METHODS notification containing
data in the IKE_SA_INIT response. no data in the IKE_SA_INIT response.
If the initiator receives the empty SUPPORTED_AUTH_METHODS If the initiator receives the empty SUPPORTED_AUTH_METHODS
notification in the IKE_SA_INIT exchange, it means that the responder notification in the IKE_SA_INIT exchange, it means that the responder
is going to send the list of the supported authentication methods in is going to send the list of the supported authentication methods in
the IKE_INTERMEDIATE exchange. If this exchange is to be initiated the IKE_INTERMEDIATE exchange. If this exchange is to be initiated
anyway for some other reason, then the responder MAY use it to send anyway for some other reason, then the responder MAY use it to send
the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator
MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by MAY start the IKE_INTERMEDIATE exchange for this sole purpose by
sending an empty IKE_INTERMEDIATE request. The initiator MAY also sending an empty IKE_INTERMEDIATE request. The initiator MAY also
indicate its identity (and possibly the perceived responder's indicate its identity (and possibly the perceived responder's
identity too) by including the IDi payload (possibly along with the identity too) by including the IDi payload (possibly along with the
IDr payload) into the IKE_INTERMEDIATE request. This information IDr payload) in the IKE_INTERMEDIATE request. This information could
could help the responder to send back only those authentication help the responder to send back only those authentication methods
methods, that are configured to be used for authentication of this that are configured to be used for authentication of this particular
particular initiator. If these payloads are sent, they MUST be initiator. If these payloads are sent, they MUST be identical to the
identical to the IDi/IDr payloads sent later in the IKE_AUTH request. IDi/IDr payloads sent later in the IKE_AUTH request.
If the responder has sent any CERTREQ payload in the IKE_SA_INIT, If the responder has sent any CERTREQ payload in the IKE_SA_INIT,
then it SHOULD re-send the same payload(s) in the IKE_INTERMEDIATE then it SHOULD resend the same payload(s) in the IKE_INTERMEDIATE
response containing the SUPPORTED_AUTH_METHODS notification if any of response containing the SUPPORTED_AUTH_METHODS notification if any of
the included Announcements has a non-zero Cert Link field (see the included Announcements has a non-zero Cert Link field (see
Section 3.2.2 and Section 3.2.3). This requirement allows peers to Sections 3.2.2 and 3.2.3). This requirement allows peers to have a
have a list of Announcements and a list of CAs in the same message, list of Announcements and a list of CAs in the same message, which
which simplifies their linking (note, that this requirement is always simplifies their linking. Note that this requirement is always
fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges). However, if fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges. However, if
for any reason the responder doesn't re-send CERTREQ payload(s) in for any reason the responder doesn't resend CERTREQ payload(s) in the
the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort
negotiation. Instead, the initiator MAY either link the negotiation. Instead, the initiator MAY either link the
Announcements to the CAs received in the IKE_SA_INIT response, or MAY Announcements to the CAs received in the IKE_SA_INIT response, or it
ignore the Announcements containing links to CAs. MAY ignore the Announcements containing links to CAs.
If multiple IKE_INTERMEDIATE exchanges take place during IKE SA If multiple IKE_INTERMEDIATE exchanges take place during IKE SA
establishments, it is RECOMMENDED that the responder use the last establishments, it is RECOMMENDED that the responder use the last
IKE_INTERMEDIATE exchange (the one just before IKE_AUTH) to send the IKE_INTERMEDIATE exchange (the one just before IKE_AUTH) to send the
list of supported auth methods. However, it is not always possible list of supported authentication methods. However, it is not always
for the responder to know how many IKE_INTERMEDIATE exchanges the possible for the responder to know how many IKE_INTERMEDIATE
initiator will use. In this case the responder MAY send the list in exchanges the initiator will use. In this case the responder MAY
any IKE_INTERMEDIATE exchange. If the initiator sends IDi/IDr in an send the list in any IKE_INTERMEDIATE exchange. If the initiator
IKE_INTERMEDIATE request, then it is RECOMMENDED that the responder sends IDi/IDr in an IKE_INTERMEDIATE request, then it is RECOMMENDED
sends back the list of authentication methods in the response. that the responder sends back the list of authentication methods in
the response.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,] <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)()] [N(SUPPORTED_AUTH_METHODS)()]
HDR, SK {..., [IDi, [IDr,]]} --> HDR, SK {..., [IDi, [IDr,]]} -->
<-- HDR, SK {..., [CERTREQ,] <-- HDR, SK {..., [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)] } [N(SUPPORTED_AUTH_METHODS)(...)] }
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr, [IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } --> [N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr } AUTH, SAr2, TSi, TSr }
Figure 3: Using the IKE_INTERMEDIATE Exchange for sending auth Figure 3: Using the IKE_INTERMEDIATE Exchange for Sending
methods Authentication Methods
Note, that sending the SUPPORTED_AUTH_METHODS notification and using Note that sending the SUPPORTED_AUTH_METHODS notification and using
information obtained from it is optional for both the initiator and information obtained from it are optional for both the initiator and
the responder. If multiple SUPPORTED_AUTH_METHODS notifications are the responder. If multiple SUPPORTED_AUTH_METHODS notifications are
included in a message, all their announcements form a single ordered included in a message, all their announcements form a single ordered
list, unless overridden by other extension (see Section 4). list, unless overridden by other extension (see Section 4).
3.2. SUPPORTED_AUTH_METHODS Notify 3.2. SUPPORTED_AUTH_METHODS Notify Message Type
The format of the SUPPORTED_AUTH_METHODS notification is shown below. The format of the SUPPORTED_AUTH_METHODS Notify payload is shown
below.
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type | | Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ List of Supported Auth Methods Announcements ~ ~ List of Supported Auth Methods Announcements ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SUPPORTED_AUTH_METHODS Notify Figure 4: SUPPORTED_AUTH_METHODS Notify Payload Format
The Notify payload format is defined in Section 3.10 of [RFC7296]. The Notify payload format is defined in Section 3.10 of [RFC7296].
When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the 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 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 <TBA by there is no SPI field), and the Notify Message Type is set to 16443.
IANA>.
Notification data contains the list of supported authentication Notification data contains the list of supported authentication
methods announcements. Each individual announcement is a variable- methods announcements. Each individual announcement is a variable-
size data blob, which format depends on the announced authentication size data blob whose format depends on the announced authentication
method. The blob always starts with an octet containing the length method. The blob always starts with an octet containing the length
of the blob followed by an octet containing the authentication of the blob followed by an octet containing the authentication
method. Authentication methods are represented as values from the method. Authentication methods are represented as values from the
"IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. The "IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. The
meaning of the remaining octets of the blob, if any, depends on the meaning of the remaining octets of the blob, if any, depends on the
authentication method. Note, that for the currently defined authentication method. Note that, for the currently defined
authentication methods the length octet fully defines both the format authentication methods, the length octet fully defines both the
and the semantics of the blob. format and the semantics of the blob.
If more authentication methods are defined in the future, the If more authentication methods are defined in the future, the
corresponding documents must describe the semantics of the corresponding documents must describe the semantics of the
announcements for these methods. Implementations MUST ignore announcements for these methods. Implementations MUST ignore
announcements whose semantics they don't understand. announcements whose semantics they don't understand.
3.2.1. 2-octet Announcement 3.2.1. 2-Octet Announcement
If the announcement contains an authentication method that is not If the announcement contains an authentication method that is not
concerned with public key cryptography, then the following format is concerned with public key cryptography, then the following format is
used. used.
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (=2) | Auth Method | | Length (=2) | Auth Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Supported Authentication Method Figure 5: 2-Octet Announcement Format
* Length - Length of the blob in octets, must be 2 for this case. Length: Length of the blob in octets; must be 2 for this case.
* Auth Method - Announced authentication method. Auth Method: Announced authentication method.
This format is applicable for the authentication methods "Shared Key This format is applicable for the authentication methods "Shared Key
Message Integrity Code" (2) and "NULL Authentication" (13). Note, Message Integrity Code" (2) and "NULL Authentication" (13). Note
that authentication method "Generic Secure Password Authentication that the authentication method "Generic Secure Password
Method" (12) would also fall in this category, however it is Authentication Method" (12) would also fall in this category;
negotiated separately (see [RFC6467]) and for this reason there is no however, it is negotiated separately (see [RFC6467]), and for this
point to announce it via this mechanism. See also Section 4. reason there is no point to announce it via this mechanism. See also
Section 4.
3.2.2. 3-octet Announcement 3.2.2. 3-Octet Announcement
If the announcement contains an authentication method that is If the announcement contains an authentication method that is
concerned with public key cryptography, then the following format is concerned with public key cryptography, then the following format is
used. This format allows linking the announcement with a particular used. This format allows linking the announcement with a particular
trust anchor from the Certificate Request payload. trust anchor from the Certificate Request payload.
1 2 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 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 (=3) | Auth Method | Cert Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Supported Authentication Method Figure 6: 3-Octet Announcement Format
* Length - Length of the blob in octets, must be 3 for this case. Length: Length of the blob in octets; must be 3 for this case.
* Auth Method - Announced authentication method. Auth Method: Announced authentication method.
* Cert Link - Links this announcement with particular CA. Cert Link: Links this announcement with a particular CA.
If the Cert Link field contains non-zero value N, it means that the 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 announced authentication method is intended to be used only with the
N-th trust anchor (CA certificate) from the Certificate Request N-th trust anchor (CA certificate) from the Certificate Request
payload(s) sent by this peer. If it is zero, then this payload(s) sent by this peer. If it is zero, then this
authentication method may be used with any CA. If multiple CERTREQ 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 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 list for the purpose of the linking. If no Certificate Request
payload were received, the content of this field MUST be ignored and payload were received, the content of this field MUST be ignored and
treated as zero. treated as zero.
This format is applicable for the authentication methods "RSA Digital This format is applicable for the authentication methods "RSA Digital
Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on 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) 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 and "ECDSA with SHA-512 on the P-521 curve" (11). Note, however,
these authentication methods are currently superseded by the "Digital that these authentication methods are currently superseded by the
Signature" (14) authentication method, which has a different "Digital Signature" (14) authentication method, which has a different
announcement format, described below. announcement format, described below.
3.2.3. Multi-octet Announcement 3.2.3. Multi-octet Announcement
The following format is currently used only with the "Digital The following format is currently used only with the "Digital
Signature" (14) authentication method. Signature" (14) authentication method.
1 2 3 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 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 | | | Length (>3) | Auth Method | Cert Link | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
~ AlgorithmIdentifier ASN.1 object ~ ~ AlgorithmIdentifier ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Supported Authentication Method Figure 7: Multi-octet Announcement Format
* Length - Length of the blob in octets, must be greater than 3 for Length: Length of the blob in octets; must be greater than 3 for
this case. this case.
* Auth Method - Announced authentication method, at the time of Auth Method: Announced authentication method. At the time of
writing this document only value 14 ("Digital Signature") is writing this document, only value 14 ("Digital Signature") is
allowed. allowed.
* Cert Link - Links this announcement with particular CA; see Cert Link: Links this announcement with a particular CA; see
Section 3.2.2 for details. Section 3.2.2 for details.
* AlgorithmIdentifier ASN.1 object - the AlgorithmIdentifier of PKIX AlgorithmIdentifier: The variable-length ASN.1 object that is
(see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoded using Distinguished Encoding Rules (DER) [X.690] and
encoding rules (DER) [X.690]. identifies the signature algorithm (see Section 4.1.1.2 of
[RFC5280]).
The "Digital Signature" authentication method, defined in [RFC7427], The "Digital Signature" authentication method, defined in [RFC7427],
supersedes previously defined signature authentication methods. In supersedes previously defined signature authentication methods. In
this case the real authentication algorithm is identified via this case, the real authentication algorithm is identified via
AlgorithmIdentifier ASN.1 object. Appendix A in [RFC7427] contains AlgorithmIdentifier ASN.1 object. Appendix A of [RFC7427] contains
examples of Commonly Used ASN.1 Objects. examples of commonly used ASN.1 objects.
4. Interaction with IKEv2 Extensions concerning Authentication 4. Interaction with IKEv2 Extensions concerning Authentication
Generally in IKEv2 each party independently determines the way it Generally in IKEv2 each party independently determines the way it
authenticates itself to the peer. In other words, authentication authenticates itself to the peer. In other words, authentication
methods selected by the peers need not be the same. However, some methods selected by the peers need not be the same. However, some
IKEv2 extensions break this rule. IKEv2 extensions break this rule.
The prominent example is [RFC6467], (Secure Password Framework for The prominent example is "Secure Password Framework for Internet Key
Internet Key Exchange Version 2), which defines a framework for using Exchange Version 2" [RFC6467], which defines a framework for using
Password-authenticated key exchanges (PAKE) in IKEv2. With this secure password authentication in IKEv2. With this framework, peers
framework peers negotiate using one of PAKE methods in the negotiate using one of the secure password methods in the IKE_SA_INIT
IKE_SA_INIT exchange - the initiator sends a list of supported PAKE exchange -- the initiator sends a list of supported methods in the
methods in the request and the responder picks one of them and sends request, and the responder picks one of them and sends it back in the
it back in the response. response.
If peers negotiate PAKE for authentication, then the selected PAKE If peers negotiate secure password authentication, then the selected
method is used by both initiator and responder and no other method is used by both initiator and responder, and no other
authentication methods are involved. For this reason there is no authentication methods are involved. For this reason, there is no
point to announce supported authentication methods in this case. point to announce supported authentication methods in this case.
Thus, if the peers choose to go with PAKE, they MUST NOT send the Thus, if the peers choose to go with secure password authentication,
SUPPORTED_AUTH_METHODS notification. they MUST NOT send the SUPPORTED_AUTH_METHODS notification.
If peers are going to use Multiple Authentication Exchanges In the situation when peers are going to use Multiple Authentication
[RFC4739], then they MAY include multiple SUPPORTED_AUTH_METHODS Exchanges [RFC4739], they MAY include multiple SUPPORTED_AUTH_METHODS
notifications instead of one, each containing authentication methods notifications (instead of one), each containing authentication
appropriate for each authentication round. The notifications are methods appropriate for each authentication round. The notifications
included in the order of the preference of performing authentication are included in the order of the preference of performing
rounds. authentication rounds.
5. Security Considerations 5. IANA Considerations
Security considerations for IKEv2 protocol are discussed in 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 |
+-------+----------------------------+-----------+
Table 1
6. Security Considerations
Security considerations for the IKEv2 protocol are discussed in
[RFC7296]. Security properties of different authentication methods [RFC7296]. Security properties of different authentication methods
varies. Refer to corresponding documents, listed in [IKEV2-IANA] for vary. Refer to corresponding documents, listed in the "IKEv2
discussion of security properties of each authentication method. Authentication Method" registry on [IKEV2-IANA] for discussion of
security properties of each authentication method.
Announcing authentication methods gives an eavesdropper additional Announcing authentication methods gives an eavesdropper additional
information about peers' capabilities. If a peer advertises NULL information about peers' capabilities. If a peer advertises "NULL
authentication along with other methods, then active attacker on the Authentication" along with other methods, then an active on-path
path can encourage peers to use NULL authentication by removing all attacker can encourage peers to use NULL authentication by removing
other announcements. Note, that this is not a real "downgrade" all other announcements. Note that this is not a real "downgrade"
attack, since authentication methods in IKEv2 are not negotiated and attack, since authentication methods in IKEv2 are not negotiated, and
in this case NULL authentication should be allowed by local security in this case NULL authentication should be allowed by local security
policy. policy.
Similarly, if an attacker on the path can break some of the announced Similarly, if an on-path attacker can break some of the announced
authentication methods online, then the attacker can encourage peers authentication methods online, then the attacker can encourage peers
to use one of these weaker methods by removing all other to use one of these weaker methods by removing all other
announcements, and if this succeeds, then perform person-in-the- announcements, and if this succeeds, then perform a person-in-the-
middle attack. middle attack.
6. IANA Considerations 7. References
This document defines a new Notify Message Type in the "IKEv2 Notify
Message Status Types" registry referencing this RFC:
<TBA> SUPPORTED_AUTH_METHODS [RFCXXXX]
7. Acknowledgments
The author would like to thank Paul Wouters for his 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 contributed to the clarity of the document.
8. References 7.1. Normative References
8.1. Normative References [IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<https://www.iana.org/assignments/ikev2-parameters/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Housley, R., and W. Polk, "Internet X.509 Public Key
May 2017, <https://www.rfc-editor.org/info/rfc8174>. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015, DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>. <https://www.rfc-editor.org/info/rfc7427>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Housley, R., and W. Polk, "Internet X.509 Public Key 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Infrastructure Certificate and Certificate Revocation List May 2017, <https://www.rfc-editor.org/info/rfc8174>.
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242, Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022, DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>. <https://www.rfc-editor.org/info/rfc9242>.
[X.690] "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", July 2002. (DER)", ISO/IEC 8825-1:2021 (E), ITU-T
Recommendation X.690, February 2021.
[IKEV2-IANA] 7.2. Informative References
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <https://www.iana.org/assignments/ikev2-
parameters/ikev2-parameters.xhtml#ikev2-parameters-12>.
8.2. Informative References [COMPOSITE-SIGS]
Ounsworth, M., Gray, J., Pala, M., and J. Klaussner,
"Composite Signatures For Use In Internet PKI", Work in
Progress, Internet-Draft, draft-ietf-lamps-pq-composite-
sigs-01, 24 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-01>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>. <https://www.rfc-editor.org/info/rfc2409>.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol", Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, DOI 10.17487/RFC4739, November 2006, RFC 4739, DOI 10.17487/RFC4739, November 2006,
<https://www.rfc-editor.org/info/rfc4739>. <https://www.rfc-editor.org/info/rfc4739>.
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key
Exchange Version 2 (IKEv2)", RFC 6467, Exchange Version 2 (IKEv2)", RFC 6467,
DOI 10.17487/RFC6467, December 2011, DOI 10.17487/RFC6467, December 2011,
<https://www.rfc-editor.org/info/rfc6467>. <https://www.rfc-editor.org/info/rfc6467>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014, DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>. <https://www.rfc-editor.org/info/rfc7383>.
[I-D.ounsworth-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., and J. Klaußner,
"Composite ML-DSA for use in Internet PKI", Work in
Progress, Internet-Draft, draft-ounsworth-pq-composite-
sigs-13, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-pq-
composite-sigs-13>.
Appendix A. Examples of Announcing Supported Authentication Methods Appendix A. Examples of Announcing Supported Authentication Methods
This appendix shows some examples of announcing authentication This appendix shows some examples of announcing authentication
methods. This appendix is purely informative; if it disagrees with methods. This appendix is purely informative; if it disagrees with
the body of this document, the other text is considered correct. the body of this document, the other text is considered correct.
Note that some payloads that are not relevant to this specification Note that some payloads that are not relevant to this specification
may be omitted for brevity. may be omitted for brevity.
A.1. No Need to Use the IKE_INTERMEDIATE Exchange A.1. No Need to Use the IKE_INTERMEDIATE Exchange
This example illustrates the situation when the This example illustrates the situation when the
SUPPORTED_AUTH_METHODS notify fits into the IKE_SA_INIT message and SUPPORTED_AUTH_METHODS Notify payload fits into the IKE_SA_INIT
thus the IKE_INTERMEDIATE exchange is not needed. In this scenario message, and thus the IKE_INTERMEDIATE exchange is not needed. In
the responder announces that it supports the "Shared Key Message this scenario, the responder announces that it supports the "Shared
Integrity Code" and the "NULL Authentication" authentication methods. Key Message Integrity Code" and the "NULL Authentication"
The initiator informs the responder that it supports only the "Shared authentication methods. The initiator informs the responder that it
Key Message Integrity Code" authentication method. supports only the "Shared Key Message Integrity Code" authentication
method.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
IKE_SA_INIT IKE_SA_INIT
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, <-- HDR, SAr1, KEr, Nr,
N(SUPPORTED_AUTH_METHODS( N(SUPPORTED_AUTH_METHODS(
PSK, NULL)) PSK, NULL))
IKE_AUTH IKE_AUTH
HDR, SK {IDi, HDR, SK {IDi,
AUTH, SAi2, TSi, TSr, AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(PSK))} --> N(SUPPORTED_AUTH_METHODS(PSK))} -->
<-- HDR, SK {IDr, <-- HDR, SK {IDr,
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
A.2. With Use of the IKE_INTERMEDIATE Exchange A.2. With Use of the IKE_INTERMEDIATE Exchange
This example illustrates the situation when the IKE_INTERMEDIATE This example illustrates the situation when the IKE_INTERMEDIATE
exchange is used. In this scenario the responder announces that it exchange is used. In this scenario, the responder announces that it
supports the "Digital signature" authentication method using the supports the "Digital signature" authentication method using the
RSASSA-PSS algorithm with CA1 and CA2 and the same 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 ECDSA algorithm with CA3. The initiator supports only the "Digital
signature" authentication method using the RSASSA-PSS algorithm with signature" authentication method using the RSASSA-PSS algorithm with
no link to a particular CA. no link to a particular CA.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
IKE_SA_INIT IKE_SA_INIT
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
skipping to change at page 14, line 32 skipping to change at line 608
SIGNATURE(ECDSA:3)))} SIGNATURE(ECDSA:3)))}
IKE_AUTH IKE_AUTH
HDR, SK {IDi, CERT, CERTREQ(CA2), HDR, SK {IDi, CERT, CERTREQ(CA2),
AUTH, SAi2, TSi, TSr, AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS( N(SUPPORTED_AUTH_METHODS(
SIGNATURE(RSASSA-PSS:0)))} --> SIGNATURE(RSASSA-PSS:0)))} -->
<-- HDR, SK {IDr, CERT, <-- HDR, SK {IDr, CERT,
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
Acknowledgments
The author would like to thank Paul Wouters for his 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 contributed to the clarity of the document.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) Moscow (Zelenograd)
124460 124460
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
 End of changes. 76 change blocks. 
222 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.48.