]> RISE AB

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

RISE AB

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

Consultant

+31-492474673 (Netherlands), +33-966015248 (France) stokcons@bbhmail.nl

Ericsson AB

Torshamnsgatan 23 Kista 16440 Stockholm Sweden francesca.palombini@ericsson.com

Internet 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. 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. 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 be used in group communication environments where messages are also exchanged 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). In some deployments, the application running on the Group Manager may know when a new OSCORE group has to be created, as well as how it should be configured and later on updated or deleted, e.g., based on the current application state or on pre-installed policies. In this case, the Group Manager application can create and configure OSCORE groups when needed, by using a local application interface. However, this requires the Group Manager to be application-specific, which in turn leads to error prone deployments and is poorly flexible. In other deployments, a separate Administrator entity, such as a Commissioning Tool, is directly responsible for creating and configuring the OSCORE groups at a Group Manager, as well as for maintaining them during their whole lifetime until their deletion. This allows the Group Manager to be agnostic of the specific applications using secure group communication. This document 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. Interaction examples are provided, in Link Format and CBOR , as well as in CoRAL . While all the CoRAL examples show the CoRAL textual serialization format, its binary serialization format is used on the wire. [ NOTE: The reported CoRAL examples are based on the textual representation used until version -03 of . These will be revised to use the CBOR diagnostic notation instead. ] 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 Appendix C of .

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 and COSE .
• 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.

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". This document also refers to the following terminology.

• Administrator: entity responsible to create, configure and delete OSCORE groups at a Group Manager.
• Group name: stable and invariant name of an OSCORE group. The group name MUST be unique under the same Group Manager, and MUST include only characters that are valid for a URI path segment.
• Group-collection resource: a single-instance resource hosted by the Group Manager. An Administrator accesses a group-collection resource to retrieve the list of existing OSCORE groups, or to create a new OSCORE group, under that Group Manager. As an example, this document uses /manage as the url-path of the group-collection resource; implementations are not required to use this name, and can define their own instead.
• Group-configuration resource: a resource hosted by the Group Manager, associated with an OSCORE group under that Group Manager. A group-configuration resource is identifiable with the invariant group name of the respective OSCORE group. An Administrator accesses a group-configuration resource to retrieve or change the configuration of the respective OSCORE group, or to delete that group. 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.
• Admin endpoint: an endpoint at the Group Manager associated with the group-collection resource or to a group-configuration resource hosted by that Group Manager.

Group Administration With reference to the ACE framework and the terminology defined in OAuth 2.0 :

• The Group Manager acts as Resource Server (RS). It provides one single group-collection resource, and one group-configuration resource per existing OSCORE group. Each of those is exported by a distinct admin endpoint.
• The Administrator acts as Client (C), and requests to access the group-collection resource and group-configuration resources, by accessing the respective admin endpoint at the Group Manager.
• The Authorization Server (AS) authorizes the Administrator to access the group-collection resource and group-configuration resources at a Group Manager. Multiple Group Managers can be associated with the same AS. The authorized access for an Administrator can be limited to performing only a subset of operations, according to what is allowed by the authorization information in the Access Token issued to that Administrator (see and ). The AS can authorize multiple Administrators to access the group-collection resource and the (same) group-configuration resources at the Group Manager. The AS MAY release Access Tokens to the Administrator for other purposes than accessing admin endpoints of registered Group Managers.

Managing OSCORE Groups shows the resources of a Group Manager available to an Administrator.

Resources of a Group Manager

The Group Manager exports a single group-collection resource, with resource type "core.osc.gcoll" defined in of this document. The interface for the group-collection resource defined in allows the Administrator to:

• Retrieve the list of existing OSCORE groups.
• Retrieve the list of existing OSCORE groups matching with specified filter criteria.
• Create a new OSCORE group, specifying its invariant group name and, optionally, its configuration.

The Group Manager exports one group-configuration resource for each of its OSCORE groups. Each group-configuration resource has resource type "core.osc.gconf" defined in of this document, and is identified by the group name specified upon creating the OSCORE group. The interface for a group-configuration resource defined in allows the Administrator to:

• Retrieve the complete current configuration of the OSCORE group.
• Retrieve part of the current configuration of the OSCORE group, by applying filter criteria.
• Overwrite the current configuration of the OSCORE group.
• Selectively update only part of the current configuration of the OSCORE group.
• Delete the OSCORE group.

Collection Representation A list of group configurations is represented as a document containing the corresponding group-configuration resources in the list. Each group-configuration is represented as a link, where the link target is the URI of the group-configuration resource. The list can be represented as a Link Format document or a CoRAL document . In the former case, the link to each group-configuration resource specifies the link target attribute 'rt' (Resource Type), with value "core.osc.gconf" defined in of this document. In the latter case, the CoRAL document specifies the group-configuration resources in the list as top-level elements. In particular, the link to each group-configuration resource has http://coreapps.org/core.osc.gcoll#item as relation type.

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

Format of Scope This section defines the exact format and encoding of scope to use, in order to express authorization information for the Administrator (see ). To this end, this document uses the Authorization Information Format (AIF) , and defines the following AIF specific data model AIF-OSCORE-GROUPCOMM-ADMIN. With reference to the generic AIF model = [* [Toid, Tperm]] ]]> the value of the CBOR byte string used as scope encodes the CBOR array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds to one scope entry. Then, for each scope entry, the following applies.

• The object identifier ("Toid") is specialized as a CBOR text string, specifying a wildcard pattern P for the scope entry. The pattern P is intended as a template for group names.
• The permission set ("Tperm") is specialized as a CBOR unsigned integer with value Q. This specifies the permissions that the Administrator has to perform operations on the admin endpoints at the Group Manager, as pertaining to any OSCORE group whose name matches with the wildcard pattern P. The value Q is computed as follows.
  • Each permission in the permission set is converted into the corresponding numeric identifier X from the "Value" column of the "Group OSCORE Admin Permissions" registry, for which this document defines the entries in .
  • The set of N numbers is converted into the single value Q, by taking each numeric identifier X_1, X_2, ..., X_N to the power of two, and then computing the inclusive OR of the binary representations of all the power values.
  In general, a single permission can be associated with multiple different operations that are possible to be performed when interacting with the Group Manager. For example, the "List" permission allows the Administrator to retrieve a list of group configurations (see ) or only a subset of that according to specified filter criteria (see ), by issuing a GET or FETCH request to the group-collection resource, respectively.

Numeric identifier of permissions on the admin endpoints at a Group Manager

The CDDL definition of the AIF-OSCORE-GROUPCOMM-ADMIN data model and the format of scope using such a data model is as follows: pattern = tstr ; wilcard pattern of group names permission_set = uint . bits permissions permissions = &( List: 0, Create: 1, Read: 2, Write: 3, Delete: 4 ) scope_entry = AIF-OSCORE-GROUPCOMM-ADMIN scope = << [ + scope_entry ] >> ]]> By relying on the scope format defined above and given an OSCORE group G1 created by a "main" Administrator, then a second "assistant" Administrator can be effectively authorized to perform some operations on G1, in spite of not being the group creator. Furthermore, having the object identifier ("Toid") specialized as a wildcard pattern displays a number of advantages.

• The encoded scope can be compact in size, while allowing the Administrator to operate on large pools of group names.
• The Administrator and the AS do not need to know exact group names when requesting and issuing an Access Token, respectively (see ). In turn, the Group Manager can effectively take the final decision about the name to assign to an OSCORE group, upon its creation (see ).
• The Administrator may have established a secure communication association with the Group Manager based on a first Access Token T1, and then created an OSCORE group G. Following the invalidation of T1 (e.g., due to expiration) and the establishment of a new secure communication association with the Group Manager based on a new Access Token T2, the Administrator can seamlessly perform authorized operations on the previously created group G.

