rfc9594v5.txt		rfc9594.txt
	Internet Engineering Task Force (IETF) F. Palombini		Internet Engineering Task Force (IETF) F. Palombini
	Request for Comments: 9594 Ericsson AB		Request for Comments: 9594 Ericsson AB
	Category: Standards Track M. Tiloca		Category: Standards Track M. Tiloca
	ISSN: 2070-1721 RISE AB		ISSN: 2070-1721 RISE AB
	August 2024		September 2024
	Key Provisioning for Group Communication Using Authentication and		Key Provisioning for Group Communication Using Authentication and
	Authorization for Constrained Environments (ACE)		Authorization for Constrained Environments (ACE)
	Abstract		Abstract
	This document defines how to use the Authentication and Authorization		This document defines how to use the Authentication and Authorization
	for Constrained Environments (ACE) framework to distribute keying		for Constrained Environments (ACE) framework to distribute keying
	material and configuration parameters for secure group communication.		material and configuration parameters for secure group communication.
	Candidate group members that act as Clients and are authorized to		Candidate group members that act as Clients and are authorized to
	skipping to change at line 100 ¶		skipping to change at line 100 ¶
	4.5.1.1. Retrieve the KDC's Authentication Credential		4.5.1.1. Retrieve the KDC's Authentication Credential
	4.6. /ace-group/GROUPNAME/policies		4.6. /ace-group/GROUPNAME/policies
	4.6.1. GET Handler		4.6.1. GET Handler
	4.6.1.1. Retrieve the Group Policies		4.6.1.1. Retrieve the Group Policies
	4.7. /ace-group/GROUPNAME/num		4.7. /ace-group/GROUPNAME/num
	4.7.1. GET Handler		4.7.1. GET Handler
	4.7.1.1. Retrieve the Keying Material Version		4.7.1.1. Retrieve the Keying Material Version
	4.8. /ace-group/GROUPNAME/nodes/NODENAME		4.8. /ace-group/GROUPNAME/nodes/NODENAME
	4.8.1. GET Handler		4.8.1. GET Handler
	4.8.1.1. Retrieve Group and Individual Keying Material		4.8.1.1. Retrieve Group and Individual Keying Material
	4.8.2. PUT Handler		4.8.2. POST Handler
	4.8.2.1. Request to Change Individual Keying Material		4.8.2.1. Request to Change Individual Keying Material
	4.8.3. DELETE Handler		4.8.3. DELETE Handler
	4.8.3.1. Leave the Group		4.8.3.1. Leave the Group
	4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred		4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred
	4.9.1. POST Handler		4.9.1. POST Handler
	4.9.1.1. Uploading an Authentication Credential		4.9.1.1. Uploading an Authentication Credential
	5. Removal of a Group Member		5. Removal of a Group Member
	6. Group Rekeying Process		6. Group Rekeying Process
	6.1. Point-to-Point Group Rekeying		6.1. Point-to-Point Group Rekeying
	6.2. One-to-Many Group Rekeying		6.2. One-to-Many Group Rekeying
	skipping to change at line 335 ¶		skipping to change at line 335 ¶
	group member in question). The specific nature and format of		group member in question). The specific nature and format of
	individual keying material used in a group is defined in the		individual keying material used in a group is defined in the
	application profiles of this specification. The individual keying		application profiles of this specification. The individual keying
	material of a group member is not related to the secure		material of a group member is not related to the secure
	association between that group member and the KDC.		association between that group member and the KDC.
	Throughout this document, examples for CBOR data items are expressed		Throughout this document, examples for CBOR data items are expressed
	in CBOR extended diagnostic notation as defined in Section 8 of		in CBOR extended diagnostic notation as defined in Section 8 of
	[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless		[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless
	noted otherwise. We often use diagnostic notation comments to		noted otherwise. We often use diagnostic notation comments to
	provide a textual representation of the numeric parameter names and		provide a textual representation of the parameters' keys and values.
	values.
	2. Overview		2. Overview
	At a high level, the key provisioning process is separated in two		At a high level, the key provisioning process is separated in two
	phases: the first one follows the ACE framework between the Client,		phases: the first one follows the ACE framework between the Client,
	AS, and KDC, while the second one is the actual key distribution		AS, and KDC, while the second one is the actual key distribution
	between the Client and KDC. After the two phases are completed, the		between the Client and KDC. After the two phases are completed, the
	Client is able to participate in the group communication via a		Client is able to participate in the group communication via a
	Dispatcher entity.		Dispatcher entity.
	skipping to change at line 647 ¶		skipping to change at line 646 ¶
	scope_entries = AIF-Generic<gname, permissions>		scope_entries = AIF-Generic<gname, permissions>
	scope = bstr .cbor scope_entries		scope = bstr .cbor scope_entries
	Figure 4: Example of scope Using AIF		Figure 4: Example of scope Using AIF
	gname = tstr		gname = tstr
	role = tstr		role = tstr
	scope_entry = [ gname , ? ( role / [ 2*role ] ) ]		scope_entry = [gname, ? ( role / [2* role] )]
	scope_entries = [ * scope_entry ]		scope_entries = [* scope_entry]
	scope = bstr .cbor scope_entries		scope = bstr .cbor scope_entries
	Figure 5: Example of scope Using the Textual Format, with the		Figure 5: Example of scope Using the Textual Format, with the
	Role Identifiers Encoded as Text Strings		Role Identifiers Encoded as Text Strings
	3.2. Authorization Response		3.2. Authorization Response
	The AS processes the Authorization Request as defined in		The AS processes the Authorization Request as defined in
	Section 5.8.2 of [RFC9200], especially verifying that the Client is		Section 5.8.2 of [RFC9200], especially verifying that the Client is
	skipping to change at line 880 ¶		skipping to change at line 879 ¶
	that indicates the signature algorithm used in the groups		that indicates the signature algorithm used in the groups
	identified by the 'gname' values. It is REQUIRED for application		identified by the 'gname' values. It is REQUIRED for application
	profiles to define specific values that this parameter can take		profiles to define specific values that this parameter can take
	(REQ3), which are selected from the set of signing algorithms of		(REQ3), which are selected from the set of signing algorithms of
	the "COSE Algorithms" registry [COSE.Algorithms].		the "COSE Algorithms" registry [COSE.Algorithms].
	* The third element 'sign_parameters' is a CBOR array that indicates		* The third element 'sign_parameters' is a CBOR array that indicates
	the parameters of the signature algorithm used in the groups		the parameters of the signature algorithm used in the groups
	identified by the 'gname' values. Its content depends on the		identified by the 'gname' values. Its content depends on the
	value of 'sign_alg'. It is REQUIRED for application profiles to		value of 'sign_alg'. It is REQUIRED for application profiles to
	define the possible values and structures for the elements of this		define the possible values and structure for the elements of this
	parameter (REQ4).		parameter (REQ4).
	* The fourth element 'sign_key_parameters' is a CBOR array that		* The fourth element 'sign_key_parameters' is a CBOR array that
	indicates the parameters of the key used with the signature		indicates the parameters of the key used with the signature
	algorithm in the groups identified by the 'gname' values. Its		algorithm in the groups identified by the 'gname' values. Its
	content depends on the value of 'sign_alg'. It is REQUIRED for		content depends on the value of 'sign_alg'. It is REQUIRED for
	application profiles to define the possible values and structures		application profiles to define the possible values and structure
	for the elements of this parameter (REQ5).		for the elements of this parameter (REQ5).
	* The fifth element 'cred_fmt' is either a CBOR integer indicating		* The fifth element 'cred_fmt' either is a CBOR integer indicating
	the format of authentication credentials used in the groups		the format of authentication credentials used in the groups
	identified by the 'gname' values or has the CBOR simple value null		identified by the 'gname' values or is the CBOR simple value null
	(0xf6), which indicates that the KDC does not act as a repository		(0xf6), which indicates that the KDC does not act as a repository
	of authentication credentials for group members. Its acceptable		of authentication credentials for group members. Its acceptable
	integer values are taken from the "Label" column of the "COSE		integer values are taken from the "Label" column of the "COSE
	Header Parameters" registry [COSE.Header.Parameters], with some of		Header Parameters" registry [COSE.Header.Parameters], with some of
	those values also indicating the type of container to use for		those values also indicating the type of container to use for
	exchanging the authentication credentials with the KDC (e.g., a		exchanging the authentication credentials with the KDC (e.g., a
	chain or bag of certificates). It is REQUIRED for application		chain or bag of certificates). It is REQUIRED for application
	profiles to define specific values to use for this parameter,		profiles to define specific values to use for this parameter,
	consistently with the acceptable formats of authentication		consistently with the acceptable formats of authentication
	credentials (REQ6).		credentials (REQ6).
	The CDDL notation [RFC8610] of the 'sign_info' parameter is given		The CDDL notation [RFC8610] of the 'sign_info' parameter is given
	below.		below.
	sign_info = sign_info_req / sign_info_resp		sign_info = sign_info_req / sign_info_resp
	sign_info_req = null ; in the Token Transfer		sign_info_req = null ; in the Token Transfer
	; Request to the KDC		; Request to the KDC
	sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer		sign_info_resp = [+ sign_info_entry] ; in the Token Transfer
	; Response from the KDC		; Response from the KDC
	sign_info_entry =		sign_info_entry =
	[		[
	id : gname / [ + gname ],		id: gname / [+ gname],
	sign_alg : int / tstr,		sign_alg: int / tstr,
	sign_parameters : [ any ],		sign_parameters: [any],
	sign_key_parameters : [ + parameter : any ],		sign_key_parameters: [+ parameter: any],
	cred_fmt : int / null		cred_fmt: int / null
	]		]
	gname = tstr		gname = tstr
	This format is consistent with every signature algorithm currently		This format is consistent with every signature algorithm currently
	defined in [RFC9053], i.e., with algorithms that have only the COSE		defined in [RFC9053], i.e., with algorithms that have only the COSE
	key type as their COSE capability. Appendix B describes how the		key type as their COSE capability. Appendix B describes how the
	format of each 'sign_info_entry' can be generalized for possible		format of each 'sign_info_entry' can be generalized for possible
	future registered algorithms having a different set of COSE		future registered algorithms having a different set of COSE
	capabilities.		capabilities.
	skipping to change at line 983 ¶		skipping to change at line 982 ¶
	name; implementations are not required to use this name and can		name; implementations are not required to use this name and can
	define their own instead.		define their own instead.
	If request messages sent to the KDC as well as success response		If request messages sent to the KDC as well as success response
	messages from the KDC include a payload and specify a Content-Format,		messages from the KDC include a payload and specify a Content-Format,
	those messages MUST have Content-Format "application/ace-		those messages MUST have Content-Format "application/ace-
	groupcomm+cbor", which is registered in Section 11.2. CBOR map keys		groupcomm+cbor", which is registered in Section 11.2. CBOR map keys
	used for the message parameters are defined in Section 8.		used for the message parameters are defined in Section 8.
	* /ace-group : the path of this root resource is invariant once the		* /ace-group : the path of this root resource is invariant once the
	resource is established and indicates that this specification is		resource is established. Its employment indicates that this
	used. If other applications run on a KDC implementing this		specification is used. If other applications run on a KDC
	specification and use this same path, those applications will		implementing this specification and use this same path, those
	collide, and a mechanism will be needed to differentiate the		applications will collide, and a mechanism will be needed to
	endpoints.		differentiate the endpoints.
	A Client can access this resource in order to retrieve a set of		A Client can access this resource in order to retrieve a set of
	group names, each corresponding to one of the specified group		group names, each corresponding to one of the specified group
	identifiers. This operation is described in Section 4.2.1.1.		identifiers. This operation is described in Section 4.2.1.1.
	Clients may be authorized to access this resource even without		Clients may be authorized to access this resource even without
	being members of any group managed by the KDC and even if they are		being members of any group managed by the KDC and even if they are
	not authorized to become group members (e.g., when authorized to		not authorized to become group members (e.g., when authorized to
	be external signature verifiers).		be external signature verifiers).
	skipping to change at line 1017 ¶		skipping to change at line 1016 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "core"		Uri-Path: "core"
	Uri-Query: "if=ace.groups"		Uri-Query: "if=ace.groups"
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/link-format		Content-Format: 40 (application/link-format)
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group>;if="ace.groups"		<coap://[2001:db8::ab]/ace-group>;if="ace.groups"
	* /ace-group/GROUPNAME : one such sub-resource to /ace-group is		* /ace-group/GROUPNAME : one such sub-resource to /ace-group is
	hosted for each group with the name GROUPNAME that the KDC		hosted for each group with the name GROUPNAME that the KDC
	manages. In particular, it is the group-membership resource		manages. In particular, it is the group-membership resource
	associated with that group, and it contains the symmetric group		associated with that group, and it contains the symmetric group
	keying material of that group.		keying material of that group.
	A Client can access this resource in order to join the group with		A Client can access this resource in order to join the group with
	skipping to change at line 1052 ¶		skipping to change at line 1051 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "core"		Uri-Path: "core"
	Uri-Query: "if=ace.group"		Uri-Query: "if=ace.group"
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/link-format		Content-Format: 40 (application/link-format)
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"		<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
	If it is not required that the value of the GROUPNAME URI path and		If it is not required that the value of the GROUPNAME URI path and
	the group name in the access token scope ('gname' in Section 3.1)		the group name in the access token scope ('gname' in Section 3.1)
	coincide, the KDC MUST implement a mechanism to map the GROUPNAME		coincide, the KDC MUST implement a mechanism to map the GROUPNAME
	value in the URI to the group name in order to refer to the		value in the URI to the group name in order to refer to the
	correct group (REQ7).		correct group (REQ7).
	* /ace-group/GROUPNAME/creds : the path of this resource is		* /ace-group/GROUPNAME/creds : the path of this resource is
	skipping to change at line 1213 ¶		skipping to change at line 1212 ¶
	credential and this is required for the correct group operation.		credential and this is required for the correct group operation.
	* GET request to /ace-group/GROUPNAME/policies in order to retrieve		* GET request to /ace-group/GROUPNAME/policies in order to retrieve
	the current group policies as a group member.		the current group policies as a group member.
	* GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to		* GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to
	retrieve the current group keying material and individual keying		retrieve the current group keying material and individual keying
	material. The former can also be retrieved through a GET request		material. The former can also be retrieved through a GET request
	to /ace-group/GROUPNAME/ (see above).		to /ace-group/GROUPNAME/ (see above).
	* PUT request to /ace-group/GROUPNAME/nodes/NODENAME in order to ask		* POST request to /ace-group/GROUPNAME/nodes/NODENAME in order to
	for new individual keying material. Alternatively, the Client		ask for new individual keying material. Alternatively, the Client
	could obtain new individual keying material by rejoining the group		could obtain new individual keying material by rejoining the group
	through a POST request to /ace-group/GROUPNAME/ (see above).		through a POST request to /ace-group/GROUPNAME/ (see above).
	Furthermore, depending on its roles in the group or on the		Furthermore, depending on its roles in the group or on the
	application profile of this specification, the Client might simply		application profile of this specification, the Client might simply
	not be associated with any individual keying material.		not be associated with any individual keying material.
	* POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order		* POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order
	to provide the KDC with a new authentication credential.		to provide the KDC with a new authentication credential.
	Alternatively, the Client could provide a new authentication		Alternatively, the Client could provide a new authentication
	credential by rejoining the group through a POST request to /ace-		credential by rejoining the group through a POST request to /ace-
	skipping to change at line 1308 ¶		skipping to change at line 1307 ¶
	occurred at the KDC. The diagnostic text is intended for software		occurred at the KDC. The diagnostic text is intended for software
	engineers as well as for device and network operators in order to		engineers as well as for device and network operators in order to
	aid debugging and provide context for possible intervention. The		aid debugging and provide context for possible intervention. The
	diagnostic message SHOULD be logged by the KDC. The 'detail'		diagnostic message SHOULD be logged by the KDC. The 'detail'
	entry is unlikely relevant in an unattended setup where human		entry is unlikely relevant in an unattended setup where human
	intervention is not expected.		intervention is not expected.
	An example of an error response using the problem-details format is		An example of an error response using the problem-details format is
	shown in Figure 6.		shown in Figure 6.
	Response:		Response:
	Header: Service Unavailable (Code=5.03)		Header: Service Unavailable (Code=5.03)
	Content-Format: application/concise-problem-details+cbor		Content-Format: 257 (application/concise-problem-details+cbor)
	Payload:		Payload:
	{		{
	/ title / -1: "No available node identifiers",		/ title / -1: "No available individual keying material",
	/ detail / -2: "Things will change after a		/ detail / -2: "Things will change after a
	group rekeying; try later",		group rekeying; try later",
	/ ace-groupcomm-error / 0: {		/ ace-groupcomm-error / 0: {
	/ error-id / 0: 4 / "No available node identifiers" /		/ error-id / 0: 4 / "No available individual keying material" /
	}		}
	}		}
	Figure 6: Example of an Error Response with Problem Details		Figure 6: Example of an Error Response with Problem Details
	The problem-details format (in general) and the Custom Problem Detail		The problem-details format (in general) and the Custom Problem Detail
	entry 'ace-groupcomm-error' (in particular) are OPTIONAL for Clients		entry 'ace-groupcomm-error' (in particular) are OPTIONAL for Clients
	to support. A Client supporting the entry 'ace-groupcomm-error' and		to support. A Client supporting the entry 'ace-groupcomm-error' and
	that can understand the specified error may use that information to		that can understand the specified error may use that information to
	determine what actions to take next.		determine what actions to take next.
	Section 9 of this specification defines an initial set of error		Section 9 of this specification defines an initial set of error
	identifiers as possible values for the 'error-id' field. Application		identifiers as possible values for the 'error-id' field. Application
	profiles of this specification inherit this initial set of error		profiles of this specification inherit this initial set of error
	skipping to change at line 1414 ¶		skipping to change at line 1413 ¶
	| |		| |
	Figure 7: Message Flow of Group Name and URI Retrieval Request-		Figure 7: Message Flow of Group Name and URI Retrieval Request-
	Response		Response
	Request:		Request:
	Header: FETCH (Code=0.05)		Header: FETCH (Code=0.05)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ gid / 0: [1, 2]		/ gid / 0: [1, 2]
	}		}
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ gid / 0: [1, 2],		/ gid / 0: [1, 2],
	/ gname / 1: ["group1", "group2"],		/ gname / 1: ["group1", "group2"],
	/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]		/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]
	}		}
	Figure 8: Example of Group Name and URI Retrieval Request-Response		Figure 8: Example of Group Name and URI Retrieval Request-Response
	4.3. /ace-group/GROUPNAME		4.3. /ace-group/GROUPNAME
	skipping to change at line 1534 ¶		skipping to change at line 1533 ¶
	Note that, for this handler, 'inclusion_flag' is always set to		Note that, for this handler, 'inclusion_flag' is always set to
	true and the array of roles 'role_filter' is always non-empty,		true and the array of roles 'role_filter' is always non-empty,
	while the array of node identifiers 'id_filter' is always empty.		while the array of node identifiers 'id_filter' is always empty.
	However, this is not necessarily the case for other handlers using		However, this is not necessarily the case for other handlers using
	the 'get_creds' parameter.		the 'get_creds' parameter.
	inclusion_flag = bool		inclusion_flag = bool
	role = tstr		role = tstr
	comb_role = [ 2*role ]		comb_role = [2* role]
	role_filter = [ *(role / comb_role) ]		role_filter = [* ( role / comb_role )]
	id = bstr		id = bstr
	id_filter = [ *id ]		id_filter = [* id]
	get_creds = null / [ inclusion_flag, role_filter, id_filter ]		get_creds = null / [inclusion_flag, role_filter, id_filter]
	Figure 9: CDDL Definition of 'get_creds', Using an Example		Figure 9: CDDL Definition of 'get_creds', Using an Example
	Node Identifier Encoded as bstr and Role as tstr		Node Identifier Encoded as bstr and Role as tstr
	* 'client_cred': encoded as a CBOR byte string, whose value is the		* 'client_cred': encoded as a CBOR byte string, whose value is the
	original binary representation of the Client's authentication		original binary representation of the Client's authentication
	credential. This parameter MUST be present if the KDC is managing		credential. This parameter MUST be present if the KDC is managing
	(collecting from and distributing to Clients) the authentication		(collecting from and distributing to Clients) the authentication
	credentials of the group members and the Client's role in the		credentials of the group members and the Client's role in the
	group will require the Client to send messages to one or more		group will require the Client to send messages to one or more
	skipping to change at line 1958 ¶		skipping to change at line 1957 ¶
	* 'group_policies': its value is encoded as a CBOR map, whose		* 'group_policies': its value is encoded as a CBOR map, whose
	elements specify how the group handles specific management		elements specify how the group handles specific management
	aspects. These include, for instance, approaches to achieve		aspects. These include, for instance, approaches to achieve
	synchronization of sequence numbers among group members. The		synchronization of sequence numbers among group members. The
	possible elements of the CBOR map are registered in the "ACE		possible elements of the CBOR map are registered in the "ACE
	Groupcomm Policies" registry defined in Section 11.10 of this		Groupcomm Policies" registry defined in Section 11.10 of this
	specification. This specification defines the three elements		specification. This specification defines the three elements
	"Sequence Number Synchronization Methods", "Key Update Check		"Sequence Number Synchronization Methods", "Key Update Check
	Interval", and "Expiration Delta", which are summarized in		Interval", and "Expiration Delta", which are summarized in
	Table 3. Application profiles of this specification MUST specify		Table 3. Application profiles of this specification MUST specify
	the format, content, and default values for the entries of the		the format and default values for the entries of the CBOR map
	CBOR map conveyed in the 'group_policies' parameter (REQ20).		conveyed in the 'group_policies' parameter (REQ20).
	+=================+=======+======+===================+===========+		+=================+=======+======+===================+===========+
	| Name | CBOR | CBOR | Description | Reference |		| Name | CBOR | CBOR | Description | Reference |
	| | Label | Type | | |		| | Label | Type | | |
	+=================+=======+======+===================+===========+		+=================+=======+======+===================+===========+
	| Sequence Number | 0 | int | Method for | RFC 9594 |		| Sequence Number | 0 | int | Method for | RFC 9594 |
	| Synchronization | | or | recipient group | |		| Synchronization | | or | recipient group | |
	| Method | | tstr | members to | |		| Method | | tstr | members to | |
	| | | | synchronize with | |		| | | | synchronize with | |
	| | | | sequence numbers | |		| | | | sequence numbers | |
	skipping to change at line 2194 ¶		skipping to change at line 2193 ¶
	| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |		| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
	Figure 12: Message Flow of the Join Request-Response		Figure 12: Message Flow of the Join Request-Response
	Request:		Request:
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ scope / 3: <<["group1", ["sender", "receiver"]]>>,		/ scope / 3: <<["group1", ["sender", "receiver"]]>>,
	/ get_creds / 4: [true, ["sender"], []],		/ get_creds / 4: [true, ["sender"], []],
	/ client_cred / 5: h'a2026008a101a5010202410a20012158		/ client_cred / 5: h'a2026008a101a5010202410a20012158
	20bbc34960526ea4d32e940cad2a2341		20bbc34960526ea4d32e940cad2a2341
	48ddc21791a12afbcbac93622046dd44		48ddc21791a12afbcbac93622046dd44
	f02258204519e257236b2a0ce2023f09		f02258204519e257236b2a0ce2023f09
	31f1f386ca7afda64fcde0108c224c51		31f1f386ca7afda64fcde0108c224c51
	eabf6072',		eabf6072',
	/ cnonce / 6: h'25a8991cd700ac01',		/ cnonce / 6: h'25a8991cd700ac01',
	/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117		/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117
	26caed57f530f8cae9d0b168513ab949		26caed57f530f8cae9d0b168513ab949
	fedc3e80a96ebe94ba08d3f8d3bf8348		fedc3e80a96ebe94ba08d3f8d3bf8348
	7458e2ab4c2f936ff78b50e33c885e35'		7458e2ab4c2f936ff78b50e33c885e35'
	}		}
	Response:		Response:
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Location-Path: "ace-group"		Location-Path: "ace-group"
	Location-Path: "g1"		Location-Path: "g1"
	Location-Path: "nodes"		Location-Path: "nodes"
	Location-Path: "c101"		Location-Path: "c101"
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ gkty / 7: 65600,		/ gkty / 7: 65600,
	/ key / 8: h'73657373696f6e6b6579',		/ key / 8: h'73657373696f6e6b6579',
	/ num / 9: 12,		/ num / 9: 12,
	/ exp / 11: 1924992000,		/ exp / 11: 1924992000,
	skipping to change at line 2352 ¶		skipping to change at line 2351 ¶
	| |		| |
	Figure 14: Message Flow of Key Distribution Request-Response		Figure 14: Message Flow of Key Distribution Request-Response
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ gkty / 7: 65600,		/ gkty / 7: 65600,
	/ key / 8: h'73657373696f6e6b6579',		/ key / 8: h'73657373696f6e6b6579',
	/ num / 9: 12		/ num / 9: 12
	}		}
	Figure 15: Example of Key Distribution Request-Response		Figure 15: Example of Key Distribution Request-Response
	4.4. /ace-group/GROUPNAME/creds		4.4. /ace-group/GROUPNAME/creds
	skipping to change at line 2497 ¶		skipping to change at line 2495 ¶
	on the group messages may be allowed to access this resource if the		on the group messages may be allowed to access this resource if the
	application needs it.		application needs it.
	4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group		4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group
	In case the KDC maintains the authentication credentials of group		In case the KDC maintains the authentication credentials of group
	members, a node in the group can contact the KDC to request the		members, a node in the group can contact the KDC to request the
	authentication credentials, roles, and node identifiers of a		authentication credentials, roles, and node identifiers of a
	specified subset of group members by sending a CoAP FETCH request to		specified subset of group members by sending a CoAP FETCH request to
	the /ace-group/GROUPNAME/creds endpoint at the KDC, which is		the /ace-group/GROUPNAME/creds endpoint at the KDC, which is
	formatted as defined in Section 4.4.1 and with the group identified		formatted as defined in Section 4.4.1 and where GROUPNAME identifies
	by GROUPNAME.		the group.
	Figure 16 gives an overview of the exchange mentioned above, while		Figure 16 gives an overview of the exchange mentioned above, while
	Figure 17 shows an example of such an exchange.		Figure 17 shows an example of such an exchange.
	Client KDC		Client KDC
	| |		| |
	| Authentication Credential Request: |		| Authentication Credential Request: |
	|-------------------------------------------------------->|		|-------------------------------------------------------->|
	| FETCH /ace-group/GROUPNAME/creds |		| FETCH /ace-group/GROUPNAME/creds |
	| |		| |
	|<-- Authentication Credential Response: 2.05 (Created) --|		|<-- Authentication Credential Response: 2.05 (Content) --|
	| |		| |
	Figure 16: Message Flow of Authentication Credential Request-		Figure 16: Message Flow of Authentication Credential Request-
	Response to Obtain the Authentication Credentials of Specific		Response to Obtain the Authentication Credentials of Specific
	Group Members		Group Members
	Request:		Request:
	Header: FETCH (Code=0.05)		Header: FETCH (Code=0.05)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "creds"		Uri-Path: "creds"
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ get_creds / 4: [true, [], [h'02', h'03']]		/ get_creds / 4: [true, [], [h'02', h'03']]
	}		}
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ creds / 13: [h'a2026008a101a5010202410320012158		/ creds / 13: [h'a2026008a101a5010202410320012158
	20ac75e9ece3e50bfc8ed60399889522		20ac75e9ece3e50bfc8ed60399889522
	405c47bf16df96660a41298cb4307f7e		405c47bf16df96660a41298cb4307f7e
	b62258206e5de611388a4b8a8211334a		b62258206e5de611388a4b8a8211334a
	c7d37ecb52a387d257e6db3c2a93df21		c7d37ecb52a387d257e6db3c2a93df21
	ff3affc8',		ff3affc8',
	h'a2026008a101a5010202410920012158		h'a2026008a101a5010202410920012158
	206f9702a66602d78f5e81bac1e0af01		206f9702a66602d78f5e81bac1e0af01
	skipping to change at line 2600 ¶		skipping to change at line 2598 ¶
	Response to Obtain the Authentication Credentials of All the		Response to Obtain the Authentication Credentials of All the
	Group Members		Group Members
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "creds"		Uri-Path: "creds"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ num / 9: 12,		/ num / 9: 12,
	/ creds / 13: [h'a2026008a101a5010202410220012158		/ creds / 13: [h'a2026008a101a5010202410220012158
	20cd4177ba62433375ede279b5e18e8b		20cd4177ba62433375ede279b5e18e8b
	91bc3ed8f1e174474a26fc0edb44ea53		91bc3ed8f1e174474a26fc0edb44ea53
	73225820a0391de29c5c5badda610d4e		73225820a0391de29c5c5badda610d4e
	301eaaa18422367722289cd18cbe6624		301eaaa18422367722289cd18cbe6624
	e89b9cfd',		e89b9cfd',
	h'a2026008a101a5010202410320012158		h'a2026008a101a5010202410320012158
	skipping to change at line 2750 ¶		skipping to change at line 2747 ¶
	Figure 21: Message Flow of KDC Authentication Credential Request-		Figure 21: Message Flow of KDC Authentication Credential Request-
	Response to Obtain the Authentication Credential of the KDC		Response to Obtain the Authentication Credential of the KDC
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "kdc-cred"		Uri-Path: "kdc-cred"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ kdc_cred / 17: h'a2026008a101a5010202419920012158		/ kdc_cred / 17: h'a2026008a101a5010202419920012158
	2065eda5a12577c2bae829437fe33870		2065eda5a12577c2bae829437fe33870
	1a10aaa375e1bb5b5de108de439c0855		1a10aaa375e1bb5b5de108de439c0855
	1d2258201e52ed75701163f7f9e40ddf		1d2258201e52ed75701163f7f9e40ddf
	9f341b3dc9ba860af7e0ca7ca7e9eecd		9f341b3dc9ba860af7e0ca7ca7e9eecd
	0084d19c',		0084d19c',
	/ kdc_nonce / 18: h'0b7db12aaff56da3',		/ kdc_nonce / 18: h'0b7db12aaff56da3',
	/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a		/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a
	skipping to change at line 2807 ¶		skipping to change at line 2803 ¶
	byte string of zero length (0x40).		byte string of zero length (0x40).
	The specific format and meaning of group policies MUST be specified		The specific format and meaning of group policies MUST be specified
	in application profiles of this specification (REQ20).		in application profiles of this specification (REQ20).
	4.6.1.1. Retrieve the Group Policies		4.6.1.1. Retrieve the Group Policies
	A node in the group can contact the KDC to retrieve the current group		A node in the group can contact the KDC to retrieve the current group
	policies by sending a CoAP GET request to the /ace-group/GROUPNAME/		policies by sending a CoAP GET request to the /ace-group/GROUPNAME/
	policies endpoint at the KDC, which is formatted as defined in		policies endpoint at the KDC, which is formatted as defined in
	Section 4.6.1 and with the group identified by GROUPNAME.		Section 4.6.1 and where GROUPNAME identifies the group.
	Figure 23 gives an overview of the exchange described above, while		Figure 23 gives an overview of the exchange described above, while
	Figure 24 shows an example.		Figure 24 shows an example.
	Client KDC		Client KDC
	| |		| |
	|-- Policies Request: GET /ace-group/GROUPNAME/policies -->|		|-- Policies Request: GET /ace-group/GROUPNAME/policies -->|
	| |		| |
	|<----------- Policies Response: 2.05 (Content) -----------|		|<----------- Policies Response: 2.05 (Content) -----------|
	| |		| |
	Figure 23: Message Flow of Policies Request-Response		Figure 23: Message Flow of Policies Request-Response
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "policies"		Uri-Path: "policies"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload(in CBOR diagnostic notation):		Payload(in CBOR diagnostic notation):
	{		{
	/ group_policies / 16: {		/ group_policies / 16: {
	/ Expiration Delta / 2: 120		/ Expiration Delta / 2: 120
	}		}
	}		}
	Figure 24: Example of Policies Request-Response		Figure 24: Example of Policies Request-Response
	4.7. /ace-group/GROUPNAME/num		4.7. /ace-group/GROUPNAME/num
	skipping to change at line 2874 ¶		skipping to change at line 2869 ¶
	material before the new keying material is distributed. This number		material before the new keying material is distributed. This number
	is stored in persistent storage.		is stored in persistent storage.
	The payload of the response is formatted as a CBOR integer.		The payload of the response is formatted as a CBOR integer.
	4.7.1.1. Retrieve the Keying Material Version		4.7.1.1. Retrieve the Keying Material Version
	A node in the group can contact the KDC to request information about		A node in the group can contact the KDC to request information about
	the version number of the symmetric group keying material by sending		the version number of the symmetric group keying material by sending
	a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the		a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the
	KDC, which is formatted as defined in Section 4.7.1 and with the		KDC, which is formatted as defined in Section 4.7.1 and where
	group identified by GROUPNAME. In particular, the version is		GROUPNAME identifies the group. In particular, the version is
	incremented by the KDC every time the group keying material is		incremented by the KDC every time the group keying material is
	renewed before it is distributed to the group members.		renewed before it is distributed to the group members.
	Figure 25 gives an overview of the exchange described above, while		Figure 25 gives an overview of the exchange described above, while
	Figure 26 shows an example.		Figure 26 shows an example.
	Client KDC		Client KDC
	| |		| |
	|---- Version Request: GET /ace-group/GROUPNAME/num ---->|		|---- Version Request: GET /ace-group/GROUPNAME/num ---->|
	| |		| |
	skipping to change at line 2898 ¶		skipping to change at line 2893 ¶
	Figure 25: Message Flow of Version Request-Response		Figure 25: Message Flow of Version Request-Response
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "num"		Uri-Path: "num"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
			Content-Format: 60 (application/cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	13		13
	Figure 26: Example of Version Request-Response		Figure 26: Example of Version Request-Response
	4.8. /ace-group/GROUPNAME/nodes/NODENAME		4.8. /ace-group/GROUPNAME/nodes/NODENAME
	This resource implements the GET, PUT, and DELETE handlers.		This resource implements the GET, POST, and DELETE handlers.
	In addition to what is defined in Section 4.1.2, each of the handlers		In addition to what is defined in Section 4.1.2, each of the handlers
	performs the following two verifications.		performs the following two verifications.
	* The handler verifies that the Client is a current member of the		* The handler verifies that the Client is a current member of the
	group. If the verification fails, the KDC MUST reply with a 4.03		group. If the verification fails, the KDC MUST reply with a 4.03
	(Forbidden) error response. The response MUST have Content-Format		(Forbidden) error response. The response MUST have Content-Format
	"application/concise-problem-details+cbor" and is formatted as		"application/concise-problem-details+cbor" and is formatted as
	defined in Section 4.1.2. Within the Custom Problem Detail entry		defined in Section 4.1.2. Within the Custom Problem Detail entry
	'ace-groupcomm-error', the value of the 'error-id' field MUST be		'ace-groupcomm-error', the value of the 'error-id' field MUST be
	skipping to change at line 3052 ¶		skipping to change at line 3047 ¶
	Figure 27: Message Flow of Key Distribution Request-Response		Figure 27: Message Flow of Key Distribution Request-Response
	Request:		Request:
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Payload: -
	Response:		Response:
	Header: Content (Code=2.05)		Header: Content (Code=2.05)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation, with "ind-key" being the		Payload (in CBOR diagnostic notation, with "ind-key" being the
	profile-specified label for individual keying material):		profile-specified label for individual keying material):
	{		{
	/ gkty / 7: 65600,		/ gkty / 7: 65600,
	/ key / 8: h'73657373696f6e6b6579',		/ key / 8: h'73657373696f6e6b6579',
	/ num / 9: 12,		/ num / 9: 12,
	"ind-key": h'fcae9023'		"ind-key": h'fcae9023'
	}		}
	Figure 28: Example of Key Distribution Request-Response		Figure 28: Example of Key Distribution Request-Response
	4.8.2. PUT Handler		4.8.2. POST Handler
	The PUT handler processes requests from a Client that asks for new		The POST handler processes requests from a Client that asks for new
	individual keying material, as required to process messages exchanged		individual keying material, as required to process messages exchanged
	in the group.		in the group.
	The handler expects a PUT request with an empty payload.		The handler expects a POST request with an empty payload.
	In addition to what is defined in Section 4.1.2 and at the beginning		In addition to what is defined in Section 4.1.2 and at the beginning
	of Section 4.8, the handler verifies that this operation is		of Section 4.8, the handler verifies that this operation is
	consistent with the set of roles that the Client has in the group		consistent with the set of roles that the Client has in the group
	(REQ11). If the verification fails, the KDC MUST reply with a 4.00		(REQ11). If the verification fails, the KDC MUST reply with a 4.00
	(Bad Request) error response. The response MUST have Content-Format		(Bad Request) error response. The response MUST have Content-Format
	"application/concise-problem-details+cbor" and is formatted as		"application/concise-problem-details+cbor" and is formatted as
	defined in Section 4.1.2. Within the Custom Problem Detail entry		defined in Section 4.1.2. Within the Custom Problem Detail entry
	'ace-groupcomm-error', the value of the 'error-id' field MUST be set		'ace-groupcomm-error', the value of the 'error-id' field MUST be set
	to 1 ("Request inconsistent with the current roles").		to 1 ("Request inconsistent with the current roles").
	If the KDC is currently not able to serve this request, i.e., to		If the KDC is currently not able to serve this request, i.e., to
	generate new individual keying material for the requesting Client,		generate new individual keying material for the requesting Client,
	the KDC MUST reply with a 5.03 (Service unavailable) error response.		the KDC MUST reply with a 5.03 (Service unavailable) error response.
	The response MUST have Content-Format "application/concise-problem-		The response MUST have Content-Format "application/concise-problem-
	details+cbor" and is formatted as defined in Section 4.1.2. Within		details+cbor" and is formatted as defined in Section 4.1.2. Within
	the Custom Problem Detail entry 'ace-groupcomm-error', the value of		the Custom Problem Detail entry 'ace-groupcomm-error', the value of
	the 'error-id' field MUST be set to 4 ("No available node		the 'error-id' field MUST be set to 4 ("No available individual
	identifiers").		keying material").
	If all verifications succeed, the handler replies with a 2.04		If all verifications succeed, the handler replies with a 2.04
	(Changed) response containing newly generated individual keying		(Changed) response containing newly generated individual keying
	material for the Client. The payload of the response is formatted as		material for the Client. The payload of the response is formatted as
	a CBOR map. The specific format of newly generated individual keying		a CBOR map. The specific format of newly generated individual keying
	material for group members or of the information to derive such		material for group members or of the information to derive such
	keying material MUST be defined in application profiles of this		keying material MUST be defined in application profiles of this
	specification (REQ27), together with the corresponding CBOR map key		specification (REQ27), together with the corresponding CBOR map key
	that has to be registered in the "ACE Groupcomm Parameters" registry		that has to be registered in the "ACE Groupcomm Parameters" registry
	defined in Section 11.7.		defined in Section 11.7.
	skipping to change at line 3142 ¶		skipping to change at line 3136 ¶
	A Client may ask the KDC for new individual keying material. For		A Client may ask the KDC for new individual keying material. For
	instance, this can be due to the expiration of such individual keying		instance, this can be due to the expiration of such individual keying
	material or to the exhaustion of Authenticated Encryption with		material or to the exhaustion of Authenticated Encryption with
	Associated Data (AEAD) nonces if an AEAD encryption algorithm is used		Associated Data (AEAD) nonces if an AEAD encryption algorithm is used
	for protecting communications in the group. An example of individual		for protecting communications in the group. An example of individual
	keying material can simply be an individual encryption key associated		keying material can simply be an individual encryption key associated
	with the Client. Hence, the Client may ask for a new individual		with the Client. Hence, the Client may ask for a new individual
	encryption key or for new input material to derive it.		encryption key or for new input material to derive it.
	To this end, the Client performs a Key Renewal Request-Response		To this end, the Client performs a Key Renewal Request-Response
	exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-		exchange with the KDC, i.e., it sends a CoAP POST request to the
	group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is		/ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is
	formatted as defined in Section 4.8.1 and with the group identified		formatted as defined in Section 4.8.1, where GROUPNAME identifies the
	by GROUPNAME.		group and NODENAME is the node name of the Client.
	Figure 29 gives an overview of the exchange described above, while		Figure 29 gives an overview of the exchange described above, while
	Figure 30 shows an example.		Figure 30 shows an example.
	Client KDC		Client KDC
	| |		| |
	|---------------- Key Renewal Request: ---------------->|		|---------------- Key Renewal Request: ---------------->|
	| PUT /ace-group/GROUPNAME/nodes/NODENAME |		| POST /ace-group/GROUPNAME/nodes/NODENAME |
	| |		| |
	|<-------- Key Renewal Response: 2.04 (Changed) --------|		|<-------- Key Renewal Response: 2.04 (Changed) --------|
	| |		| |
	Figure 29: Message Flow of Key Renewal Request-Response		Figure 29: Message Flow of Key Renewal Request-Response
	Request:		Request:
	Header: PUT (Code=0.03)		Header: POST (Code=0.02)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Payload: -
	Response:		Response:
	Header: Changed (Code=2.04)		Header: Changed (Code=2.04)
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation, with "ind-key" being the		Payload (in CBOR diagnostic notation, with "ind-key" being the
	profile-specified label for individual keying material):		profile-specified label for individual keying material):
	{		{
	"ind-key": h'b71acc28'		"ind-key": h'b71acc28'
	}		}
	Figure 30: Example of Key Renewal Request-Response		Figure 30: Example of Key Renewal Request-Response
	Note that there is a difference between the Key Renewal Request in		Note that there is a difference between the Key Renewal Request in
	this section and the Key Distribution Request in Section 4.8.1.1.		this section and the Key Distribution Request in Section 4.8.1.1.
	skipping to change at line 3378 ¶		skipping to change at line 3371 ¶
	Request:		Request:
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "kdc.example.com"		Uri-Host: "kdc.example.com"
	Uri-Path: "ace-group"		Uri-Path: "ace-group"
	Uri-Path: "g1"		Uri-Path: "g1"
	Uri-Path: "nodes"		Uri-Path: "nodes"
	Uri-Path: "c101"		Uri-Path: "c101"
	Uri-Path: "cred"		Uri-Path: "cred"
	Content-Format: application/ace-groupcomm+cbor		Content-Format: 261 (application/ace-groupcomm+cbor)
	Payload (in CBOR diagnostic notation):		Payload (in CBOR diagnostic notation):
	{		{
	/ client_cred / 5: h'a2026008a101a501020241fc20012158		/ client_cred / 5: h'a2026008a101a501020241fc20012158
	20bac5b11cad8f99f9c72b05cf4b9e26		20bac5b11cad8f99f9c72b05cf4b9e26
	d244dc189f745228255a219a86d6a09e		d244dc189f745228255a219a86d6a09e
	ff22582020138bf82dc1b6d562be0fa5		ff22582020138bf82dc1b6d562be0fa5
	4ab7804a3a64b6d72ccfed6b6fb6ed28		4ab7804a3a64b6d72ccfed6b6fb6ed28
	bbfc117e',		bbfc117e',
	/ cnonce / 6: h'0446baefc56111bf',		/ cnonce / 6: h'0446baefc56111bf',
	/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4		/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4
	e408282cbefb5d06cbf414af2e19d982		e408282cbefb5d06cbf414af2e19d982
	ac45ac98b8544c908b4507de1e90b717		ac45ac98b8544c908b4507de1e90b717
	c3d34816fe926a2b98f53afd2fa0f30a'		c3d34816fe926a2b98f53afd2fa0f30a'
	}		}
	Response:		Response:
	Header: Changed (Code=2.04)		Header: Changed (Code=2.04)
	Payload: -
	Figure 33: Example of Authentication Credential Update Request-		Figure 33: Example of Authentication Credential Update Request-
	Response		Response
	Additionally, after updating its own authentication credential, a		Additionally, after updating its own authentication credential, a
	group member MAY send to the group a number of requests, including an		group member MAY send to the group a number of requests, including an
	identifier of the updated authentication credential, to notify other		identifier of the updated authentication credential, to notify other
	group members that they have to retrieve it. How this is done		group members that they have to retrieve it. How this is done
	depends on the group communication protocol used and therefore is		depends on the group communication protocol used and therefore is
	application profile specific (OPT13).		application profile specific (OPT13).
	skipping to change at line 3875 ¶		skipping to change at line 3867 ¶
	* A Base IV is also included with the same size of the AEAD nonce		* A Base IV is also included with the same size of the AEAD nonce
	considered by the encryption algorithm to use.		considered by the encryption algorithm to use.
	First, the KDC computes a COSE_Encrypt0 object as follows.		First, the KDC computes a COSE_Encrypt0 object as follows.
	* The encryption key to use is selected from the administrative		* The encryption key to use is selected from the administrative
	keying material, as defined by the rekeying scheme used in the		keying material, as defined by the rekeying scheme used in the
	group.		group.
	* The plaintext is the actual data content of the present rekeying		* The plaintext is the actual data content of the current rekeying
	message.		message.
	* The Additional Authenticated Data (AAD) is empty unless otherwise		* The Additional Authenticated Data (AAD) is empty unless otherwise
	specified by separate documents profiling the use of the group		specified by separate documents profiling the use of the group
	rekeying scheme.		rekeying scheme.
	* Since the KDC is the only sender of rekeying messages, the AEAD		* Since the KDC is the only sender of rekeying messages, the AEAD
	nonce can be computed as follows, where NONCE_SIZE is the size in		nonce can be computed as follows, where NONCE_SIZE is the size in
	bytes of the AEAD nonce. Separate documents profiling the use of		bytes of the AEAD nonce. Separate documents profiling the use of
	the group rekeying scheme may define alternative ways to compute		the group rekeying scheme may define alternative ways to compute
	skipping to change at line 3916 ¶		skipping to change at line 3908 ¶
	encryption key, AEAD nonce). For example, this includes not using		encryption key, AEAD nonce). For example, this includes not using
	the same encryption key from the administrative keying material		the same encryption key from the administrative keying material
	more than 2^16 times during the same rekeying instance.		more than 2^16 times during the same rekeying instance.
	* The protected header of the COSE_Encrypt0 object MUST include the		* The protected header of the COSE_Encrypt0 object MUST include the
	following parameters.		following parameters.
	- 'alg': specifying the used encryption algorithm.		- 'alg': specifying the used encryption algorithm.
	- 'kid': specifying the identifier of the encryption key from the		- 'kid': specifying the identifier of the encryption key from the
	administrative keying material used to protect the present		administrative keying material used to protect the current
	rekeying message.		rekeying message.
	* The unprotected header of the COSE_Encrypt0 object MUST include		* The unprotected header of the COSE_Encrypt0 object MUST include
	the 'Partial IV' parameter with the value of the Partial IV		the 'Partial IV' parameter with the value of the Partial IV
	computed above.		computed above.
	In order to ensure source authentication, each rekeying message		In order to ensure source authentication, each rekeying message
	protected with the administrative keying material MUST be signed by		protected with the administrative keying material MUST be signed by
	the KDC. To this end, the KDC computes a countersignature of the		the KDC. To this end, the KDC computes a countersignature of the
	COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of		COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of
	skipping to change at line 4314 ¶		skipping to change at line 4306 ¶
	+=======+=============================================+		+=======+=============================================+
	| 0 | Operation permitted only to group members |		| 0 | Operation permitted only to group members |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 1 | Request inconsistent with the current roles |		| 1 | Request inconsistent with the current roles |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 2 | Authentication credential incompatible with |		| 2 | Authentication credential incompatible with |
	| | the group configuration |		| | the group configuration |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 3 | Invalid proof-of-possession evidence |		| 3 | Invalid proof-of-possession evidence |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 4 | No available node identifiers |		| 4 | No available individual keying material |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 5 | Group membership terminated |		| 5 | Group membership terminated |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	| 6 | Group deleted |		| 6 | Group deleted |
	+-------+---------------------------------------------+		+-------+---------------------------------------------+
	Table 6: ACE Groupcomm Error Identifiers		Table 6: ACE Groupcomm Error Identifiers
	If a Client supports the problem-details format [RFC9290] and the		If a Client supports the problem-details format [RFC9290] and the
	Custom Problem Detail entry 'ace-groupcomm-error' defined in		Custom Problem Detail entry 'ace-groupcomm-error' defined in
	skipping to change at line 5210 ¶		skipping to change at line 5202 ¶
	REQ1: Specify the format and encoding of scope. This includes		REQ1: Specify the format and encoding of scope. This includes
	defining the set of possible roles and their identifiers, as		defining the set of possible roles and their identifiers, as
	well as the corresponding encoding to use in the scope		well as the corresponding encoding to use in the scope
	entries according to the used scope format (see Section 3.1).		entries according to the used scope format (see Section 3.1).
	REQ2: If scope uses AIF, register its specific instance of "Toid"		REQ2: If scope uses AIF, register its specific instance of "Toid"
	and "Tperm" as media type parameters and a corresponding		and "Tperm" as media type parameters and a corresponding
	Content-Format, as per the guidelines in [RFC9237].		Content-Format, as per the guidelines in [RFC9237].
	REQ3: If used, specify the acceptable values for the 'sign_alg'		REQ3: If used, specify the acceptable values for the 'sign_alg'
	parameter (see Section 3.3).		parameter (see Section 3.3.1).
	REQ4: If used, specify the acceptable values and structures for the		REQ4: If used, specify the acceptable values and structure for the
	'sign_parameters' parameter (see Section 3.3).		'sign_parameters' parameter (see Section 3.3.1).
	REQ5: If used, specify the acceptable values and structures for the		REQ5: If used, specify the acceptable values and structure for the
	'sign_key_parameters' parameter (see Section 3.3).		'sign_key_parameters' parameter (see Section 3.3.1).
	REQ6: Specify the acceptable formats for authentication credentials		REQ6: Specify the acceptable formats for authentication credentials
	and, if applicable, the acceptable values for the 'cred_fmt'		and, if applicable, the acceptable values for the 'cred_fmt'
	parameter (see Section 3.3).		parameter (see Section 3.3.1).
	REQ7: If the value of the GROUPNAME URI path and the group name in		REQ7: If the value of the GROUPNAME URI path and the group name in
	the access token scope ('gname' in Section 3.1) are not		the access token scope ('gname' in Section 3.1) are not
	required to coincide, specify the mechanism to map the		required to coincide, specify the mechanism to map the
	GROUPNAME value in the URI to the group name (see		GROUPNAME value in the URI to the group name (see
	Section 4.1).		Section 4.1).
	REQ8: Define whether the KDC has an authentication credential as		REQ8: Define whether the KDC has an authentication credential as
	required for the correct group operation and if this has to		required for the correct group operation and if this has to
	be provided through the 'kdc_cred' parameter (see		be provided through the 'kdc_cred' parameter (see Sections
	Section 4.3.1).		4.1 and 4.3.1).
	REQ9: Specify if any part of the KDC interface as defined in this		REQ9: Specify if any part of the KDC interface as defined in this
	document is not supported by the KDC (see Section 4.1).		document is not supported by the KDC (see Section 4.1).
	REQ10: Register a Resource Type for the group-membership resources,		REQ10: Register a Resource Type for the group-membership resources,
	which is used to discover the correct URL for sending a Join		which is used to discover the correct URL for sending a Join
	Request to the KDC (see Section 4.1).		Request to the KDC (see Section 4.1).
	REQ11: Define what specific actions (e.g., CoAP methods) are allowed		REQ11: Define what specific actions (e.g., CoAP methods) are allowed
	on each resource that are accessible through the KDC		on each resource that are accessible through the KDC
	skipping to change at line 5280 ¶		skipping to change at line 5272 ¶
	conveyed in the 'key' parameter (see Section 4.3.1).		conveyed in the 'key' parameter (see Section 4.3.1).
	REQ18: Specify the acceptable values of the 'gkty' parameter (see		REQ18: Specify the acceptable values of the 'gkty' parameter (see
	Section 4.3.1). For each of them, register a corresponding		Section 4.3.1). For each of them, register a corresponding
	entry in the "ACE Groupcomm Key Types" IANA registry if such		entry in the "ACE Groupcomm Key Types" IANA registry if such
	an entry does not exist already.		an entry does not exist already.
	REQ19: Specify and register the application profile identifier (see		REQ19: Specify and register the application profile identifier (see
	Section 4.3.1).		Section 4.3.1).
	REQ20: If used, specify the format, content, and default values of		REQ20: If used, specify the format and default values of the entries
	the entries of the CBOR map to include in the		of the CBOR map to include in the 'group_policies' parameter
	'group_policies' parameter (see Section 4.3.1).		(see Section 4.3.1).
	REQ21: Specify the approaches used to compute and verify the PoP		REQ21: Specify the approaches used to compute and verify the PoP
	evidence to include in the 'kdc_cred_verify' parameter and		evidence to include in the 'kdc_cred_verify' parameter and
	which of those approaches is used in which case (see Sections		which of those approaches is used in which case (see Sections
	4.3.1 and 4.5.1). If external signature verifiers are		4.3.1 and 4.5.1). If external signature verifiers are
	supported, specify how those provide a nonce to the KDC to be		supported, specify how those provide a nonce to the KDC to be
	used for computing the PoP evidence (see Section 4.5.1).		used for computing the PoP evidence (see Section 4.5.1).
	REQ22: Specify the communication protocol that members of the group		REQ22: Specify the communication protocol that members of the group
	use to communicate with each other (e.g., CoAP for group		use to communicate with each other (e.g., CoAP for group
	skipping to change at line 5439 ¶		skipping to change at line 5431 ¶
	In particular, each 'sign_capab' array has the same format and		In particular, each 'sign_capab' array has the same format and
	value of the COSE capabilities array for the algorithm capability		value of the COSE capabilities array for the algorithm capability
	specified in 'sign_parameters'[i].		specified in 'sign_parameters'[i].
	Such a COSE capabilities array is currently defined for the		Such a COSE capabilities array is currently defined for the
	algorithm capability COSE key type in the "Capabilities" column of		algorithm capability COSE key type in the "Capabilities" column of
	the "COSE Key Types" registry [COSE.Key.Types].		the "COSE Key Types" registry [COSE.Key.Types].
	sign_info_entry =		sign_info_entry =
	[		[
	id : gname / [ + gname ],		id : gname / [+ gname],
	sign_alg : int / tstr,		sign_alg : int / tstr,
	sign_parameters : [ * alg_capab : any ],		sign_parameters : [* alg_capab : any],
	* sign_capab : [ * capab : any ],		* sign_capab : [* capab : any],
	cred_fmt : int / null		cred_fmt : int / null
	]		]
	gname = tstr		gname = tstr
	Figure 38: 'sign_info_entry' with a General Format		Figure 38: 'sign_info_entry' with a General Format
	Acknowledgments		Acknowledgments
	The following individuals were helpful in shaping this document:		The following individuals were helpful in shaping this document:
	skipping to change at line 5470 ¶		skipping to change at line 5462 ¶
	The work on this document has been partly supported by the Sweden's		The work on this document has been partly supported by the Sweden's
	Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, by		Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, by
	the H2020 project SIFIS-Home (Grant agreement 952652), and by the		the H2020 project SIFIS-Home (Grant agreement 952652), and by the
	EIT-Digital High Impact Initiative ACTIVE.		EIT-Digital High Impact Initiative ACTIVE.
	Authors' Addresses		Authors' Addresses
	Francesca Palombini		Francesca Palombini
	Ericsson AB		Ericsson AB
	Torshamnsgatan 23		Torshamnsgatan 23
	SE-16440 Kista, Stockholm		SE-164 40 Kista
	Sweden		Sweden
	Email: francesca.palombini@ericsson.com		Email: francesca.palombini@ericsson.com
	Marco Tiloca		Marco Tiloca
	RISE AB		RISE AB
	Isafjordsgatan 22		Isafjordsgatan 22
	SE-164 40 Kista		SE-164 40 Kista
	Sweden		Sweden
	Email: marco.tiloca@ri.se		Email: marco.tiloca@ri.se
End of changes. 68 change blocks.
	101 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.48.