]> RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden rikard.hoglund@ri.se

Security ACE Working Group Internet-Draft Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) can also be used for group communication , where messages are exchanged between members of a group (e.g., over IP multicast). Applications relying on CoAP can achieve end-to-end security at the application layer by using Object Security for Constrained RESTful Environments (OSCORE) and especially Group OSCORE in group communication scenarios. When group communication for CoAP is protected with Group OSCORE, nodes are required to explicitly join the correct OSCORE group. To this end, a joining node interacts with a Group Manager entity responsible for that group, and it retrieves from the Group Manager the required keying material to securely communicate with other group members using Group OSCORE. The method in specifies how nodes can join an OSCORE group through the respective Group Manager. Such a method builds on the ACE framework for Authentication and Authorization , so ensuring a secure joining process as well as authentication and authorization of joining nodes (clients) at the Group Manager (resource server). Furthermore, specifies a RESTful admin interface at the Group Manager, which is intended for an Administrator as a separate entity external to the Group Manager and its application. The interface allows the Administrator to create and delete OSCORE groups, as well as to configure and update their configuration. This document builds on and specifies how an Administrator interacts with the same RESTful admin interface by using the Constrained RESTful Application Language (CoRAL) . Compared to , there is no change in the admin interface and its operations, nor in the way the group configurations are organized and represented. Interaction examples using Packed CBOR are provided and are expressed in CBOR diagnostic notation as defined in and . provides the notation and assumptions used in the examples. The ACE framework is used to ensure authentication and authorization of the Administrator (client) at the Group Manager (resource server). In order to achieve communication security, proof-of-possession, and server authentication, the Administrator and the Group Manager leverage protocol-specific transport profiles of ACE, such as or . These also include possible forthcoming transport profiles that comply with the requirements in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts from the following specifications.

• Concise Binary Object Representation (CBOR) , Packed CBOR , and CBOR Object Signing and Encryption (COSE) .
• The Constrained RESTful Application Language (CoRAL) and Constrained Resource Identifiers (CRIs) .
• CoAP , also in group communication scenarios . These especially include the concepts below:
  • "Application group", as a set of CoAP nodes that share a common set of resources.
  • "Security group", as a set of CoAP nodes that share the same security material and use it to protect and verify exchanged messages.
• The security protocols OSCORE and Group OSCORE . These especially include the concepts below:
  • Group Manager, as the entity responsible for a set of OSCORE groups where communications among members are secured using Group OSCORE. An OSCORE group is used as security group for one or many application groups.
  • Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates .
• The ACE framework for Authentication and Authorization . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes client (C), resource server (RS), and authorization server (AS).
• The management of keying material for groups in ACE and specifically for OSCORE groups . These include the concept of group-membership resource hosted by the Group Manager. Candidate group members access such a resource to join the OSCORE group, while current group members can access it to retrieve updated keying material.

Readers are also expected to be familiar with the terms and concepts used in , with particular reference to "Administrator", "group name", "group-collection resource", and "group-configuration resource". Like in , this document uses /manage as the url-path of the group-collection resource at the Group Manager when providing examples; implementations can use a different url-path. Building on that, this document uses /manage/GROUPNAME as the url-path of a group-configuration resource; implementations are not required to use this name and can define their own instead. Note that the term "endpoint" is used here following its OAuth definition , aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document.

Notation and Assumptions Used in the Examples As per , CoRAL expresses Uniform Resource Identifiers (URIs) as Constrained Resource Identifier (CRI) references . Examples in this document use the following notation. When using the CURIE syntax , the following applies.

• 'core.osc.gcoll' stands for http://coreapps.org/core.osc.gcoll
• 'core.osc.gconf' stands for http://coreapps.org/core.osc.gconf
• 'linkformat' stands for http://www.iana.org/assignments/linkformat/ This URI is to be defined with IANA, together with other URIs that build on it through further path segments, e.g., http://www.iana.org/assignments/linkformat/rt

When using a URI http://www.iana.org/assignments/linkformat/SEG1/SEG2