When using the scope format defined in this section, the permission set ("Tperm") of each scope entry MUST include the "List" permission in order for the scope to be considered valid. That is, for each scope entry, the unsigned integer Q MUST be odd. Therefore, an Administrator is always allowed to retrieve a list of existing group configurations. The exact elements included in the returned list are determined by the Group Manager, based on the group name patterns specified in the scope entries of the Administrator's Access Token, as well as on possible filter criteria specified in the request from the Administrator. [ NOTE: There is a potential follow-up building on this. An ACE Client might want to interact with the same Group Manager to be both Administrator for some groups and member for some other groups. In order to keep a single Access Token per Client, the scope would have to generally include some "admin" scope entries as per the AIF data model defined in this document, together with some "user" scope entries as per the AIF data model defined in . In the scope entries of the former type, the least significant bit of the Tperm integer and denoting the "List" admin permission is always set to 1 (see above). In the scope entries of the latter type, the least significant bit of the Tperm integer is reserved and always 0 (see ). Therefore, "admin" and "user" scope entries can unambiguously coexist in the same 'scope' claim and Authorization Request/Response parameter, and can be easily distinguished by checking the least significant bit of the Tperm integer. In turn, this would require to accordingly revise the scope format and the ACE scope semantics integer defined in this document, in order to denote the certain presence of "admin" scope entries and the optional additional presence of "user" scope entries, within a same scope claim/parameter. ] Future specifications that define new permissions on the admin endpoints at the Group Manager MUST register a corresponding numeric identifier in the "Group OSCORE Admin Permissions" registry defined in of this document.

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 format and encoding of scope defined in of this document MUST be used, for both the 'scope' claim in the Access Token, as well as for the 'scope' parameter in the Authorization Request and Authorization Response exchanged with the AS (see Sections and of ). Furthermore, the AS MAY use the extended format of scope defined in for the 'scope' claim of the Access Token. In such a case, the first element of the CBOR sequence MUST be the CBOR integer with value SEM_ID_TBD, defined in of this document. This indicates that the second element of the CBOR sequence, as conveying the actual access control information, follows the scope semantics defined in of this document. In order to get access to the Group Manager for managing OSCORE groups, an Administrator performs the following steps.

1. The Administrator requests an Access Token from the AS, in order to access the group-collection and group-configuration resources on the Group Manager. To this end, it sends to the AS an Authorization Request as defined in . The Administrator will start or continue using secure communications with the Group Manager, according to the response from the AS.
2. The AS processes the Authorization Request as defined in , especially verifying that the Administrator is authorized to obtain the requested permissions, or possibly a subset of those. With reference to the scope format specified in , the AS builds the value of the 'scope' claim to include in the Access Token as follows.
   1. The AS initializes three empty sets of scope entries, namely S1, S2 and S3.
   2. For each scope entry E in the 'scope' parameter of the Authorization Request, the AS performs the following actions.
      • In its access policies related to administrative operations at the Group Manager for the Administrator, the AS determines every group name superpattern P*, such that every group name matching with the wildcard pattern P of the scope entry E matches also with P*.
      • If no superpatterns are found, the AS proceeds with the next scope entry, if any. Otherwise, the AS computes Tperm* as the union of the permission sets associated with the superpatterns found at the previous step. That is, Tperm* is the inclusive OR of the binary representations of the Tperm values associated with the found superpatterns and encoding the corresponding permission sets as per .
      • The AS adds to the set S1 a scope entry, such that its Toid is the same as in the scope entry E, while its Tperm is the AND of Tperm* with the Tperm in the scope entry E.
   3. For each scope entry E in the 'scope' parameter of the Authorization Request, the AS performs the following actions.
      • In its access policies related to administrative operations at the Group Manager for the Administrator, the AS determines every group name subpattern P*, such that: i) the wildcard pattern P of the scope entry E is different from P*; and ii) every group name matching with P* also matches with P.
      • If no subpatterns are found, the AS proceeds with the next scope entry, if any. Otherwise, for each found subpattern P*, the AS adds to the set S2 a scope entry, such that its Toid is the same as in the subpattern P*, while its Tperm is the AND of the Tperm from the subpattern P* with the Tperm in the scope entry E.
   4. For each scope entry E in the 'scope' parameter of the Authorization Request, the AS performs the following actions.
      • For each group name pattern P* in its access policies related to administrative operations at the Group Manager for the Administrator, the AS performs the following actions.
        • The AS attempts to determine a crosspattern P** such that: i) in the previous step, P** was not identified as a superpattern or subpattern for the pattern P of the scope entry E; ii) every group name matching with P** also matches with both P and P*.
        • If no crosspattern is built, the AS proceeds with the next pattern in its access policies related to administrative operations at the Group Manager for the Administrator, if any. Otherwise, the AS adds to the set S3 a scope entry, such that its Toid is the same as in the crosspattern P**, while its Tperm is the AND of the Tperm from the pattern P* and the Tperm in the scope entry E.
   5. If the sets S1, S2 and S3 are all empty, the Authorization Request has not been successfully verified, and the AS returns an error response as per . Otherwise, the AS uses the scope entries in the sets S1, S2 and S3 as the scope entries for the 'scope' claim to include in the Access Token, as per the format defined in .
   The AS MUST include the 'scope' parameter in the Authorization Response defined in , when the value included in the Access Token differs from the one specified by the Administrator in the Authorization Response. In such a case, the second element of each scope entry specifies a set of permissions that the Administrator actually has to perform operations at the Group Manager, encoded as specified in .
3. The Administrator transfers authentication and authorization information to the Group Manager by posting the obtained Access Token, according to the used profile of ACE, such as and . After that, the Administrator must have a secure communication association established with the Group Manager, before performing any administrative operation on that Group Manager. Possible ways to provide secure communication are DTLS and OSCORE . The Administrator and the Group Manager maintain the secure association, to support possible future communications.
4. Consistently with what is allowed by the authorization information in the Access Token, the Administrator performs administrative operations at the Group Manager, as described in . These include retrieving a list of existing OSCORE groups, creating new OSCORE groups, retrieving and changing OSCORE group configurations, and removing OSCORE groups. Messages exchanged among the Administrator and the Group Manager are specified in . Upon receiving a request from the Administrator targeting the group-configuration resource or a group-collection resource, the Group Manager MUST check that it is storing a valid Access Token for that Administrator. If this is not the case, the Group Manager MUST reply with a 4.01 (Unauthorized) error response. If the request targets the group-configuration resource associated to a group with name GROUPNAME, the Group Manager MUST check that it is storing a valid Access Token from that Administrator, such that the 'scope' claim specified in the Access Token has the format defined in and includes a scope entry where:
   • The group name GROUPNAME matches with the wildcard pattern specified in the scope entry; and
   • The permission set specified in the scope entry allows the Administrator to perform the requested operation on the targeted group-configuration resource.
   Further details are defined separately for each operation specified in . In case the Group Manager stores a valid Access Token but the verifications above fail, the Group Manager MUST reply with a 4.03 (Forbidden) error response. This response MAY be an AS Request Creation Hints, as defined in , in which case the Content-Format MUST be set to application/ace+cbor. If the request is not formatted correctly (e.g., required fields are not present or are not encoded as expected), the Group Manager MUST reply with a 4.00 (Bad Request) error response.

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

Group Configuration Representation The group configuration representation is a CBOR map which MUST include configuration properties and status properties.

Configuration Properties The CBOR map MUST include the following configuration parameters, whose CBOR abbreviations are defined in of this document.

