]> 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 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 entity 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 (GM) entity responsible for that group, and retrieves 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). specifies a RESTful admin interface at the Group Manager, 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 . 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 . These include also 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.

• CBOR , Packed CBOR , and COSE .
• The Constrained RESTful Application Language (CoRAL) and Constrained Resource Identifiers (CRIs) .
• The CoAP protocol , also in group communication scenarios . These include the concepts of:
  • "application group", as a set of CoAP nodes that share a common set of resources; and of
  • "security group", as a set of CoAP nodes that share the same security material, and use it to protect and verify exchanged messages.
• The OSCORE and Group OSCORE security protocols. These especially include the concepts of:
  • 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, that new members access to join the OSCORE group, while current members can access 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 , the url-path to a group-configuration resource has GROUPNAME as last segment, with GROUPNAME the invariant group name assigned upon its creation. Building on the considered url-path of the group-collection resource, 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, unless otherwise indicated, 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. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol".

Notation and Assumptions in the Examples As per , CoRAL expresses Uniform Resource Identifiers (URIs) as Constrained Resource Identifier (CRI) references . The 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. The examples especially refer to the values from the two shared item tables in . Finally, the examples 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 The same resource model defined in as based on a group-collection resource and multiple group-configuration resources is used in this document. 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" defined in . The Administrator can discover group-configuration resources for the group-collection resource as specified in and .

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 the CoAP protocol 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 specifically used transport profile of ACE, 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 performed not as defined in , but instead as defined in of this document.

Multiple Administrators for the Same OSCORE Group What is defined in 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 properties and status properties.

Configuration Properties The same configuration properties defined in are used.

Status Properties The same status properties 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, defined 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 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 "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 Section 3.1.4 of ).
• 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 properties 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 properties 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 properties 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_title /, "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 properties 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_title /, "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 "null".
• 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 as in 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_title /, 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_title /, "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 PUT 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 PUT request.

An example of message exchange is shown below. 0.03 PUT 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, in case the request payload includes both any 'app_group' link element as well as 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, in case 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 'error', 'error_description', '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, 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 'error', 'error_description', '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' parameter, 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 including the link element 'error', this can specify any of the values defined in . The same guidelines in for the Administrator to handle such error identifiers holds.

Security Considerations Security considerations are inherited from the ACE framework for Authentication and Authorization , and from the specific transport profile of ACE used between the Administrator and the Group Manager, such as and . 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 for 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 Universitaet Duisburg-Essen This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged 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 any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. Ericsson AB RISE AB 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 acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as 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. RISE AB Universitaet Duisburg-Essen Ericsson AB This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that 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 Consultant Ericsson AB Group communication for 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. 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 InterDigital RISE AB This document specifies the use of the Constrained Application Protocol (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 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 receiver needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a simple transformation of a CBOR data item into another 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 receiver. // The present version (-10) fixes references, an example, and // various nits and typos. 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) instead of a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –14 of this draft picks up comments from the // shepherd review and adds sections on CoAP integration and on cri // application-oriented literals for the Extended Diagnostic // Notation. This revision still contains open issues and is // intended to serve as a snapshot while the processing of the // shepherd review is being completed. 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. 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. 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. 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. 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 Nexus Group 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, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. 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 with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Universität Bremen TZI The Constrained RESTful Environments (CoRE) specifications apply Web technologies to constrained environments. One important such 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 CoAP's Resource Discovery Protocol (Section 7.2 of RFC7252) 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. 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.

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.

Compression of CoRAL predicates The following shared item table is used for compressing CoRAL predicates, as per .

Shared item table for compressing CoRAL predicates.

Compression of Values of the rt= Target Attribute The following shared item table is used for compressing values of the rt= target attribute, as per .

Shared item table for compressing values of the rt= target attribute.

Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION.

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. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652).