rfc9593v1.txt		rfc9593.txt
	skipping to change at line 17 ¶		skipping to change at line 17 ¶
	Announcing Supported Authentication Methods in the Internet Key Exchange		Announcing Supported Authentication Methods in the Internet Key Exchange
	Protocol Version 2 (IKEv2)		Protocol Version 2 (IKEv2)
	Abstract		Abstract
	This specification defines a mechanism that allows implementations of		This specification defines a mechanism that allows implementations of
	the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the		the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the
	list of supported authentication methods to their peers while		list of supported authentication methods to their peers while
	establishing IKEv2 Security Associations (SAs). This mechanism		establishing IKEv2 Security Associations (SAs). This mechanism
	improves interoperability when IKEv2 partners are configured with		improves interoperability when IKEv2 partners are configured with
	multiple 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 is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 54 ¶		skipping to change at line 55 ¶
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Terminology and Notation		2. Terminology and Notation
	3. Protocol Details		3. Protocol Details
	3.1. Exchanges		3.1. Exchanges
	3.2. SUPPORTED_AUTH_METHODS Notify		3.2. SUPPORTED_AUTH_METHODS Notify Message Type
	3.2.1. 2-Octet Announcement		3.2.1. 2-Octet Announcement
	3.2.2. 3-Octet Announcement		3.2.2. 3-Octet Announcement
	3.2.3. Multi-octet Announcement		3.2.3. Multi-octet Announcement
	4. Interaction with IKEv2 Extensions concerning Authentication		4. Interaction with IKEv2 Extensions concerning Authentication
	5. IANA Considerations		5. IANA Considerations
	6. Security Considerations		6. Security Considerations
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	7.2. Informative References		7.2. Informative References
	Appendix A. Examples of Announcing Supported Authentication		Appendix A. Examples of Announcing Supported Authentication
	skipping to change at line 92 ¶		skipping to change at line 93 ¶
	selecting authentication credentials. SA establishment failure		selecting authentication credentials. SA establishment failure
	between peers may occur 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 use exactly one authentication method,		IKEv2 requires that each peer use exactly one authentication method,
	and it 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, the peer that supports a		which authentication methods they support, the peer that supports a
	wider range of authentication methods (or authentication token		wider range of authentication methods (or authentication token
	formats) could improperly select the method (or format) that is not		formats) could improperly select a method (or format) that 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 [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.
	skipping to change at line 114 ¶		skipping to change at line 115 ¶
	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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 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 an IKE SA, each party may send a list to its peer		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.		of the authentication methods it supports and is configured to use.
	For this purpose, this specification introduces a new Notify Message		For this purpose, this specification introduces a new Notify Message
	Type SUPPORTED_AUTH_METHODS. The Notify payload with this Notify		Type SUPPORTED_AUTH_METHODS. The Notify payload with this Notify
	Message Type is utilized to convey the supported authentication		Message Type is utilized to convey the supported authentication
	methods of the party sending it. The sending party may additionally		methods of the party sending it. The sending party may additionally
	specify that some of the authentication methods are only for use with		specify that some of the authentication methods are only for use with
	the 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
	skipping to change at line 165 ¶		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 an actual list of the		then the responder MAY choose not to send an actual list of the
	skipping to change at line 209 ¶		skipping to change at line 210 ¶
	that are configured to be used for authentication of this particular		that are configured to be used for authentication of this particular
	initiator. If these payloads are sent, they MUST be identical to the		initiator. If these payloads are sent, they MUST be 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 resend 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
	Sections 3.2.2 and 3.2.3). This requirement allows peers to have a		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		list of Announcements and a list of CAs in the same message, 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 resend CERTREQ payload(s) in the		for any reason the responder doesn't resend CERTREQ payload(s) in 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 it		Announcements to the CAs received in the IKE_SA_INIT response, or it
	MAY 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 authentication methods. However, it is not always		list of supported authentication methods. However, it is not always
	skipping to change at line 253 ¶		skipping to change at line 254 ¶
	Figure 3: Using the IKE_INTERMEDIATE Exchange for Sending		Figure 3: Using the IKE_INTERMEDIATE Exchange for Sending
	Authentication 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 are 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 16443.		there is no SPI field), and the Notify Message Type is set to 16443.
	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 whose 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
	skipping to change at line 305 ¶		skipping to change at line 307 ¶
	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 the authentication method "Generic Secure Password		that the authentication method "Generic Secure Password
	Authentication Method" (12) would also fall in this category;		Authentication Method" (12) would also fall in this category;
	however, it is negotiated separately (see [RFC6467]), and for this		however, it is negotiated separately (see [RFC6467]), and for this
	skipping to change at line 332 ¶		skipping to change at line 334 ¶
	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 particular CA.
	If the Cert Link field contains a 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
	skipping to change at line 369 ¶		skipping to change at line 371 ¶
	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 a 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 of [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 "Secure Password Framework for Internet Key		The prominent example is "Secure Password Framework for Internet Key
	Exchange Version 2" [RFC6467], which defines a framework for using		Exchange Version 2" [RFC6467], which defines a framework for using
	password-authenticated key exchanges (PAKEs) in IKEv2. With this		secure password authentication in IKEv2. With this framework, peers
	framework, peers negotiate using one of the 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 PAKE methods in
	methods in the request, and the responder picks one of them and sends		the request, and the responder picks one of them and sends it back in
	it back in the response.		the 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 then 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		notifications (instead of one), each containing authentication
	methods appropriate for each authentication round. The notifications		methods appropriate for each authentication round. The notifications
	are included in the order of the preference of performing		are included in the order of the preference of performing
	authentication rounds.		authentication rounds.
	5. IANA Considerations		5. IANA Considerations
	This document defines a new type in the "IKEv2 Notify Message Status		This document defines a new type in the "IKEv2 Notify Message Status
	Types" registry:		Types" registry:
	skipping to change at line 464 ¶		skipping to change at line 467 ¶
	Similarly, if an on-path attacker 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 a person-in-the-		announcements, and if this succeeds, then perform a person-in-the-
	middle attack.		middle attack.
	7. References		7. References
	7.1. Normative References		7.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, "Information Technology - ASN.1 encoding rules:		[X.690] ITU-T, "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)", ISO/IEC 8825-1:2021 (E), ITU-T		(DER)", ISO/IEC 8825-1:2021 (E), ITU-T
	Recommendation X.690, February 2021.		Recommendation X.690, February 2021.
	[IKEV2-IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters",
	<https://www.iana.org/assignments/ikev2-parameters/>.
	7.2. Informative References		7.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>.
	[COMPOSITE-SIGS]
	Ounsworth, M., Gray, J., Pala, M., and J. Klaußner,
	"Composite Signatures For Use In Internet PKI", Work in
	Progress, Internet-Draft, draft-ietf-lamps-pq-composite-
	sigs-00, 24 May 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	pq-composite-sigs-00>.
	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
End of changes. 25 change blocks.
	57 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.48.