• 'hkdf', which specifies the HKDF Algorithm used in the OSCORE group, encoded as a CBOR text string or a CBOR integer. Possible values are the same ones admitted for the 'hkdf' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'cred_fmt', which specifies the format of authentication credentials used in the OSCORE group, encoded as a CBOR integer. Possible values are the same ones admitted for the 'cred_fmt' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'group_mode', encoded as a CBOR simple value. Its value is "true" (0xf5) if the OSCORE group uses the group mode of Group OSCORE , or "false" (0xf4) otherwise.
• 'sign_enc_alg', which is formatted as follows. If the configuration parameter 'group_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the Signature Encryption Algorithm used in the OSCORE group to encrypt messages protected with the group mode, encoded as a CBOR text string or a CBOR integer. Possible values are the same ones admitted for the 'sign_enc_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'sign_alg', which is formatted as follows. If the configuration parameter 'group_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the Signature Algorithm used in the OSCORE group, encoded as a CBOR text string or a CBOR integer. Possible values are the same ones admitted for the 'sign_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'sign_params', which is formatted as follows. If the configuration parameter 'group_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the additional parameters for the Signature Algorithm used in the OSCORE group, encoded as a CBOR array. Possible formats and values are the same ones admitted for the 'sign_params' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'pairwise_mode', encoded as a CBOR simple value. Its value is "true" (0xf5) if the OSCORE group uses the pairwise mode of Group OSCORE , or "false" (0xf4) otherwise.
• 'alg', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the AEAD Algorithm used in the OSCORE group to encrypt messages protected with the pairwise mode, encoded as a CBOR text string or a CBOR integer. Possible values are the same ones admitted for the 'alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'ecdh_alg', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the Pairwise Key Agreement Algorithm used in the OSCORE group, encoded as a CBOR text string or a CBOR integer. Possible values are the same ones admitted for the 'ecdh_alg' parameter of the Group_OSCORE_Input_Material object, defined in .
• 'ecdh_params', which is formatted as follows. If the configuration parameter 'pairwise_mode' has value "false" (0xf4), this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this parameter specifies the parameters for the Pairwise Key Agreement Algorithm used in the OSCORE group, encoded as a CBOR array. Possible formats and values are the same ones admitted for the 'ecdh_params' parameter of the Group_OSCORE_Input_Material object, defined in .

The CBOR map MAY include the following configuration parameters, whose CBOR abbreviations are defined in of this document.

• 'det_req', encoded as a CBOR simple value. Its value is "true" (0xf5) if the OSCORE group uses deterministic requests as defined in , or "false" (0xf4) otherwise. This parameter MUST NOT be present if the configuration parameter 'group_mode' has value "false" (0xf4).
• 'det_hash_alg', encoded as a CBOR integer or text string. If present, this parameter specifies the Hash Algorithm used in the OSCORE group when producing deterministic requests, as defined in . This parameter takes values from the "Value" column of the "COSE Algorithms" Registry . This parameter MUST NOT be present if the configuration parameter 'det_req' is not present or if it is present with value "false" (0xf4). If the configuration parameter 'det_req' is present with value "true" (0xf5) and 'det_hash_alg' is not present, the choice of the Hash Algorithm to use when producing deterministic requests is left to the Group Manager.

Status Properties The CBOR map MUST include the following status parameters:

• 'rt', with value the resource type "core.osc.gconf" associated with group-configuration resources, encoded as a CBOR text string.
• 'active', encoding the CBOR simple value "true" (0xf5) if the OSCORE group is currently active, or the CBOR simple value "false" (0xf4) otherwise. This parameter is defined in of this document.
• 'group_name', with value the group name of the OSCORE group encoded as a CBOR text string. This parameter is defined in of this document.
• 'group_title', with value either a human-readable description of the OSCORE group encoded as a CBOR text string, or the CBOR simple value "null" (0xf6) if no description is specified. This parameter is defined in of this document.
• 'ace-groupcomm-profile', defined in Section 4.3.1 of , with value "coap_group_oscore_app" defined in encoded as a CBOR integer.
• 'exp', defined in .
• 'app_groups', with value a list of names of application groups, encoded as a CBOR array. Each element of the array is a CBOR text string, specifying the name of an application group using the OSCORE group as security group (see ).
• 'joining_uri', with value the URI of the group-membership resource for joining the newly created OSCORE group as per , encoded as a CBOR text string. This parameter is defined in of this document.

The CBOR map MAY include the following status parameters:

• 'group_policies', defined in , and consistent with the format and content defined in .
• 'max_stale_sets', defined in of this document and encoded as a CBOR unsigned integer, with value strictly greater than 1. With reference to , this parameter specifies N, i.e., the maximum number of sets of stale OSCORE Sender IDs that the Group Manager stores in the collection associated with the group.
• 'as_uri', defined in of this document, specifies the URI of the Authorization Server associated with the Group Manager for the OSCORE group, encoded as a CBOR text string. Candidate group members will have to obtain an Access Token from that Authorization Server, before starting the joining process with the Group Manager to join the OSCORE group (see Sections and of ).

Default Values This section defines the default values that the Group Manager assumes for configuration and status parameters.

Configuration Parameters For each configuration parameter, the Group Manager MUST use a pre-configured default value, if none is specified by the Administrator. In particular:

• For 'group_mode', the Group Manager SHOULD use the CBOR simple value "true" (0xf5).
• If 'group_mode' has value "true" (0xf5), the Group Manager SHOULD use the same default values defined in for the parameters 'sign_enc_alg', 'sign_alg' and 'sign_params'.
• If 'group_mode' has value "true" (0xf5), the Group Manager SHOULD use the CBOR simple value "false" (0xf4) for the parameter 'det_req'.
• If 'det_req' has value "true" (0xf5), the Group Manager SHOULD use SHA-256 (COSE algorithm encoding: -16) as default value for the parameter 'det_hash_alg'.
• For 'pairwise_mode', the Group Manager SHOULD use the CBOR simple value "false" (0xf4).
• If 'pairwise_mode' has value "true" (0xf5), the Group Manager SHOULD use the same default values defined in for the parameters 'alg', 'ecdh_alg' and 'ecdh_params'.
• For any other configuration parameter, the Group Manager SHOULD use the same default values defined in .

Status Parameters For the following status parameters, the Group Manager MUST use a pre-configured default value, if none is specified by the Administrator. In particular:

• For 'active', the Group Manager SHOULD use the CBOR simple value "false" (0xf4).
• For 'group_title', the Group Manager SHOULD use the CBOR simple value "null" (0xf6).
• For 'app_groups', the Group Manager SHOULD use the empty CBOR array.
• For 'group_policies', the Group Manager SHOULD use the default values defined in .

Interactions with the Group Manager This section describes the operations available on the group-collection resource and the group-configuration resources. When custom CBOR is used, the Content-Format in messages containing a payload is set to application/ace-groupcomm+cbor, defined in . Furthermore, the entry labels defined in of this document MUST be used, when specifying the corresponding configuration and status parameters.

Retrieve the Full List of Group Configurations 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. This is returned as a list of links to the corresponding group-configuration resources. The Group Manager MUST prepare the list L to include in the response as follows. For each group-configuration resource R:

1. The Group Manager considers the group name GROUPNAME of the OSCORE group associated to R.
2. The Group Manager retrieves the stored Access Token for the Administrator. Then, it checks whether GROUPNAME matches with the group name pattern specified in any scope entry of the 'scope' claim in the Access Token.
3. The link to the group-configuration resource R is added to the list L only in case of a positive match.

