< draft-ietf-ipsecme-g-ikev2-02.txt		draft-ietf-ipsecme-g-ikev2-03.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: July 15, 2021 January 11, 2021		Expires: January 13, 2022 July 12, 2021
	Group Key Management using IKEv2		Group Key Management using IKEv2
	draft-ietf-ipsecme-g-ikev2-02		draft-ietf-ipsecme-g-ikev2-03
	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 July 15, 2021.		This Internet-Draft will expire on January 13, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	Section 1.4.1.		Section 1.4.1.
	Initiator (Member) Responder (GCKS)		Initiator (Member) Responder (GCKS)
	-------------------- ------------------		-------------------- ------------------
	HDR, SK{IDg, [SAg,] [N]} -->		HDR, SK{IDg, [SAg,] [N]} -->
	<-- HDR, SK{N}		<-- HDR, SK{N}
	Figure 7: GSA_REGISTRATION Error Exchange		Figure 7: GSA_REGISTRATION Error Exchange
	This exchange can also be used if the group member finds the policy		This exchange can also be used if the group member finds the policy
	sent by the GCKS is unacceptable or for some reason wants to		sent by the GCKS is unacceptable or for some reason wants to leave
	unregister itself from the group. The group member SHOULD notify the		the group. The group member SHOULD notify the GCKS by sending IDg
	GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN or		and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED, as
	REGISTRATION_FAILED, as shown below. The GCKS MUST unregister the		shown below. The GCKS in this case MUST remove the GM from the group
	group member.		IDg.
	Initiator (Member) Responder (GCKS)		Initiator (Member) Responder (GCKS)
	-------------------- ------------------		-------------------- ------------------
	HDR, SK{IDg, N} -->		HDR, SK{IDg, N} -->
	<-- HDR, SK{}		<-- HDR, SK{}
	Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange		Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange
	1.4.3. GM Registration Operations		1.4.3. GM Registration Operations
	A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS		A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS
	using the IKE_SA_INIT exchange and receives the response from the		using the IKE_SA_INIT exchange and receives the response from the
	GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2		GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2
	protocol.		protocol.
	Upon completion of parsing and verifying the IKE_SA_INIT response,		Upon completion of parsing and verifying the IKE_SA_INIT response,
	the GM sends the GSA_AUTH message with the IKEv2 payloads from		the GM sends the GSA_AUTH message with the IKEv2 payloads from
	IKE_AUTH (without the SAi2, TSi and TSr payloads) along with the		IKE_AUTH (without the SAi2, TSi and TSr payloads) along with the
	Group ID informing the GCKS of the group the initiator wishes to		Group ID informing the GCKS of the group the initiator wishes to
	join. An initiator intending to emit data traffic SHOULD send a		join. An initiator intending to emit data traffic SHOULD send a
	SENDER Notify payload status. The SENDER not only signifies that it		SENDER Notify payload status. The SENDER notification not only
	is a sender, but provides the initiator the ability to request		signifies that it is a sender, but provides the initiator the ability
	Sender-ID values, in case the data security SA supports a counter		to request Sender-ID values, in case the data security SA supports a
	mode cipher. Section 1.4.6) includes guidance on requesting Sender-		counter mode cipher. Section 1.4.6) includes guidance on requesting
	ID values.		Sender-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 [RFC4302] and/or ESP [RFC4303]) SAs may be included into		security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be included into
	SAg. Each Proposal contains a list of Transforms that the GM is able		SAg. Each Proposal contains a list of Transforms that the GM is able
	to support for that protocol. Valid transform types depend on the		to support for that protocol. Valid transform types depend on the
	protocol and are defined in Figure 15. Other transform types SHOULD		protocol and are defined in Figure 15. Other transform types SHOULD
	NOT be included. The SPI length of each Proposal in an SAg is set to		NOT be included. The SPI length of each Proposal in an SAg is set to
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	the GCKS via the GSA_REKEY messages.		the GCKS via the GSA_REKEY messages.
	GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange		GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange
	using the IKEv2 SA that was setup to protecting the member		using the IKEv2 SA that was setup to protecting the member
	registration exchange. This exchange allows the GCKS to rekey		registration exchange. This exchange allows the GCKS to rekey
	without using an independent GSA_REKEY pseudo-exchange. The		without using an independent GSA_REKEY pseudo-exchange. The
	GSA_INBAND_REKEY exchange provides a reliable policy delivery and		GSA_INBAND_REKEY exchange provides a reliable policy delivery and
	is useful when G-IKEv2 is used with a small group of cooperating		is useful when G-IKEv2 is used with a small group of cooperating
	devices.		devices.
	Depending on the policy the GCKS may combine these two methods. For		Depending on the policy the GCKS MAY combine these two methods. For
	example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in		example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in
	the group acting as senders (as this would provide reliable keys		the group acting as senders (as this would provide reliable keys
	delivery), and the GSA_REKEY for the rest GMs.		delivery), and the GSA_REKEY for the rest GMs.
	1.4.5.1. GSA_REKEY		1.4.5.1. GSA_REKEY
	The GCKS initiates the G-IKEv2 Rekey securely, usually using IP		The GCKS initiates the G-IKEv2 Rekey securely, usually using IP
	multicast. Since this rekey does not require a response and it sends		multicast. Since this rekey does not require a response and it sends
	to multiple GMs, G-IKEv2 rekeying MUST NOT support IKE SA windowing.		to multiple GMs, G-IKEv2 rekeying MUST NOT support IKE SA windowing.
	The GCKS rekey message replaces the rekey GSA KEK or KEK array, and/		The GCKS rekey message replaces the rekey GSA KEK or KEK array, and/
	skipping to change at page 54, line 40 ¶		skipping to change at page 54, line 40 ¶
	<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., Bartlett, G., Fluhrer, S.,		Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
	Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple		Geest, D. V., Garcia-Morchon, O., and V. Smyslov,
	Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-		"Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme-
	multiple-ke-02 (work in progress), January 2021.		ikev2-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-02 (work in progress), August 2020.		ipsecme-ikev2-qr-alt-03 (work in progress), February 2021.
	[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,
End of changes. 8 change blocks.
	18 lines changed or deleted		18 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/