• The path segment SEG1 is the name of a web link target attribute. Names of target attributes used in Link Format are expected to be coordinated through the "Target Attributes" registry defined in .
• The path segment SEG2 is the value of the target attribute.

The application-extension identifier "cri" defined in is used to notate a CBOR Extended Diagnostic Notation (EDN) literal for a CRI or CRI reference. This format is not expected to be sent over the network. Packed CBOR is also used, thus reducing representation size. Examples in this document especially refer to the values from the two shared item tables in . Finally, examples in this document consider a Group Manager with address [2001:db8::ab] and use the CoAP Content-Format ID 65087 for the media type "application/coral+cbor".

Group Administration The group administration is enforced as defined in .

Managing OSCORE Groups This document uses the same resource model defined in , which is based on a group-collection resource and multiple group-configuration resources. When accessing such resources, the Administrator relies on the same interface defined in , for which differences that apply when using CoRAL are compiled in of this document.

Collection Representation A collection of group configurations is represented as a CoRAL document containing the list of corresponding group-configuration resources. Each group configuration is represented as a top-level link element, with the URI of the group-configuration resource as link target and with http://coreapps.org/core.osc.gcoll#item as relation type.

Discovery The Administrator can discover the group-collection resource from a Resource Directory (see, for instance, ) or from /.well-known/core, by using the resource type "core.osc.gcoll" registered in . The Administrator can discover group-configuration resources for the group-collection resource as specified in and of this document.

Format of Scope In order to express authorization information for the Administrator (see ), the same format and encoding of scope defined in is used, as relying on the Authorization Information Format (AIF) and the extended AIF data model AIF-OSCORE-GROUPCOMM defined in .

Getting Access to the Group Manager All communications between the involved entities rely on CoAP and MUST be secured. In particular, communications between the Administrator and the Group Manager leverage protocol-specific transport profiles of ACE to achieve communication security, proof-of-possession, and server authentication. To this end, the AS may explicitly signal the specific transport profile to use, consistently with requirements and assumptions defined in the ACE framework . With reference to the AS, communications between the Administrator and the AS (/token endpoint) as well as between the Group Manager and the AS (/introspect endpoint) can be secured by different means, for instance using DTLS or OSCORE . Further details on how the AS secures communications (with the Administrator and the Group Manager) depend on the transport profile of ACE specifically used and are out of the scope of this document. The Administrator requests access to the Group Manager as per Steps 1-3 in . The Administrator accesses the admin interface at the Group Manager as per Step 4 in , with the difference that administrative operations are not performed as defined in , but instead as defined in of this document.

Multiple Administrators for the Same OSCORE Group What is defined in also holds for this document, with the following difference. The Administrator performs administrative operations at the Group Manager not as defined in , but instead as defined in of this document.

Group Configurations A group configuration consists of a set of parameters.

Group Configuration Representation The same group configuration representation defined in is used, as including configuration parameters and status parameters.

Configuration Parameters The same configuration parameters defined in are used.

Status Parameters The same status parameters defined in are used.

Default Values The Group manager refers to the same default values defined in .

Interactions with the Group Manager The same as defined in holds, with the following differences.

• The Content-Format in messages containing a payload is set to application/coral+cbor, which is registered in .
• The parameters 'sign_params', 'ecdh_params', 'app_groups', and 'group_policies' are referred to as "structured parameters".
• If a message payload specifies a link element corresponding to a structured parameter, then the following applies:
  • The payload MUST NOT include any link element corresponding to an inner information element of that structured parameter.
  • The link element MUST have the link target with value the CBOR simple value false (0xf4) for indicating the structured parameter with no elements. Editor's note: this should change to using an empty CBOR array or an empty CBOR map as appropriate, once this is made explicitly possible in the binary format of link items in CoRAL (see ).
• If a message payload specifies an information element of a structured parameter from the group configuration, then that information element MUST be specified by means of the corresponding link element.

