draft-ietf-ace-key-groupcomm-oscore-02.txt		draft-ietf-ace-key-groupcomm-oscore-03.txt
	ACE Working Group M. Tiloca		ACE Working Group M. Tiloca
	Internet-Draft RISE AB		Internet-Draft RISE AB
	Intended status: Standards Track J. Park		Intended status: Standards Track J. Park
	Expires: January 6, 2020 Universitaet Duisburg-Essen		Expires: May 7, 2020 Universitaet Duisburg-Essen
	F. Palombini		F. Palombini
	Ericsson AB		Ericsson AB
	July 05, 2019		November 04, 2019
	Key Management for OSCORE Groups in ACE		Key Management for OSCORE Groups in ACE
	draft-ietf-ace-key-groupcomm-oscore-02		draft-ietf-ace-key-groupcomm-oscore-03
	Abstract		Abstract
	This document describes a method to request and provision keying		This document describes a method to request and provision keying
	material in group communication scenarios where the group		material in group communication scenarios where the group
	communication is based on CoAP and secured with Object Security for		communication is based on CoAP and secured with Object Security for
	Constrained RESTful Environments (OSCORE). The proposed method		Constrained RESTful Environments (OSCORE). The proposed method
	delegates the authentication and authorization of new client nodes		delegates the authentication and authorization of new client nodes
	that join an OSCORE group through a Group Manager server. This		that join an OSCORE group through a Group Manager server. This
	approach builds on the ACE framework for Authentication and		approach builds on the ACE framework for Authentication and
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 6, 2020.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Overview of the Joining Process . . . . . . . . . . . . . 7
	2.1. Overview of the Join Process . . . . . . . . . . . . . . 7
	2.2. Overview of the Group Rekeying Process . . . . . . . . . 8		2.2. Overview of the Group Rekeying Process . . . . . . . . . 8
	3. Joining Node to Authorization Server . . . . . . . . . . . . 9		3. Joining Node to Authorization Server . . . . . . . . . . . . 8
	3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9		3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9
	3.2. Authorization Response . . . . . . . . . . . . . . . . . 10		3.2. Authorization Response . . . . . . . . . . . . . . . . . 9
	4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 11		4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10
	4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Joining Request . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 13		4.3. Joining Response . . . . . . . . . . . . . . . . . . . . 13
	5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 17		5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 17
	6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 18		6. Retrieval of Updated Keying Material . . . . . . . . . . . . 19
	7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 20		7. Retrieval of New Keying Material . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 21		8. Retrieval of Public Keys of Group Members . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20
	9.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 22		10. Retrieval of Keying Material Version . . . . . . . . . . . . 21
	9.2. OSCORE Security Context Parameters Registry . . . . . . . 23		11. Request to Leave the Group . . . . . . . . . . . . . . . . . 21
	9.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 24		12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21
	9.4. Sequence Number Synchronization Method Registry . . . . . 24		13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22
	9.5. ACE Public Key Encoding Registry . . . . . . . . . . . . 25		14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . 25		15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . 26		15.2. OSCORE Security Context Parameters Registry . . . . . . 24
	Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 27		15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26
	Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 28		15.4. Sequence Number Synchronization Method Registry . . . . 26
	B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 28		15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 27
	B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 29		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29		16.1. Normative References . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		16.2. Informative References . . . . . . . . . . . . . . . . . 28
			Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 29
			Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 31
			B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 31
			B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32
			B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 32
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	Object Security for Constrained RESTful Environments (OSCORE)		Object Security for Constrained RESTful Environments (OSCORE)
	[I-D.ietf-core-object-security] is a method for application-layer		[RFC8613] is a method for application-layer protection of the
	protection of the Constrained Application Protocol (CoAP) [RFC7252],		Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object
	using CBOR Object Signing and Encryption (COSE) [RFC8152] and		Signing and Encryption (COSE) [RFC8152] and enabling end-to-end
	enabling end-to-end security of CoAP payload and options.		security of CoAP payload and options.
	As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used		As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is
	to protect CoAP group communication over IP multicast		used to protect CoAP group communication over IP multicast
	[RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group		[RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group
	Manager, which is responsible for managing an OSCORE group, where		Manager, which is responsible for managing an OSCORE group, where
	members exchange CoAP messages secured with OSCORE. The Group		members exchange CoAP messages secured with Group OSCORE. The Group
	Manager can be responsible for multiple groups, coordinates the join		Manager can be responsible for multiple groups, coordinates the
	process of new group members, and is entrusted with the distribution		joining process of new group members, and is entrusted with the
	and renewal of group keying material.		distribution and renewal of group keying material.
	This specification builds on the ACE framework for Authentication and		This specification builds on the ACE framework for Authentication and
	Authorization [I-D.ietf-ace-oauth-authz] and defines a method to:		Authorization [I-D.ietf-ace-oauth-authz] and defines a method to:
	o Authorize a node to join an OSCORE group, and provide it with the		o Authorize a node to join an OSCORE group, and provide it with the
	group keying material to communicate with other group members.		group keying material to communicate with other group members.
	o Provide updated keying material to group members upon request.		o Provide updated keying material to group members upon request.
	o Renew the group keying material and distribute it to the OSCORE		o Renew the group keying material and distribute it to the OSCORE
	group (rekeying) upon changes in the group membership.		group (rekeying) upon changes in the group membership.
	A client node joins an OSCORE group through a resource server acting		A client node joins an OSCORE group through a resource server acting
	as Group Manager for that group. The join process relies on an		as Group Manager for that group. The joining process relies on an
	Access Token, which is bound to a proof-of-possession key and		Access Token, which is bound to a proof-of-possession key and
	authorizes the client to access a specific join resource at the Group		authorizes the client to access a specific group-membership resource
	Manager.		at the Group Manager.
	Messages exchanged among the participants follow the formats defined		Message exchanges among the participants as well as message formats
	in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying		and processing follow what specified in [I-D.ietf-ace-key-groupcomm]
	material in group communication scenarios.		for provisioning and renewing keying material in group communication
			scenarios.
	In order to achieve communication security, proof-of-possession and		In order to achieve communication security, proof-of-possession and
	server authentication, the client and the Group Manager leverage		server authentication, the client and the Group Manager leverage
	protocol-specific transport profiles of ACE. These include also		protocol-specific transport profiles of ACE. These include also
	possible forthcoming transport profiles that comply with the		possible forthcoming transport profiles that comply with the
	requirements in Appendix C of [I-D.ietf-ace-oauth-authz].		requirements in Appendix C of [I-D.ietf-ace-oauth-authz].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	Readers are expected to be familiar with the terms and concepts		Readers are expected to be familiar with the terms and concepts
	related to the CoAP protocol described in		related to the CoAP protocol described in
	[RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless		[RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless
	otherwise indicated, the term "endpoint" is used here following its		otherwise indicated, the term "endpoint" is used here following its
	OAuth definition, aimed at denoting resources such as /token and		OAuth definition, aimed at denoting resources such as /token and
	/introspect at the AS and /authz-info at the RS. This document does		/introspect at the AS and /authz-info at the RS. This document does
	not use the CoAP definition of "endpoint", which is "An entity		not use the CoAP definition of "endpoint", which is "An entity
	participating in the CoAP protocol".		participating in the CoAP protocol".
	Readers are expected to be familiar with the terms and concepts for		Readers are expected to be familiar with the terms and concepts for
	protection and processing of CoAP messages through OSCORE		protection and processing of CoAP messages through OSCORE [RFC8613]
	[I-D.ietf-core-object-security] also in group communication scenarios		and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] in group
	[I-D.ietf-core-oscore-groupcomm]. These include the concept of Group		communication scenarios. These include the concept of Group Manager,
	Manager, as the entity responsible for a set of groups where		as the entity responsible for a set of groups where communications
	communications are secured with OSCORE. In this specification, the		are secured with Group OSCORE. In this specification, the Group
	Group Manager acts as Resource Server.		Manager acts as Resource Server.
	This document refers also to the following terminology.		This document refers also to the following terminology.
	o Joining node: a network node intending to join an OSCORE group,		o Joining node: a network node intending to join an OSCORE group,
	where communication is based on CoAP		where communication is based on CoAP
	[RFC7390][I-D.dijk-core-groupcomm-bis] and secured with OSCORE as		[RFC7390][I-D.dijk-core-groupcomm-bis] and secured with Group
	described in [I-D.ietf-core-oscore-groupcomm].		OSCORE as described in [I-D.ietf-core-oscore-groupcomm].
	o Join process: the process through which a joining node becomes a		o Joining process: the process through which a joining node becomes
	member of an OSCORE group. The join process is enforced and		a member of an OSCORE group. The joining process is enforced and
	assisted by the Group Manager responsible for that group.		assisted by the Group Manager responsible for that group.
	o Join resource: a resource hosted by the Group Manager, associated		o Group name: stable and invariant identifier of an OSCORE group.
	to an OSCORE group under that Group Manager. A join resource is		The group name MUST be unique under the same Group Manager, and
	identifiable with the Group Identifier (Gid) of the respective		MUST include only characters that are valid for a url-path
	group. A joining node accesses a join resource to start the join		segment, namely unreserved and pct-encoded characters [RFC3986].
	process and become a member of that group. The URI of a join
	resource is fixed.
	o Join endpoint: an endpoint at the Group Manager associated to a		o Group-membership resource: a resource hosted by the Group Manager,
	join resource.		associated to an OSCORE group under that Group Manager. A group-
			membership resource is identifiable with the name of the
			respective OSCORE group. A joining node accesses a group-
			membership resource to start the joining process and become a
			member of that group. The url-path of a group-membership resource
			is fixed, and ends with the segments /group-oscore/NAME , where
			"NAME" is the name of the associated OSCORE group. This replaces
			the url-path /ace-group/gid at the KDC used in
			[I-D.ietf-ace-key-groupcomm], with "gid" indicating the group
			identifier. The url-path /group-oscore/NAME is a default name:
			implementations are not required to use this name, and can define
			their own instead.
			o Group-membership endpoint: an endpoint at the Group Manager
			associated to a group-membership resource.
	o Requester: member of an OSCORE group that sends request messages		o Requester: member of an OSCORE group that sends request messages
	to other members of the group.		to other members of the group.
	o Responder: member of an OSCORE group that receives request		o Responder: member of an OSCORE group that receives request
	messages from other members of the group. A responder may reply		messages from other members of the group. A responder may reply
	back, by sending a response message to the requester which has		back, by sending a response message to the requester which has
	sent the request message.		sent the request message.
	o Monitor: member of a group that is configured as responder and		o Monitor: member of an OSCORE group that is configured as responder
	never replies back to requesters after receiving request messages.		and never replies back to requesters after receiving request
	This corresponds to the term "silent server" used in		messages. This corresponds to the term "silent server" used in
	[I-D.ietf-core-oscore-groupcomm].		[I-D.ietf-core-oscore-groupcomm].
	o Group rekeying process: the process through which the Group		o Group rekeying process: the process through which the Group
	Manager renews the security parameters and group keying material,		Manager renews the security parameters and group keying material,
	and (re-)distributes them to the OSCORE group members.		and (re-)distributes them to the OSCORE group members.
	1.2. Relation to Other Documents
	Figure 1 overviews the main documents related to this specification.
	Arrows and asterisk-arrows denote normative references and
	informative refences, respectively.
	+---------------------------------------+
	| |
	+----------------|--------------+ |
	| | | |
	| v v Key Management
	Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups
	profile * [[WG]] [[WG]] [[This document]]
	| * * ^ ^ | |
	| * * * * | |
	| * * * *************** | |
	| *********** * * * | |
	| * * * * +--------------+ |
	ACE | * * * * | |
	-----|-*--------------*--------------*-*-|--------------------|-------
	CoRE | * * * * | |
	v v v * * v v
	CoRE CoRE OSCORE -------------> OSCORE
	Pubsub Groupcomm <*** Groupcomm <************* [[WG]]
	[[WG]] [[RFC7390]] [[WG]]
	Figure 1: Related Documents
	2. Protocol Overview		2. Protocol Overview
	Group communication for CoAP over IP multicast has been enabled in		Group communication for CoAP over IP multicast has been enabled in
	[RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Object		[RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Group
	Security for Constrained RESTful Environments (OSCORE)		Object Security for Constrained RESTful Environments (OSCORE)
	[I-D.ietf-core-object-security] as described in		[RFC8613] as described in [I-D.ietf-core-oscore-groupcomm]. A
	[I-D.ietf-core-oscore-groupcomm]. A network node joins an OSCORE		network node joins an OSCORE group by interacting with the
	group by interacting with the responsible Group Manager. Once		responsible Group Manager. Once registered in the group, the new
	registered in the group, the new node can securely exchange messages		node can securely exchange messages with other group members.
	with other group members.
	This specification describes how to use the ACE framework for		This specification describes how to use the ACE framework for
	authentication and authorization [I-D.ietf-ace-oauth-authz] to:		authentication and authorization [I-D.ietf-ace-oauth-authz] to:
	o Enable a node to join an OSCORE group through the Group Manager		o Enable a node to join an OSCORE group through the Group Manager
	and receive the security parameters and keying material to		and receive the security parameters and keying material to
	communicate with the other members of the gorup.		communicate with the other members of the group.
	o Enable members of OSCORE groups to retrieve updated group keying		o Enable members of OSCORE groups to retrieve updated group keying
	material from the Group Manager.		material and public key of other group members, from the Group
			Manager.
	o Enable the Group Manager to renew the security parameters and		o Enable the Group Manager to renew the security parameters and
	group keying material, and to (re-)distribute them to the members		group keying material, and to (re-)distribute them to the members
	of the OSCORE group (rekeying).		of the OSCORE group (rekeying).
	With reference to the ACE framework and the terminology defined in		With reference to the ACE framework and the terminology defined in
	OAuth 2.0 [RFC6749]:		OAuth 2.0 [RFC6749]:
	o The Group Manager acts as Resource Server (RS), and hosts one join		o The Group Manager acts as Resource Server (RS), and hosts one
	resource for each OSCORE group it manages. Each join resource is		group-membership resource for each OSCORE group it manages. Each
	exported by a distinct join endpoint. During the join process,		group-membership resource is exported by a distinct group-
	the Group Manager provides joining nodes with the parameters and		membership endpoint. During the joining process, the Group
	keying material for taking part to secure communications in the		Manager provides joining nodes with the parameters and keying
	OSCORE group. The Group Manager also maintains the group keying		material for taking part to secure communications in the OSCORE
	material and performs the group rekeying process to distribute		group. The Group Manager also maintains the group keying material
	updated keying material to the group members.		and performs the group rekeying process to distribute updated
			keying material to the group members.
	o The joining node acts as Client (C), and requests to join an		o The joining node acts as Client (C), and requests to join an
	OSCORE group by accessing the related join endpoint at the Group		OSCORE group by accessing the related group-membership endpoint at
	Manager.		the Group Manager.
	o The Authorization Server (AS) authorizes joining nodes to join		o The Authorization Server (AS) authorizes joining nodes to join
	OSCORE groups under their respective Group Manager. Multiple		OSCORE groups under their respective Group Manager. Multiple
	Group Managers can be associated to the same AS. The AS MAY		Group Managers can be associated to the same AS. The AS MAY
	release Access Tokens for other purposes than joining OSCORE		release Access Tokens for other purposes than joining OSCORE
	groups under registered Group Managers. For example, the AS may		groups under registered Group Managers. For example, the AS may
	also release Access Tokens for accessing resources hosted by		also release Access Tokens for accessing resources hosted by
	members of OSCORE groups.		members of OSCORE groups.
	All communications between the involved entities rely on the CoAP		All communications between the involved entities rely on the CoAP
	protocol and MUST be secured.		protocol and MUST be secured.
	In particular, communications between the joining node and the Group		In particular, communications between the joining node and the Group
	Manager leverage protocol-specific transport profiles of ACE to		Manager leverage protocol-specific transport profiles of ACE to
	achieve communication security, proof-of-possession and server		achieve communication security, proof-of-possession and server
	authentication. To this end, the AS must signal the specific		authentication. To this end, the AS MAY signal the specific
	transport profile to use, consistently with requirements and		transport profile to use, consistently with requirements and
	assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].		assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].
			Note that in the commonly referred base-case the transport profile to
			use is pre-configured and well-known to nodes participating in
			constrained applications.
	With reference to the AS, communications between the joining node and		With reference to the AS, communications between the joining node and
	the AS (/token endpoint) as well as between the Group Manager and the		the AS (/token endpoint) as well as between the Group Manager and the
	AS (/introspect endpoint) can be secured by different means, for		AS (/introspect endpoint) can be secured by different means, for
	instance using DTLS [RFC6347] or OSCORE		instance using DTLS [RFC6347] or OSCORE [RFC8613]. Further details
	[I-D.ietf-core-object-security]. Further details on how the AS		on how the AS secures communications (with the joining node and the
	secures communications (with the joining node and the Group Manager)		Group Manager) depend on the specifically used transport profile of
	depend on the specifically used transport profile of ACE, and are out		ACE, and are out of the scope of this specification.
	of the scope of this specification.
	2.1. Overview of the Join Process		2.1. Overview of the Joining Process
	A node performs the following steps in order to join an OSCORE group.		A node performs the following steps in order to join an OSCORE group.
	Messages exchanged among the participants follow the formats defined		The format and processing of messages exchanged among the
	in [I-D.ietf-ace-key-groupcomm], and are further specified in		participants follow what is defined in [I-D.ietf-ace-key-groupcomm],
	Section 3 and Section 4 of this document. The Group Manager acts as		and are further specified in Section 3 and Section 4 of this
	the Key Distribution Center (KDC) defined in		document. The Group Manager acts as the Key Distribution Center
	[I-D.ietf-ace-key-groupcomm].		(KDC) defined in [I-D.ietf-ace-key-groupcomm].
	1. The joining node requests an Access Token from the AS, in order		1. The joining node requests an Access Token from the AS, in order
	to access a join resource on the Group Manager and hence join the		to access a group-membership resource on the Group Manager and
	associated OSCORE group (see Section 3). The joining node will		hence join the associated OSCORE group (see Section 3). The
	start or continue using a secure communication channel with the		joining node will start or continue using a secure communication
	Group Manager, according to the response from the AS.		association with the Group Manager, according to the response
			from the AS.
	2. The joining node transfers authentication and authorization		2. The joining node transfers authentication and authorization
	information to the Group Manager by posting the obtained Access		information to the Group Manager, by posting the obtained Access
	Token (see Section 4). After that, a joining node must have a		Token to the /authz-info endpoint at the Group Manager (see
	secure communication channel established with the Group Manager,		Section 4). After that, a joining node MUST have a secure
			communication association established with the Group Manager,
	before starting to join an OSCORE group under that Group Manager		before starting to join an OSCORE group under that Group Manager
	(see Section 4). Possible ways to provide a secure communication		(see Section 4). Possible ways to provide a secure communication
	channel are DTLS [RFC6347] and OSCORE		association are DTLS [RFC6347] and OSCORE [RFC8613].
	[I-D.ietf-core-object-security].
	3. The joining node starts the join process to become a member of		3. The joining node starts the joining process to become a member of
	the OSCORE group, by accessing the related join resource hosted		the OSCORE group, by accessing the related group-membership
	by the Group Manager (see Section 4).		resource hosted by the Group Manager (see Section 4).
	4. At the end of the join process, the joining node has received		4. At the end of the joining process, the joining node has received
	from the Group Manager the parameters and keying material to		from the Group Manager the parameters and keying material to
	securely communicate with the other members of the OSCORE group.		securely communicate with the other members of the OSCORE group.
	5. The joining node and the Group Manager maintain the secure		5. The joining node and the Group Manager maintain the secure
	channel, to support possible future communications.		association, to support possible future communications. These
			especially include key management operations, such as retrieval
			of updated keying material from the Group Manager or
			participation to a group rekeying process (see Section 2.2).
	All further communications between the joining node and the Group		All further communications between the joining node and the Group
	Manager MUST be secured, for instance with the same secure channel		Manager MUST be secured, for instance with the same secure
	mentioned in step 2.		association mentioned in step 2.
	2.2. Overview of the Group Rekeying Process		2.2. Overview of the Group Rekeying Process
	If the application requires backward and forward security, the Group		If the application requires backward and forward security, the Group
	Manager MUST generate new security parameters and group keying		Manager MUST generate new security parameters and group keying
	material, and distribute them to the group (rekeying) upon membership		material, and distribute them to the group (rekeying) upon membership
	changes.		changes.
	That is, the group is rekeyed when a node joins the group as a new		That is, the group is rekeyed when a node joins the group as a new
	member, or after a current member leaves the group. By doing so, a		member, or after a current member leaves the group. By doing so, a
	joining node cannot access communications in the group prior its		joining node cannot access communications in the group prior its
	joining, while a leaving node cannot access communications in the		joining, while a leaving node cannot access communications in the
	group after its leaving.		group after its leaving.
	Parameters and keying material include a new Group Identifier (Gid)		Parameters and group keying material include a new Group Identifier
	for the group and a new Master Secret for the OSCORE Common Security		(Gid) for the group and a new Master Secret for the OSCORE Common
	Context of that group (see Section 2 of		Security Context of that group (see Section 2 of
	[I-D.ietf-core-oscore-groupcomm]).		[I-D.ietf-core-oscore-groupcomm]). Once completed a group rekeying,
			the GM MUST increment the version number of the group keying
			material.
	The Group Manager MUST support the Group Rekeying Process described		The Group Manager MUST support the Group Rekeying Process described
	in Section 7. Future application profiles may define alternative		in Section 13. Future application profiles may define alternative
	message formats and distribution schemes to perform group rekeying.		message formats and distribution schemes to perform group rekeying.
	3. Joining Node to Authorization Server		3. Joining Node to Authorization Server
	This section describes how the joining node interacts with the AS in		This section describes how the joining node interacts with the AS in
	order to be authorized to join an OSCORE group under a given Group		order to be authorized to join an OSCORE group under a given Group
	Manager. In particular, it considers a joining node that intends to		Manager. In particular, it considers a joining node that intends to
	contact that Group Manager for the first time.		contact that Group Manager for the first time.
	The message exchange between the joining node and the AS consists of		The message exchange between the joining node and the AS consists of
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 8 ¶
	in Section 3 of [I-D.ietf-ace-key-groupcomm].		in Section 3 of [I-D.ietf-ace-key-groupcomm].
	In case the specific AS associated to the Group Manager is unknown to		In case the specific AS associated to the Group Manager is unknown to
	the joining node, the latter can rely on mechanisms like the		the joining node, the latter can rely on mechanisms like the
	Unauthorized Resource Request message described in Section 5.1.1 of		Unauthorized Resource Request message described in Section 5.1.1 of
	[I-D.ietf-ace-oauth-authz] to discover the correct AS to contact.		[I-D.ietf-ace-oauth-authz] to discover the correct AS to contact.
	3.1. Authorization Request		3.1. Authorization Request
	The joining node contacts the AS, in order to request an Access Token		The joining node contacts the AS, in order to request an Access Token
	for accessing the join resource hosted by the Group Manager and		for accessing the group-membership resource hosted by the Group
	associated to the OSCORE group. The Access Token request sent to the		Manager and associated to the OSCORE group. The Access Token request
	/token endpoint follows the format of the Authorization Request		sent to the /token endpoint follows the format of the Authorization
	message defined in Section 3.1 of [I-D.ietf-ace-key-groupcomm]. In		Request message defined in Section 3.1 of
	particular:		[I-D.ietf-ace-key-groupcomm]. In particular:
	o The 'scope' parameter MUST be present and MUST include:		o The 'scope' parameter MUST be present and MUST include:
	* in the first element, either the Group Identifier (Gid) of the		* in the first element, the name of the OSCORE group to join
	group to join under the Group Manager, or a value from which		under the Group Manager, encoded as a CBOR text string.
	the Group Manager can derive the Gid of the group to join. It
	is up to the application to define how the Group Manager
	possibly performs the derivation of the full Gid. Appendix C of
	[I-D.ietf-core-oscore-groupcomm] provides an example of
	structured Gid, composed of a fixed part, namely Group Prefix,
	and a variable part, namely Group Epoch.
	* in the second element, the role (encoded as a text string) or		* in the second element, the role (encoded as a text string) or
	CBOR array of roles that the joining node intends to have in		CBOR array of roles that the joining node intends to have in
	the group it intends to join. Accepted values of roles are:		the group it intends to join. Accepted values of roles are:
	"requester", "responder", and "monitor". Possible combinations		"requester", "responder", and "monitor". Possible combinations
	are: ["requester" , "responder"]; ["requester" , "monitor"].		are: ["requester" , "responder"]; ["requester" , "monitor"].
	o The 'audience' parameter MUST be present and is set to the		o The 'audience' parameter MUST be present and is set to the
	identifier of the Group Manager.		identifier of the Group Manager.
	3.2. Authorization Response		3.2. Authorization Response
	The AS is responsible for authorizing the joining node to join		The AS is responsible for authorizing the joining node to join
	specific OSCORE groups, according to join policies enforced on behalf		specific OSCORE groups, according to join policies enforced on behalf
	skipping to change at page 10, line 25 ¶		skipping to change at page 9, line 42 ¶
	of the respective Group Manager.		of the respective Group Manager.
	In case of successful authorization, the AS releases an Access Token		In case of successful authorization, the AS releases an Access Token
	bound to a proof-of-possession key associated to the joining node.		bound to a proof-of-possession key associated to the joining node.
	Then, the AS provides the joining node with the Access Token as part		Then, the AS provides the joining node with the Access Token as part
	of an Access Token response, which follows the format of the		of an Access Token response, which follows the format of the
	Authorization Response message defined in Section 3.2 of		Authorization Response message defined in Section 3.2 of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	The 'exp' parameter MUST be present. Other means for the AS to		The AS MUST include the 'exp' parameter in the response to the
	specify the lifetime of Access Tokens are out of the scope of this		joining node. Other means for the AS to specify the lifetime of
	specification.		Access Tokens are out of the scope of this specification.
	The AS must include the 'scope' parameter in the response when the		The AS must include the 'scope' parameter in the response to the
	value included in the Access Token differs from the one specified by		joining node, when the value included in the Access Token differs
	the joining node in the request. In such a case, the second element		from the one specified by the joining node in the request. In such a
	of 'scope' MUST be present and includes the role or CBOR array of		case, the second element of 'scope' MUST be present and includes the
	roles that the joining node is actually authorized to take in the		role or CBOR array of roles that the joining node is actually
	group, encoded as specified in Section 3.1 of this document.		authorized to take in the group, encoded as specified in Section 3.1
			of this document.
	Also, the 'profile' parameter indicates the specific transport		The AS MAY also include the 'profile' parameter in the response to
	profile of ACE to use for securing communications between the joining		the joining node, in order to indicate the specific transport profile
	node and the Group Manager (see Section 5.6.4.3 of		of ACE to use for securing communications between the joining node
			and the Group Manager (see Section 5.6.4.3 of
	[I-D.ietf-ace-oauth-authz]).		[I-D.ietf-ace-oauth-authz]).
	In particular, if symmetric keys are used, the AS generates a proof-		In particular, if symmetric keys are used, the AS generates a proof-
	of-possession key, binds it to the Access Token, and provides it to		of-possession key, binds it to the Access Token, and provides it to
	the joining node in the 'cnf' parameter of the Access Token response.		the joining node in the 'cnf' parameter of the Access Token response.
	Instead, if asymmetric keys are used, the joining node provides its		Instead, if asymmetric keys are used, the joining node provides its
	own public key to the AS in the 'req_cnf' parameter of the Access		own public key to the AS in the 'req_cnf' parameter of the Access
	Token request. Then, the AS uses it as proof-of-possession key bound		Token request. Then, the AS uses it as proof-of-possession key bound
	to the Access Token, and provides the joining node with the Group		to the Access Token, and provides the joining node with the Group
	Manager's public key in the 'rs_cnf' parameter of the Access Token		Manager's public key in the 'rs_cnf' parameter of the Access Token
	response.		response.
	4. Joining Node to Group Manager		4. Joining Node to Group Manager
	The following subsections describe the interactions between the		The following subsections describe the interactions between the
	joining node and the Group Manager, i.e. the Access Token post and		joining node and the Group Manager, i.e. the sending of the Access
	the Request-Response exchange to join the OSCORE group.		Token and the Request-Response exchange to join the OSCORE group.
	4.1. Token Post		4.1. Token Post
	The joining node posts the Access Token to the /authz-info endpoint		The joining node posts the Access Token to the /authz-info endpoint
	at the Group Manager, according to the Token post defined in		at the Group Manager, according to the Token post defined in
	Section 3.3 of [I-D.ietf-ace-key-groupcomm].		Section 3.3 of [I-D.ietf-ace-key-groupcomm].
	At this point in time, the joining node might not have all the		At this point in time, the joining node might not have all the
	necessary information concerning the public keys in the OSCORE group,		necessary information concerning the public keys in the OSCORE group,
	as well as concerning the algorithm and related parameters for		as well as concerning the algorithm and related parameters for
	skipping to change at page 11, line 36 ¶		skipping to change at page 10, line 52 ¶
	other means, e.g. by using the approach described in		other means, e.g. by using the approach described in
	[I-D.tiloca-core-oscore-discovery].		[I-D.tiloca-core-oscore-discovery].
	If the Access Token is valid, the Group Manager responds to the POST		If the Access Token is valid, the Group Manager responds to the POST
	request with a 2.01 (Created) response, according to what is		request with a 2.01 (Created) response, according to what is
	specified in the signalled transport profile of ACE. The Group		specified in the signalled transport profile of ACE. The Group
	Manager MUST use the Content-Format "application/ace+cbor" defined in		Manager MUST use the Content-Format "application/ace+cbor" defined in
	Section 8.14 of [I-D.ietf-ace-oauth-authz].		Section 8.14 of [I-D.ietf-ace-oauth-authz].
	The payload of the 2.01 (Created) response is a CBOR map, which MUST		The payload of the 2.01 (Created) response is a CBOR map, which MUST
	include the 'cnonce' parameter defined in section 5.1.2 of		include the 'rsnonce' parameter defined in Section 3.3.3 of
	[I-D.ietf-ace-oauth-authz], and MAY include the 'sign_info' parameter
	as well as the 'pub_key_enc' parameter.
	The 'cnonce' parameter includes a nonce N generated by the Group		[I-D.ietf-ace-key-groupcomm], and MAY include the 'sign_info'
	Manager. The joining node may use this nonce in order to prove the		parameter as well as the 'pub_key_enc' parameter, defined in its
	possession of its own private key, upon joining the group (see		Sections 3.3.1 and 3.3.2, respectively. Note that this deviates from
	Section 4.2).		the default payload format for this response message as defined in
			the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]).
			The 'rsnonce' parameter includes a dedicated nonce N_S generated by
			the Group Manager. The joining node may use this nonce in order to
			prove the possession of its own private key, upon joining the group
			(see Section 4.2).
	If present in the response:		If present in the response:
	o 'sign_alg', i.e. the first element of the 'sign_info' parameter,		o 'sign_alg', i.e. the first element of the 'sign_info' parameter,
	takes value from Tables 5 and 6 of [RFC8152].		takes value from Tables 5 and 6 of [RFC8152].
	o 'sign_parameters', i.e. the second element of the 'sign_info'		o 'sign_parameters', i.e. the second element of the 'sign_info'
	parameter, takes values from the "Counter Signature Parameters"		parameter, takes values from the "Counter Signature Parameters"
	Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).		Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).
	Its structure depends on the value of 'sign_alg'. If no		Its structure depends on the value of 'sign_alg'. If no
	parameters of the counter signature algorithm are specified,		parameters of the counter signature algorithm are specified,
	'sign_parameters' MUST be encoding the CBOR simple value Null.		'sign_parameters' MUST be encoding the CBOR simple value Null.
	o 'sign_key_parameters', i.e. the third element of the 'sign_info'		o 'sign_key_parameters', i.e. the third element of the 'sign_info'
	parameter, takes values from the "Counter Signature Key		parameter, takes values from the "Counter Signature Key
	Parameters" Registry (see Section 9.2 of		Parameters" Registry (see Section 9.2 of
	[I-D.ietf-core-oscore-groupcomm]). Its structure depends on the		[I-D.ietf-core-oscore-groupcomm]). Its structure depends on the
	value of 'sign_alg'. If no parameters of the key used with the		value of 'sign_alg'. If no parameters of the key used with the
	counter signature algorithm are specified, 'sign_key_parameters'		counter signature algorithm are specified, 'sign_key_parameters'
	skipping to change at page 12, line 17 ¶		skipping to change at page 11, line 36 ¶
	'sign_parameters' MUST be encoding the CBOR simple value Null.		'sign_parameters' MUST be encoding the CBOR simple value Null.
	o 'sign_key_parameters', i.e. the third element of the 'sign_info'		o 'sign_key_parameters', i.e. the third element of the 'sign_info'
	parameter, takes values from the "Counter Signature Key		parameter, takes values from the "Counter Signature Key
	Parameters" Registry (see Section 9.2 of		Parameters" Registry (see Section 9.2 of
	[I-D.ietf-core-oscore-groupcomm]). Its structure depends on the		[I-D.ietf-core-oscore-groupcomm]). Its structure depends on the
	value of 'sign_alg'. If no parameters of the key used with the		value of 'sign_alg'. If no parameters of the key used with the
	counter signature algorithm are specified, 'sign_key_parameters'		counter signature algorithm are specified, 'sign_key_parameters'
	MUST be encoding the CBOR simple value Null.		MUST be encoding the CBOR simple value Null.
	o 'pub_key_enc' takes value from Figure 2, as a public key encoding		o 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation
	in the "ACE Public Key Encoding" Registry (see Section 11.2 of		Key' column of the "CWT Confirmation Method" Registry defined in
	[I-D.ietf-ace-key-groupcomm]).		[I-D.ietf-ace-cwt-proof-of-possession], so indicating that public
			keys in the OSCORE group are encoded as COSE Keys [RFC8152].
	+----------+-------+--------------------------------+-------------+		Future specifications may define additional values for this
	| Name | Value | Description | Reference |		parameter.
	+----------+-------+--------------------------------+-------------+
	| COSE_Key | 1 | Public key encoded as COSE Key | {{RFC8152}} |
	+----------+-------+--------------------------------+-------------+
	Figure 2: ACE Public Key Encoding Values
	Note that the CBOR map specified as payload of the 2.01 (Created)		The CBOR map specified as payload of the 2.01 (Created) response may
	response may include further parameters, e.g. according to the		include further parameters, e.g. according to the signalled transport
	signalled transport profile of ACE.		profile of ACE.
	Finally, the joining node establishes a secure channel with the Group		Finally, the joining node establishes a secure channel with the Group
	Manager, according to what is specified in the Access Token response		Manager, according to what is specified in the Access Token response
	and the signalled transport profile of ACE.		and the signalled transport profile of ACE.
	4.2. Join Request		4.2. Joining Request
	Once a secure communication channel with the Group Manager has been		Once a secure communication channel with the Group Manager has been
	established, the joining node requests to join the OSCORE group, by		established, the joining node requests to join the OSCORE group, by
	accessing the related join resource at the Group Manager.		sending a Joining Request message to the related group-membership
			resource at the Group Manager, as per Section 4.2 of
			[I-D.ietf-ace-key-groupcomm].
	In particular, the joining node sends to the Group Manager a		In particular, the joining node sends a CoAP POST request to the
	confirmable CoAP request, using the method POST and targeting the		endpoint /group-oscore/NAME at the Group Manager, where NAME is the
	join endpoint associated to that group. This Join Request follows		name of the OSCORE group to join. This Joining Request is formatted
	the format and processing of the Key Distribution Request message		as defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm].
	defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In		Specifically:
	particular:
	o The 'type' parameter is set to 1 ("key distribution").		o The 'scope' parameter MUST be present.
	o The 'get_pub_keys' parameter is present only if the joining node		o The 'get_pub_keys' parameter is present only if the joining node
	wants to retrieve the public keys of the group members from the		wants to retrieve the public keys of the group members from the
	Group Manager during the join process (see Section 6). Otherwise,		Group Manager during the joining process (see Section 5).
	this parameter MUST NOT be present.		Otherwise, this parameter MUST NOT be present.
	o The 'client_cred' parameter, if present, includes the public key		o The 'client_cred' parameter, if present, includes the public key
	of the joining node. In case the joining node knows the encoding		of the joining node. In case the joining node knows the encoding
	of public keys in the OSCORE group, as well as the		of public keys in the OSCORE group, as well as the
	countersignature algorithm and possible associated parameters used		countersignature algorithm and possible associated parameters used
	in the OSCORE group, the included public key MUST be in a		in the OSCORE group, the included public key MUST be compatible
	consistent format. This parameter MAY be omitted if: i) the		with those criteria. That is, the public key MUST be encoded
	joining node is asking to access the group exclusively as monitor;		according to the encoding of public keys in the OSCORE group, and
	or ii) the Group Manager already acquired this information, for		MUST be compatible with the countersignature algorithm and
	instance during a past join process. In any other case, this		possible associated parameters used in the OSCORE group. This
	parameter MUST be present.		parameter MAY be omitted if: i) the joining node is asking to
			access the group exclusively as monitor; or ii) the Group Manager
			already acquired this information, for instance during a past
			joining process. In any other case, this parameter MUST be
			present.
	Furthermore, the CBOR map specified as payload of the Join Request		Furthermore, if the 'client_cred' parameter is present, the CBOR map
	MAY also include the following additional parameter, which MUST be		specified as payload of the Joining Request MUST also include the
	present if the 'client_cred' parameter is present.		following parameters.
	o The 'client_cred_verify' parameter, which is encoded as a CBOR		o 'cnonce', as defined in Section 5.1.2 of
	byte string and contains a signature computed by the joining node,		[I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C
	in order to prove possession of its own private key. The		generated by the Client.
	signature is computed over the nonce N received in the 2.01
	(Created) response to the Token POST (see Section 4.1). In
	particular, the joining node MUST use the COSE_CounterSignature0
	object [RFC8152], with the Sig_structure containing the nonce N as
	payload; and an empty external_aad. The joining node computes the
	signature by using the same private key and countersignature
	algorithm it intends to use for signing messages in the OSCORE
	group.
	4.3. Join Response		o The 'client_cred_verify' parameter, including a signature encoded
			as a CBOR byte string, computed by the joining node to prove
			possession of its own private key. The signature is computed over
			N_S concatenated with N_C, where N_S is the nonce received in the
			'rsnonce' parameter of the 2.01 (Created) response to the Token
			POST (see Section 4.1), while N_C is the nonce generated by the
			Client and specified in the 'cnonce' parameter above. The joining
			node computes the signature by using the same private key and
			countersignature algorithm it intends to use for signing messages
			in the OSCORE group.
	The Group Manager processes the Join Request according to		4.3. Joining Response
	[I-D.ietf-ace-oauth-authz] and Section 4.2 of
	[I-D.ietf-ace-key-groupcomm]. Also, the Group Manager MUST return a		The Group Manager processes the Joining Request as defined in
	4.00 (Bad Request) response in case the Join Request includes the		Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Also, the Group
	'client_cred' parameter but does not include the 'client_cred_verify'		Manager MUST return a 4.00 (Bad Request) response in case the Joining
	parameter.		Request includes the 'client_cred' parameter but does not include
			both the 'cnonce' and 'client_cred_verify' parameters.
	If the request processing yields a positive outcome, the Group		If the request processing yields a positive outcome, the Group
	Manager performs the further following checks.		Manager performs the further following checks.
	o In case the Join Request includes the 'client_cred' parameter, the		o In case the Joining Request includes the 'client_cred' parameter,
	Group Manager checks that the public key of the joining node has		the Group Manager checks that the public key of the joining node
	an accepted format. That is, the public key has to be encoded as		has an accepted format. That is, the public key has to be encoded
	expected in the OSCORE group, and has to be consistent with the		as expected in the OSCORE group, and has to be compatible with the
	counter signature algorithm and possible associated parameters		counter signature algorithm and possible associated parameters
	used in the OSCORE group. The join process fails if the public		used in the OSCORE group. The joining process fails if the public
	key of the joining node does not have an accepted format.		key of the joining node does not have an accepted format.
	o In case the Join Request does not include the 'client_cred'		o In case the Joining Request does not include the 'client_cred'
	parameter, the Group Manager checks whether it is storing a public		parameter, the Group Manager checks whether it is storing a public
	key for the joining node, which is consistent with the encoding,		key for the joining node, which is compatible with the encoding,
	counter signature algorithm and possible associated parameters		counter signature algorithm and possible associated parameters
	used in the OSCORE group. The join process fails if the Group		used in the OSCORE group. The joining process fails if the Group
	Manager either: i) does not store a public key with an accepted		Manager either: i) does not store a public key with an accepted
	format for the joining node; or ii) stores multiple public keys		format for the joining node; or ii) stores multiple public keys
	with an accepted format for the joining node.		with an accepted format for the joining node.
	o In case the Join Request includes the 'client_cred_verify'		o In case the Joining Request includes the 'client_cred_verify'
	parameter, the Group Manager verifies the signature contained in		parameter, the Group Manager verifies the signature contained in
	the parameter. To this end, it considers: i) as signed value, the		the parameter. To this end, it considers: i) as signed value, N_S
	nonce N previously provided in the 2.01 (Created) response to the		concatenated with N_C, where N_S is the nonce previously provided
	Token POST (see Section 4.1); ii) the countersignature algorithm		in the 'rsnonce' parameter of the 2.01 (Created) response to the
	used in the OSCORE group; and iii) the public key of the joining		Token POST (see Section 4.1), while N_C is the nonce provided in
	node, either retrieved from the 'client_cred' parameter, or as		the 'cnonce' parameter of the Joining Request; ii) the
	stored from a past join process. The join process fails if the		countersignature algorithm used in the OSCORE group, and possible
	Group Manager does not successfully verify the signature.		correponding parameters; and iii) the public key of the joining
			node, either retrieved from the 'client_cred' parameter, or
			already stored as acquired from previous interactions with the
			joining node. The joining process fails if the Group Manager does
			not successfully verify the signature.
	If the join process has failed, the Group Manager MUST reply to the		If the joining process has failed, the Group Manager MUST reply to
	joining node with a 4.00 (Bad Request) response. The payload of this		the joining node with a 4.00 (Bad Request) response. The payload of
	response is a CBOR map, which includes a 'sign_info' parameter and a		this response is a CBOR map, which includes a 'sign_info' parameter
	'pub_key_enc' parameter, formatted as in the Token POST response in		and a 'pub_key_enc' parameter, formatted as in the Token POST
	Section 4.1.		response in Section 4.1.
	Upon receiving this response, the joining node SHOULD send a new Join		Upon receiving this response, the joining node SHOULD send a new
	Request to the Group Manager, which contains:		Joining Request to the Group Manager, which contains:
	o The 'client_cred' parameter, including a public key in a format		o The 'client_cred' parameter, including a public key compatible
	consistent with the encoding, countersignature algorithm and		with the encoding, countersignature algorithm and possible
	possible associated parameters indicated by the Group Manager.		associated parameters indicated by the Group Manager.
	o The 'client_cred_verify' parameter, including a signature computed		o The 'client_cred_verify' parameter, including a signature computed
	as described in Section 4.2, by using the public key indicated in		as described in Section 4.2, by using the public key indicated in
	the current 'client_cred' parameter, with the countersignature		the current 'client_cred' parameter, with the countersignature
	algorithm and possible associated parameters indicated by the		algorithm and possible associated parameters indicated by the
	Group Manager.		Group Manager.
	Otherwise, in case of success, the Group Manager updates the group		Otherwise, in case of success, the Group Manager updates the group
	membership by registering the joining node as a new member of the		membership by registering the joining node as a new member of the
	OSCORE group.		OSCORE group. If the joining node is not exclusively configured as
			monitor, the Group Manager performs also the following actions.
			o The Group Manager selects an available OSCORE Sender ID in the
			OSCORE group, and exclusively assigns it to the joining node.
			o If the 'client_cred' parameter was present in the request, the
			Group Manager adds the specified public key of the joining node to
			the list of public keys of the current group members.
			o If the 'client_cred' parameter was not present in the request, the
			Group Manager retrieves the already stored public key of the
			joining node, as acquired from previous interactions (see also
			Section 5). Then, the Group Manager adds the retrieved public key
			to the list of public keys of the current group members.
			o The Group Manager stores the association between i) the public key
			of the joining node; and ii) the Group Identifier (Gid) associated
			to the OSCORE group together with the OSCORE Sender ID assigned to
			the joining node in the group. The Group Manager MUST keep this
			association updated over time.
	Then, the Group Manager replies to the joining node providing the		Then, the Group Manager replies to the joining node providing the
	updated security parameters and keying meterial necessary to		updated security parameters and keying meterial necessary to
	participate in the group communication. This Join Response follows		participate in the group communication. This success Joining
	the format and processing of the Key Distribution success Response		Response is formatted as defined in Section 4.1.2.1 of
	message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In		[I-D.ietf-ace-key-groupcomm]. In particular:
	particular:
	o The 'kty' parameter identifies a key of type		o The 'kty' parameter identifies a key of type
	"Group_OSCORE_Security_Context object", defined in Section 9.1 of		"Group_OSCORE_Security_Context object", defined in Section 15.1 of
	this specification.		this specification.
	o The 'key' parameter includes what the joining node needs in order		o The 'key' parameter includes what the joining node needs in order
	to set up the OSCORE Security Context as per Section 2 of		to set up the OSCORE Security Context as per Section 2 of
	[I-D.ietf-core-oscore-groupcomm]. This parameter has as value a		[I-D.ietf-core-oscore-groupcomm]. This parameter has as value a
	Group_OSCORE_Security_Context object, which is defined in this		Group_OSCORE_Security_Context object, which is defined in this
	specification and extends the OSCORE_Security_Context object		specification and extends the OSCORE_Security_Context object
	encoded in CBOR as defined in Section 3.2.1 of		encoded in CBOR as defined in Section 3.2.1 of
	[I-D.ietf-ace-oscore-profile]. In particular, it contains the		[I-D.ietf-ace-oscore-profile]. In particular, it contains the
	additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and		additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and
	'cs_key_enc' defined in Section 9.2 of this specification. More		'cs_key_enc' defined in Section 15.2 of this specification. More
	specifically, the 'key' parameter is composed as follows.		specifically, the 'key' parameter is composed as follows.
	* The 'ms' parameter MUST be present and includes the OSCORE		* The 'ms' parameter MUST be present and includes the OSCORE
	Master Secret value.		Master Secret value.
	* The 'clientId' parameter, if present, has as value the OSCORE		* The 'clientId' parameter, if present, has as value the OSCORE
	Sender ID assigned to the joining node by the Group Manager.		Sender ID assigned to the joining node by the Group Manager, as
	This parameter is not present if the node joins the group		described above. This parameter is not present if the node
	exclusively as monitor, according to what specified in the		joins the group exclusively as monitor, according to what
	Access Token (see Section 3.2). In any other case, this		specified in the Access Token (see Section 3.2). In any other
	parameter MUST be present.		case, this parameter MUST be present.
	* The 'hkdf' parameter, if present, has as value the KDF		* The 'hkdf' parameter, if present, has as value the KDF
	algorithm used in the group.		algorithm used in the group.
	* The 'alg' parameter, if present, has as value the AEAD		* The 'alg' parameter, if present, has as value the AEAD
	algorithm used in the group.		algorithm used in the group.
	* The 'salt' parameter, if present, has as value the OSCORE		* The 'salt' parameter, if present, has as value the OSCORE
	Master Salt.		Master Salt.
	skipping to change at page 16, line 20 ¶		skipping to change at page 16, line 16 ¶
	* The 'cs_key_params' parameter MAY be present and specifies the		* The 'cs_key_params' parameter MAY be present and specifies the
	additional parameters for the key used with the counter		additional parameters for the key used with the counter
	signature algorithm. This parameter is a CBOR map whose		signature algorithm. This parameter is a CBOR map whose
	content depends on the counter signature algorithm, as		content depends on the counter signature algorithm, as
	specified in Section 2 and Section 9.2 of		specified in Section 2 and Section 9.2 of
	[I-D.ietf-core-oscore-groupcomm].		[I-D.ietf-core-oscore-groupcomm].
	* The 'cs_key_enc' parameter MAY be present and specifies the		* The 'cs_key_enc' parameter MAY be present and specifies the
	encoding of the public keys of the group members. This		encoding of the public keys of the group members. This
	parameter is a CBOR integer, whose value is taken from		parameter is a CBOR integer, whose value is 1 ("COSE_Key")
	Figure 2, as a public key encoding in the "ACE Public Key		taken from the 'Confirmation Key' column of the "CWT
	Encoding" Registry (see Section 11.2 of		Confirmation Method" Registry defined in
	[I-D.ietf-ace-key-groupcomm]). If this parameter is not		[I-D.ietf-ace-cwt-proof-of-possession], so indicating that
	present, COSE_Key (1) MUST be assumed as default value.		public keys in the OSCORE group are encoded as COSE Keys
			[RFC8152]. Future specifications may define additional values
			for this parameter. If this parameter is not present, 1
			("COSE_Key") MUST be assumed as default value.
			o The 'num' parameter MUST be present and specifies the current
			version number of the group keying material.
	o The 'profile' parameter MUST be present and has value		o The 'profile' parameter MUST be present and has value
	coap_group_oscore_app (TBD), which is defined in Section 9.3 of		coap_group_oscore_app (TBD), which is defined in Section 15.3 of
	this specification.		this specification.
	o The 'exp' parameter MUST be present and specifies the expiration		o The 'exp' parameter MUST be present and specifies the expiration
	time in seconds after which the OSCORE Security Context derived		time in seconds after which the OSCORE Security Context derived
	from the 'key' parameter is not valid anymore.		from the 'key' parameter is not valid anymore.
	o The 'pub_keys' parameter is present only if the 'get_pub_keys'		o The 'pub_keys' parameter is present only if the 'get_pub_keys'
	parameter was present in the Join Request. If present, this		parameter was present in the Joining Request. If present, this
	parameter includes the public keys of the group members that are		parameter includes the public keys of the group members that are
	relevant to the joining node. That is, it includes: i) the public		relevant to the joining node. That is, it includes: i) the public
	keys of the responders currently in the group, in case the joining		keys of the responders currently in the group, in case the joining
	node is configured (also) as requester; and ii) the public keys of		node is configured (also) as requester; and ii) the public keys of
	the requesters currently in the group, in case the joining node is		the requesters currently in the group, in case the joining node is
	configured (also) as responder or monitor.		configured (also) as responder or monitor. If public keys are
			encoded as COSE_Keys, each of them has as 'kid' the Sender ID that
			the corresponding owner has in the group, thus used as group
			member identifier.
	o The 'group_policies' parameter SHOULD be present and includes a		o The 'group_policies' parameter SHOULD be present and includes a
	list of parameters indicating particular policies enforced in the		list of parameters indicating particular policies enforced in the
	group. For instance, its field "Sequence Number Synchronization		group. In particular, if the field "Sequence Number
	Method" can indicate the method to achieve synchronization of		Synchronization Method" is present, it indicates the method to
	sequence numbers among group members (see Appendix E of		achieve synchronization of sequence numbers among group members
	[I-D.ietf-core-oscore-groupcomm]), as indicated by the		(see Appendix E of [I-D.ietf-core-oscore-groupcomm]), by
	corresponding value from the "Sequence Number Synchronization		specifying the corresponding value from the "Sequence Number
	Method" Registry defined in Section 11.8 of		Synchronization Method" Registry defined in Section 8.6 of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	Finally, the joining node uses the information received in the Join		Finally, the joining node uses the information received in the
	Response to set up the OSCORE Security Context, as described in		Joining Response to set up the OSCORE Security Context, as described
	Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the		in Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the
	joining node can exchange group messages secured with OSCORE as		joining node can exchange group messages secured with Group OSCORE as
	described in [I-D.ietf-core-oscore-groupcomm].		described in [I-D.ietf-core-oscore-groupcomm].
	If the application requires backward security, the Group Manager		If the application requires backward security, the Group Manager MUST
	SHALL generate updated security parameters and group keying material,
	and provide it to all the current group members (see Section 7).
	When the OSCORE Security Context expires, as specified by the 'exp'
	parameter of the Join Response, the node considers it invalid and to
	be renewed. Then, the node retrieves updated security parameters and
	keying material, by exchanging with the Group Manager a shortened
	Join Request sent to the same Join Resource with the 'type' parameter
	set to 3 ("update key") and a shortened Join Response message,
	according to the approach defined in Section 6 of
	[I-D.ietf-ace-key-groupcomm]. Finally, the node uses the updated
	security parameters and keying material to set up the new OSCORE
	Security Context as described in Section 2 of
	[I-D.ietf-core-oscore-groupcomm].
	Furthermore, as discussed in Section 2.2 of
	[I-D.ietf-core-oscore-groupcomm], the node may at some point
	experience a wrap-around of its own Sender Sequence Number in the
	group. When this happens, the node MUST send to the Group Manager a
	shortened Join Request message to the same Join Resource, with the
	'type' parameter set to 4 ("new"). Upon receiving this request
	message, the Group Manager either rekeys the whole OSCORE group as
	discussed in Section 7, or generates a new Sender ID for that node
	and replies with a shortened Join Response message where:
	o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are
	present.
	o The 'clientId' parameter of the 'key' parameter specifies the new
	Sender ID of the node.
	5. Leaving of a Group Member
	A node may be removed from the OSCORE group, due to expired or
	revoked authorization, or after its own request to the Group Manager.
	If the application requires forward security, the Group Manager SHALL
	generate updated security parameters and group keying material, and		generate updated security parameters and group keying material, and
	provide it to the remaining group members (see Section 7). The		provide it to all the current group members (see Section 13).
	leaving node must not be able to acquire the new security parameters
	and group keying material distributed after its leaving.
	Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
	apply here as well, considering the Group Manager acting as KDC. In
	particular, a node requests to leave the OSCORE group as described in
	Section 5.2 of [I-D.ietf-ace-key-groupcomm], i.e. by sending to the
	Group Manager a request to the same Join Resource with the 'type'
	parameter set to 2 ("leave").
	6. Public Keys of Joining Nodes		5. Public Keys of Joining Nodes
	Source authentication of OSCORE messages exchanged within the group		Source authentication of OSCORE messages exchanged within the group
	is ensured by means of digital counter signatures (see Sections 2 and		is ensured by means of digital counter signatures (see Sections 2 and
	3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members		3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members
	must be able to retrieve each other's public key from a trusted key		must be able to retrieve each other's public key from a trusted key
	repository, in order to verify source authenticity of incoming group		repository, in order to verify source authenticity of incoming group
	messages.		messages.
	As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group		As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
	Manager acts as trusted repository of the public keys of the group		Manager acts as trusted repository of the public keys of the group
	skipping to change at page 18, line 40 ¶		skipping to change at page 17, line 48 ¶
	o The joining node is going to join the group exclusively as		o The joining node is going to join the group exclusively as
	monitor. That is, it is not going to send messages to the group,		monitor. That is, it is not going to send messages to the group,
	and hence to produce signatures with its own private key. In this		and hence to produce signatures with its own private key. In this
	case, the joining node is not required to provide its own public		case, the joining node is not required to provide its own public
	key to the Group Manager, which thus does not have to perform any		key to the Group Manager, which thus does not have to perform any
	check related to the public key encoding, or to a countersignature		check related to the public key encoding, or to a countersignature
	algorithm and possible associated parameters for that joining		algorithm and possible associated parameters for that joining
	node.		node.
	o The Group Manager already acquired the public key of the joining		o The Group Manager already acquired the public key of the joining
	node during a past join process. In this case, the joining node		node during a past joining process. In this case, the joining
	MAY not provide again its own public key to the Group Manager, in		node MAY choose not to provide again its own public key to the
	order to limit the size of the Join Request. The joining node		Group Manager, in order to limit the size of the Joining Request.
	MUST provide its own public key again if it has provided the Group		The joining node MUST provide its own public key again if it has
	Manager with multiple public keys during past join processes,		provided the Group Manager with multiple public keys during past
	intended for different OSCORE groups. If the joining node		joining processes, intended for different OSCORE groups. If the
	provides its own public key, the Group Manager performs		joining node provides its own public key, the Group Manager
	consistency checks as in Section 4.3 and, in case of success,		performs consistency checks as per Section 4.3 and, in case of
	considers it as the public key associated to the joining node in		success, considers it as the public key associated to the joining
	the OSCORE group.		node in the OSCORE group.
	o The joining node and the Group Manager use an asymmetric proof-of-		o The joining node and the Group Manager use an asymmetric proof-of-
	possession key to establish a secure communication channel. Then,		possession key to establish a secure communication channel. Then,
	two cases can occur.		two cases can occur.
	1. The proof-of-possession key is consistent with the encoding as		1. The proof-of-possession key is compatible with the encoding as
	well as with the counter signature algorithm and possible		well as with the counter signature algorithm and possible
	associated parameters used in the OSCORE group. Then, the		associated parameters used in the OSCORE group. Then, the
	Group Manager considers the proof-of-possession key as the		Group Manager considers the proof-of-possession key as the
	public key associated to the joining node in the OSCORE group.		public key associated to the joining node in the OSCORE group.
	If the joining node is aware that the proof-of-possession key		If the joining node is aware that the proof-of-possession key
	is also valid for the OSCORE group, it MAY not provide it		is also valid for the OSCORE group, it MAY not provide it
	again as its own public key to the Group Manager. The joining		again as its own public key to the Group Manager. The joining
	node MUST provide its own public key again if it has provided		node MUST provide its own public key again if it has provided
	the Group Manager with multiple public keys during past join		the Group Manager with multiple public keys during past
	processes, intended for different OSCORE groups. If the		joining processes, intended for different OSCORE groups. If
	joining node provides its own public key in the 'client_cred'		the joining node provides its own public key in the
	parameter of the Join Request (see Section 4.2), the Group		'client_cred' parameter of the Joining Request (see
	Manager performs consistency checks as in Section 4.3 and, in		Section 4.2), the Group Manager performs consistency checks as
	case of success, considers it as the public key associated to		per Section 4.3 and, in case of success, considers it as the
	the joining node in the OSCORE group.		public key associated to the joining node in the OSCORE group.
	2. The proof-of-possession key is not consistent with the		2. The proof-of-possession key is not compatible with the
	encoding or with the counter signature algorithm and possible		encoding or with the counter signature algorithm and possible
	associated parameters used in the OSCORE group. In this case,		associated parameters used in the OSCORE group. In this case,
	the joining node MUST provide a different consistent public		the joining node MUST provide a different compatible public
	key to the Group Manager in the 'client_cred' parameter of the		key to the Group Manager in the 'client_cred' parameter of the
	Join Request (see Section 4.2). Then, the Group Manager		Joining Request (see Section 4.2). Then, the Group Manager
	performs consistency checks on this latest provided public key		performs consistency checks on this latest provided public key
	as in Section 4.3 and, in case of success, considers it as the		as per Section 4.3 and, in case of success, considers it as
	public key associated to the joining node in the OSCORE group.		the public key associated to the joining node in the OSCORE
			group.
	o The joining node and the Group Manager use a symmetric proof-of-		o The joining node and the Group Manager use a symmetric proof-of-
	possession key to establish a secure communication channel. In		possession key to establish a secure communication channel. In
	this case, upon performing a join process with that Group Manager		this case, upon performing a joining process with that Group
	for the first time, the joining node specifies its own public key		Manager for the first time, the joining node specifies its own
	in the 'client_cred' parameter of the Join Request targeting the		public key in the 'client_cred' parameter of the Joining Request
	join endpoint (see Section 4.2).		targeting the group-membership endpoint (see Section 4.2).
	Furthermore, as described in Section 4.2, the joining node may have		6. Retrieval of Updated Keying Material
	explicitly requested the Group Manager to retrieve the public keys of
	the current group members, i.e. by including the 'get_pub_keys'
	parameter in the Join Request. In this case, the Group Manager
	includes also such public keys in the 'pub_keys' parameter of the
	Join Response (see Section 4.3).
	Later on as a group member, the node may need to retrieve the public		At some point, a group member considers the OSCORE Security Context
	keys of other group members. The node can do that by exchanging with		invalid and to be renewed. This happens, for instance, after a
	the Group Manager a shortened Join Request sent to the same Join		number of unsuccessful security processing of incoming messages from
	Resource with the 'type' parameter set to 5 ("pub keys") and a		other group members, or when the Security Context expires as
	shortened Join Response, according to the approach defined in		specified by the 'exp' parameter of the Joining Response.
	Section 7 of [I-D.ietf-ace-key-groupcomm].
	7. Group Rekeying Process		When this happens, the group member retrieves updated security
			parameters and group keying material, by sending a Key Distribution
			Request message to the Group Manager, as per Section 4.3 of
			[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET
			request to the endpoint /group-oscore/NAME at the Group Manager,
			where NAME is the name of the OSCORE group. The Key Distribution
			Request is formatted as defined in Section 4.1.2.2 of
			[I-D.ietf-ace-key-groupcomm].
			The Group Manager processes the Key Distribution Request according to
			Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key
			Distribution Response is formatted as defined in Section 4.1.2.2 of
			[I-D.ietf-ace-key-groupcomm].
			Upon receiving the Key Distribution Response, the group member
			retrieves the updated security parameters and group keying material,
			and use them to set up the new OSCORE Security Context as described
			in Section 2 of [I-D.ietf-core-oscore-groupcomm].
			7. Retrieval of New Keying Material
			As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a
			group member may at some point experience a wrap-around of its own
			Sender Sequence Number in the group.
			When this happens, the group member MUST send a Key Renewal Request
			message to the Group Manager, as per Section 4.4 of
			[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET
			request to the endpoint /group-oscore/NAME/node at the Group Manager,
			where NAME is the name of the OSCORE group.
			Upon receiving the Key Renewal Request, the Group Manager processes
			it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and
			performs one of the following actions.
			1. The Group Manager replies to the group member with a 4.06 (Not
			Acceptable) error response, and rekeys the whole OSCORE group as
			discussed in Section 13.
			2. The Group Manager generates a new Sender ID for that group member
			and replies with a Key Renewal Response, formatted as defined in
			Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. In particular,
			the CBOR Map in the response payload includes a single parameter
			'clientId' defined in Section 15.5 of this document, specifying
			the new Sender ID of the group member encoded as a CBOR byte
			string.
			8. Retrieval of Public Keys of Group Members
			A group member may need to retrieve the public keys of other group
			members. To this end, the group member sends a Public Key Request
			message to the Group Manager, as per Section 4.5 of
			[I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to
			the endpoint /group-oscore/NAME/pub-key at the Group Manager, where
			NAME is the name of the OSCORE group.
			If the Public Key Request uses the method POST, the Public Key
			Request is formatted as defined in Section 4.1.3.1 of
			[I-D.ietf-ace-key-groupcomm]. In particular, each element of the
			'get_pub_keys' parameter is a CBOR byte string, which encodes the
			Sender ID of the group member for which the associated public key is
			requested.
			Upon receiving the Public Key Request, the Group Manager processes it
			as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm],
			depending on the request method being POST or GET, respectively. If
			the Public Key Request uses the method POST, the Group Manager
			silently ignores identifiers included in the 'get_pub_keys' parameter
			of the request that are not associated to any current group member.
			The success Public Key Response is formatted as defined in
			Section 4.1.3.1 of [I-D.ietf-ace-key-groupcomm].
			9. Retrieval of Group Policies
			A group member may request the current policies used in the OSCORE
			group. To this end, the group member sends a Policies Request, as
			per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In particular, it
			sends a CoAP GET request to the endpoint /group-oscore/NAME/policies
			at the Group Manager, where NAME is the name of the OSCORE group.
			Upon receiving the Policies Request, the Group Manager processes it
			as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success
			Policies Response is formatted as defined in Section 4.1.4.1 of
			[I-D.ietf-ace-key-groupcomm].
			10. Retrieval of Keying Material Version
			A group member may request the current version of the keying material
			used in the OSCORE group. To this end, the group member sends a
			Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm].
			In particular, it sends a CoAP GET request to the endpoint /group-
			oscore/NAME/ctx-num at the Group Manager, where NAME is the name of
			the OSCORE group.
			Upon receiving the Version Request, the Group Manager processes it as
			per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success
			Version Response is formatted as defined in Section 4.1.5.1 of
			[I-D.ietf-ace-key-groupcomm].
			11. Request to Leave the Group
			A group member may request to leave the OSCORE group. To this end,
			the group member sends a Group Leaving Request, as per Section 4.8 of
			[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST
			request to the endpoint /group-oscore/NAME/node at the Group Manager,
			where NAME is the name of the OSCORE group to leave.
			The Leaving Request is formatted as defined in Section 4.1.6.1 of
			[I-D.ietf-ace-key-groupcomm], and MUST have an empty CBOR Map as
			payload.
			Upon receiving the Leaving Request, the Group Manager processes it as
			per Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm].
			12. Removal of a Group Member
			Other than after a spontaneous request to the Group Manager as
			described in Section 11, a node may be forcibly removed from the
			OSCORE group, e.g. due to expired or revoked authorization.
			In either case, if the leaving node is not configured exclusively as
			monitor, the Group Manager performs the following actions.
			o The Group Manager frees the OSCORE Sender ID value of the leaving
			node, which becomes available for possible upcoming joining nodes.
			o The Group Manager cancels the association between, on one hand,
			the public key of the leaving node and, on the other hand, the
			Group Identifier (Gid) associated to the OSCORE group together
			with the freed OSCORE Sender ID value. The Group Manager deletes
			the public key of the leaving node, if that public key has no
			remaining association with any pair (Group ID, Sender ID).
			If the application requires forward security, the Group Manager MUST
			generate updated security parameters and group keying material, and
			provide it to the remaining group members (see Section 13). As a
			consequence, the leaving node is not able to acquire the new security
			parameters and group keying material distributed after its leaving.
			Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
			apply here as well, considering the Group Manager acting as KDC.
			13. Group Rekeying Process
	In order to rekey the OSCORE group, the Group Manager distributes a		In order to rekey the OSCORE group, the Group Manager distributes a
	new Group ID of the group and a new OSCORE Master Secret for that		new Group ID of the group and a new OSCORE Master Secret for that
	group. When doing so, the Group Manager MAY take a best effort to		group. When doing so, the Group Manager MUST increment the version
			number of the group keying material. Also, the Group Manager MUST
	preserve the same unchanged Sender IDs for all group members. This		preserve the same unchanged Sender IDs for all group members. This
	avoids affecting the retrieval of public keys from the Group Manager		avoids affecting the retrieval of public keys from the Group Manager
	as well as the verification of message countersignatures.		as well as the verification of message countersignatures.
	The Group Manager MUST support at least the following group rekeying		The Group Manager MUST support at least the following group rekeying
	scheme. Future application profiles may define alternative message		scheme. Future application profiles may define alternative message
	formats and distribution schemes.		formats and distribution schemes.
	The Group Manager uses the same format of the Join Response message		The Group Manager uses the same format of the Joining Response
	in Section 4.3. In particular:		message in Section 4.3. In particular:
	o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are		o Only the parameters 'kty', 'key', 'num', 'profile' and 'exp' are
	present.		present.
	o The 'ms' parameter of the 'key' parameter specifies the new OSCORE		o The 'ms' parameter of the 'key' parameter specifies the new OSCORE
	Master Secret value.		Master Secret value.
	o The 'contextId' parameter of the 'key' parameter specifies the new		o The 'contextId' parameter of the 'key' parameter specifies the new
	Group ID.		Group ID.
	The Group Manager separately sends a group rekeying message to each		The Group Manager separately sends a group rekeying message to each
	group member to be rekeyed. Each rekeying message MUST be secured		group member to be rekeyed. Each rekeying message MUST be secured
	with the pairwise secure communication channel between the Group		with the pairwise secure communication channel between the Group
	Manager and the group member used during the join process.		Manager and the group member used during the joining process.
	This approach requires group members to act (also) as servers, in		This approach requires group members to act (also) as servers, in
	order to correctly handle unsolicited group rekeying messages from		order to correctly handle unsolicited group rekeying messages from
	the Group Manager. In particular, if a group member and the Group		the Group Manager. In particular, if a group member and the Group
	Manager use OSCORE [I-D.ietf-core-object-security] to secure their		Manager use OSCORE [RFC8613] to secure their pairwise communications,
	pairwise communications, the group member MUST create a Replay Window		the group member MUST create a Replay Window in its own Recipient
	in its own Recipient Context upon establishing the OSCORE Security		Context upon establishing the OSCORE Security Context with the Group
	Context with the Group Manager, e.g. by means of the OSCORE profile		Manager, e.g. by means of the OSCORE profile of ACE
	of ACE [I-D.ietf-ace-oscore-profile].		[I-D.ietf-ace-oscore-profile].
	Group members and the Group Manager SHOULD additionally support		Group members and the Group Manager SHOULD additionally support
	alternative rekeying approaches that do not require group members to		alternative rekeying approaches that do not require group members to
	act (also) as servers. A number of such approaches are defined in		act (also) as servers. A number of such approaches are defined in
	Section 6 of [I-D.ietf-ace-key-groupcomm], and are based on the		Section 4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group
	following rationale:		member may subscribe for updates to the group-membership resource of
			the group, at the endpoint /group-oscore/NAME of the Group Manager,
	o A group member queries the Group Manager for updated group keying		where NAME is the name of the OSCORE group. This can rely on CoAP
	material, by sending a dedicated request to the same Join Resource		Observe [RFC7641] or on a full-fledged Pub-Sub model
	targeted when joining the group. Like for the case discussed in		[I-D.ietf-core-coap-pubsub] with the Group Manager acting as Broker.
	Section 4.3 where the OSCORE Security Context expires, the group
	member exchanges with the Group Manager a shortened Join Request
	sent to the same Join Resource with the 'type' parameter set to 3
	("update key") and a shortened Join Response message, according to
	the approach defined in Section 6 of [I-D.ietf-ace-key-groupcomm].
	o A group member subscribes for updates to the join resource and its
	associated group keying material on the Group Manager. This can
	rely on CoAP Observe [RFC7641] or on a full-fledged Pub-Sub model
	[I-D.ietf-core-coap-pubsub] with the Group Manager acting as
	Broker.
	Either case, the Group Manager provides the (updated) group keying
	material as specified above in this section.
	8. Security Considerations		14. Security Considerations
	The method described in this document leverages the following		The method described in this document leverages the following
	management aspects related to OSCORE groups and discussed in the		management aspects related to OSCORE groups and discussed in the
	sections of [I-D.ietf-core-oscore-groupcomm] referred below.		sections of [I-D.ietf-core-oscore-groupcomm] referred below.
	o Management of group keying material (see Section 2.1 of		o Management of group keying material (see Section 2.1 of
	[I-D.ietf-core-oscore-groupcomm]). The Group Manager is		[I-D.ietf-core-oscore-groupcomm]). The Group Manager is
	responsible for the renewal and re-distribution of the keying		responsible for the renewal and re-distribution of the keying
	material in the groups of its competence (rekeying). According to		material in the groups of its competence (rekeying). According to
	the specific application requirements, this can include rekeying		the specific application requirements, this can include rekeying
	the group upon changes in its membership. In particular, renewing		the group upon changes in its membership. In particular, renewing
	the keying material is required upon a new node's joining or a		the group keying material is required upon a new node's joining or
	current node's leaving, in case backward security and forward		a current node's leaving, in case backward security and forward
	security have to be preserved, respectively.		security have to be preserved, respectively.
	o Provisioning and retrieval of public keys (see Section 2 of		o Provisioning and retrieval of public keys (see Section 2 of
	[I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key		[I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key
	repository of public keys of group members, and provides them upon		repository of public keys of group members, and provides them upon
	request.		request.
	o Synchronization of sequence numbers (see Section 5 of		o Synchronization of sequence numbers (see Section 5 of
	[I-D.ietf-core-oscore-groupcomm]). This concerns how a responder		[I-D.ietf-core-oscore-groupcomm]). This concerns how a responder
	node that has just joined an OSCORE group can synchronize with the		node that has just joined an OSCORE group can synchronize with the
	sequence number of requesters in the same group.		sequence number of requesters in the same group.
	Before sending the Join Response, the Group Manager MUST verify that		Before sending the Joining Response, the Group Manager MUST verify
	the joining node actually owns the associated private key. To this		that the joining node actually owns the associated private key. To
	end, the Group Manager can rely on the proof-of-possession challenge-		this end, the Group Manager can rely on the proof-of-possession
	response defined in Section 4. Alternatively, the joining node can		challenge-response defined in Section 4. Alternatively, the joining
	use its own public key as asymmetric proof-of-possession key to		node can use its own public key as asymmetric proof-of-possession key
	establish a secure channel with the Group Manager, e.g. as in		to establish a secure channel with the Group Manager, e.g. as in
	Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires		Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires
	such proof-of-possession key to be consistent with the encoding as		such proof-of-possession key to be compatible with the encoding as
	well as with the countersignature algorithm and possible associated		well as with the countersignature algorithm and possible associated
	parameters used in the OSCORE group.		parameters used in the OSCORE group.
	A node may have joined multiple OSCORE groups under different non-		A node may have joined multiple OSCORE groups under different non-
	synchronized Group Managers. Therefore, it can happen that those		synchronized Group Managers. Therefore, it can happen that those
	OSCORE groups have the same Group Identifier (Gid). It follows that,		OSCORE groups have the same Group Identifier (Gid). It follows that,
	upon receiving a Group OSCORE message addressed to one of those		upon receiving a Group OSCORE message addressed to one of those
	groups, the node would have multiple Security Contexts matching with		groups, the node would have multiple Security Contexts matching with
	the Gid in the incoming message. It is up to the application to		the Gid in the incoming message. It is up to the application to
	decide how to handle such collisions of Group Identifiers, e.g. by		decide how to handle such collisions of Group Identifiers, e.g. by
	trying to process the incoming message using one Security Context at		trying to process the incoming message using one Security Context at
	the time until the right one is found.		the time until the right one is found.
	Further security considerations are inherited from		Further security considerations are inherited from
	[I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication		[I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication
	and Authorization [I-D.ietf-ace-oauth-authz], and the specific		and Authorization [I-D.ietf-ace-oauth-authz], and the specific
	transport profile of ACE signalled by the AS, such as		transport profile of ACE signalled by the AS, such as
	[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].		[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].
	9. IANA Considerations		15. IANA Considerations
	Note to RFC Editor: Please replace all occurrences of "[[This		Note to RFC Editor: Please replace all occurrences of "[[This
	specification]]" with the RFC number of this specification and delete		specification]]" with the RFC number of this specification and delete
	this paragraph.		this paragraph.
	This document has the following actions for IANA.		This document has the following actions for IANA.
	9.1. ACE Groupcomm Key Registry		15.1. ACE Groupcomm Key Registry
	IANA is asked to register the following entry in the "ACE Groupcomm		IANA is asked to register the following entry in the "ACE Groupcomm
	Key" Registry defined in Section 11.5 of		Key" Registry defined in Section 8.3 of [I-D.ietf-ace-key-groupcomm].
	[I-D.ietf-ace-key-groupcomm].
	o Name: Group_OSCORE_Security_Context object		o Name: Group_OSCORE_Security_Context object
	o Key Type Value: TBD		o Key Type Value: TBD
	o Profile: "coap_group_oscore_app", defined in Section 9.3 of this		o Profile: "coap_group_oscore_app", defined in Section 15.3 of this
	specification.		specification.
	o Description: A Group_OSCORE_Security_Context object encoded as		o Description: A Group_OSCORE_Security_Context object encoded as
	described in Section 4.3 of this specification.		described in Section 4.3 of this specification.
	o Reference: [[This specification]]		o Reference: [[This specification]]
	9.2. OSCORE Security Context Parameters Registry		15.2. OSCORE Security Context Parameters Registry
	IANA is asked to register the following entries in the "OSCORE		IANA is asked to register the following entries in the "OSCORE
	Security Context Parameters" Registry defined in Section 9.2 of		Security Context Parameters" Registry defined in Section 9.2 of
	[I-D.ietf-ace-oscore-profile].		[I-D.ietf-ace-oscore-profile].
	o Name: cs_alg		o Name: cs_alg
	o CBOR Label: TBD		o CBOR Label: TBD
	o CBOR Type: tstr / int		o CBOR Type: tstr / int
	o Registry: COSE Algorithm Values (ECDSA, EdDSA)		o Registry: COSE Algorithm Values (ECDSA, EdDSA)
	o Description: OSCORE Counter Signature Algorithm Value		o Description: OSCORE Counter Signature Algorithm Value
	o Reference: [[This specification]]		o Reference: [[This specification]]
	skipping to change at page 24, line 4 ¶		skipping to change at page 25, line 44 ¶
	o Description: OSCORE Counter Signature Key Additional Parameters		o Description: OSCORE Counter Signature Key Additional Parameters
	o Reference: [[This specification]]		o Reference: [[This specification]]
	o Name: cs_key_enc		o Name: cs_key_enc
	o CBOR Label: TBD		o CBOR Label: TBD
	o CBOR Type: integer		o CBOR Type: integer
	o Registry: ACE Public Key Encoding		o Registry: ACE Public Key Encoding
	o Description: Encoding of Public Keys to be used with the OSCORE		o Description: Encoding of Public Keys to be used with the OSCORE
	Counter Signature Algorithm		Counter Signature Algorithm
	o Reference: [[This specification]]		o Reference: [[This specification]]
	9.3. ACE Groupcomm Profile Registry		15.3. ACE Groupcomm Profile Registry
	IANA is asked to register the following entry in the "ACE Groupcomm		IANA is asked to register the following entry in the "ACE Groupcomm
	Profile" Registry defined in Section 11.6 of		Profile" Registry defined in Section 8.4 of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	o Name: coap_group_oscore_app		o Name: coap_group_oscore_app
	o Description: Application profile to provision keying material for		o Description: Application profile to provision keying material for
	participating in group communication protected with Group OSCORE		participating in group communication protected with Group OSCORE
	as per [I-D.ietf-core-oscore-groupcomm].		as per [I-D.ietf-core-oscore-groupcomm].
	o CBOR Value: TBD		o CBOR Value: TBD
	o Reference: [[This specification]]		o Reference: [[This specification]]
	9.4. Sequence Number Synchronization Method Registry		15.4. Sequence Number Synchronization Method Registry
	IANA is asked to register the following entries in the "Sequence		IANA is asked to register the following entries in the "Sequence
	Number Synchronization Method" Registry defined in Section 11.8 of		Number Synchronization Method" Registry defined in Section 8.6 of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	o Name: Best effort		o Name: Best effort
	o Value: 1		o Value: 1
	o Description: No action is taken.		o Description: No action is taken.
	o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1).		o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1).
	skipping to change at page 25, line 4 ¶		skipping to change at page 26, line 46 ¶
	o Value: 2		o Value: 2
	o Description: The first received request sets the baseline		o Description: The first received request sets the baseline
	reference point, and is discarded with no delivery to the		reference point, and is discarded with no delivery to the
	application.		application.
	o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2).		o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2).
	o Name: Echo challenge-response		o Name: Echo challenge-response
	o Value: 3		o Value: 3
	o Description: Challenge response using the Echo Option for CoAP		o Description: Challenge response using the Echo Option for CoAP
	from [I-D.ietf-core-echo-request-tag].		from [I-D.ietf-core-echo-request-tag].
	o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3).		o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3).
	9.5. ACE Public Key Encoding Registry		15.5. ACE Groupcomm Parameters Registry
	This specification registers the value defined in Figure 2 in the		IANA is asked to register the following entry in the "ACE Groupcomm
	"ACE Public Key Encoding" IANA Registry.		Parameters" Registry defined in Section 8.2 of
			[I-D.ietf-ace-key-groupcomm].
	10. References		o Name: clientId
	10.1. Normative References		o CBOR Key: TBD
			o CBOR Type: Byte string
			o Reference: [[This document]] (Section 7).
			16. References
			16.1. Normative References
			[I-D.ietf-ace-cwt-proof-of-possession]
			Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
			Tschofenig, "Proof-of-Possession Key Semantics for CBOR
			Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
			possession-11 (work in progress), October 2019.
	[I-D.ietf-ace-key-groupcomm]		[I-D.ietf-ace-key-groupcomm]
	Palombini, F. and M. Tiloca, "Key Provisioning for Group		Palombini, F. and M. Tiloca, "Key Provisioning for Group
	Communication using ACE", draft-ietf-ace-key-groupcomm-02		Communication using ACE", draft-ietf-ace-key-groupcomm-03
	(work in progress), July 2019.		(work in progress), November 2019.
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25
	(work in progress), March 2019.		(work in progress), October 2019.
	[I-D.ietf-ace-oscore-profile]		[I-D.ietf-ace-oscore-profile]
	Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,		Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
	"OSCORE profile of the Authentication and Authorization		"OSCORE profile of the Authentication and Authorization
	for Constrained Environments Framework", draft-ietf-ace-		for Constrained Environments Framework", draft-ietf-ace-
	oscore-profile-07 (work in progress), February 2019.		oscore-profile-08 (work in progress), July 2019.
	[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-16 (work in
	progress), March 2019.
	[I-D.ietf-core-oscore-groupcomm]		[I-D.ietf-core-oscore-groupcomm]
	Tiloca, M., Selander, G., Palombini, F., and J. Park,		Tiloca, M., Selander, G., Palombini, F., and J. Park,
	"Group OSCORE - Secure Group Communication for CoAP",		"Group OSCORE - Secure Group Communication for CoAP",
	draft-ietf-core-oscore-groupcomm-05 (work in progress),		draft-ietf-core-oscore-groupcomm-05 (work in progress),
	July 2019.		July 2019.
	[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>.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[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>.
	10.2. Informative References		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
			"Object Security for Constrained RESTful Environments
			(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
			<https://www.rfc-editor.org/info/rfc8613>.
			16.2. Informative References
	[I-D.dijk-core-groupcomm-bis]		[I-D.dijk-core-groupcomm-bis]
	Dijk, E., Wang, C., and M. Tiloca, "Group Communication		Dijk, E., Wang, C., and M. Tiloca, "Group Communication
	for the Constrained Application Protocol (CoAP)", draft-		for the Constrained Application Protocol (CoAP)", draft-
	dijk-core-groupcomm-bis-00 (work in progress), March 2019.		dijk-core-groupcomm-bis-01 (work in progress), July 2019.
	[I-D.ietf-ace-dtls-authorize]		[I-D.ietf-ace-dtls-authorize]
	Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and		Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
	L. Seitz, "Datagram Transport Layer Security (DTLS)		L. Seitz, "Datagram Transport Layer Security (DTLS)
	Profile for Authentication and Authorization for		Profile for Authentication and Authorization for
	Constrained Environments (ACE)", draft-ietf-ace-dtls-		Constrained Environments (ACE)", draft-ietf-ace-dtls-
	authorize-08 (work in progress), April 2019.		authorize-08 (work in progress), April 2019.
	[I-D.ietf-core-coap-pubsub]		[I-D.ietf-core-coap-pubsub]
	Koster, M., Keranen, A., and J. Jimenez, "Publish-		Koster, M., Keranen, A., and J. Jimenez, "Publish-
	Subscribe Broker for the Constrained Application Protocol		Subscribe Broker for the Constrained Application Protocol
	(CoAP)", draft-ietf-core-coap-pubsub-08 (work in		(CoAP)", draft-ietf-core-coap-pubsub-09 (work in
	progress), March 2019.		progress), September 2019.
	[I-D.ietf-core-echo-request-tag]		[I-D.ietf-core-echo-request-tag]
	Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,		Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
	Request-Tag, and Token Processing", draft-ietf-core-echo-		Request-Tag, and Token Processing", draft-ietf-core-echo-
	request-tag-05 (work in progress), May 2019.		request-tag-08 (work in progress), November 2019.
	[I-D.tiloca-core-oscore-discovery]		[I-D.tiloca-core-oscore-discovery]
	Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE		Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
	Groups with the CoRE Resource Directory", draft-tiloca-		Groups with the CoRE Resource Directory", draft-tiloca-
	core-oscore-discovery-02 (work in progress), March 2019.		core-oscore-discovery-03 (work in progress), July 2019.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for		[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
	skipping to change at page 27, line 29 ¶		skipping to change at page 29, line 39 ¶
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/info/rfc7641>.		<https://www.rfc-editor.org/info/rfc7641>.
	Appendix A. Profile Requirements		Appendix A. Profile Requirements
	This appendix lists the specifications on this application profile of		This appendix lists the specifications on this application profile of
	ACE, based on the requiremens defined in Appendix A of		ACE, based on the requiremens defined in Appendix A of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	o Communication protocol that the members of the group must use:		o REQ1 - Specify the encoding and value of the identifier of group
	CoAP, possibly over IP multicast.		of 'scope': see Section 3.1.
	o Security protocols that the group members must use to protect
	their communication: Group OSCORE.
	o Specify the encoding and value of the identifier of group and role		o REQ2 - Specify the encoding and value of the identifier of roles
	of 'scope': see Section 3.1.		of 'scope': see Section 3.1.
	o Profile identifier: coap_group_oscore_app		o REQ3 (Optional) - Specify the acceptable values for 'sign_alg':
			values from Tables 5 and 6 of [RFC8152].
	o Acceptable values of 'kty': Group_OSCORE_Security_Context object		o REQ4 (Optional) - Specify the acceptable values for
			'sign_parameters': values from the "Counter Signature Parameters"
			Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).
	o Specify the format and content of 'group_policies' entries: three		o REQ5 (Optional) - Specify the acceptable values for
	values are defined and registered, as content of the entry		'sign_key_parameters': values from the "Counter Signature Key
	"Sequence Number Synchronization Method" (see Section 9.4).		Parameters" Registry (see Section 9.2 of
			[I-D.ietf-core-oscore-groupcomm]).
	o (Optional) specify the format and content of 'mgt_key_material':		o REQ6 (Optional) - Specify the acceptable values for 'pub_key_enc':
	no.		1 ("COSE_Key") from the 'Confirmation Key' column of the "CWT
			Confirmation Method" Registry defined in
			[I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may
			define additional values for this parameter.
	o (Optional) specify the transport profile of ACE		o REQ7 - Format of the 'key' value: see Section 4.3.
	[I-D.ietf-ace-oauth-authz] to use between Client and Group
	Manager: any transport profile of ACE that complies with the
	requirements in Appendix C of [I-D.ietf-ace-oauth-authz].
	o (Optional) specify the encoding of public keys, of 'client_cred',		o REQ8 - Acceptable values of 'kty': Group_OSCORE_Security_Context
	and of 'pub_keys' if COSE_Keys are not used: no.		object (see Section 4.3).
	o (Optional) specify the acceptable values for parameters related to		o REQ9: Specify the format of the identifiers of group members: see
	signature algorithm and signature keys: 'sign_alg' takes value		Section 4.3 and Section 8.
	from Tables 5 and 6 of [RFC8152]; 'sign_parameters' takes values
	from the "Counter Signature Parameters" Registry (see Section 9.1
	of [I-D.ietf-core-oscore-groupcomm]); 'sign_key_parameters' takes
	values from the "Counter Signature Key Parameters" Registry (see
	Section 9.2 of [I-D.ietf-core-oscore-groupcomm]); 'pub_key_enc'
	takes value from Figure 2 in Section 4.1.
	o (Optional) specify the negotiation of parameter values for		o REQ10 (Optional) - Specify the format and content of
			'group_policies' entries: three values are defined and registered,
			as content of the entry "Sequence Number Synchronization Method"
			(see Section 15.4).
			o REQ11 - Communication protocol that the members of the group must
			use: CoAP, possibly over IP multicast.
			o REQ12 - Security protocols that the group members must use to
			protect their communication: Group OSCORE.
			o REQ13 - Profile identifier: coap_group_oscore_app
			o REQ14 (Optional) - Specify the encoding of public keys, of
			'client_cred', and of 'pub_keys' if COSE_Keys are not used: no.
			o REQ15 - Specify policies at the KDC to handle member ids that are
			not included in 'get_pub_keys': see Section 8.
			o REQ16 - Specify the format and content of 'group_policies': see
			Section 4.3.
			o REQ17 - Specify the format of newly-generated individual keying
			material for group members, or of the information to derive it,
			and corresponding CBOR label: see Section 7.
			o REQ18 - Specify how the communication is secured between the
			Client and KDC: by means of any transport profile of ACE
			[I-D.ietf-ace-oauth-authz] between Client and Group Manager that
			complies with the requirements in Appendix C of
			[I-D.ietf-ace-oauth-authz].
			o OPT1 (Optional) - Specify the encoding of public keys, of
			'client_cred', and of 'pub_keys' if COSE_Keys are not used: no.
			o OPT2 (Optional) - Specify the negotiation of parameter values for
	signature algorithm and signature keys, if 'sign_info' and		signature algorithm and signature keys, if 'sign_info' and
	'pub_key_enc' are not used: pre-knowledge by using the approach		'pub_key_enc' are not used: possible early discovery by using the
	based on the CoRE Resource Directory described in		approach based on the CoRE Resource Directory described in
	[I-D.tiloca-core-oscore-discovery].		[I-D.tiloca-core-oscore-discovery].
			o OPT3 (Optional) - Specify the format and content of
			'mgt_key_material': no.
			o OPT4 (Optional) - Specify policies that instruct clients to retain
			unsuccessfully decrypted messages and for how long, so that they
			can be decrypted after getting updated keying material: no.
	Appendix B. Document Updates		Appendix B. Document Updates
	RFC EDITOR: PLEASE REMOVE THIS SECTION.		RFC EDITOR: PLEASE REMOVE THIS SECTION.
	B.1. Version -01 to -02		B.1. Version -02 to -03
			o New sections, aligned with the interface of ace-key-groupcomm .
			o Exchange of information on the countersignature algorithm and
			related parameters, during the Token POST (Section 4.1).
			o Nonce 'rsnonce' from the Group Manager to the Client
			(Section 4.1).
			o Client PoP signature in the Key Distribution Request upon joining
			(Section 4.2).
			o Local actions on the Group Manager, upon a new node's joining
			(Section 4.2).
			o Local actions on the Group Manager, upon a node's leaving
			(Section 12).
			o IANA registration in ACE Groupcomm Parameters Registry.
			o More fulfilled profile requirements (Appendix A).
			B.2. Version -01 to -02
	o Editorial fixes.		o Editorial fixes.
	o Changed: "listener" to "responder"; "pure listener" to "monitor".		o Changed: "listener" to "responder"; "pure listener" to "monitor".
	o Changed profile name to "coap_group_oscore_app", to reflect it is		o Changed profile name to "coap_group_oscore_app", to reflect it is
	an application profile.		an application profile.
	o Added the 'type' parameter for all requests to a Join Resource.		o Added the 'type' parameter for all requests to a Join Resource.
	skipping to change at page 29, line 17 ¶		skipping to change at page 32, line 43 ¶
	o Extended security considerations: proof-of-possession of signature		o Extended security considerations: proof-of-possession of signature
	keys; collision of OSCORE Group Identifiers (Section 8).		keys; collision of OSCORE Group Identifiers (Section 8).
	o Registered three entries in the IANA Registry "Sequence Number		o Registered three entries in the IANA Registry "Sequence Number
	Synchronization Method Registry" (Section 9).		Synchronization Method Registry" (Section 9).
	o Registered one public key encoding in the "ACE Public Key		o Registered one public key encoding in the "ACE Public Key
	Encoding" IANA Registry (Section 9).		Encoding" IANA Registry (Section 9).
	B.2. Version -00 to -01		B.3. Version -00 to -01
	o Changed name of 'req_aud' to 'audience' in the Authorization		o Changed name of 'req_aud' to 'audience' in the Authorization
	Request (Section 3.1).		Request (Section 3.1).
	o Added negotiation of countersignature algorithm/parameters between		o Added negotiation of countersignature algorithm/parameters between
	Client and Group Manager (Section 4).		Client and Group Manager (Section 4).
	o Updated format of the Key Distribution Response as a whole		o Updated format of the Key Distribution Response as a whole
	(Section 4.3).		(Section 4.3).
	o Added parameter 'cs_params' in the 'key' parameter of the Key		o Added parameter 'cs_params' in the 'key' parameter of the Key
	Distribution Response (Section 4.3).		Distribution Response (Section 4.3).
	o New IANA registrations in the "ACE Authorization Server Request		o New IANA registrations in the "ACE Authorization Server Request
	Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE		Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE
	Security Context Parameters" Registry and "ACE Groupcomm Profile"		Security Context Parameters" Registry and "ACE Groupcomm Profile"
	Registry (Section 9).		Registry (Section 9).
	Acknowledgments		Acknowledgments
	The authors sincerely thank Santiago Aragon, Stefan Beck, Martin		The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten
	Gunnarsson, Rikard Hoeglund, Jim Schaad, Ludwig Seitz, Goeran		Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim
	Selander and Peter van der Stok for their comments and feedback.		Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for
			their comments and feedback.
	The work on this document has been partly supported by VINNOVA and		The work on this document has been partly supported by VINNOVA and
	the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact		the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
	Initiative ACTIVE.		Initiative ACTIVE.
	Authors' Addresses		Authors' Addresses
	Marco Tiloca		Marco Tiloca
	RISE AB		RISE AB
	Isafjordsgatan 22		Isafjordsgatan 22
	Kista SE-164 29 Stockholm		Kista SE-164 29 Stockholm
	Sweden		Sweden
	Email: marco.tiloca@ri.se		Email: marco.tiloca@ri.se
	Jiye Park		Jiye Park
	Universitaet Duisburg-Essen		Universitaet Duisburg-Essen
End of changes. 147 change blocks.
	490 lines changed or deleted		683 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/