Example in Link Format: 0.01 GET Uri-Path: manage <= 2.05 Content Content-Format: 40 (application/link-format) ;rt="core.osc.gconf", ;rt="core.osc.gconf", ;rt="core.osc.gconf" ]]> Example in CoRAL: 0.01 GET Uri-Path: manage <= 2.05 Content Content-Format: TBD1 (application/coral+cbor) #using #base item item item ]]>

Retrieve a List of Group Configurations by Filters 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. This is returned as a list of links to the corresponding group-configuration resources. When custom CBOR is used, the set of filter criteria is specified in the request payload as a CBOR map, whose possible entries are specified in and use the same abbreviations defined in . Entry values are the ones admitted for the corresponding labels in the POST request for creating a group configuration (see ). A valid request MUST NOT include the same entry multiple times. When CoRAL is used, the filter criteria are specified in the request payload with top-level elements, each of which corresponds to an entry specified in , with the exception of the 'app_groups' status parameter. 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 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 ). The Group Manager MUST prepare the list L to include in the response as follows.

1. The Group Manager prepares a preliminary version of the list L, as specified in for the processing of a GET request to the group-collection resource.
2. The Group Manager applies the filter criteria specified in the FETCH request to the list L from the previous step. The result is the list L to include in the response.

Example in custom CBOR and Link Format: 0.05 FETCH Uri-Path: manage Content-Format: TBD2 (application/ace-groupcomm+cbor) { "group_mode" : true, "sign_enc_alg" : 10, "hkdf" : 5 } <= 2.05 Content Content-Format: 40 (application/link-format) ;rt="core.osc.gconf", ;rt="core.osc.gconf", ;rt="core.osc.gconf" ]]> Example in CoRAL: 0.05 FETCH Uri-Path: manage Content-Format: TBD1 (application/coral+cbor) group_mode true sign_enc_alg 10 hkdf 5 <= 2.05 Content Content-Format: TBD1 (application/coral+cbor) #using #base item item item ]]>

Create a New Group Configuration 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 request MUST specify the intended group name GROUPNAME, and MAY specify the intended group title together with pieces of information concerning the group configuration. When custom CBOR is used, the request payload is a CBOR map, whose possible entries are specified in and use the same abbreviations defined in . When CoRAL is used, each element of the request payload corresponds to an entry specified in , with the exception of the 'app_groups' status parameter (see below). In particular:

• The payload MAY include any of the configuration parameter defined in .
• The payload MUST include the status parameter 'group_name' defined in and specifying the intended group name.
• The payload MAY include any of the status parameter 'group_title', 'max_stale_sets', 'exp', 'app_groups, 'group_policies', 'as_uri' and 'active' defined in . When CoRAL is used, each element of the 'app_groups' array from the status properties is included as a separate element with name 'app_group'.
• The payload MUST NOT include any of the status parameter 'rt', 'ace-groupcomm-profile' and 'joining_uri' defined in .

Consistently with what is defined at step 4 of , the Group Manager MUST check whether the group name specified in the 'group_name' parameter matches with the group name pattern specified in any scope entry of the 'scope' claim in the stored Access Token for the Administrator. In case of a positive match, the Group Manager MUST check whether the permission set in the found scope entry specifies the permission "Create". If the verification above fails (i.e., there are no matching scope entries specifying the "Create" permission), the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . Otherwise, if any of the following occurs, the Group Manager MUST respond with a 4.00 (Bad Request) response.

• Any of the received parameters is specified multiple times, with the exception of the 'app_group' element when using CoRAL.
• Any of the received parameters is not recognized, or not valid, or not consistent with respect to other related parameters.
• The Group Manager does not trust the Authorization Server with URI specified in the 'as_uri' parameter, and has no alternative Authorization Server to consider for the OSCORE group to create.

After a successful processing of the POST request, the Group Manager performs the following actions. If the 'group_name' parameter specifies the group name of an already existing OSCORE group, the Group Manager MUST find an alternative name for the new OSCORE group to create. Note that the final decision about the name assigned to the new OSCORE group is always of the Group Manager, which may have more constraints than the Administrator can be aware of, possibly beyond the availability of suggested names. If the Group Manager has selected a name GROUPNAME different from the name GROUPNAME* indicated in the parameter 'group_name' of the request, then the following conditions MUST hold.

• The chosen name GROUPNAME is available to assign; and
• If GROUPNAME* matches with the group name pattern of certain scope entries from the 'scope' claim in the stored Access Token for the Administrator, then the chosen group name GROUPNAME also matches with each of those group name patterns.

If the Group Manager does not find any group name for which both the above conditions hold, the Group Manager MUST respond with a 5.03 (Service Unavailable) response. Otherwise, the Group Manager creates a new group-configuration resource, accessible to the Administrator at /manage/GROUPNAME, where GROUPNAME is the name of the OSCORE group as either indicated in the parameter 'group_name' of the request or uniquely assigned by the Group Manager. The value of the status parameter 'rt' is set to "core.osc.gconf". The values of other parameters specified in the request are used as group configuration information for the newly created OSCORE group. For each parameter not specified in the request, the Group Manager MUST use default values as specified in . After that, the Group Manager creates a new group-membership resource accessible at ace-group/GROUPNAME to nodes that want to join the OSCORE group, as specified in . Note that such group membership-resource comprises a number of sub-resources intended to current group members, as defined in and . From then on, the Group Manager will rely on the current group configuration to build the Joining Response message defined in , when handling the joining of a new group member. Furthermore, the Group Manager generates the following pieces of information, and assigns them to the newly created OSCORE group.

• The OSCORE Master Secret.
• The OSCORE Master Salt (optionally).
• The Group ID, used as OSCORE ID Context, which MUST be unique within the set of OSCORE groups under the Group Manager.

Finally, the Group Manager replies to the Administrator with a 2.01 (Created) response. The Location-Path option MUST be included in the response, indicating the location of the just created group-configuration resource. The response MUST NOT include a Location-Query option. The response payload specifies the parameters 'group_name', 'joining_uri' and 'as_uri', from the status properties of the newly created OSCORE group (see ), as detailed below. When custom CBOR is used, the response payload is a CBOR map, where entries use the same abbreviations defined in . When CoRAL is used, the response payload includes one element for each specified parameter.

• 'group_name', with value the group name of the OSCORE group. This value can be different from the group name possibly specified by the Administrator in the POST request, and reflects the final choice of the Group Manager as 'group_name' status property for the OSCORE group. This parameter MUST be included.
• 'joining_uri', with value the URI of the group-membership resource for joining the newly created OSCORE group. This parameter MUST be included.
• 'as_uri', with value the URI of the Authorization Server associated with the Group Manager for the newly created OSCORE group. This parameter MUST be included if specified in the status properties of the group. This value can be different from the URI possibly specified by the Administrator in the POST request, and reflects the final choice of the Group Manager as 'as_uri' status property for the OSCORE group.

If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in , then the response payload MUST include also those parameters, specifying the values chosen by the Group Manager for the current group configuration. The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory , as defined in . The Group Manager considers the current group configuration when specifying additional information for the link to register. Alternatively, the Administrator can perform the registration in the Resource Directory on behalf of the Group Manager, acting as Commissioning Tool. The Administrator considers the following when specifying additional information for the link to register.

• The name of the OSCORE group MUST take the value specified in 'group_name' from the 2.01 (Created) response.
• The names of the application groups using the OSCORE group MUST take the values possibly specified by the elements of the 'app_groups' parameter (when custom CBOR is used) or by the different 'app_group' elements (when CoRAL is used) in the POST request.
• If also registering a related link to the Authorization Server associated with the OSCORE group, the related link MUST have as link target the URI in 'as_uri' from the 2.01 (Created) response, if the 'as_uri' parameter was included in the response.
• Every other information element describing the current group configuration MUST take the value that the Administrator specified in the POST request. If a certain parameter was not specified in the POST request, the Administrator MUST use either the value specified in the the 2.01 (Created) response, if the Group Manager specified one, or the corresponding default value recommended in otherwise.