Retrieve the Full List of Group Configurations This operation MUST be supported by the Group Manager and an Administrator. The Administrator can send a GET request to the group-collection resource, in order to retrieve a list of the existing OSCORE groups at the Group Manager. The same as defined in holds. An example of message exchange is shown below. 0.01 GET Uri-Path: "manage" <= 2.05 Content Content-Format: 65087 (application/coral+cbor) Payload: [ [1, cri'coap://[2001:db8::ab]/manage'], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp1', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp2', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp3', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ] ] ]]>

Retrieve a List of Group Configurations by Filters This operation MUST be supported by the Group Manager and MAY be supported by an Administrator. The Administrator can send a FETCH request to the group-collection resource, in order to retrieve a list of the existing OSCORE groups that fully match a set of specified filter criteria. The same as defined in holds, with the following differences.

• The filter criteria are specified in the request payload with top-level link elements, each of which corresponds to an entry of the group configuration (see ), with the exception of non-empty structured parameters.
• If names of application groups are used as filter criteria, each element of the 'app_groups' array from the status parameters is included as a separate link element with name 'app_group'.
• With the exception of the 'app_group' element, a valid request MUST NOT include the same element multiple times. Element values are the ones admitted for the corresponding labels in the POST request for creating a group configuration (see ).

An example of message exchange is shown below. 0.05 FETCH Uri-Path: "manage" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(27) / item 70 for core.osc.gconf:#group_mode /, true], [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 10], [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, 5] ] <= 2.05 Content Content-Format: 65087 (application/coral+cbor) Payload: [ [1, cri'coap://[2001:db8::ab]/manage'], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp1', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp2', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ], [2, 6(17) / item 50 for core.osc.gcoll:#item /, cri'/gp3', [ [2, simple(6) / item 6 for linkformat:rt /, 6(-200) / item 415 for cri'http://www.iana.org/assignments /linkformat/rt/core.osc.gconf' /]] ] ] ]]>

Create a New Group Configuration This operation MUST be supported by the Group Manager and an Administrator. The Administrator can send a POST request to the group-collection resource, in order to create a new OSCORE group at the Group Manager. The same as defined in holds, with the following differences.

• In the request payload, each link element corresponds to an entry of the group configuration (see ), with the exception of non-empty structured parameters.
• In the request payload, each element of the 'app_groups' array from the status parameters is included as a separate element with name 'app_group'.
• The Group Manager MUST respond with a 4.00 (Bad Request) response if any link element is specified multiple times in the payload of the POST request, with the exception of the 'app_group' link element.
• The response payload includes one link element for each specified parameter, with the exception of non-empty structured parameters.
• In the response payload, each element of the 'app_groups' array from the status parameters is included as a separate element with name 'app_group'.
• If the Administrator performs the registration of the group-membership resource to a Resource Directory on behalf of the Group Manager, then the names of the application groups using the OSCORE group MUST take the values possibly specified by the different 'app_group' link elements in the POST request.

An example of message exchange is shown below. 0.02 POST Uri-Path: "manage" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 10], [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, 5], [2, 6(-31) / item 77 for core.osc.gconf:#pairwise_mode /, true], [2, 6(-36) / item 87 for core.osc.gconf:#active /, true], [2, 6(36) / item 88 for core.osc.gconf:#group_name /, "gp4"], [2, 6(-37) / item 89 for core.osc.gconf:#group_description /, "rooms 1 and 2"], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 1"], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 2"], [2, 6(43) / item 102 for core.osc.gconf:#as_uri /, cri'coap://as.example.com/token'] ] <= 2.01 Created Location-Path: "manage" Location-Path: "gp4" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(36) / item 88 for core.osc.gconf:#group_name /, "gp4"], [2, 6(-41) / item 97 for core.osc.gconf:#joining_uri /, cri'coap://[2001:db8::ab]/ace-group/gp4/'], [2, 6(43) / item 102 for core.osc.gconf:#as_uri /, cri'coap://as.example.com/token'] ] ]]>

Retrieve a Group Configuration This operation MUST be supported by the Group Manager and an Administrator. The Administrator can send a GET request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to retrieve the complete current configuration of that group. The same as defined in holds, with the following differences.

• The response payload includes one link element for each entry of the group configuration (see ), with the exception of non-empty status parameters.
• Each element of the 'app_groups' array from the status parameters is included as a separate link element with name 'app_group'.

An example of message exchange is shown below. 0.01 GET Uri-Path: "manage" Uri-Path: "gp4" <= 2.05 Content Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, 5], [2, 6(-27) / item 69 for core.osc.gconf:#cred_fmt /, 33], [2, 6(27) / item 70 for core.osc.gconf:#group_mode /, true], [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 10], [2, 6(28) / item 72 for core.osc.gconf:#sign_alg /, -8], [2, 6(29) / item 74 for core.osc.gconf:#sign_params.alg_capab.key_type /, 1], [2, 6(-30) / item 75 for core.osc.gconf:#sign_params.key_type_capab.key_type /, 1], [2, 6(30) / item 76 for core.osc.gconf:#sign_params.key_type_capab.curve /, 6], [2, 6(-31) / item 77 for core.osc.gconf:#pairwise_mode /, true], [2, 6(31) / item 78 for core.osc.gconf:#alg /, 10], [2, 6(-32) / item 79 for core.osc.gconf:#ecdh_alg /, -27], [2, 6(-33) / item 81 for core.osc.gconf:#ecdh_params.alg_capab.key_type /, 1], [2, 6(33) / item 82 for core.osc.gconf:#ecdh_params.key_type_capab.key_type /, 1], [2, 6(-34) / item 83 for core.osc.gconf:#ecdh_params.key_type_capab.curve /, 6], [2, 6(34) / item 84 for core.osc.gconf:#det_req /, false], [2, 6(35) / item 86 for core.osc.gconf:#rt /, "core.osc.gconf"], [2, 6(-36) / item 87 for core.osc.gconf:#active /, true], [2, 6(36) / item 88 for core.osc.gconf:#group_name /, "gp4"], [2, 6(-37) / item 89 for core.osc.gconf:#group_description /, "rooms 1 and 2"], [2, 6(37) / item 90 for core.osc.gconf:#ace_groupcomm_profile /, "coap_group_oscore_app"], [2, 6(-38) / item 91 for core.osc.gconf:#max_stale_sets /, 3], [2, 6(38) / item 92 for core.osc.gconf:#exp /, 1360289224], [2, 6(-39) / item 93 for core.osc.gconf:#gid_reuse /, false], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 1"], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 2"], [2, 6(-41) / item 97 for core.osc.gconf:#joining_uri /, cri'coap://[2001:db8::ab]/ace-group/gp4/'], [2, 6(43) / item 102 for core.osc.gconf:#as_uri /, cri'coap://as.example.com/token'] ] ]]>

Retrieve Part of a Group Configuration by Filters This operation MUST be supported by the Group Manager and MAY be supported by an Administrator. The Administrator can send a FETCH request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to retrieve part of the current configuration of that group. The same as defined in holds, with the following differences.

• The request payload includes one link element for each requested configuration parameter or status parameter of the current group configuration (see ). All the specified link elements MUST have the link target with value the CBOR simple value null (0xf6).
• The request payload MUST NOT include any link element corresponding to an inner information element of a structured parameter.
• The response payload includes the requested configuration parameters and status parameters, and is formatted like the response payload of a GET request to a group-configuration resource (see ). If the request payload specifies a parameter that is not included in the group configuration, then the response payload MUST NOT include a corresponding link element.

An example of message exchange is shown below. 0.05 FETCH Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, null], [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, null], [2, 6(-31) / item 77 for core.osc.gconf:#pairwise_mode /, null], [2, 6(-36) / item 87 for core.osc.gconf:#active /, null], [2, 6(-37) / item 89 for core.osc.gconf:#group_description /, null], [2, 6(41) / item 98 for core.osc.gconf:#app_groups /, null] ] <= 2.05 Content Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 10], [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, 5], [2, 6(-31) / item 77 for core.osc.gconf:#pairwise_mode /, true], [2, 6(-36) / item 87 for core.osc.gconf:#active /, true], [2, 6(-37) / item 89 for core.osc.gconf:#group_description /, "rooms 1 and 2"], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 1"], [2, 6(39) / item 94 for core.osc.gconf:#app_group /, "room 2"] ] ]]>

Overwrite a Group Configuration This operation MAY be supported by the Group Manager and an Administrator. The Administrator can send a POST request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to overwrite the current configuration of that group with a new one. The same as defined in holds, with the following difference.

• If the Administrator updates the registration of the group-membership resource in the Resource Directory on behalf of the Group Manager, then the names of the application groups using the OSCORE group MUST take the values possibly specified by the different 'app_group' link elements in the POST request.

An example of message exchange is shown below. 0.02 POST Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 11], [2, 6(26) / item 68 for core.osc.gconf:#hkdf /, 5] ] <= 2.04 Changed Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(36) / item 88 for core.osc.gconf:#group_name /, "gp4"], [2, 6(-41) / item 97 for core.osc.gconf:#joining_uri /, cri'coap://[2001:db8::ab]/ace-group/gp4/'], [2, 6(43) / item 102 for core.osc.gconf:#as_uri /, cri'coap://as.example.com/token'] ] ]]>

Effects on Joining Nodes The same as defined in holds.

Effects on the Group Members The same as defined in holds.

Selective Update of a Group Configuration This operation MAY be supported by the Group Manager and an Administrator. The Administrator can send a PATCH/iPATCH request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to update the value of only part of the group configuration. The same as defined in holds, with the following differences.

• If the request payload specifies names of application groups to be removed from or added to the 'app_groups' status parameter, then such names are specified by means of the following top-level link elements.
  • 'app_group_del', with value a text string specifying the name of an application group to remove from the 'app_groups' status parameter. This link element can be included multiple times.
  • 'app_group_add', with value a text string specifying the name of an application group to add to the 'app_groups' status parameter. This link element can be included multiple times.
  The Group Manager MUST respond with a 4.00 (Bad Request) response, if the request payload includes any 'app_group' link element together with any 'app_group_del' and/or 'app_group_add' link element.
• The Group Manager MUST respond with a 4.00 (Bad Request) response, if the request payload includes no link elements.
• When the request uses specifically the iPATCH method, the Group Manager MUST respond with a 4.00 (Bad Request) response, if any link element 'app_group_del' and/or 'app_group_add' is included.
• When updating the 'app_groups' status parameter by difference, the Group Manager:
  • Deletes from the 'app_groups' status parameter the names of the application groups specified in the different 'app_group_del' link elements.
  • Adds to the 'app_groups' status parameter the names of the application groups specified in the different 'app_group_add' link elements.

An example of message exchange is shown below. 0.06 PATCH Uri-Path: "manage" Uri-Path: "gp4" Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(-28) / item 71 for core.osc.gconf:#gp_enc_alg /, 10], [2, 6(-40) / item 95 for core.osc.gconf:#app_group_del /, "room1"], [2, 6(40) / item 96 for core.osc.gconf:#app_group_add /, "room3"], [2, 6(40) / item 96 for core.osc.gconf:#app_group_add /, "room4"] ] <= 2.04 Changed Content-Format: 65087 (application/coral+cbor) Payload: [ [2, 6(36) / item 88 for core.osc.gconf:#group_name /, "gp4"], [2, 6(-41) / item 97 for core.osc.gconf:#joining_uri /, cri'coap://[2001:db8::ab]/ace-group/gp4/'], [2, 6(43) / item 102 for core.osc.gconf:#as_uri /, cri'coap://as.example.com/token'] ] ]]>

Effects on Joining Nodes The same as defined in holds.

Effects on the Group Members The same as defined in holds.

Delete a Group Configuration This operation MUST be supported by the Group Manager and an Administrator. The Administrator can send a DELETE request to the group-configuration resource /manage/GROUPNAME associated with an OSCORE group with group name GROUPNAME, in order to delete that OSCORE group. The same as defined in holds.

Effects on the Group Members The same as defined in holds.

Support of Top-Level Link Elements Consistently with , the following holds for the Group Manager.

• It MUST support the top-level link elements 'ace_groupcomm_profile', 'exp', and 'group_policies' corresponding to the ACE Groupcomm Parameters defined in . This is consistent with what is defined in for the Key Distribution Center (KDC), of which the Group Manager defined in is a specific instance.
• It MUST support the top-level link elements corresponding to all the parameters listed in , with the exception of 'app_groups_diff' that MUST be supported only if the Group Manager supports the selective update of a group configuration (see ).

The following holds for an Administrator.

• It MUST support the top-level link elements 'ace_groupcomm_profile', 'exp', and 'group_policies' corresponding to the ACE Groupcomm Parameters defined in .
• It MUST support the top-level link elements corresponding to all the parameters listed in , with the following exceptions.
  • 'conf_filter', which MUST be supported only if the Administrator supports the partial retrieval of a group configuration by filters (see ).
  • 'app_groups_diff', which MUST be supported only if the Administrator supports the selective update of a group configuration (see ).

Error Identifiers If the Group Manager sends an error response with Content-Format application/concise-problem-details+cbor as defined in , then the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' takes value from those defined in and in . The same guidelines in for the Administrator to handle such error identifiers hold.

Security Considerations Security considerations are inherited from the ACE framework for Authentication and Authorization and from the transport profile of ACE specifically used between the Administrator and the Group Manager, such as or . The same security considerations from and also apply, with particular reference to the process of rekeying OSCORE groups. The same security considerations from also apply, as well as the security considerations for CoRAL and Packed CBOR .

IANA Considerations This document has no actions for IANA.

References Normative References RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession for a key owned by the Client and bound to an OAuth 2.0 access token. RISE AB RISE AB Ericsson AB Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession, and server authentication. ARM The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. Universität Bremen TZI TUD Dresden University of Technology The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -17 contains a number of editorial improvements, it is // intended for a brief discussion at the 2025-10-15 CBOR WG interim. // The wording of the present revision continues to make use of the // tunables A/B/C to be set to specific numbers before completing the // Packed CBOR specification; not all the examples may fully align // yet. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -19 // includes the definition of the cri'' application- extension. cri'' // was previously defined in draft-ietf-core-href; however the latter // document overtook the present document in the approval process. // As the definition of cri'' is dependent on the present document // (and conversely has essentially no dependency on the technical // content of draft-ietf-core-href beyond its mere existence), the // text (including IANA considerations) has been moved here. -19 is // intended for use at the CBOR WG meeting at IETF 124. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things. This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Ericsson This document explores how the Constrained RESTful Application Language (CoRAL) might be used for two use cases in Constrained RESTful Environments (CoRE): CoRE Resource Discovery, which allows a client to discover the resources of a server given a host name or IP address, and CoRE Resource Directory, which provides a directory of resources on many servers. Ericsson AB Ericsson AB RISE AB RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates by over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the Resource Directory (RD) (RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry.

Shared Item Tables for Packed CBOR This appendix defines the two shared item tables that the examples in this document refer to for using Packed CBOR . The application-extension identifier "cri" defined in is used to notate a CBOR Extended Diagnostic Notation (EDN) literal for a CRI.

Compacting CoRAL Predicates with Packed CBOR The following shared item table is used for compacting CoRAL predicates, as per . Shared Item Table for Compacting CoRAL Predicates.

Index	Item
6	cri'http://www.iana.org/assignments/linkformat/rt'
50	cri'http://coreapps.org/core.osc.gcoll#item'
68	cri'http://coreapps.org/core.osc.gconf#hkdf'
69	cri'http://coreapps.org/core.osc.gconf#cred_fmt'
70	cri'http://coreapps.org/core.osc.gconf#group_mode'
71	cri'http://coreapps.org/core.osc.gconf#gp_enc_alg'
72	cri'http://coreapps.org/core.osc.gconf#sign_alg'
73	cri'http://coreapps.org/core.osc.gconf#sign_params'
74	cri'http://coreapps.org/core.osc.gconf#sign_params       .alg_capab.key_type'
75	cri'http://coreapps.org/core.osc.gconf#sign_params       .key_type_capab.key_type'
76	cri'http://coreapps.org/core.osc.gconf#sign_params       .key_type_capab.curve'
77	cri'http://coreapps.org/core.osc.gconf#pairwise_mode'
78	cri'http://coreapps.org/core.osc.gconf#alg'
79	cri'http://coreapps.org/core.osc.gconf#ecdh_alg'
80	cri'http://coreapps.org/core.osc.gconf#ecdh_params'
81	cri'http://coreapps.org/core.osc.gconf#ecdh_params       .alg_capab.key_type'
82	cri'http://coreapps.org/core.osc.gconf#ecdh_params       .key_type_capab.key_type'
83	cri'http://coreapps.org/core.osc.gconf#ecdh_params       .key_type_capab.curve'
84	cri'http://coreapps.org/core.osc.gconf#det_req'
85	cri'http://coreapps.org/core.osc.gconf#det_hash_alg'
86	cri'http://coreapps.org/core.osc.gconf#rt'
87	cri'http://coreapps.org/core.osc.gconf#active'
88	cri'http://coreapps.org/core.osc.gconf#group_name'
89	cri'http://coreapps.org/core.osc.gconf#group_description'
90	cri'http://coreapps.org/core.osc.gconf       #ace_groupcomm_profile'
91	cri'http://coreapps.org/core.osc.gconf#max_stale_sets'
92	cri'http://coreapps.org/core.osc.gconf#exp'
93	cri'http://coreapps.org/core.osc.gconf#gid_reuse'
94	cri'http://coreapps.org/core.osc.gconf#app_group'
95	cri'http://coreapps.org/core.osc.gconf#app_group_del'
96	cri'http://coreapps.org/core.osc.gconf#app_group_add'
97	cri'http://coreapps.org/core.osc.gconf#joining_uri'
98	cri'http://coreapps.org/core.osc.gconf#app_groups'
99	cri'http://coreapps.org/core.osc.gconf#group_policies'
100	cri'http://coreapps.org/core.osc.gconf#group_policies       .key_update_check_interval'
101	cri'http://coreapps.org/core.osc.gconf#group_policies       .exp_delta'
102	cri'http://coreapps.org/core.osc.gconf#as_uri'

Compacting Values of the rt= Target Attribute with Packed CBOR The following shared item table is used for compacting values of the rt= target attribute, as per . Shared Item Table for Compacting Values of the rt= Target Attribute.

Index	Item
415	cri'http://www.iana.org/assignments/linkformat/rt       /core.osc.gconf'

Document Updates

Version -04 to -05

• Use "compacting" instead of "compressing" when referring to Packed CBOR.
• Updated references.
• Editorial fixes and improvements.

Version -03 to -04

• Updated references.
• Editorial improvements and fixes.

Version -02 to -03

• Uri-Path and Location-Path as text strings in examples.
• Updated references.
• Editorial fixes.

Version -01 to -02

• Avoid quotation marks for CBOR simple values.
• Fixed use of 'linkformat' in the CURIE syntax.
• Fixed use of CURIEs that result in a URI with the fragment component.
• Renamed 'group_title' as 'group_description'.
• Status/Configuration "properties" renamed as "parameters".
• POST (instead of PUT) for overwriting a group-configuration resource.
• Remove reference to the abandoned, custom format for error messages.
• Editorial improvements.

Version -00 to -01

• Updated reference and introductory text for the CBOR EDN application-extension identifier "cri".

Version -00

• CoRAL content taken out from draft-ietf-ace-oscore-gm-admin-08.

Acknowledgments Most of the content in this document was originally specified in draft-ietf-ace-oscore-gm-admin, which is co-authored also by Peter van der Stok and Francesca Palombini, and where Klaus Hartke contributed in the initial definition of the resource model and interactions using CoRAL. The authors sincerely thank , , and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).