rfc9370.txt		rfc9370-alternate.txt
	skipping to change at line 332 ¶		skipping to change at line 332 ¶
	2.2.1. IKE_SA_INIT Round: Negotiation		2.2.1. IKE_SA_INIT Round: Negotiation
	Multiple key exchanges are negotiated using the standard IKEv2		Multiple key exchanges are negotiated using the standard IKEv2
	mechanism via SA payload. For this purpose, seven new transform		mechanism via SA payload. For this purpose, seven new transform
	types are defined: Additional Key Exchange 1 (AKE1) with IANA-		types are defined: Additional Key Exchange 1 (AKE1) with IANA-
	assigned value 6, Additional Key Exchange 2 (AKE2) (7), Additional		assigned value 6, Additional Key Exchange 2 (AKE2) (7), Additional
	Key Exchange 3 (AKE3) (8), Additional Key Exchange 4 (AKE4) (9),		Key Exchange 3 (AKE3) (8), Additional Key Exchange 4 (AKE4) (9),
	Additional Key Exchange 5 (AKE5) (10), Additional Key Exchange 6		Additional Key Exchange 5 (AKE5) (10), Additional Key Exchange 6
	(AKE6) (11), and Additional Key Exchange 7 (AKE7) (12). They are		(AKE6) (11), and Additional Key Exchange 7 (AKE7) (12). They are
	collectively called "Additional Key Exchange Transform Types" in this		collectively called "Additional Key Exchange (AKE*) Transform Types"
	document and have slightly different semantics than the existing		in this document and have slightly different semantics than the
	IKEv2 Transform Types. They are interpreted as an indication of		existing IKEv2 Transform Types. They are interpreted as an
	additional key exchange methods that peers agree to perform in a		indication of additional key exchange methods that peers agree to
	series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT		perform in a series of IKE_INTERMEDIATE exchanges following the
	exchange. The allowed Transform IDs for these transform types are		IKE_SA_INIT exchange. The allowed Transform IDs for these transform
	the same as the IDs for Transform Type 4, so they all share a single		types are the same as the IDs for Transform Type 4, so they all share
	IANA registry for Transform IDs.		a single IANA registry for Transform IDs.
	The key exchange method negotiated via Transform Type 4 always takes		The key exchange method negotiated via Transform Type 4 always takes
	place in the IKE_SA_INIT exchange, as defined in [RFC7296].		place in the IKE_SA_INIT exchange, as defined in [RFC7296].
	Additional key exchanges negotiated via newly defined transforms MUST		Additional key exchanges negotiated via newly defined transforms MUST
	take place in a series of IKE_INTERMEDIATE exchanges following the		take place in a series of IKE_INTERMEDIATE exchanges following the
	IKE_SA_INIT exchange, performed in an order of the values of their		IKE_SA_INIT exchange, performed in an order of the values of their
	Transform Types. This is so that the key exchange negotiated using		Transform Types. This is so that the key exchange negotiated using
	Additional Key Exchange i always precedes that of Additional Key		Additional Key Exchange i always precedes that of Additional Key
	Exchange i + 1. Each additional key exchange method MUST be fully		Exchange i + 1. Each additional key exchange method MUST be fully
	completed before the next one is started.		completed before the next one is started.
	With these semantics, note that Additional Key Exchange Transform		With these semantics, note that Additional Key Exchange (AKE*)
	Types are not associated with any particular type of key exchange and		Transform Types are not associated with any particular type of key
	do not have any Transform IDs that are specific per Transform Type		exchange and do not have any Transform IDs that are specific per
	IANA registry. Instead, they all share a single registry for		Transform Type IANA registry. Instead, they all share a single
	Transform IDs, namely "Transform Type 4 - Key Exchange Method		registry for Transform IDs, namely "Transform Type 4 - Key Exchange
	Transform IDs". All key exchange algorithms (both classical or post-		Method Transform IDs". All key exchange algorithms (both classical
	quantum) should be added to this registry. This approach gives peers		or post-quantum) should be added to this registry. This approach
	flexibility in defining the ways they want to combine different key		gives peers flexibility in defining the ways they want to combine
	exchange methods.		different key exchange methods.
	When forming a proposal, the initiator adds transforms for the		When forming a proposal, the initiator adds transforms for the
	IKE_SA_INIT exchange using Transform Type 4. In most cases, they		IKE_SA_INIT exchange using Transform Type 4. In most cases, they
	will contain classical (EC)DH key exchange methods, but that is not a		will contain classical (EC)DH key exchange methods, but that is not a
	requirement. Additional key exchange methods are proposed using		requirement. Additional key exchange methods are proposed using
	Additional Key Exchange Transform Types. All of these transform		Additional Key Exchange (AKE*) Transform Types. All of these
	types are optional; the initiator is free to select any of them for		transform types are optional; the initiator is free to select any of
	proposing additional key exchange methods. Consequently, if none of		them for proposing additional key exchange methods. Consequently, if
	the Additional Key Exchange Transform Types are included in the		none of the Additional Key Exchange (AKE*) Transform Types are
	proposal, then this proposal indicates the performing of standard		included in the proposal, then this proposal indicates the performing
	IKEv2, as defined in [RFC7296]. On the other hand, if the initiator		of standard IKEv2, as defined in [RFC7296]. On the other hand, if
	includes any Additional Key Exchange Transform Type in the proposal,		the initiator includes any Additional Key Exchange (AKE*) Transform
	the responder MUST select one of the algorithms proposed using this		Type in the proposal, the responder MUST select one of the algorithms
	type. Note that this is not a new requirement; this behavior is		proposed using this type. Note that this is not a new requirement;
	already specified in Section 2.7 of [RFC7296]. A Transform ID NONE		this behavior is already specified in Section 2.7 of [RFC7296]. A
	MAY be added to those transform types that contain key exchange		Transform ID NONE MAY be added to those transform types that contain
	methods which the initiator believes are optional according to its		key exchange methods which the initiator believes are optional
	local policy.		according to its local policy.
	The responder performs the negotiation using the standard IKEv2		The responder performs the negotiation using the standard IKEv2
	procedure described in Section 3.3 of [RFC7296]. However, for the		procedure described in Section 3.3 of [RFC7296]. However, for the
	Additional Key Exchange Transform Types, the responder's choice MUST		Additional Key Exchange (AKE*) Transform Types, the responder's
	NOT contain duplicated algorithms (those with an identical Transform		choice MUST NOT contain duplicated algorithms (those with an
	ID and attributes), except for the Transform ID of NONE. An		identical Transform ID and attributes), except for the Transform ID
	algorithm is represented as a transform. In some cases, the		of NONE. An algorithm is represented as a transform. In some cases,
	transform could include a set of associated attributes that define		the transform could include a set of associated attributes that
	details of the algorithm. In this case, two transforms can be the		define details of the algorithm. In this case, two transforms can be
	same, but the attributes must be different. Additionally, the order		the same, but the attributes must be different. Additionally, the
	of the attributes does not affect the equality of the algorithm, so		order of the attributes does not affect the equality of the
	the following two transforms define the same algorithm: "ID=alg1,		algorithm, so the following two transforms define the same algorithm:
	ATTR1=attr1, ATTR2=attr2" and "ID=alg1, ATTR2=attr2, ATTR1=attr1".		"ID=alg1, ATTR1=attr1, ATTR2=attr2" and "ID=alg1, ATTR2=attr2,
	If the responder is unable to select algorithms that are not		ATTR1=attr1". If the responder is unable to select algorithms that
	duplicated for each proposed key exchange (either because the		are not duplicated for each proposed key exchange (either because the
	proposal contains too few choices or due to the local policy		proposal contains too few choices or due to the local policy
	restrictions on using the proposed algorithms), then the responder		restrictions on using the proposed algorithms), then the responder
	MUST reject the message with an error notification of type		MUST reject the message with an error notification of type
	NO_PROPOSAL_CHOSEN. If the responder's message contains one or more		NO_PROPOSAL_CHOSEN. If the responder's message contains one or more
	duplicated choices, the initiator should log the error and MUST treat		duplicated choices, the initiator should log the error and MUST treat
	the exchange as failed. The initiator MUST NOT initiate any		the exchange as failed. The initiator MUST NOT initiate any
	IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges so that no new SA is		IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges so that no new SA is
	created. If this happens in the CREATE_CHILD_SA exchange, then the		created. If this happens in the CREATE_CHILD_SA exchange, then the
	initiator MAY delete the IKE SA over which the invalid message was		initiator MAY delete the IKE SA over which the invalid message was
	received by sending a Delete payload.		received by sending a Delete payload.
	If the responder selects NONE for some Additional Key Exchange		If the responder selects NONE for some Additional Key Exchange (AKE*)
	Transform Types (provided they are proposed by the initiator), then		Transform Types (provided they are proposed by the initiator), then
	any corresponding additional key exchanges MUST NOT take place.		any corresponding additional key exchanges MUST NOT take place.
	Therefore, if the initiator includes NONE in all of the Additional		Therefore, if the initiator includes NONE in all of the Additional
	Key Exchange Transform Types and the responder selects this value for		Key Exchange (AKE*) Transform Types and the responder selects this
	all of them, then no IKE_INTERMEDIATE exchanges performing additional		value for all of them, then no IKE_INTERMEDIATE exchanges performing
	key exchanges will take place between the peers. Note that the		additional key exchanges will take place between the peers. Note
	IKE_INTERMEDIATE exchanges may still take place for other purposes.		that the IKE_INTERMEDIATE exchanges may still take place for other
			purposes.
	The initiator MAY propose Additional Key Exchange Transform Types		The initiator MAY propose Additional Key Exchange (AKE*) Transform
	that are not consecutive, for example, proposing Additional Key		Types that are not consecutive, for example, proposing Additional Key
	Exchange 2 (AKE2) and Additional Key Exchange 5 (AKE5) Transform		Exchange 2 (AKE2) and Additional Key Exchange 5 (AKE5) Transform
	Types only. The responder MUST treat all of the omitted Additional		Types only. The responder MUST treat all of the omitted Additional
	Key Exchange transforms as if they were proposed with Transform ID		Key Exchange transforms as if they were proposed with Transform ID
	NONE.		NONE.
	Below is an example of the SA payload in the initiator's IKE_SA_INIT		Below is an example of the SA payload in the initiator's IKE_SA_INIT
	request message. Here, the abbreviation "AKEi" is used to denote the		request message. Here, the abbreviation "AKEi" is used to denote the
	i-th Additional Key Exchange Transform Type defined in this document;		i-th Additional Key Exchange (AKE*) Transform Type defined in this
	the abbreviation "KE" is used for the Key Exchange transform, which		document; the abbreviation "KE" is used for the Key Exchange
	this document renames from the Diffie-Hellman Group transform.		transform, which this document renames from the Diffie-Hellman Group
	Additionally, the notations PQ_KEM_1, PQ_KEM_2, and PQ_KEM_3 are used		transform. Additionally, the notations PQ_KEM_1, PQ_KEM_2, and
	to represent Transform IDs that have yet to be defined of some		PQ_KEM_3 are used to represent Transform IDs that have yet to be
	popular post-quantum key exchange methods.		defined of some popular post-quantum key exchange methods.
	SA Payload		SA Payload
	|		|
	+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,		+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
	| 9 transforms, SPI = 0x35a1d6f22564f89d )		| 9 transforms, SPI = 0x35a1d6f22564f89d )
	|		|
	+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )		+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
	| +-- Attribute ( Key Length = 256 )		| +-- Attribute ( Key Length = 256 )
	|		|
	+-- Transform KE ( ID = 4096-bit MODP Group )		+-- Transform KE ( ID = 4096-bit MODP Group )
	skipping to change at line 483 ¶		skipping to change at line 484 ¶
	+-- Transform KE ( ID = 4096-bit MODP Group )		+-- Transform KE ( ID = 4096-bit MODP Group )
	|		|
	+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )		+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
	|		|
	+-- Transform AKE2 ( ID = PQ_KEM_2 )		+-- Transform AKE2 ( ID = PQ_KEM_2 )
	|		|
	+-- Transform AKE3 ( ID = PQ_KEM_1 )		+-- Transform AKE3 ( ID = PQ_KEM_1 )
	|		|
	+-- Transform AKE5 ( ID = NONE )		+-- Transform AKE5 ( ID = NONE )
	If the initiator includes any Additional Key Exchange Transform Types		If the initiator includes any Additional Key Exchange (AKE*)
	into the SA payload in the IKE_SA_INIT exchange request message, then		Transform Types into the SA payload in the IKE_SA_INIT exchange
	it MUST also negotiate the use of the IKE_INTERMEDIATE exchange, as		request message, then it MUST also negotiate the use of the
	described in [RFC9242] by including an		IKE_INTERMEDIATE exchange, as described in [RFC9242] by including an
	INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If		INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If
	the responder agrees to use additional key exchanges while		the responder agrees to use additional key exchanges while
	establishing an initial IKE SA, it MUST also return this notification		establishing an initial IKE SA, it MUST also return this notification
	in the IKE_SA_INIT response message, confirming that IKE_INTERMEDIATE		in the IKE_SA_INIT response message, confirming that IKE_INTERMEDIATE
	exchange is supported and will be used for transferring additional		exchange is supported and will be used for transferring additional
	key exchange data. If the IKE_INTERMEDIATE exchange is not		key exchange data. If the IKE_INTERMEDIATE exchange is not
	negotiated, then the peers MUST treat any Additional Key Exchange		negotiated, then the peers MUST treat any Additional Key Exchange
	Transform Types in the IKE_SA_INIT exchange messages as unknown		(AKE*) Transform Types in the IKE_SA_INIT exchange messages as
	transform types and skip the proposals they appear in. If no other		unknown transform types and skip the proposals they appear in. If no
	proposals are present in the SA payload, the peers will proceed as if		other proposals are present in the SA payload, the peers will proceed
	no proposal has been chosen (i.e., the responder will send a		as if no proposal has been chosen (i.e., the responder will send a
	NO_PROPOSAL_CHOSEN notification).		NO_PROPOSAL_CHOSEN notification).
	Initiator Responder		Initiator Responder
	---------------------------------------------------------------------		---------------------------------------------------------------------
	HDR, SAi1(.. AKE*...), KEi, Ni,		HDR, SAi1(.. AKE*...), KEi, Ni,
	N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->		N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
	HDR, SAr1(.. AKE*...), KEr, Nr,		HDR, SAr1(.. AKE*...), KEr, Nr,
	[CERTREQ],		[CERTREQ],
	<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)		<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
	skipping to change at line 578 ¶		skipping to change at line 579 ¶
	creating additional Child SAs, rekeying these Child SAs, and rekeying		creating additional Child SAs, rekeying these Child SAs, and rekeying
	IKE SA itself. When creating or rekeying Child SAs, the peers may		IKE SA itself. When creating or rekeying Child SAs, the peers may
	optionally perform a key exchange to add a fresh entropy into the		optionally perform a key exchange to add a fresh entropy into the
	session keys. In the case of an IKE SA rekey, the key exchange is		session keys. In the case of an IKE SA rekey, the key exchange is
	mandatory. Peers supporting this specification may want to use		mandatory. Peers supporting this specification may want to use
	multiple key exchanges in these situations.		multiple key exchanges in these situations.
	Using multiple key exchanges with a CREATE_CHILD_SA exchange is		Using multiple key exchanges with a CREATE_CHILD_SA exchange is
	negotiated in a similar fashion to the initial IKE exchange, see		negotiated in a similar fashion to the initial IKE exchange, see
	Section 2.2.1. If the initiator includes any Additional Key Exchange		Section 2.2.1. If the initiator includes any Additional Key Exchange
	Transform Types in the SA payload (along with Transform Type 4), and		(AKE*) Transform Types in the SA payload (along with Transform Type
	if the responder agrees to perform additional key exchanges, then the		4), and if the responder agrees to perform additional key exchanges,
	additional key exchanges are performed in a series of new		then the additional key exchanges are performed in a series of new
	IKE_FOLLOWUP_KE exchanges that follow the CREATE_CHILD_SA exchange.		IKE_FOLLOWUP_KE exchanges that follow the CREATE_CHILD_SA exchange.
	The IKE_FOLLOWUP_KE exchange is introduced especially for		The IKE_FOLLOWUP_KE exchange is introduced especially for
	transferring data of additional key exchanges following the one		transferring data of additional key exchanges following the one
	performed in the CREATE_CHILD_SA. Its Exchange Type value is 44.		performed in the CREATE_CHILD_SA. Its Exchange Type value is 44.
	The key exchange negotiated via Transform Type 4 always takes place		The key exchange negotiated via Transform Type 4 always takes place
	in the CREATE_CHILD_SA exchange, as per the IKEv2 specification		in the CREATE_CHILD_SA exchange, as per the IKEv2 specification
	[RFC7296]. Additional key exchanges are performed in an order of the		[RFC7296]. Additional key exchanges are performed in an order of the
	values of their Transform Types so that the key exchange negotiated		values of their Transform Types so that the key exchange negotiated
	using Transform Type i always precedes the key exchange negotiated		using Transform Type i always precedes the key exchange negotiated
	skipping to change at line 749 ¶		skipping to change at line 750 ¶
	from the IKE_SA_INIT exchange, can be immediately rekeyed with		from the IKE_SA_INIT exchange, can be immediately rekeyed with
	CREATE_CHILD_SA with additional key exchanges, where IKE_FOLLOWUP_KE		CREATE_CHILD_SA with additional key exchanges, where IKE_FOLLOWUP_KE
	messages are used for these additional key exchanges. If the		messages are used for these additional key exchanges. If the
	classical key exchange method is used in the IKE_SA_INIT message, the		classical key exchange method is used in the IKE_SA_INIT message, the
	very first Child SA created in IKE_AUTH will offer no resistance		very first Child SA created in IKE_AUTH will offer no resistance
	against the quantum threats. Consequently, if the peers' local		against the quantum threats. Consequently, if the peers' local
	policy requires all Child SAs to be post-quantum secure, then the		policy requires all Child SAs to be post-quantum secure, then the
	peers can avoid creating the very first Child SA by adopting		peers can avoid creating the very first Child SA by adopting
	[RFC6023]. In this case, the initiator sends two types of proposals		[RFC6023]. In this case, the initiator sends two types of proposals
	in the IKE_SA_INIT request: one with and another one without		in the IKE_SA_INIT request: one with and another one without
	Additional Key Exchange Transform Types. The responder chooses the		Additional Key Exchange (AKE*) Transform Types. The responder
	latter proposal type and includes a CHILDLESS_IKEV2_SUPPORTED		chooses the latter proposal type and includes a
	notification in the IKE_SA_INIT response. Assuming that the		CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response.
	initiator supports childless IKE SA extension, both peers perform the		Assuming that the initiator supports childless IKE SA extension, both
	modified IKE_AUTH exchange described in [RFC6023], and no Child SA is		peers perform the modified IKE_AUTH exchange described in [RFC6023],
	created in this exchange. The peers should then immediately rekey		and no Child SA is created in this exchange. The peers should then
	the IKE SA and subsequently create the Child SAs, all with additional		immediately rekey the IKE SA and subsequently create the Child SAs,
	key exchanges using a CREATE_CHILD_SA exchange.		all with additional key exchanges using a CREATE_CHILD_SA exchange.
	It is also possible for the initiator to send proposals without any		It is also possible for the initiator to send proposals without any
	Additional Key Exchange Transform Types in the IKE_SA_INIT message.		Additional Key Exchange (AKE*) Transform Types in the IKE_SA_INIT
	In this instance, the responder will have no information about		message. In this instance, the responder will have no information
	whether or not the initiator supports the extension in this		about whether or not the initiator supports the extension in this
	specification. This may not be efficient, as the responder will have		specification. This may not be efficient, as the responder will have
	to wait for the subsequent CREATE_CHILD_SA request to determine		to wait for the subsequent CREATE_CHILD_SA request to determine
	whether or not the initiator's request is appropriate for its local		whether or not the initiator's request is appropriate for its local
	policy.		policy.
	The support for childless IKE SA is not negotiated, but it is the		The support for childless IKE SA is not negotiated, but it is the
	responder that indicates the support for this mode. As such, the		responder that indicates the support for this mode. As such, the
	responder cannot enforce that the initiator use this mode.		responder cannot enforce that the initiator use this mode.
	Therefore, it is entirely possible that the initiator does not		Therefore, it is entirely possible that the initiator does not
	support this extension and sends IKE_AUTH request as per [RFC7296]		support this extension and sends IKE_AUTH request as per [RFC7296]
End of changes. 13 change blocks.
	77 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.48.