Note that, compared to the Group Manager, the Administrator is less likely to remain closely aligned with possible changes and updates that would require a prompt update to the registration in the Resource Directory. This applies especially to the address of the Group Manager, as well as the URI of the group-membership resource or of the Authorization Server associated with the Group Manager. Therefore, it is RECOMMENDED that registrations of links to group-membership resources in the Resource Directory are made (and possibly updated) directly by the Group Manager, rather than by the Administrator. Example in custom CBOR: 0.02 POST Uri-Path: manage Content-Format: TBD2 (application/ace-groupcomm+cbor) { "sign_enc_alg" : 10, "hkdf" : 5, "pairwise_mode" : true, "active" : true, "group_name" : "gp4", "group_title" : "rooms 1 and 2", "app_groups": : ["room1", "room2"], "as_uri" : "coap://as.example.com/token" } <= 2.01 Created Location-Path: manage Location-Path: gp4 Content-Format: TBD2 (application/ace-groupcomm+cbor) { "group_name" : "gp4", "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", "as_uri" : "coap://as.example.com/token" } ]]> Example in CoRAL: 0.02 POST Uri-Path: manage Content-Format: TBD1 (application/coral+cbor) #using sign_enc_alg 10 hkdf 5 pairwise_mode true active true group_name "gp4" group_title "rooms 1 and 2" app_group "room1" app_group "room2" as_uri <= 2.01 Created Location-Path: manage Location-Path: gp4 Content-Format: TBD1 (application/coral+cbor) #using group_name "gp4" joining_uri as_uri ]]>

Retrieve a Group Configuration 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. Consistently with what is defined at step 4 of , the Group Manager MUST check whether GROUPNAME matches with the group name pattern specified in any scope entry of the 'scope' claim in the stored Access Token for the Administrator. In case of a positive match, the Group Manager MUST check whether the permission set in the found scope entry specifies the permission "Read". If the verification above fails (i.e., there are no matching scope entries specifying the "Read" permission), the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . Otherwise, after a successful processing of the GET request, the Group Manager replies to the Administrator with a 2.05 (Content) response. The response has as payload the representation of the group configuration as specified in . The exact content of the payload reflects the current configuration of the OSCORE group. This includes both configuration properties and status properties. When custom CBOR is used, the response payload is a CBOR map, whose possible entries are specified in and use the same abbreviations defined in . When CoRAL is used, the response payload includes one element for each entry specified in , with the exception of the 'app_groups' status parameter. That is, each element of the 'app_groups' array from the status properties is included as a separate element with name 'app_group'. Example in custom CBOR: 0.01 GET Uri-Path: manage Uri-Path: gp4 <= 2.05 Content Content-Format: TBD2 (application/ace-groupcomm+cbor) { "hkdf" : 5, "cred_fmt" : 33, "group_mode" : true, "sign_enc_alg" : 10, "sign_alg" : -8, "sign_params" : [[1], [1, 6]], "pairwise_mode" : true, "alg" : 10, "ecdh_alg" : -27, "ecdh_params" : [[1], [1, 6]], "rt" : "core.osc.gconf", "active" : true, "group_name" : "gp4", "group_title" : "rooms 1 and 2", "ace-groupcomm-profile" : "coap_group_oscore_app", "max_stale_sets" : 3, "exp" : 1360289224, "app_groups": : ["room1", "room2"], "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", "as_uri" : "coap://as.example.com/token" } ]]> Example in CoRAL: 0.01 GET Uri-Path: manage Uri-Path: gp4 <= 2.05 Content Content-Format: TBD1 (application/coral+cbor) #using hkdf 5 cred_fmt 33 group_mode true sign_enc_alg 10 sign_alg -8 sign_params.alg_capab.key_type 1 sign_params.key_type_capab.key_type 1 sign_params.key_type_capab.curve 6 pairwise_mode true alg 10 ecdh_alg -27 ecdh_params.alg_capab.key_type 1 ecdh_params.key_type_capab.key_type 1 ecdh_params.key_type_capab.curve 6 rt "core.osc.gconf", active true group_name "gp4" group_title "rooms 1 and 2" ace-groupcomm-profile "coap_group_oscore_app" max_stale_sets 3 exp 1360289224 app_group "room1" app_group "room2" joining_uri as_uri ]]>

Retrieve Part of a Group Configuration by Filters 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. When custom CBOR is used, the request payload is a CBOR map, which contains the following fields:

• 'conf_filter', defined in of this document and encoded as a CBOR array. Each element of the array specifies one requested configuration parameter or status parameter of the current group configuration (see ), using the corresponding abbreviation defined in .

When CoRAL is used, the request payload includes one element for each requested configuration parameter or status parameter of the current group configuration (see ). All the specified elements have no value. The Group Manager MUST perform the same authorization checks defined for the processing of a GET request to a group-configuration resource in . That is, the Group Manager MUST verify that the Administrator has been granted a "Read" permission applicable to the targeted group-configuration resource. After a successful processing of the FETCH request, the Group Manager replies to the Administrator with a 2.05 (Content) response. The response has as payload a partial representation of the group configuration (see ). The exact content of the payload reflects the current configuration of the OSCORE group, and is limited to the configuration properties and status properties requested by the Administrator in the FETCH request. 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 ). Example in custom CBOR: 0.05 FETCH Uri-Path: manage Uri-Path: gp4 Content-Format: TBD2 (application/ace-groupcomm+cbor) { "conf_filter" : ["sign_enc_alg", "hkdf", "pairwise_mode", "active", "group_title", "app_groups"] } <= 2.05 Content Content-Format: TBD2 (application/ace-groupcomm+cbor) { "sign_enc_alg" : 10, "hkdf" : 5, "pairwise_mode" : true, "active" : true, "group_title" : "rooms 1 and 2", "app_groups": : ["room1", "room2"] } ]]> Example in CoRAL: 0.05 FETCH Uri-Path: manage Uri-Path: gp4 Content-Format: TBD1 (application/coral+cbor) #using sign_enc_alg hkdf pairwise_mode active group_title app_groups <= 2.05 Content Content-Format: TBD1 (application/coral+cbor) #using sign_enc_alg 10 hkdf 5 pairwise_mode true active true group_title "rooms 1 and 2" app_group "room1" app_group "room2" ]]>

