rfc9593v2.txt		rfc9593.txt
	skipping to change at line 409 ¶		skipping to change at line 409 ¶
	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
	secure password authentication in IKEv2. With this framework, peers		secure password authentication in IKEv2. With this framework, peers
	negotiate using one of the secure password methods in the IKE_SA_INIT		negotiate using one of the secure password methods in the IKE_SA_INIT
	exchange -- the initiator sends a list of supported PAKE methods in		exchange -- the initiator sends a list of supported methods in the
	the request, and the responder picks one of them and sends it back in		request, and the responder picks one of them and sends it back in the
	the response.		response.
	If peers negotiate secure password authentication, then the selected		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 secure password authentication,		Thus, if the peers choose to go with secure password authentication,
	they MUST NOT send the SUPPORTED_AUTH_METHODS notification.		they MUST NOT send the SUPPORTED_AUTH_METHODS notification.
	In the situation when peers are going to use Multiple Authentication		In the situation when peers are going to use Multiple Authentication
	Exchanges [RFC4739], they MAY include multiple SUPPORTED_AUTH_METHODS		Exchanges [RFC4739], they MAY include multiple SUPPORTED_AUTH_METHODS
End of changes. 1 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.