< draft-ietf-ipsecme-g-ikev2-01.txt		draft-ietf-ipsecme-g-ikev2-02.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Obsoletes: 6407 (if approved) B. Weis		Obsoletes: 6407 (if approved) B. Weis
	Intended status: Standards Track Independent		Intended status: Standards Track Independent
	Expires: January 14, 2021 July 13, 2020		Expires: July 15, 2021 January 11, 2021
	Group Key Management using IKEv2		Group Key Management using IKEv2
	draft-ietf-ipsecme-g-ikev2-01		draft-ietf-ipsecme-g-ikev2-02
	Abstract		Abstract
	This document presents an extension to the Internet Key Exchange		This document presents an extension to the Internet Key Exchange
	version 2 (IKEv2) protocol for the purpose of a group key management.		version 2 (IKEv2) protocol for the purpose of a group key management.
	The protocol is in conformance with the Multicast Security (MSEC) key		The protocol is in conformance with the Multicast Security (MSEC) key
	management architecture, which contains two components: member		management architecture, which contains two components: member
	registration and group rekeying. Both components require a Group		registration and group rekeying. Both components require a Group
	Controller/Key Server to download IPsec group security associations		Controller/Key Server to download IPsec group security associations
	to authorized members of a group. The group members then exchange IP		to authorized members of a group. The group members then exchange IP
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 14, 2021.		This Internet-Draft will expire on July 15, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	1.2.2. IKEv2 Header Initialization . . . . . . . . . . . . . 6		1.2.2. IKEv2 Header Initialization . . . . . . . . . . . . . 6
	1.3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . 6		1.3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . 6
	1.3.1. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . 6		1.3.1. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . 6
	1.4. G-IKEv2 Member Registration and Secure Channel		1.4. G-IKEv2 Member Registration and Secure Channel
	Establishment . . . . . . . . . . . . . . . . . . . . . . 7		Establishment . . . . . . . . . . . . . . . . . . . . . . 7
	1.4.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 7		1.4.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 7
	1.4.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 9		1.4.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 9
	1.4.3. GM Registration Operations . . . . . . . . . . . . . 10		1.4.3. GM Registration Operations . . . . . . . . . . . . . 10
	1.4.4. GCKS Registration Operations . . . . . . . . . . . . 12		1.4.4. GCKS Registration Operations . . . . . . . . . . . . 12
	1.4.5. Group Maintenance Channel . . . . . . . . . . . . . . 13		1.4.5. Group Maintenance Channel . . . . . . . . . . . . . . 13
	1.4.6. Counter-based modes of operation . . . . . . . . . . 20		1.4.6. Counter-based modes of operation . . . . . . . . . . 21
	2. Group Key Management and Access Control . . . . . . . . . . . 22		2. Group Key Management and Access Control . . . . . . . . . . . 23
	2.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 23		2.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 23
	2.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 23		2.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 24
	2.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 23		2.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 24
	2.2.1. Forward Access Control Requirements . . . . . . . . . 24		2.2.1. Forward Access Control Requirements . . . . . . . . . 25
	2.3. GM Key Management Semantics . . . . . . . . . . . . . . . 25		2.3. GM Key Management Semantics . . . . . . . . . . . . . . . 25
	2.4. Group SA Keys . . . . . . . . . . . . . . . . . . . . . . 26		2.4. Group SA Keys . . . . . . . . . . . . . . . . . . . . . . 27
	3. Header and Payload Formats . . . . . . . . . . . . . . . . . 27		3. Header and Payload Formats . . . . . . . . . . . . . . . . . 28
	3.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 27		3.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 28
	3.2. Group Identification Payload . . . . . . . . . . . . . . 27		3.2. Group Identification Payload . . . . . . . . . . . . . . 28
	3.3. Security Association - GM Supported Transforms Payload . 27		3.3. Security Association - GM Supported Transforms Payload . 28
	3.4. Group Security Association Payload . . . . . . . . . . . 28		3.4. Group Security Association Payload . . . . . . . . . . . 28
	3.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 28		3.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 29
	3.4.2. Group Security Association Policy Substructure . . . 29		3.4.2. Group Security Association Policy Substructure . . . 30
	3.4.3. Group Associated Policy Substructure . . . . . . . . 35		3.4.3. Group Associated Policy Substructure . . . . . . . . 35
	3.5. Key Download Payload . . . . . . . . . . . . . . . . . . 37		3.5. Key Download Payload . . . . . . . . . . . . . . . . . . 37
	3.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 37		3.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 38
	3.5.2. Group Key Packet Substructure . . . . . . . . . . . . 39		3.5.2. Group Key Packet Substructure . . . . . . . . . . . . 39
	3.5.3. Member Key Packet Substructure . . . . . . . . . . . 40		3.5.3. Member Key Packet Substructure . . . . . . . . . . . 41
	3.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 43		3.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 44
	3.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 43		3.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 44
	3.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 44		3.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 45
	3.8. Authentication Payload . . . . . . . . . . . . . . . . . 45		3.8. Authentication Payload . . . . . . . . . . . . . . . . . 45
	4. Interaction with other IKEv2 Protocol Extensions . . . . . . 45		4. Interaction with other IKEv2 Protocol Extensions . . . . . . 46
	4.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 45		4.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 46
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 47		5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	5.1. GSA Registration and Secure Channel . . . . . . . . . . . 47		5.1. GSA Registration and Secure Channel . . . . . . . . . . . 48
	5.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 47		5.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 48
	5.2.1. Authentication/Authorization . . . . . . . . . . . . 47		5.2.1. Authentication/Authorization . . . . . . . . . . . . 48
	5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 47		5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 48
	5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 48		5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 48
	5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 48		5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 49
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 48		6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 49
	6.2. Changes in the Existing IKEv2 Registries . . . . . . . . 50		6.2. Changes in the Existing IKEv2 Registries . . . . . . . . 51
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	9.1. Normative References . . . . . . . . . . . . . . . . . . 52		9.1. Normative References . . . . . . . . . . . . . . . . . . 53
	9.2. Informative References . . . . . . . . . . . . . . . . . 53		9.2. Informative References . . . . . . . . . . . . . . . . . 54
	Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 56		Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 57
	A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 56		A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 57
	A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 56		A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 57
	A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 57		A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 58
	A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 58		A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 59
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
	1. Introduction and Overview		1. Introduction and Overview
	A group key management protocol provides IPsec keys and policy to a		A group key management protocol provides IPsec keys and policy to a
	set of IPsec devices which are authorized to communicate using a		set of IPsec devices which are authorized to communicate using a
	Group Security Association (GSA) defined in [RFC3740]. The data		Group Security Association (GSA) defined in [RFC3740]. The data
	communications within the group (e.g., IP multicast packets) are		communications within the group (e.g., IP multicast packets) are
	protected by a key pushed to the group members (GMs) by the Group		protected by a key pushed to the group members (GMs) by the Group
	Controller/Key Server (GCKS). This document presents an extension to		Controller/Key Server (GCKS). This document presents an extension to
	IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key		IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	SENDER Notify payload status. The SENDER not only signifies that it		SENDER Notify payload status. The SENDER not only signifies that it
	is a sender, but provides the initiator the ability to request		is a sender, but provides the initiator the ability to request
	Sender-ID values, in case the data security SA supports a counter		Sender-ID values, in case the data security SA supports a counter
	mode cipher. Section 1.4.6) includes guidance on requesting Sender-		mode cipher. Section 1.4.6) includes guidance on requesting Sender-
	ID values.		ID values.
	A GM may be limited in the types of Transforms that it is able or		A GM may be limited in the types of Transforms that it is able or
	willing to use, and may find it useful to inform the GCKS which		willing to use, and may find it useful to inform the GCKS which
	Transforms it is willing to accept for different security protocols.		Transforms it is willing to accept for different security protocols.
	Proposals for Rekey SA (with protocol GIKE_REKEY) and for data		Proposals for Rekey SA (with protocol GIKE_REKEY) and for data
	security (AH and/or ESP) SAs may be included into SAg. Each Proposal		security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be included into
	contains a list of Transforms that the GM is able to support for that		SAg. Each Proposal contains a list of Transforms that the GM is able
	protocol. Valid transform types depend on the protocol and are		to support for that protocol. Valid transform types depend on the
	defined in Figure 15. Other transform types SHOULD NOT be included.		protocol and are defined in Figure 15. Other transform types SHOULD
	The SPI length of each Proposal in an SAg is set to zero, and thus		NOT be included. The SPI length of each Proposal in an SAg is set to
	the SPI field is empty. The GCKS MUST ignore SPI field in the SAg		zero, and thus the SPI field is empty. The GCKS MUST ignore SPI
	payload.		field in the SAg payload.
	Generally, a single Proposal of each type will suffice, because the		Generally, a single Proposal of each type will suffice, because the
	group member is not negotiating Transform sets, simply alerting the		group member is not negotiating Transform sets, simply alerting the
	GCKS to restrictions it may have. In particular, the restriction		GCKS to restrictions it may have. In particular, the restriction
	from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must		from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must
	not be combined in a single proposal doesn't hold when the SAg		not be combined in a single proposal doesn't hold when the SAg
	payload is being formed. However if the GM has restrictions on		payload is being formed. However if the GM has restrictions on
	combination of algorithms, this can be expressed by sending several		combination of algorithms, this can be expressed by sending several
	proposals.		proposals.
			Proposal Num field in Proposal substructure is treated specially in
			SAg payload: it allows a GM to indicate that algorithms used in Rekey
			SA and in data security (AH and/or ESP) SAs are dependent. In
			particular, Proposals of different types having the same value in
			Proposal Num field are treated as a set, so that if GCKS uses
			transforms from one of such Proposal for one protocol, then it MUST
			only use transforms from one of the Proposals with the same value in
			Proposal Num field for other protocols. For example, a GM may
			support algorithms X and Y for both Rekey and data security SAs, but
			with a restriction that if X is used in Rekey SA, then only X can be
			used in data security SAs, and the same for Y. To indicate this the
			GM sends several Proposals marking those of them that must be used in
			conjunction by putting the same value in their Proposal Num field.
			In the simplest case when no dependency between transforms exists,
			all Proposals in SAg payload will have the same value in Proposal Num
			field.
	Although the SAg payload is optional, it is RECOMMENDED for the GM to		Although the SAg payload is optional, it is RECOMMENDED for the GM to
	include this payload into the GSA_AUTH request to allow the GCKS to		include this payload into the GSA_AUTH request to allow the GCKS to
	select an appropriate policy.		select an appropriate policy.
	A GM may also indicate the support for IPcomp by inclusion one or		A GM may also indicate the support for IPcomp by inclusion one or
	more the IPCOMP_SUPPORTED notifications along with the SAg payload.		more the IPCOMP_SUPPORTED notifications along with the SAg payload.
	The CPI in these notifications is set to zero and MUST be ignored by		The CPI in these notifications is set to zero and MUST be ignored by
	the GCKS.		the GCKS.
	Upon receiving the GSA_AUTH response, the initiator parses the		Upon receiving the GSA_AUTH response, the initiator parses the
	skipping to change at page 16, line 15 ¶		skipping to change at page 17, line 4 ¶
	length of P plus the size of the Payload header (four octets).		length of P plus the size of the Payload header (four octets).
	DataToAuthenticate = A | P		DataToAuthenticate = A | P
	GsaRekeyMessage = GenIKEHDR | EncPayload		GsaRekeyMessage = GenIKEHDR | EncPayload
	GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR		GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR
	AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen		AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen
	EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV		EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV
	AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen		AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen
	A = AdjustedIKEHDR | AdjustedEncPldHdr		A = AdjustedIKEHDR | AdjustedEncPldHdr
	P = InnerPlds		P = InnerPlds
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
	| G-IKEv2 SA Initiator's SPI | | |		| G-IKEv2 SA Initiator's SPI | | |
	| | | |		| | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
	| G-IKEv2 SA Responder's SPI | K |		| G-IKEv2 SA Responder's SPI | K |
	| | E |		| | E |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Next Payload | MjVer | MnVer | Exchange Type | Flags | H A		| Next Payload | MjVer | MnVer | Exchange Type | Flags | H A
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
	| Message ID | r |		| Message ID | r |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
	| AdjustedLeng | | |		| AdjustedLen | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x |
	| Next Payload |C| RESERVED | AdjustedPldLen | | |		| Next Payload |C| RESERVED | AdjustedPldLen | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
	| Initialization Vector | n		| | |
			~ Initialization Vector ~ E
			| | n
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
	| | r |		| | r |
	~ Inner payloads (not yet encrypted) ~ P		~ Inner payloads (not yet encrypted) ~ P
	| | P |		| | P |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
	| Padding (0-255 octets) | Pad Length | d		~ Padding (0-255 octets) | Pad Length | d
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
			| | |
	~ Integrity Checksum Data ~ |		~ Integrity Checksum Data ~ |
			| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
	Figure 10: Data to Authenticate in the GSA_REKEY Messages		Figure 10: Data to Authenticate in the GSA_REKEY Messages
	The authentication data is calculated using the authentication		The authentication data is calculated using the authentication
	algorithm from the Authentication Method transform and the key		algorithm from the Authentication Method transform and the key
	provided before in the AUTH_KEY attribute. Depending on the		provided before in the AUTH_KEY attribute. Depending on the
	authentication method the authentication data is either a digital		authentication method the authentication data is either a digital
	signature or a result of applying prf from the Pseudorandom Function		signature or a result of applying prf from the Pseudorandom Function
	transform. The calculated authentication data is placed into the		transform. The calculated authentication data is placed into the
	skipping to change at page 32, line 8 ¶		skipping to change at page 32, line 19 ¶
	are used. In addition, new transform types are defined for using in		are used. In addition, new transform types are defined for using in
	G-IKEv2: Authentication Method (AUTH) and Group Key Management Method		G-IKEv2: Authentication Method (AUTH) and Group Key Management Method
	(GKM), see Section 6.		(GKM), see Section 6.
	Valid Transform Types depend on group SA protocol and are summarized		Valid Transform Types depend on group SA protocol and are summarized
	in the table below.		in the table below.
	Protocol Mandatory Types Optional Types		Protocol Mandatory Types Optional Types
	----------------------------------------------------------		----------------------------------------------------------
	GIKE_REKEY ENCR, INTEG*, PRF, AUTH, GKM		GIKE_REKEY ENCR, INTEG*, PRF, AUTH, GKM
	ESP ENCR INTEG		ESP ENCR INTEG, ESN
	AH INTEG		AH INTEG ESN
	Figure 15: Valid Transform Types		Figure 15: Valid Transform Types
	(*) If AEAD encryption algorithm is used, then INTEG transform MUST		(*) If AEAD encryption algorithm is used, then INTEG transform MUST
	NOT be specified, otherwise it MUST be specified.		NOT be specified, otherwise it MUST be specified.
	3.4.2.1.1. Authentication Method Transform		3.4.2.1.1. Authentication Method Transform
	The Authentication Method (AUTH) transform is used in the GIKE_REKEY		The Authentication Method (AUTH) transform is used in the GIKE_REKEY
	policy to convey information of how GCKS will authenticate the		policy to convey information of how GCKS will authenticate the
	skipping to change at page 33, line 32 ¶		skipping to change at page 33, line 43 ¶
	Wrapped Key Download (<TBA by IANA>) - Keys are downloaded by GCKS		Wrapped Key Download (<TBA by IANA>) - Keys are downloaded by GCKS
	to the GMs in encrypted form. This algorithm may provide forward		to the GMs in encrypted form. This algorithm may provide forward
	and backward access control if some form of key hierarchy is used		and backward access control if some form of key hierarchy is used
	and each GM is provided with a personal key at the time of		and each GM is provided with a personal key at the time of
	registration. Otherwise no access control is provided.		registration. Otherwise no access control is provided.
	The type of the Group Key Management Method transform is <TBA by		The type of the Group Key Management Method transform is <TBA by
	IANA>.		IANA>.
			3.4.2.1.3. Extended Sequence Number Transform
			Extended Sequence Number (ESN) Transform is defined in [RFC7296] to
			allow using 64-bit sequence numbers in ESP and AH. Since both AH
			[RFC4302] and ESP [RFC4303] are defined so, that high-order 32 bits
			of extended sequence numbers are never transferred on the wire, it
			makes using ESN in multicast data security SAs problematic, because
			GMs that join group long after it is created will have to somehow
			learn the current high order 32 bits of ESN for each sender in the
			group. The algorithm for doing this described in [RFC4302] and
			[RFC4303] is resource-consuming. For this reason extended sequence
			numbers SHOULD NOT be used for multicast data security SAs and thus
			the ESN Transform SHOULD NOT be included in the GSA Payload.
	3.4.2.2. GSA Attributes		3.4.2.2. GSA Attributes
	GSA attributes are generally used to provide GMs with additional		GSA attributes are generally used to provide GMs with additional
	parameters for the GSA policy. Unlike security parameters		parameters for the GSA policy. Unlike security parameters
	distributed via transforms, which are expected not to change over		distributed via transforms, which are expected not to change over
	time (unless policy changes), the parameters distributed via GSA		time (unless policy changes), the parameters distributed via GSA
	attributes may depend on the time the distribution takes place, on		attributes may depend on the time the provision takes place, on the
	the existence of others group SAs or on other conditions.		existence of others group SAs or on other conditions.
	This document creates a new IKEv2 IANA registry for the types of the		This document creates a new IKEv2 IANA registry for the types of the
	GSA attributes which is initially filled as described in Section 6.		GSA attributes which is initially filled as described in Section 6.
	In particular, the following attributes are initially added.		In particular, the following attributes are initially added.
	GSA Attributes Value Type Multiple Used In		GSA Attributes Value Type Multiple Used In
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Reserved 0		Reserved 0
	GSA_KEY_LIFETIME 1 V N (GIKE_REKEY, AH, ESP)		GSA_KEY_LIFETIME 1 V N (GIKE_REKEY, AH, ESP)
	GSA_INITIAL_MESSAGE_ID 2 V N (GIKE_REKEY)		GSA_INITIAL_MESSAGE_ID 2 V N (GIKE_REKEY)
	skipping to change at page 43, line 4 ¶		skipping to change at page 43, line 38 ¶
	authentication then the content of the AUTH_KEY attribute is the		authentication then the content of the AUTH_KEY attribute is the
	shared secret that MUST be represented in the form of Wrapped Key		shared secret that MUST be represented in the form of Wrapped Key
	(see Section 3.5.1) with zero KWK ID. The Key ID in this case is		(see Section 3.5.1) with zero KWK ID. The Key ID in this case is
	arbitrary and MUST be ignored by the GM.		arbitrary and MUST be ignored by the GM.
	o If digital signatures are used for the GSA_REKEY messages		o If digital signatures are used for the GSA_REKEY messages
	authentication then the content of the AUTH_KEY attribute is a		authentication then the content of the AUTH_KEY attribute is a
	public key used for digital signature authentication. The public		public key used for digital signature authentication. The public
	key MUST be represented as DER-encoded ASN.1 object		key MUST be represented as DER-encoded ASN.1 object
	SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280].		SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280].
	The signature algorithm that will use this key was specified in		The signature algorithm that will use this key was specified in
	the Algorithm Identifier attribute of the Authentication Method		the Algorithm Identifier attribute of the Authentication Method
	transform. The key MUST be compatible with this algorithm. An		transform. The key MUST be compatible with this algorithm. An
	RSA public key format is defined in [RFC3447], Section A.1. DSS		RSA public key format is defined in [RFC8017], Section A.1. DSS
	public key format is defined in [RFC3279] Section 2.3.2. For		public key format is defined in [RFC3279] Section 2.3.2. For
	ECDSA Public keys, use format described in [RFC5480] Section 2.		ECDSA Public keys, use format described in [RFC5480] Section 2.
	Other algorithms added to the IKEv2 Authentication Method registry		Other algorithms added to the IKEv2 Authentication Method registry
	are also expected to include a format of the SubjectPublicKeyInfo		are also expected to include a format of the SubjectPublicKeyInfo
	object included in the algorithm specification.		object included in the algorithm specification.
	Multiple instances of the AUTH_KEY attributes MUST NOT be sent.		Multiple instances of the AUTH_KEY attributes MUST NOT be sent.
	3.6. Delete Payload		3.6. Delete Payload
	skipping to change at page 52, line 39 ¶		skipping to change at page 53, line 39 ¶
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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>.
	[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
	Multicast: Issues and Architectures", RFC 2627,
	DOI 10.17487/RFC2627, June 1999,
	<https://www.rfc-editor.org/info/rfc2627>.
	[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
	Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
	<https://www.rfc-editor.org/info/rfc3740>.
	[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
	"Multicast Security (MSEC) Group Key Management
	Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
	<https://www.rfc-editor.org/info/rfc4046>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
			[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
			DOI 10.17487/RFC4302, December 2005,
			<https://www.rfc-editor.org/info/rfc4302>.
			[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
			RFC 4303, DOI 10.17487/RFC4303, December 2005,
			<https://www.rfc-editor.org/info/rfc4303>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with		[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with
	Encapsulating Security Payload (ESP) and Authentication		Encapsulating Security Payload (ESP) and Authentication
	Header (AH) to Protect Group Traffic", RFC 6054,		Header (AH) to Protect Group Traffic", RFC 6054,
	DOI 10.17487/RFC6054, November 2010,		DOI 10.17487/RFC6054, November 2010,
	<https://www.rfc-editor.org/info/rfc6054>.		<https://www.rfc-editor.org/info/rfc6054>.
	[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
			the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
			DOI 10.17487/RFC7427, January 2015,
			<https://www.rfc-editor.org/info/rfc7427>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-ipsecme-ikev2-multiple-ke]		[I-D.ietf-ipsecme-ikev2-multiple-ke]
	Tjhai, C., Tomlinson, M., grbartle@cisco.com, g., Fluhrer,		Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
	S., Geest, D., Garcia-Morchon, O., and V. Smyslov,		Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
	"Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme-		Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-
	ikev2-multiple-ke-00 (work in progress), January 2020.		multiple-ke-02 (work in progress), January 2021.
	[I-D.smyslov-ipsecme-ikev2-qr-alt]		[I-D.smyslov-ipsecme-ikev2-qr-alt]
	Smyslov, V., "Alternative Approach for Mixing Preshared		Smyslov, V., "Alternative Approach for Mixing Preshared
	Keys in IKEv2 for Post-quantum Security", draft-smyslov-		Keys in IKEv2 for Post-quantum Security", draft-smyslov-
	ipsecme-ikev2-qr-alt-01 (work in progress), February 2020.		ipsecme-ikev2-qr-alt-02 (work in progress), August 2020.
	[IKEV2-IANA]		[IKEV2-IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)		IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters", <http://www.iana.org/assignments/ikev2-		Parameters", <http://www.iana.org/assignments/ikev2-
	parameters/ikev2-parameters.xhtml#ikev2-parameters-7>.		parameters/ikev2-parameters.xhtml#ikev2-parameters-7>.
	[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and		[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and
	Tracing Schemes for Stateless Receivers", Advances in		Tracing Schemes for Stateless Receivers", Advances in
	Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,		Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,
	pp. 41-62, 2001,		pp. 41-62, 2001,
	skipping to change at page 54, line 21 ¶		skipping to change at page 55, line 21 ¶
	[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large		[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large
	Dynamic Groups Using One-Way Function Trees", Manuscript,		Dynamic Groups Using One-Way Function Trees", Manuscript,
	submitted to IEEE Transactions on Software Engineering,		submitted to IEEE Transactions on Software Engineering,
	1998, <https://pdfs.semanticscholar.org/		1998, <https://pdfs.semanticscholar.org/
	d24c/7b41f7bcc2b6690e1b4d80eaf8c3e1cc5ee5.pdf>.		d24c/7b41f7bcc2b6690e1b4d80eaf8c3e1cc5ee5.pdf>.
	[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>.
			[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
			Multicast: Issues and Architectures", RFC 2627,
			DOI 10.17487/RFC2627, June 1999,
			<https://www.rfc-editor.org/info/rfc2627>.
	[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and		[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
	Identifiers for the Internet X.509 Public Key		Identifiers for the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April		(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
	2002, <https://www.rfc-editor.org/info/rfc3279>.		2002, <https://www.rfc-editor.org/info/rfc3279>.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
	2003, <https://www.rfc-editor.org/info/rfc3447>.
	[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)		[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
	Counter Mode With IPsec Encapsulating Security Payload		Counter Mode With IPsec Encapsulating Security Payload
	(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,		(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
	<https://www.rfc-editor.org/info/rfc3686>.		<https://www.rfc-editor.org/info/rfc3686>.
			[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
			Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
			<https://www.rfc-editor.org/info/rfc3740>.
			[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
			"Multicast Security (MSEC) Group Key Management
			Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
			<https://www.rfc-editor.org/info/rfc4046>.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)",		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	RFC 4106, DOI 10.17487/RFC4106, June 2005,		RFC 4106, DOI 10.17487/RFC4106, June 2005,
	<https://www.rfc-editor.org/info/rfc4106>.		<https://www.rfc-editor.org/info/rfc4106>.
	[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM		[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
	Mode with IPsec Encapsulating Security Payload (ESP)",		Mode with IPsec Encapsulating Security Payload (ESP)",
	RFC 4309, DOI 10.17487/RFC4309, December 2005,		RFC 4309, DOI 10.17487/RFC4309, December 2005,
	<https://www.rfc-editor.org/info/rfc4309>.		<https://www.rfc-editor.org/info/rfc4309>.
	skipping to change at page 55, line 34 ¶		skipping to change at page 56, line 44 ¶
	[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>.
	[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
	the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
	DOI 10.17487/RFC7427, January 2015,
	<https://www.rfc-editor.org/info/rfc7427>.
	[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the		[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
	Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,		Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
	DOI 10.17487/RFC7634, August 2015,		DOI 10.17487/RFC7634, August 2015,
	<https://www.rfc-editor.org/info/rfc7634>.		<https://www.rfc-editor.org/info/rfc7634>.
			[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
			"PKCS #1: RSA Cryptography Specifications Version 2.2",
			RFC 8017, DOI 10.17487/RFC8017, November 2016,
			<https://www.rfc-editor.org/info/rfc8017>.
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.		August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,		[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
	"Mixing Preshared Keys in the Internet Key Exchange		"Mixing Preshared Keys in the Internet Key Exchange
	Protocol Version 2 (IKEv2) for Post-quantum Security",		Protocol Version 2 (IKEv2) for Post-quantum Security",
	RFC 8784, DOI 10.17487/RFC8784, June 2020,		RFC 8784, DOI 10.17487/RFC8784, June 2020,
	<https://www.rfc-editor.org/info/rfc8784>.		<https://www.rfc-editor.org/info/rfc8784>.
End of changes. 36 change blocks.
	91 lines changed or deleted		132 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/