Overwrite a Group Configuration The Administrator can send a PUT request to the group-configuration resource associated with an OSCORE group, in order to overwrite the current configuration of that group with a new one. The payload of the request has the same format of the POST request defined in , with the exception that the configuration parameters 'group_mode' and 'pairwise_mode' as well as the status parameter 'group_name' MUST NOT be included. The error handling for the PUT request is the same as for the POST request defined in , with the following difference in terms of authorization checks. Consistently with what is defined at step 4 of , the Group Manager MUST check whether GROUPNAME matches with the group name pattern specified in any scope entry of the 'scope' claim in the stored Access Token for the Administrator. In case of a positive match, the Group Manager MUST check whether the permission set in the found scope entry specifies the permission "Write". If the verification above fails (i.e., there are no matching scope entries specifying the "Write" permission), the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . If no error occurs and the PUT request is successfully processed, the Group Manager performs the following actions. First, the Group Manager updates the group-configuration resource, consistently with the values indicated in the PUT request from the Administrator. For each parameter not specified in the PUT request, the Group Manager MUST use default values as specified in . If a new value N' is specified for the 'max_stale_sets' status parameter and N' is smaller than the current value N, the Group Manager preserves the (up to) N' most recent sets in the collection of sets of stale OSCORE Sender IDs associated with the group, and deletes any possible older set from the collection (see ). From then on, the Group Manager relies on the latest updated configuration to build the Joining Response message defined in , when handling the joining of a new group member. Similarly, the Group Manager relies on the new group configuration when building responses specifying (part of) the group configuration to a current group member. For instance, this applies when a group member retrieves from the Group Manager the updated group keying material (see ) or the current group status (see ). Then, the Group Manager replies to the Administrator with a 2.04 (Changed) response. The payload of the response has the same format of the 2.01 (Created) response defined in . If the PUT request did not specify certain parameters and the Group Manager used default values different from the ones recommended in , then the response payload MUST include also those parameters, specifying the values chosen by the Group Manager for the current group configuration. If the link to the group-membership resource was registered in the Resource Directory , the GM is responsible to refresh the registration, as defined in . Alternatively, the Administrator can update the registration in the Resource Directory on behalf of the Group Manager, acting as Commissioning Tool. The Administrator considers the following when specifying additional information for the link to update.

• The name of the OSCORE group MUST take the value specified in 'group_name' from the 2.04 (Changed) response.
• The names of the application groups using the OSCORE group MUST take the values possibly specified by the elements of the 'app_groups' parameter (when custom CBOR is used) or by the different 'app_group' elements (when CoRAL is used) in the PUT request.
• If also registering a related link to the Authorization Server associated with the OSCORE group, the related link MUST have as link target the URI in 'as_uri' from the 2.04 (Changed) response, if the 'as_uri' parameter was included in the response.
• Every other information element describing the current group configuration MUST take the value that the Administrator specified in the PUT request. If a certain parameter was not specified in the PUT request, the Administrator MUST use either the value specified in the the 2.04 (Changed) response, if the Group Manager specified one, or the corresponding default value recommended in otherwise.

As discussed in , it is RECOMMENDED that registrations of links to group-membership resources in the Resource Directory are made (and possibly updated) directly by the Group Manager, rather than by the Administrator. Example in custom CBOR: 0.03 PUT Uri-Path: manage Uri-Path: gp4 Content-Format: TBD2 (application/ace-groupcomm+cbor) { "sign_enc_alg" : 11, "hkdf" : 5 } <= 2.04 Changed Content-Format: TBD2 (application/ace-groupcomm+cbor) { "group_name" : "gp4", "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", "as_uri" : "coap://as.example.com/token" } ]]> Example in CoRAL: 0.03 PUT Uri-Path: manage Uri-Path: gp4 Content-Format: TBD1 (application/coral+cbor) #using sign_enc_alg 11 hkdf 5 <= 2.04 Changed Content-Format: TBD1 (application/coral+cbor) #using group_name "gp4" joining_uri as_uri ]]>

Effects on Joining Nodes After having overwritten a group configuration, if the value of the status parameter 'active' is changed from "true" (0xf5) to "false" (0xf4), the Group Manager MUST stop admitting new members in the OSCORE group. In particular, until the status parameter 'active' is changed back to "true" (0xf5), the Group Manager MUST respond to a Joining Request with a 5.03 (Service Unavailable) response, as defined in . If the value of the status parameter 'active' is changed from "false" (0xf4) to "true" (0xf5), the Group Manager resumes admitting new members in the OSCORE group, by processing their Joining Requests (see ).

Effects on the Group Members After having overwritten a group configuration, the Group Manager informs the members of the OSCORE group, over the pairwise secure communication channels established when joining the group (see ). To this end, the Group Manager can individually target the 'control_uri' URI of each group member (see ), if provided by the intended recipient upon joining the OSCORE group (see ). To this end, messages sent by the Group Manager to each group member MUST have Content-Format set to application/ace-groupcomm+cbor, and MUST be formatted as the Joining Response defined in , with the following differences.

• Only the parameters 'gkty', 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present.
• The 'key' parameter includes only the parameters 'hkdf', 'cred_fmt', 'sign_enc_alg', 'sign_alg', 'sign_params', 'alg', 'ecdh_alg' and 'ecdh_params', with values reflecting the new configuration of the OSCORE group.

Alternatively, group members can subscribe for updates to the group-membership resource of the OSCORE group, e.g., by using CoAP Observe . If the value of the status parameter 'active' is changed from "true" (0xf5) to "false" (0xf4):

• The Group Manager MUST stop accepting requests for new individual keying material from current group members (see ). In particular, until the status parameter 'active' is changed back to "true" (0xf5), the Group Manager MUST respond to a Key Renewal Request with a 5.03 (Service Unavailable) response, as defined in .
• The Group Manager MUST stop accepting updated authentication credentials uploaded by current group members (see ). In particular, until the status parameter 'active' is changed back to "true" (0xf5), the Group Manager MUST respond to a Public Key Update Request with a 5.03 (Service Unavailable) response, as defined in .

Every group member, upon learning that the OSCORE group has been deactivated (i.e., 'active' has value "false" (0xf4)), SHOULD stop communicating in the group. Every group member, upon learning that the OSCORE group has been reactivated (i.e., 'active' has value "true" (0xf5) again), can resume communicating in the group. Every group member, upon receiving updated values for 'hkdf', 'sign_enc_alg' and 'alg', MUST either:

• Leave the OSCORE group (see ), e.g., if not supporting the indicated new algorithms; or
• Use the new parameter values, and accordingly re-derive the OSCORE Security Context for the OSCORE group (see ).

Every group member, upon receiving updated values for 'cred_fmt', 'sign_alg', 'sign_params', 'ecdh_alg' and 'ecdh_params' MUST either:

• Leave the OSCORE group, e.g., if not supporting the indicated new format, algorithms, parameters and encoding; or
• Leave the OSCORE group and rejoin it (see ). When rejoining the group, a new authentication credential in the indicated format used in the OSCORE group MUST be provided to the Group Manager. The authentication credential as well as the included public key MUST be compatible with the indicated algorithms and parameters.
• Use the new parameter values, and, if required, perform the following actions.
  • Provide the Group Manager with a new authentication credential to use in the OSCORE group (see ). The new authentication credential MUST be in the indicated format used in the OSCORE group. The new authentication credential as well as the included public key MUST be compatible with the indicated algorithms and parameters.
  • Retrieve from the Group Manager the new Group Manager's authentication credential (see ). The new Group Manager's authentication credential is in the indicated format used in the OSCORE group. The new authentication credential as well as the included public key are compatible with the indicated algorithms and parameters.

Selective Update of a Group Configuration The Administrator can send a PATCH/iPATCH request to the group-configuration resource associated with an OSCORE group, in order to update the value of only part of the group configuration. The request payload has the same format of the PUT request defined in , with the difference that it MAY also specify names of application groups to be removed from or added to the 'app_groups' status parameter. The names of such application groups are provided as defined below.

• When custom CBOR is used, the CBOR map in the request payload includes the field 'app_groups_diff'. This field MUST NOT be present multiple times, and it is encoded as a CBOR array including the following two elements.
  • The first element is a CBOR array, namely 'app_groups_del'. Each of its elements is a CBOR text string, with value the name of an application group to remove from the 'app_groups' status parameter.
  • The second element is a CBOR array, namely 'app_groups_add'. Each of its elements is a CBOR text string, with value the name of an application group to add to the 'app_groups' status parameter.
  The CDDL definition of the CBOR array 'app_groups_diff' formatted as in the response from the Group Manager is provided below.

CDDL definition of the 'app_groups_diff' field

