rfc9867v1.txt		rfc9867.txt
	skipping to change at line 180 ¶		skipping to change at line 180 ¶
	Initiator Responder		Initiator Responder
	------------------------------------------------------------------		------------------------------------------------------------------
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	N(INTERMEDIATE_EXCHANGE_SUPPORTED),		N(INTERMEDIATE_EXCHANGE_SUPPORTED),
	N(USE_PPK_INT) --->		N(USE_PPK_INT) --->
	<--- HDR, SAr1, KEr, Nr, [CERTREQ,]		<--- HDR, SAr1, KEr, Nr, [CERTREQ,]
	N(INTERMEDIATE_EXCHANGE_SUPPORTED),		N(INTERMEDIATE_EXCHANGE_SUPPORTED),
	N(USE_PPK_INT)		N(USE_PPK_INT)
	The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify		The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify
	Message Type is 16445; the Protocol ID and Security Parameter Index		Message Type is 16445; the Protocol ID is set to 0; the Security
	(SPI) Size are both set to 0. This specification does not define any		Parameter Index (SPI) is absent, so the SPI Size is set to 0 too.
	data that this notification may contain, so the Notification Data is		This specification does not define any data that this notification
	left empty. However, future extensions of this specification may		may contain, so the Notification Data is left empty. However, future
	make use of it. Implementations MUST ignore any data in the		extensions of this specification may make use of it. Implementations
	notification that they do not understand.		MUST ignore any data in the notification that they do not understand.
	Note that this negotiation is independent from the negotiation of		Note that this negotiation is independent from the negotiation of
	using PPKs as specified in [RFC8784]. An initiator that supports		using PPKs as specified in [RFC8784]. An initiator that supports
	both the use of PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY		both the use of PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY
	include both the USE_PPK_INT and USE_PPK notifications if configured		include both the USE_PPK_INT and USE_PPK notifications if configured
	to do so. However, if the responder supports both specifications and		to do so. However, if the responder supports both specifications and
	is configured to use PPKs, it has to choose one to use; thus, it MUST		is configured to use PPKs, it has to choose one to use; thus, it MUST
	return either a USE_PPK_INT or a USE_PPK notification in the response		return either a USE_PPK_INT or a USE_PPK notification in the response
	but not both.		but not both.
	skipping to change at line 207 ¶		skipping to change at line 207 ¶
	IKE_SA_INIT request and the responder's policy mandates protecting		IKE_SA_INIT request and the responder's policy mandates protecting
	initial IKE SA with a PPK, then the responder MUST return the		initial IKE SA with a PPK, then the responder MUST return the
	NO_PROPOSAL_CHOSEN notification.		NO_PROPOSAL_CHOSEN notification.
	If the negotiation was successful, the initiator includes one or more		If the negotiation was successful, the initiator includes one or more
	PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with		PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with
	PPK identities that the initiator believes are appropriate for the		PPK identities that the initiator believes are appropriate for the
	IKE SA being created.		IKE SA being created.
	The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify		The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify
	Message Type is 16446; the Protocol ID and SPI Size fields are both		Message Type is 16446; the Protocol ID and the SPI Size fields are
	set to 0. The format of the Notification Data is shown below in		both set to 0. The format of the Notification Data is shown below in
	Figure 1.		Figure 1.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ PPK_ID ~		~ PPK_ID ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at line 245 ¶		skipping to change at line 245 ¶
	computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:		computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:
	* "prf" is the negotiated PRF;		* "prf" is the negotiated PRF;
	* PPK is the key value for a specified PPK_ID;		* PPK is the key value for a specified PPK_ID;
	* Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being		* Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being
	established.		established.
	If a series of the IKE_INTERMEDIATE exchanges takes place, the		If a series of the IKE_INTERMEDIATE exchanges takes place, the
	PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.,		PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.,
	in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH		in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH
	exchange. If the last IKE_INTERMEDIATE exchange contains other		exchange. If this IKE_INTERMEDIATE exchange contains other payloads
	payloads aimed for some other purpose, then the notification(s) MAY		aimed for some other purpose, then the notification(s) MAY be
	be piggybacked with these payloads.		piggybacked with these payloads. Note that future IKEv2 extensions
			utilizing the IKE_INTERMEDIATE exchange may allow one or more of
			these exchanges to happen after the one concerned with PPK for the
			case when such extensions are negotiated.
	Initiator Responder		Initiator Responder
	------------------------------------------------------------------		------------------------------------------------------------------
	HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)		HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
	[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...		[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
	[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->		[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
	Depending on the responder's capabilities and policy, the following		Depending on the responder's capabilities and policy, the following
	situations are possible:		situations are possible:
	1. If the responder is configured with one of the PPKs which IDs		1. If the responder is configured with a PPK with an ID that is
	were sent by the initiator and this PPK matches the initiator's		among the IDs sent by the initiator, and if this PPK matches the
	one (based on the information from the PPK Confirmation field),		initiator's PPK (based on the information from the PPK
	then the responder selects this PPK and returns back its identity		Confirmation field), then the responder selects this PPK and
	in the PPK_IDENTITY notification. The PPK_IDENTITY notification		returns its identity in the PPK_IDENTITY notification. The
	is defined in [RFC8784].		PPK_IDENTITY notification is defined in [RFC8784].
	Initiator Responder		Initiator Responder
	---------------------------------------------------------------		---------------------------------------------------------------
	<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}		<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}
	In this case, the IKE_AUTH exchange is performed as defined in		In this case, the IKE_AUTH exchange is performed as defined in
	IKEv2 [RFC7296]. However, the keys for the IKE SA are computed		IKEv2 [RFC7296]. However, the keys for the IKE SA are computed
	using PPK, as described in Section 3.1.1. If the responder		using PPK, as described in Section 3.1.1. If the responder
	returns a PPK identity that was not proposed by the initiator,		returns a PPK identity that was not proposed by the initiator,
	then the initiator MUST treat this as fatal and abort the IKE SA		then the initiator MUST treat this as fatal and abort the IKE SA
	establishment.		establishment.
	2. If the responder does not have any of the PPKs which IDs were		2. If the responder does not have a PPK with an ID that matches any
	sent by the initiator, or if it has some of the proposed PPKs but		of IDs sent by the initiator, or if the responder has some of the
	their values mismatch the initiator's ones (based on the		proposed PPKs but their values are mismatched from the
	information from the PPK Confirmation field), and using PPK is		initiator's PPKs (based on the information from the PPK
	mandatory for the responder, then it MUST return		Confirmation field), and if using PPK is mandatory for the
	AUTHENTICATION_FAILED notification and abort creating the IKE SA.		responder, then it MUST return an AUTHENTICATION_FAILED
			notification and abort creating the IKE SA.
	Initiator Responder		Initiator Responder
	---------------------------------------------------------------		---------------------------------------------------------------
	<--- HDR, SK {... N(AUTHENTICATION_FAILED)}		<--- HDR, SK {... N(AUTHENTICATION_FAILED)}
	3. If the responder does not have any PPKs proposed by the		3. If the responder does not have any PPKs proposed by the
	initiator, or if it has only some of the proposed PPKs but their		initiator, or if it has only some of the proposed PPKs but their
	values mismatch the initiator's ones (based on the information		values mismatch the initiator's ones (based on the information
	from the PPK Confirmation field), and if using PPK is optional		from the PPK Confirmation field), and if using PPK is optional
	for the responder, then it does not include any PPK_IDENTITY		for the responder, then it does not include any PPK_IDENTITY
	skipping to change at line 354 ¶		skipping to change at line 358 ¶
	that the responder does have this PPK, but it is just not listed		that the responder does have this PPK, but it is just not listed
	among the PPKs to be used with this initiator. In this case, the		among the PPKs to be used with this initiator. In this case, the
	responder SHOULD abort negotiation and return back the		responder SHOULD abort negotiation and return back the
	AUTHENTICATION_FAILED notification to be consistent with its policy.		AUTHENTICATION_FAILED notification to be consistent with its policy.
	However, the responder MAY continue creating IKE SA using the		However, the responder MAY continue creating IKE SA using the
	negotiated "wrong" PPK if this is acceptable according to its local		negotiated "wrong" PPK if this is acceptable according to its local
	policy.		policy.
	3.1.1. Computing IKE SA Keys		3.1.1. Computing IKE SA Keys
	Once the PPK is negotiated in the last IKE_INTERMEDIATE exchange, the		Once the PPK is negotiated in the IKE_INTERMEDIATE exchange, the IKE
	IKE SA keys are recalculated. Note that if the IKE SA keys are also		SA keys are recalculated. Note that if the IKE SA keys are also
	recalculated as the result of the other actions performed in the		recalculated as a result of other actions performed in this
	IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),		IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),
	then applying the PPK MUST be done after all of them so that		then applying the PPK MUST be done after all of them so that
	recalculating IKE SA keys with the PPK is the last action before they		recalculating IKE SA keys with the PPK is the last action before they
	are used in the IKE_AUTH exchange.		are used in the next exchange. Note that future IKEv2 extensions
			utilizing the IKE_INTERMEDIATE exchange may update this requirement
			for the case when such extensions are negotiated.
	The IKE SA keys are computed differently compared to how PPKs are		The IKE SA keys are computed differently compared to how PPKs are
	used in IKE_AUTH. A new SKEYSEED' value is computed using the		used in IKE_AUTH. A new SKEYSEED' value is computed using the
	negotiated PPK and the most recently computed SK_d key. Note that		negotiated PPK and the most recently computed SK_d key. Note that
	the PPK is applied to SK_d exactly how it is specified in [RFC8784],		the PPK is applied to SK_d exactly how it is specified in [RFC8784],
	and the result is used as SKEYSEED'.		and the result is used as SKEYSEED'.
	SKEYSEED' = prf+ (PPK, SK_d)		SKEYSEED' = prf+ (PPK, SK_d)
	Then the SKEYSEED' is used to recalculate all SK_* keys as defined in		Then the SKEYSEED' is used to recalculate all SK_* keys as defined in
	skipping to change at line 431 ¶		skipping to change at line 437 ¶
	HDR, SK {SA, Ni, KEi,		HDR, SK {SA, Ni, KEi,
	N(PPK_IDENTITY_KEY, PPK_ID_1)		N(PPK_IDENTITY_KEY, PPK_ID_1)
	[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...		[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
	[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->		[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
	<--- HDR, SK {SA, Nr, KEr,		<--- HDR, SK {SA, Nr, KEr,
	N(PPK_IDENTITY, PPK_ID_i)}		N(PPK_IDENTITY, PPK_ID_i)}
	Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA		Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA
	In case the responder does not support (or is not configured for)		If the responder does not support (or is not configured for) using
	using PPKs in the CREATE_CHILD_SA exchange or does not have any of		PPKs in the CREATE_CHILD_SA exchange or does not have a PPK with an
	the PPKs which IDs were sent by the initiator, or if it has some of		ID that matches any of IDs sent by the initiator, or if the responder
	proposed PPKs but their values mismatch the initiator's PPKs (based		has some of the proposed PPKs but their values are mismatched from
	on the information from the PPK Confirmation field), then it does not		the initiator's PPKs (based on the information from the PPK
	include any PPK_IDENTITY notification in the response and a new SA is		Confirmation field), then it will not include any PPK_IDENTITY
	created as defined in IKEv2 [RFC7296]. If this is inappropriate for		notifications in the response, and new SA is created as defined in
	the initiator, it can immediately delete this SA.		IKEv2 [RFC7296]. If this is inappropriate for the initiator, it can
			immediately delete this SA.
	If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and		If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and
	the initiator does not include any PPK_IDENTITY_KEY notifications in		the initiator does not include any PPK_IDENTITY_KEY notifications in
	the request, or if the responder does not have any of the PPKs which		the request, or if the responder does not have a PPK with an ID that
	IDs were sent by the initiator, or it has some of proposed PPKs but		matches any of IDs sent by the initiator, or if the responder has
	their values mismatch the initiator's ones (based on the information		some of the proposed PPKs but with mismatched values from the
	from the PPK Confirmation field), then the responder MUST return the		initiator's PPKs (based on the information from the PPK Confirmation
	NO_PROPOSAL_CHOSEN notification.		field), then the responder MUST return the NO_PROPOSAL_CHOSEN
			notification.
	Otherwise, the new SA is created using the selected PPK.		Otherwise, the new SA is created using the selected PPK.
	3.2.1. Computing Keys		3.2.1. Computing Keys
	For the purpose of calculation session keys for the new SA, the		For the purpose of calculation session keys for the new SA, the
	current SK_d key is first mixed with the selected PPK:		current SK_d key is first mixed with the selected PPK:
	SK_d' = prf+ (PPK, SK_d)		SK_d' = prf+ (PPK, SK_d)
	skipping to change at line 478 ¶		skipping to change at line 486 ¶
	IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in		IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in
	IKE_AUTH, this specification makes even initial IKE SA quantum		IKE_AUTH, this specification makes even initial IKE SA quantum
	secure. In addition, a PPK is mixed into the SK_* keys calculation		secure. In addition, a PPK is mixed into the SK_* keys calculation
	before the IKE_AUTH exchange starts, and since the PPK is used in		before the IKE_AUTH exchange starts, and since the PPK is used in
	authentication too, this exchange is quantum secure even against an		authentication too, this exchange is quantum secure even against an
	active attacker.		active attacker.
	This specification relies on the IKE_INTERMEDIATE exchange. Refer to		This specification relies on the IKE_INTERMEDIATE exchange. Refer to
	[RFC9242] for discussion of related security issues.		[RFC9242] for discussion of related security issues.
	Section 4 of [RFC9370] discusses the potential impact of appearing a		Section 4 of [RFC9370] discusses the potential impact of when a CRQC
	CRQC to various cryptographic primitives used in IKEv2. It is		is accessible on various cryptographic primitives used in IKEv2. It
	worthwhile to repeat here that it is believed that the security of		is worthwhile to repeat here that it is believed that the security of
	symmetric key cryptographic primitives will not be affected by CRQC.		symmetric key cryptographic primitives will not be affected by CRQC.
	5. IANA Considerations		5. IANA Considerations
	Per this document, IANA has added the following Notify Message Types		Per this document, IANA has added the following Notify Message Types
	in the "IKEv2 Notify Message Status Types" registry:		in the "IKEv2 Notify Message Status Types" registry:
	16445 USE_PPK_INT		16445 USE_PPK_INT
	16446 PPK_IDENTITY_KEY		16446 PPK_IDENTITY_KEY
End of changes. 10 change blocks.
	43 lines changed or deleted		51 lines changed or added
This html diff was produced by rfcdiff 1.48.