The Group Manager MUST respond with a 4.00 (Bad Request) response, in case both the inner CBOR arrays 'app_groups_del' and 'app_groups_add' are empty, or in case the 'app_groups_diff' field occurs more than once. The Group Manager MUST respond with a 4.00 (Bad Request) response, in case the CBOR map in the request payload includes both the 'app_groups' field and the 'app_groups_diff' field.

• When CoRAL is used, the request payload includes the following top-level 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 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 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' element as well as any 'app_group_del' and/or 'app_group_add' element.

The error handling for the PATCH/iPATCH request is the same as for the PUT request defined in , with the following additions.

• The set of group configuration parameters to update MUST NOT be empty. That is, the Group Manager MUST respond with a 4.00 (Bad Request) response, if the request payload includes an empty CBOR map (when custom CBOR is used) or no elements (when CoRAL is used).
• If the Request-URI does not point to an existing group-configuration resource, the Group Manager MUST NOT create a new resource, and MUST respond with a 4.04 (Not Found) response.
• When applying the specified updated values would yield an inconsistent group configuration, the Group Manager MUST respond with a 4.09 (Conflict) response. The response, MAY include the current representation of the group configuration resource, like when responding to a GET request as defined in . Otherwise, the response SHOULD include a diagnostic payload with additional information for the Administrator to recognize the source of the conflict.
• When the request uses specifically the iPATCH method, the Group Manager MUST respond with a 4.00 (Bad Request) response, in case:
  • When custom CBOR is used, the CBOR map includes the parameter 'app_groups_diff'; or
  • When CoRAL is used, any element 'app_group_del' and/or 'app_group_add' is included.

Furthermore, the Group Manager MUST perform the same authorization checks defined for the processing of a PUT request to a group-configuration resource in . That is, the Group Manager MUST verify that the Administrator has been granted a "Write" permission applicable to the targeted group-configuration resource. If no error occurs and the PATCH/iPATCH request is successfully processed, the Group Manager performs the following actions. First, the Group Manager updates the group-configuration resource, consistently with the values indicated in the PATCH/iPATCH request from the Administrator. Unlike for the PUT request defined in , the Group Manager does not alter the value of configuration parameters and status parameters for which updated values are not specified in the request payload. In particular, the Group Manager does not assign possible default values to those parameters. Special processing occurs when updating the 'app_groups' status parameter by difference, as defined below. The Administrator should not expect the Group Manager to add or delete names of application group names according to any particular order.

• If the name of an application group to add (delete) is specified multiple times, the Group Manager considers it only once for addition to (deletion from) the 'app_groups' status parameter.
• If the name of an application group to delete is not present in the 'app_groups' status parameter before any change is applied, the Group Manager ignores that name.
• If the name of an application group to add is already present in the 'app_groups' status parameter before any change is applied, the Group Manager ignores that name.
• When custom CBOR is used, the Group Manager:
  • Deletes from the 'app_groups' status parameter the names of the application groups specified in the inner 'app_groups_del' CBOR array of the 'app_groups_diff' field.
  • Adds to the 'app_groups' status parameter the names of the application groups specified in the inner 'app_groups_add' CBOR array of the 'app_groups_diff' field.
• When CoRAL is used, the Group Manager:
  • Deletes from the 'app_groups' status parameter the names of the application groups specified in the different 'app_group_del' elements.
  • Adds to the 'app_groups' status parameter the names of the application groups specified in the different 'app_group_add' elements.

After having updated the group-configuration resource, from then on the Group Manager relies on the new group configuration to build the Joining Response message defined in , when handling the joining of a new group member. Similarly, the Group Manager relies on the new group configuration when building responses specifying (part of) the group configuration to a current group member. For instance, this applies when a group member retrieves from the Group Manager the updated group keying material (see ) or the current group status (see ). Finally, the Group Manager replies to the Administrator with a 2.04 (Changed) response. The payload of the response has the same format of the 2.01 (Created) response defined in . The same considerations as for the PUT request defined in hold also in this case, with respect to refreshing a possible registration of the link to the group-membership resource in the Resource Directory . Example in custom CBOR: 0.06 PATCH Uri-Path: manage Uri-Path: gp4 Content-Format: TBD2 (application/ace-groupcomm+cbor) { "sign_enc_alg" : 10, "app_groups_diff" : [["room1"], ["room3", "room4"]] } <= 2.04 Changed Content-Format: TBD2 (application/ace-groupcomm+cbor) { "group_name" : "gp4", "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", "as_uri" : "coap://as.example.com/token" } ]]> Example in CoRAL: 0.06 PATCH Uri-Path: manage Uri-Path: gp4 Content-Format: TBD1 (application/coral+cbor) #using sign_enc_alg 10 app_group_del "room1" app_group_add "room3" app_group_add "room4" <= 2.04 Changed Content-Format: TBD1 (application/coral+cbor) #using group_name "gp4" joining_uri as_uri ]]>

Effects on Joining Nodes After having selectively updated part of a group configuration, the effects on candidate joining nodes are the same as defined in for the case of group configuration overwriting.

Effects on the Group Members After having selectively updated part of a group configuration, the effects on the current group members are the same as defined in for the case of group configuration overwriting.

Delete a Group Configuration The Administrator can send a DELETE request to the group-configuration resource, in order to delete that OSCORE group. Consistently with what is defined at step 4 of , the Group Manager MUST check whether GROUPNAME matches with the group name pattern specified in any scope entry of the 'scope' claim in the stored Access Token for the Administrator. In case of a positive match, the Group Manager MUST check whether the permission set in the found scope entry specifies the permission "Delete". If the verification above fails (i.e., there are no matching scope entries specifying the "Delete" permission), the Group Manager MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . Otherwise, the Group Manager continues processing the request, which would be successful only on an inactive OSCORE group. That is, the DELETE request actually yields a successful deletion of the OSCORE group, only if the corresponding status parameter 'active' has current value "false" (0xf4). The Administrator can ensure that, by first performing an update of the group-configuration resource associated with the OSCORE group (see ), and setting the corresponding status parameter 'active' to "false" (0xf4). If, upon receiving the DELETE request, the current value of the status parameter 'active' is "true" (0xf5), the Group Manager MUST respond with a 4.09 (Conflict) response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . The value of the 'error' field MUST be set to 8 ("Group currently active"). After a successful processing of the DELETE request, the Group Manager performs the following actions. First, the Group Manager deletes the OSCORE group and deallocates both the group-configuration resource as well as the group-membership resource associated with that group. Then, the Group Manager replies to the Administrator with a 2.02 (Deleted) response. Example: 0.04 DELETE Uri-Path: manage Uri-Path: gp4 <= 2.02 Deleted ]]>

Effects on the Group Members After having deleted an OSCORE group, the Group Manager can inform the group members by means of the following two methods. When contacting a group member, the Group Manager uses the pairwise secure communication association established with that member during its joining process (see ).

• The Group Manager sends an individual request message to each group member, targeting the respective resource used to perform the group rekeying process (see ). The Group Manager uses the same format of the Joining Response message in , where only the parameters 'gkty', 'key' and 'ace-groupcomm-profile' are present, and the 'key' parameter is the empty CBOR map.
• A group member may subscribe for updates to the group-membership resource associated with the OSCORE group. In particular, if this relies on CoAP Observe , a group member would receive a 4.04 (Not Found) notification response from the Group Manager, since the group-configuration resource has been deallocated upon deleting the OSCORE group (see ). The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in . The value of the 'error' field MUST be set to 5 ("Group deleted").

When being informed about the deletion of the OSCORE group, a group member deletes the OSCORE Security Context that it stores as associated with that group, and possibly deallocates any dedicated control resource intended for the Group Manager that it has for that group.

ACE Groupcomm Error Identifiers In addition to what is defined in , this document defines a new value that the Group Manager can include as error identifiers, in the 'error' field of an error response with Content-Format application/ace-groupcomm+cbor.

ACE Groupcomm Error Identifiers

A Client supporting the 'error' parameter (see Sections and of ) and able to understand the specified error may use that information to determine what actions to take next. If it is included in the error response and supported by the Client, the 'error_description' parameter may provide additional context. In particular, the following guidelines apply.

• In case of error 10, the Client should stop sending the request in question to the Group Manager, until the group becomes inactive. As per this document, this error is relevant only for the Administrator, if it tries to delete a group without having set its status to inactive first (see ). In such a case, the Administrator should take the expected course of actions, and set the group status to inactive first (see and ), before proceeding with the group deletion.

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 .

IANA Considerations RFC Editor: Please replace "[[this document]]" with the RFC number of this document and delete this paragraph. This document has the following actions for IANA.

ACE Groupcomm Parameters IANA is asked to register the following entries in the "ACE Groupcomm Parameters" registry defined in .

ACE Groupcomm Parameters

ACE Groupcomm Errors IANA is asked to register the following entry in the "ACE Groupcomm Errors" registry defined in .

• Value: 10
• Description: Group currently active.
• Reference: [[This document]]

Resource Types IANA is asked to enter the following values in the "Resource Type (rt=) Link Target Attribute Values" registry within the "Constrained Restful Environments (CoRE) Parameters" registry group.

Group OSCORE Admin Permissions This document establishes the IANA "Group OSCORE Admin Permissions" registry. The registry has been created to use the "Expert Review" registration procedure . Expert review guidelines are provided in . This registry includes the possible permissions that Administrators can have to perform operations on an OSCORE Group Manager, each in combination with a numeric identifier. These numeric identifiers are used to express authorization information about performing administrative operations concerning OSCORE groups under the control of the Group Manager, as specified in of [[this document]]. The columns of this registry are:

• Name: A value that can be used in documents for easier comprehension, to identify a possible permission that Administrators can perform when interacting with an OSCORE Group Manager.
• Value: The numeric identifier for this permission. Integer values greater than 65535 are marked as "Private Use", all other values use the registration policy "Expert Review" . Note that, in general, a single permission can be associated with multiple different operations that are possible to be performed when interacting with the Group Manager.
• Description: This field contains a brief description of the permission.
• Reference: This contains a pointer to the public specification for the permission.

This registry will be initially populated by the values in . The Reference column for all of these entries will be [[this document]].

AIF For the media-types application/aif+cbor and application/aif+json defined in , IANA is requested to register the following entries for the two media-type parameters Toid and Tperm, in the respective sub-registry defined in within the "MIME Media Type Sub-Parameter" registry group.

• Name: oscore-group-name-pattern
• Description/Specification: wildcard pattern of OSCORE group names
• Reference: [[This document]]

 

• Name: oscore-group-admin-permissions
• Description/Specification: permission(s) to perform administrative operations at the OSCORE Group Manager
• Reference: [[This document]]

CoAP Content-Format IANA is asked to register the following entries to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

• Media Type: application/aif+cbor;Toid="oscore-group-name-pattern",Tperm="oscore-group-admin-permissions"
• Encoding: -
• ID: TBD
• Reference: [[This document]]

 

• Media Type: application/aif+json;Toid="oscore-group-name-pattern",Tperm="oscore-group-admin-permissions"
• Encoding: -
• ID: TBD
• Reference: [[This document]]

ACE Scope Semantics IANA is asked to register the following entry in the "ACE Scope Semantics" registry defined in .

• Value: SEM_ID_TBD
• Description: Permissions to perform administrative operations at the ACE Group Manager for Group OSCORE.
• Reference: [[This document]]

Expert Review Instructions The IANA registry established in this document is defined as "Expert Review". This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points:

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts should inspect the entry for the considered permission, to verify the correctness of its description against the permission as intended in the specification that defined it. Expert should consider requesting an opinion on the correctness of registered parameters from the Authentication and Authorization for Constrained Environments (ACE) Working Group and the Constrained RESTful Environments (CoRE) Working Group. Entries that do not meet these objective of clarity and completeness should not be registered.
• Duplicated registration and point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments.
• Experts should take into account the expected usage of permissions when approving point assignment. Given a 'Value' V as code point, the length of the encoding of (2^(V+1) - 1) should be weighed against the usage of the entry, considering the resources and capabilities of devices it will be used on. Additionally, given a 'Value' V as code point, the length of the encoding of (2^(V+1) - 1) should be weighed against how many code points resulting in that encoding length are left, and the resources and capabilities of devices it will be used on.
• Specifications are recommended. When specifications are not provided, the description provided needs to have sufficient information to verify the points above.

References Normative References RISE AB Ericsson AB Ericsson AB Ericsson AB Universitaet Duisburg-Essen This document defines 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 approach 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. Combitech Ericsson Spotify AB Arm Ltd. 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. 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 secured with Group Object Security for Constrained RESTful Environments (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. Ericsson AB Combitech Ericsson AB RISE 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. 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. August Cellars Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined 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 [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. August Cellars Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined 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 XXXX. 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 RFC 7390, while it updates RFC 7252 and RFC 7641. Universität Bremen TZI 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 REST resources identified by URI path. 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. 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 Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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 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. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. 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. IANA Informative References Universität Bremen TZI Universität Bremen TZI Universität Bremen TZI Ericsson AB Combitech This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 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 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 intentionally 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. ARM SmartThings Universitaet Bremen TZI consultant In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. RISE AB Consultant Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. 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. RISE AB Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. 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. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. 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.

Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION.

Version -04 to -05

• Defined format of scope based on a new AIF data model.
• Specified authorization checks at the Group Manager.
• Revised resource handlers based on the new scope format.
• Renamed 'pub_key_enc' to 'cred_fmt'.
• Mandatory to include 'group_name' in the group creation request.
• Suggesting a used 'group_name' results in a new name, not in an error.
• Distinction between authentication credentials and public keys.
• More details on informing group members about changes in the group configuration.
• Revised order of sections; editorial improvements.

Version -03 to -04

• Clarifications on what to do in case of enhanced error responses.
• Clarifications on handling default values for group parameters.
• New configuration parameters to support OSCORE deterministic requests.
• IANA considerations - Use RFC8126 terminology.
• Author's change of address.
• Editorial improvements.

Version -02 to -03

• Aligned new and old parameters to core-groupcomm-oscore and ace-key-groupcomm-oscore.
• Removed 'cs_key_params' and 'ecdh_key_params' to avoid redundant COSE capabilities of key types, consistently with draft-ietf-ace-key-groupcomm-oscore.
• Revised examples and side effects due to parameter changes.
• New error type "Group currently active".

Version -01 to -02

• Admit multiple Administrators and limited access to admin resources.
• Early design considerations for defining the format of scope.
• Additional error handling, using also error types.
• Selective update of group-configuration resources with PATCH/iPATCH.
• Editorial improvements.

Version -00 to -01

• Names of application groups as status parameter.
• Parameters related to the pairwise mode of Group OSCORE.
• Defined FETCH for group-configuration resources.
• Policies on registration of links to the Resource Directory.
• Added resource type for group-configuration resources.
• Fixes, clarifications and editorial improvements.

Acknowledgments Klaus Hartke provided substantial contribution in defining the resource model based on group collection and group configurations, as well as the interactions with the Group Manager using CoRAL. The authors sincerely thank Christian Amsuess, Carsten Bormann and Jim Schaad 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).