]> RISE AB

Isafjordsgatan 22 Kista 164 29 Stockholm Sweden marco.tiloca@ri.se

Universitaet Duisburg-Essen

Schuetzenbahn 70 Essen 45127 Germany ji-ye.park@uni-due.de

Ericsson AB

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

Security ACE Working Group Internet-Draft This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token.

Introduction Object Security for Constrained RESTful Environments (OSCORE) is a method for application-layer protection of the Constrained Application Protocol (CoAP) , using CBOR Object Signing and Encryption (COSE) and enabling end-to-end security of CoAP payload and options. As described in , Group OSCORE is used to protect CoAP group communication , which can employ, for example, IP multicast as underlying data transport. This relies on a Group Manager, which is responsible for managing an OSCORE group and enables the group members to exchange CoAP messages secured with Group OSCORE. The Group Manager can be responsible for multiple groups, coordinates the joining process of new group members, and is entrusted with the distribution and renewal of group keying material. This document is an application profile of , which itself builds on the ACE framework for Authentication and Authorization . Message exchanges among the participants as well as message formats and processing follow what specified in for provisioning and renewing keying material in group communication scenarios, where Group OSCORE is used to protect CoAP group communication.

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 described in the ACE framework for authentication and authorization and in the Authorization Information Format (AIF) to express authorization information. 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 terms and concept related to the message formats and processing specified in , for provisioning and renewing keying material in group communication scenarios.
• The terms and concepts described in CBOR and COSE .
• The terms and concepts described in CoAP and group communication for CoAP . 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".
• The terms and concepts for protection and processing of CoAP messages through OSCORE and through Group OSCORE in group communication scenarios. These especially include:
  • Group Manager, as the entity responsible for a set of groups where communications are secured with Group OSCORE. In this document, the Group Manager acts as Resource Server.
  • 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 .

Additionally, this document makes use of the following terminology.

• Requester: member of an OSCORE group that sends request messages to other members of the group.
• Responder: member of an OSCORE group that receives request messages from other members of the group. A responder may reply back, by sending a response message to the requester which has sent the request message.
• Monitor: member of an OSCORE group that is configured as responder and never replies back to requesters after receiving request messages. This corresponds to the term "silent server" used in .
• Signature verifier: entity external to the OSCORE group and intended to verify the signature of messages exchanged in the group (see Sections and of ). An authorized signature verifier does not join the OSCORE group as an actual member, yet it can retrieve the authentication credentials of the current group members from the Group Manager.
• Signature-only group: an OSCORE group that uses only the group mode (see ).
• Pairwise-only group: an OSCORE group that uses only the pairwise mode (see ).

Protocol Overview Group communication for CoAP has been enabled in and can be secured with Group Object Security for Constrained RESTful Environments (Group OSCORE) as specified in . A network node joins an OSCORE group by interacting with the responsible Group Manager. Once registered in the group, the new node can securely exchange messages with other group members. This document describes how to use and to perform a number of authentication, authorization and key distribution actions as overviewed in , when the considered group is specifically an OSCORE group. With reference to :

• The node wishing to join the OSCORE group, i.e., the joining node, is the Client.
• The Group Manager is the Key Distribution Center (KDC), acting as a Resource Server.
• The Authorization Server associated with the Group Manager is the AS.

A node performs the steps described in Sections and of in order to obtain an authorization for joining an OSCORE group and then to join that group. The format and processing of messages exchanged during such steps are further specified in and of this document. All communications between the involved entities MUST be secured. In particular, communications between the Client and the Group Manager leverage protocol-specific transport profiles of ACE to achieve communication security, proof-of-possession and server authentication. It is expected that, in the commonly referred base-case of this document, the transport profile to use is pre-configured and well-known to nodes participating in constrained applications. With respect to what is defined in :

• The interface provided by the Group Manager extends the original interface defined in for the KDC, as specified in of this document.
• In addition to those defined in , additional parameters are defined in this document and summarized in .
• In addition to those defined in , additional error identifiers are defined in this document and summarized in .

Finally, lists the specifications on this application profile of ACE, based on the requirements defined in Appendix A of .

Format of Scope Building on , this section defines the exact format and encoding of scope used in this profile. To this end, this profile uses the Authorization Information Format (AIF) . In particular, 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. Furthermore, this document defines the new AIF specific data model AIF-OSCORE-GROUPCOMM, that this profile MUST use to format and encode scope entries. In particular, the following holds for each scope entry.

• The object identifier ("Toid") is specialized as a CBOR item specifying the name of the groups pertaining to the scope entry.
• The permission set ("Tperm") is specialized as a CBOR unsigned integer with value R, specifying the permissions that the Client wishes to have in the groups indicated by "Toid".

More specifically, the following applies when, as defined in this document, a scope entry includes as set of permissions the set of roles to take in an OSCORE group.

• The object identifier ("Toid") is a CBOR text string, specifying the group name for the scope entry.
• The permission set ("Tperm") is a CBOR unsigned integer with value R, specifying the role(s) that the Client wishes to take in the group (REQ1). The value R is computed as follows.
  • Each role in the permission set is converted into the corresponding numeric identifier X from the "Value" column of the "Group OSCORE Roles" registry, for which this document defines the entries in .
  • The set of N numbers is converted into the single value R, by taking two to the power of each numeric identifier X_1, X_2, ..., X_N, and then computing the inclusive OR of the binary representations of all the power values.

Numeric identifier of roles in an OSCORE group

The following CDDL notation defines a scope entry that uses the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group OSCORE roles from those in . oscore-gname = tstr ; Group name oscore-gperm = uint . bits group-oscore-roles group-oscore-roles = &( Requester: 1, Responder: 2, Monitor: 3, Verifier: 4 ) scope_entry = [oscore-gname, oscore-gperm] ]]> Future specifications that define new Group OSCORE roles MUST register a corresponding numeric identifier in the "Group OSCORE Roles" registry defined in of this document. Note that the value 0 is not available to use as numeric identifier to specify a Group OSCORE role. It follows that, when expressing Group OSCORE roles to take in a group as per this document, a scope entry has the least significant bit of "Tperm" always set to 0. This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model. That is, for each scope entry, the least significant bit of "Tperm" set to 0 explicitly identifies the scope entry as exactly expressing a set of Group OSCORE roles ("Tperm"), pertaining to a single group whose name is specified by the string literal in "Toid". Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model, defines the format of scope entries for Administrator Clients that wish to access an admin interface at the Group Manager. In such scope entries, the least significant bit of "Tperm" is always set to 1.

Authentication Credentials Source authentication of a message sent within the group and protected with Group OSCORE is ensured by means of a digital signature embedded in the message (in group mode), or by integrity-protecting the message with pairwise keying material derived from the asymmetric keys of sender and recipient (in pairwise mode). Therefore, group members must be able to retrieve each other's authentication credential from a trusted repository, in order to verify source authenticity of incoming group messages. As also discussed in , the Group Manager acts as trusted repository of the authentication credentials of the group members, and provides those authentication credentials to group members if requested to. Upon joining an OSCORE group, a joining node is thus expected to provide its own authentication credential to the Group Manager. In particular, one of the following four cases can occur when a new node joins an OSCORE group.

• The joining node is going to join the group exclusively as monitor, i.e., it is not going to send messages to the group. In this case, the joining node is not required to provide its own authentication credential to the Group Manager, which thus does not have to perform any check related to the format of the authentication credential, to a signature or ECDH algorithm, and to possible parameters associated with the algorithm and the public key. In case the joining node still provides an authentication credential in the 'client_cred' parameter of the Join Request (see ), the Group Manager silently ignores that parameter, as well as the related parameters 'cnonce' and 'client_cred_verify'.
• The Group Manager already acquired the authentication credential of the joining node during a past joining process. In this case, the joining node MAY choose not to provide again its own authentication credential to the Group Manager, in order to limit the size of the Join Request. The joining node MUST provide its own authentication credential again if it has provided the Group Manager with multiple authentication credentials during past joining processes, intended for different OSCORE groups. If the joining node provides its own authentication credential, the Group Manager performs consistency checks as per and, in case of success, considers it as the authentication credential associated with the joining node in the OSCORE group.
• The joining node and the Group Manager use an asymmetric proof-of-possession key to establish a secure communication association. Then, two cases can occur.
  1. When establishing the secure communication association, the Group Manager obtained from the joining node the joining node's authentication credential, in the format used in the OSCORE group and including the asymmetric proof-of-possession key as public key. Also, such authentication credential and the proof-of-possession key are compatible with the signature or ECDH algorithm, and possible associated parameters used in the OSCORE group. In this case, the Group Manager considers the authentication credential as the one associated with the joining node in the OSCORE group. If the joining node is aware that the authentication credential and the public key included thereof are also valid for the OSCORE group, then the joining node MAY choose to not provide again its own authentication credential to the Group Manager. The joining node MUST provide again its own authentication credential if it has provided the Group Manager with multiple authentication credentials during past joining processes, intended for different OSCORE groups. If the joining node provides its own authentication credential in the 'client_cred' parameter of the Join Request (see ), the Group Manager performs consistency checks as per and, in case of success, considers it as the authentication credential associated with the joining node in the OSCORE group.
  2. The authentication credential is not in the format used in the OSCORE group, or else the authentication credential and the proof-of-possession key included as public key are not compatible with the signature or ECDH algorithm, and possible associated parameters used in the OSCORE group. In this case, the joining node MUST provide a different compatible authentication credential and public key included thereof to the Group Manager in the 'client_cred' parameter of the Join Request (see ). Then, the Group Manager performs consistency checks on this latest provided authentication credential as per and, in case of success, considers it as the authentication credential associated with the joining node in the OSCORE group.
• The joining node and the Group Manager use a symmetric proof-of-possession key to establish a secure communication association. In this case, upon performing a joining process with that Group Manager for the first time, the joining node specifies its own authentication credential in the 'client_cred' parameter of the Join Request (see ).

Authorization to Join a Group This section builds on and is organized as follows. First, and describe how the joining node interacts with the AS, in order to be authorized to join an OSCORE group under a given Group Manager and to obtain an Access Token. Then, describes how the joining node transfers the obtained Access Token to the Group Manager. The following considers a joining node that intends to contact the Group Manager for the first time. Note that what is defined in applies, and only additions or modifications to that specification are defined in this document.

Authorization Request The Authorization Request message is as defined in , with the following additions.

• If the 'scope' parameter is present:
  • The value of the CBOR byte string encodes a CBOR array, whose format MUST follow the data model AIF-OSCORE-GROUPCOMM defined in . In particular, for each OSCORE group to join:
    • The group name is encoded as a CBOR text string.
    • The set of requested roles is expressed as a single CBOR unsigned integer. This is computed as defined in , from the numerical abbreviations of each requested role defined in the "Group OSCORE Roles" registry, for which this document defines the entries in (REQ1).

Authorization Response The Authorization Response message is as defined in , with the following additions:

• The AS MUST include the 'expires_in' parameter. Other means for the AS to specify the lifetime of Access Tokens are out of the scope of this document.
• The AS MUST include the 'scope' parameter, when the value included in the Access Token differs from the one specified by the joining node in the Authorization Request. In such a case, the second element of each scope entry MUST be present, and specifies the set of roles that the joining node is actually authorized to take in the OSCORE group for that scope entry, encoded as specified in .

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 AS MUST use the CBOR tag with tag number TAG_NUMBER, associated with the CoAP Content-Format CF_ID for the media type application/aif+cbor registered in of this document (REQ28). Note to RFC Editor: In the previous paragraph, please replace "TAG_NUMBER" with the CBOR tag number computed as TN(ct) in , where ct is the ID assigned to the CoAP Content-Format registered in of this document. Then, please replace "CF_ID" with the ID assigned to that CoAP Content-Format. Finally, please delete this paragraph. This indicates that the binary encoded scope, as conveying the actual access control information, follows the scope semantics defined for this application profile in of this document.

Token Transferring The exchange of Token Transfer Request and Token Transfer Response is defined in . In addition to that, the following applies.

• The Token Transfer Request MAY additionally contain the following parameters, which, if included, MUST have the corresponding values defined below (OPT2):
  • 'ecdh_info' defined in of this document, with value the CBOR simple value "null" (0xf6) to request information about the ECDH algorithm, the ECDH algorithm parameters, the ECDH key parameters and the exact format of authentication credentials used in the groups that the Client has been authorized to join. This is relevant in case the joining node supports the pairwise mode of Group OSCORE .
  • 'kdc_dh_creds' defined in of this document, with value the CBOR simple value "null" (0xf6) to request the Diffie-Hellman authentication credentials of the Group Manager for the groups that the Client has been authorized to join. That is, each of such authentication credentials includes a Diffie-Hellman public key of the Group Manager. This is relevant in case the joining node supports the pairwise mode of Group OSCORE .
  Alternatively, the joining node may retrieve this information by other means.
• The 'kdcchallenge' parameter contains a dedicated nonce N_S generated by the Group Manager. For the N_S value, it is RECOMMENDED to use a 8-byte long random nonce. The joining node can use this nonce in order to prove the possession of its own private key, upon joining the group (see ). The 'kdcchallenge' parameter MAY be omitted from the Token Transfer Response, if the 'scope' of the Access Token specifies only the role "monitor" or only the role "verifier" or only the two roles combined, for each and every of the specified groups.
• If the 'sign_info' parameter is present in the response, the following applies for each element 'sign_info_entry'.
  • 'id' MUST NOT refer to OSCORE groups that are pairwise-only groups.
  • 'sign_alg' takes value from the "Value" column of the "COSE Algorithms" registry .
  • 'sign_parameters' is a CBOR array. Its format and value are the same of the COSE capabilities array for the algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (REQ4).
  • 'sign_key_parameters' is a CBOR array. Its format and value are the same of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'sign_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (REQ5).
  • 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6). Consistently with , acceptable values denote a format of authentication credential that MUST explicitly provide the public key as well as the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable). At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates and C509 certificates . Further formats may be available in the future, and would be acceptable to use as long as they comply with the criteria defined above. [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 'kccs' are under pending registration requested by draft-ietf-lake-edhoc. ] [ As to C509 certificates, the COSE Header Parameters 'c5b' and 'c5c' are under pending registration requested by draft-ietf-cose-cbor-encoded-cert. ]
  This format is consistent with every signature algorithm currently considered in , i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B of describes how the format of each 'sign_info_entry' can be generalized for possible future registered algorithms having a different set of COSE capabilities.
• If 'ecdh_info' is included in the Token Transfer Request, the Group Manager SHOULD include the 'ecdh_info' parameter in the Token Transfer Response, as per the format defined in . Note that the field 'id' of each 'ecdh_info_entry' specifies the name, or array of group names, for which that 'ecdh_info_entry' applies to. As an exception, the KDC MAY omit the 'ecdh_info' parameter in the Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Request, in case all the groups that the Client is authorized to join are signature-only groups.
• If 'kdc_dh_creds' is included in the Token Transfer Request and any of the groups that the Client has been authorized to join is a pairwise-only group, then the Group Manager MUST include the 'kdc_dh_creds' parameter in the Token Transfer Response, as per the format defined in . Otherwise, if 'kdc_dh_creds' is included in the Token Transfer Request, the Group Manager MAY include the 'kdc_dh_creds' parameter in the Token Transfer Response. Note that the field 'id' specifies the group name, or array of group names, for which the corresponding 'kdc_dh_creds' applies to.

Note that, other than through the above parameters as defined in , the joining node may have obtained such information by alternative means. For example, information conveyed in the 'sign_info' and 'ecdh_info' parameters may have been pre-configured, or the joining node may early retrieve it, e.g., by using the approach described in to discover the OSCORE group and the link to the associated group-membership resource at the Group Manager (OPT3).

'ecdh_info' Parameter The 'ecdh_info' parameter is an OPTIONAL parameter of the request and response messages exchanged between the Client and the authz-info endpoint at the RS (see ). This parameter allows the Client and the RS to exchange information about an ECDH algorithm as well as about the authentication credentials and public keys to accordingly use for deriving Diffie-Hellman secrets. Its exact semantics and content are application specific. In this application profile, this parameter is used to exchange information about the ECDH algorithm as well as about the authentication credentials and public keys to be used with it, in the groups indicated by the transferred Acces Token as per its 'scope' claim (see ). When used in the Token Transfer Request sent to the Group Manager, the 'ecdh_info' parameter has value the CBOR simple value "null" (0xf6). This is done to ask for information about the ECDH algorithm as well as about the authentication credentials and public keys to be used to compute static-static Diffie-Hellman shared secrets , in the OSCORE groups that the Client has been authorized to join and that use the pairwise mode of Group OSCORE . When used in the following Token Transfer Response from the Group Manager, the 'ecdh_info' parameter is a CBOR array of one or more elements. The number of elements is at most the number of OSCORE groups that the Client has been authorized to join. Each element contains information about ECDH parameters as well as about authentication credentials and public keys, for one or more OSCORE groups that use the pairwise mode of Group OSCORE and that the Client has been authorized to join. Each element is formatted as follows.

• The first element 'id' is the group name of the OSCORE group or an array of group names for the OSCORE groups for which the specified information applies. In particular 'id' MUST NOT refer to OSCORE groups that are signature-only groups.
• The second element 'ecdh_alg' is a CBOR integer or a CBOR text string indicating the ECDH algorithm used in the OSCORE group identified by 'gname'. Values are taken from the "Value" column of the "COSE Algorithms" registry .
• The third element 'ecdh_parameters' is a CBOR array indicating the parameters of the ECDH algorithm used in the OSCORE group identified by 'gname'. Its format and value are the same of the COSE capabilities array for the algorithm indicated in 'ecdh_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
• The fourth element 'ecdh_key_parameters' is a CBOR array indicating the parameters of the keys used with the ECDH algorithm in the OSCORE group identified by 'gname'. Its content depends on the value of 'ecdh_alg'. In particular, its format and value are the same of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'ecdh_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
• The fifth element 'cred_fmt' is a CBOR integer indicating the format of authentication credentials used in the OSCORE group identified by 'gname'. It takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6). Acceptable values denote a format that MUST provide the public key as well as the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable). The same considerations and guidelines for the 'cred_fmt' element of 'sign_info' apply (see ).

The CDDL notation of the 'ecdh_info' parameter is given below. This format is consistent with every ECDH algorithm currently defined in , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of each 'ecdh_info_entry' can be generalized for possible future registered algorithms having a different set of COSE capabilities.

'kdc_dh_creds' Parameter The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request and response messages exchanged between the Client and the authz-info endpoint at the RS (see ). This parameter allows the Client to request and retrieve the Diffie-Hellman authentication credentials of the RS, i.e., authentication credentials including a Diffie-Hellman public key of the RS. In this application profile, this parameter is used to request and retrieve from the Group Manager its Diffie-Hellman authentication credentials to use, in the OSCORE groups that the Client has been authorized to join. The Group Manager has specifically a Diffie-Hellman authentication credential in an OSCORE group, and thus a Diffie-Hellman public key in that group, if and only if the group is a pairwise-only group. In this case, the early retrieval of the Group Manager's authentication credential is necessary in order for the joining node to prove the possession of its own private key, upon joining the group (see ). When used in the Token Transfer Request sent to the Group Manager, the 'kdc_dh_creds' parameter has value the CBOR simple value "null" (0xf6). This is done to ask for the Diffie-Hellman authentication credentials that the Group Manager uses in the OSCORE groups that the Client has been authorized to join. When used in the following Token Transfer Response from the Group Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more elements. The number of elements is at most the number of OSCORE groups that the Client has been authorized to join. Each element 'kdc_dh_creds_entry' contains information about the Group Manager's Diffie-Hellman authentication credentials, for one or more OSCORE groups that are pairwise-only groups and that the Client has been authorized to join. Each element is formatted as follows.

• The first element 'id' is the group name of the OSCORE group or an array of group names for the OSCORE groups for which the specified information applies. In particular 'id' MUST refer exclusively to OSCORE groups that are pairwise-only groups.
• The second element 'cred_fmt' is a CBOR integer indicating the format of authentication credentials used in the OSCORE group identified by 'gname'. It takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6). Acceptable values denote a format that MUST explicitly provide the public key as well as comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable). The same considerations and guidelines for the 'cred_fmt' element of 'sign_info' apply (see ).
• The third element 'cred' is a CBOR byte string, which encodes the Group Manager's Diffie-Hellman authentication credential in its original binary representation made available to other endpoints in the group. In particular, the original binary representation complies with the format specified by the 'cred_fmt' element. Note that the authentication credential provides the comprehensive set of information related to its public key algorithm, i.e., the ECDH algorithm used in the OSCORE group as pairwise key agreement algorithm.

The CDDL notation of the 'kdc_dh_creds' parameter is given below.

Group Joining This section describes the interactions between the joining node and the Group Manager to join an OSCORE group. The message exchange between the joining node and the Group Manager consists of the messages defined in . Note that what is defined in applies, and only additions or modifications to that specification are defined in this document.

Send the Join Request The joining node requests to join the OSCORE group by sending a Join Request message to the related group-membership resource at the Group Manager, as per . Additionally to what is defined in , the following applies.

• The 'scope' parameter MUST be included. Its value encodes one scope entry with the format defined in , indicating the group name and the role(s) that the joining node wants to take in the group.
• The 'get_creds' parameter is present only if the joining node wants to retrieve the authentication credentials of the group members from the Group Manager during the joining process (see ). Otherwise, this parameter MUST NOT be present. If this parameter is present and its value is not the CBOR simple value "null" (0xf6), each element of the inner CBOR array 'role_filter' is encoded as a CBOR unsigned integer, with the same value of a permission set ("Tperm") indicating that role or combination of roles in a scope entry, as defined in .
• 'cnonce' contains a dedicated nonce N_C generated by the joining node. For the N_C value, it is RECOMMENDED to use a 8-byte long random nonce.
• The proof-of-possession (PoP) evidence included in 'client_cred_verify' is computed as defined below (REQ14). In either case, the N_S used to build the PoP input is as defined in .
  • If the group is not a pairwise-only group, the PoP evidence MUST be a signature. The joining node computes the signature by using the same private key and signature algorithm it intends to use for signing messages in the OSCORE group.
  • If the group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows.
    • salt takes as value the empty byte string.
    • IKM is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of , using the ECDH algorithm used in the OSCORE group. The joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager. For X25519 and X448, the procedure is described in .
    • info takes as value the PoP input.
    • L is equal to 8, i.e., the size of the MAC, in bytes.

Value of the N_S Challenge The value of the N_S challenge is determined as follows.

1. If the joining node has provided the Access Token to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S takes the same value of the most recent 'kdcchallenge' parameter received by the joining node from the Group Manager. This can be either the one specified in the Token Transfer Response, or the one possibly specified in a 4.00 (Bad Request) error response to a following Join Request (see ).
2. If the provisioning of the Access Token to the Group Manager has relied on the DTLS profile of ACE , and the Access Token was specified:
   • in the "psk_identity" field of the ClientKeyExchange message when using DTLS 1.2 ; or
   • in the "identity" field of a PskIdentity within the PreSharedKeyExtension of the ClientHello message when using DTLS 1.3 ,
   then N_S is an exporter value computed as defined in . Specifically, N_S is exported from the DTLS session between the joining node and the Group Manager, using an empty 'context_value', 32 bytes as 'key_length', and the exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app" defined in of this document.

It is up to applications to define how N_S is computed in further alternative settings. provides security considerations on the reusage of the N_S challenge.

Receive the Join Request The Group Manager processes the Join Request as defined in , with the following additions. The Group Manager verifies the PoP evidence contained in 'client_cred_verify' as follows:

• As PoP input, the Group Manager uses the value of the 'scope' parameter from the Join Request as a CBOR byte string, concatenated with N_S encoded as a CBOR byte string, concatenated with N_C encoded as a CBOR byte string. In particular, N_S is determined as described in , while N_C is the nonce provided in the 'cnonce' parameter of the Join Request.
• As public key of the joining node, the Group Manager uses either the one included in the authentication credential retrieved from the 'client_cred' parameter of the Join Request, or the one from the already stored authentication credential as acquired from previous interactions with the joining node (see ).
• If the group is not a pairwise-only group, the PoP evidence is a signature. The Group Manager verifies it by using the public key of the joining node, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
• If the group is a pairwise-only group, the PoP evidence is a MAC. The Group Manager recomputes the MAC through the same process taken by the joining node when preparing the value of the 'client_cred_verify' parameter for the Join Request (see ), with the difference that the Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Request.

The Group Manager MUST reply with a 5.03 (Service Unavailable) error response in the following cases:

• There are currently no OSCORE Sender IDs available to assign in the OSCORE group and, at the same time, the joining node is not going to join the group exclusively as monitor. 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 4 ("No available node identifiers").
• The OSCORE group that the joining node has been trying to join is currently inactive (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 9 ("Group currently not active").

The Group Manager MUST reply with a 4.00 (Bad Request) error response in the following cases:

• The 'client_cred' parameter is present in the Join Request and its value is not an eligible authentication credential (e.g., it is not of the format accepted in the group).
• The 'client_cred' parameter is not present in the Join Request while the joining node is not going to join the group exclusively as monitor, and any of the following conditions holds:
  • The Group Manager does not store an eligible authentication credential (e.g., of the format accepted in the group) for the joining node.
  • The Group Manager stores multiple eligible authentication credentials (e.g., of the format accepted in the group) for the joining node.
• The 'scope' parameter is not present in the Join Request, or it is present and specifies any set of roles not included in the following list: "requester", "responder", "monitor", ("requester", "responder"). Future specifications that define a new role for members of OSCORE groups MUST define possible sets of roles (including the new role and existing roles) that are acceptable to specify in the 'scope' parameter of a Join Request.
• The Join Request includes the 'client_cred' parameter but does not include both the 'cnonce' and 'client_cred_verify' parameters.

In order to prevent the acceptance of Ed25519 and Ed448 public keys that cannot be successfully converted to Montgomery coordinates, and thus cannot be used for the derivation of pairwise keys (see ), the Group Manager MAY reply with a 4.00 (Bad Request) error response in case all the following conditions hold:

• The OSCORE group uses the pairwise mode of Group OSCORE.
• The OSCORE group uses EdDSA public keys .
• The authentication credential of the joining node from the 'client_cred' parameter includes a public key which:
  • Is for the elliptic curve Ed25519 and has its Y coordinate equal to -1 or 1 (mod p), with p = (2^255 - 19), see ; or
  • Is for the elliptic curve Ed448 and has its Y coordinate equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see .

A 4.00 (Bad Request) error response from the Group Manager to the joining node MUST have content format application/ace-groupcomm+cbor. The response payload is a CBOR map formatted as follows:

• If the group uses (also) the group mode of Group OSCORE, the CBOR map MUST contain the 'sign_info' parameter, whose CBOR label is defined in . This parameter has the same format of 'sign_info_res' defined in . In particular, it includes a single element 'sign_info_entry' pertaining to the OSCORE group that the joining node has tried to join with the Join Request.
• If the group uses (also) the pairwise mode of Group OSCORE, the CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR label is defined in . This parameter has the same format of 'ecdh_info_res' defined in . In particular, it includes a single element 'ecdh_info_entry' pertaining to the OSCORE group that the joining node has tried to join with the Join Request.
• If the group is a pairwise-only group, the CBOR map MUST contain the 'kdc_dh_creds' parameter, whose CBOR label is defined in . This parameter has the same format of 'kdc_dh_creds_res' defined in . In particular, it includes a single element 'kdc_dh_creds_entry' pertaining to the OSCORE group that the joining node has tried to join with the Join Request.
• The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR label is defined in . If present, this parameter is a CBOR byte string, which encodes a newly generated 'kdcchallenge' value that the Client can use when preparing a Join Request (see ). In such a case the Group Manager MUST store the newly generated value as the 'kdcchallenge' value associated with the joining node, possibly replacing the currently stored value.

Follow-up to a 4.00 (Bad Request) Error Response When receiving a 4.00 (Bad Request) error response, the joining node MAY send a new Join Request to the Group Manager. In such a case:

• The 'cnonce' parameter MUST include a new dedicated nonce N_C generated by the joining node.
• The 'client_cred' parameter MUST include an authentication credential in the format indicated by the Group Manager. Also, the authentication credential as well as the included public key MUST be compatible with the signature or ECDH algorithm, and possible associated parameters.
• The 'client_cred_verify' parameter MUST include a PoP evidence computed as described in , by using the private key associated with the authentication credential specified in the current 'client_cred' parameter, with the signature or ECDH algorithm, and possible associated parameters indicated by the Group Manager. If the error response from the Group Manager includes the 'kdcchallenge' parameter, the joining node MUST use its content as new N_S challenge to compute the PoP evidence.

Send the Join Response If the processing of the Join Request described in is successful, the Group Manager updates the group membership by registering the joining node NODENAME as a new member of the OSCORE group GROUPNAME, as described in . If the joining node has not taken exclusively the role of monitor, the Group Manager performs also the following actions.

• The Group Manager selects an available OSCORE Sender ID in the OSCORE group, and exclusively assigns it to the joining node. The Group Manager MUST NOT assign an OSCORE Sender ID to the joining node if this joins the group exclusively with the role of monitor, according to what is specified in the Access Token (see ). Consistently with , the Group Manager MUST assign an OSCORE Sender ID that has not been used in the OSCORE group since the latest time when the current Gid value was assigned to the group. If the joining node is recognized as a current group member, e.g., through the ongoing secure communication association, the following also applies.
  • The Group Manager MUST assign a new OSCORE Sender ID different than the one currently used by the joining node in the OSCORE group.
  • The Group Manager MUST add the old, relinquished OSCORE Sender ID of the joining node to the most recent set of stale Sender IDs, in the collection associated with the group (see ).
• The Group Manager stores the association between i) the authentication credential of the joining node; and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, associated with the OSCORE group together with the OSCORE Sender ID assigned to the joining node in the group. The Group Manager MUST keep this association updated over time.

Then, the Group Manager replies to the joining node, providing the updated security parameters and keying meterial necessary to participate in the group communication. This success Join Response is formatted as defined in , with the following additions:

• The 'gkty' parameter identifies a key of type "Group_OSCORE_Input_Material object", defined in of this document.
• The 'key' parameter includes what the joining node needs in order to set up the Group OSCORE Security Context as per . This parameter has as value a Group_OSCORE_Input_Material object, which is defined in this document and extends the OSCORE_Input_Material object encoded in CBOR as defined in . In particular, it contains the additional parameters 'group_senderId', 'cred_fmt', 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and 'ecdh_params' defined in of this document. More specifically, the 'key' parameter is composed as follows.
  • The 'hkdf' parameter, if present, specifies the HKDF Algorithm used in the OSCORE group. The HKDF Algorithm is specified by the HMAC Algorithm value. This parameter MAY be omitted, if the HKDF Algorithm used in the group is HKDF SHA-256. Otherwise, this parameter MUST be present.
  • The 'salt' parameter, if present, has as value the OSCORE Master Salt used in the OSCORE group. This parameter MAY be omitted, if the Master Salt used in the group is the empty byte string. Otherwise, this parameter MUST be present.
  • The 'ms' parameter includes the OSCORE Master Secret value used in the OSCORE group. This parameter MUST be present.
  • The 'contextId' parameter has as value the Group Identifier (Gid), i.e., the OSCORE ID Context of the OSCORE group. This parameter MUST be present.
  • The 'group_senderId' parameter has as value the OSCORE Sender ID assigned to the joining node by the Group Manager, as described above. This parameter MUST be present if and only if the node does not join the OSCORE group exclusively with the role of monitor, according to what is specified in the Access Token (see ).
  • The 'cred_fmt' parameter specifies the format of authentication credentials used in the OSCORE group. This parameter MUST be present and it takes value from the "Label" column of the "COSE Header Parameters" registry (REQ6). Consistently with , acceptable values denote a format that MUST explicitly provide the public key as well as the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable). At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates and C509 certificates . Further formats may be available in the future, and would be acceptable to use as long as they comply with the criteria defined above. [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and 'kccs' are under pending registration requested by draft-ietf-lake-edhoc. ] [ As to C509 certificates, the COSE Header Parameters 'c5b' and 'c5c' are under pending registration requested by draft-ietf-cose-cbor-encoded-cert. ]
  The 'key' parameter MUST also include the following parameters, if and only if the OSCORE group is not a pairwise-only group.
  • The 'sign_enc_alg' parameter, specifying the Signature Encryption Algorithm used in the OSCORE group to encrypt messages protected with the group mode. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
  • The 'sign_alg' parameter, specifying the Signature Algorithm used to sign messages in the OSCORE group. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
  • The 'sign_params' parameter, specifying the parameters of the Signature Algorithm. This parameter is a CBOR array, which includes the following two elements:
    • 'sign_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the Signature Algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
    • 'sign_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the Signature Algorithm indicated in 'sign_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
  The 'key' parameter MUST also include the following parameters, if and only if the OSCORE group is not a signature-only group.
  • The 'alg' parameter, specifying the AEAD Algorithm used in the OSCORE group to encrypt messages protected with the pairwise mode.
  • The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement Algorithm used in the OSCORE group. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
  • The 'ecdh_params' parameter, specifying the parameters of the Pairwise Key Agreement Algorithm. This parameter is a CBOR array, which includes the following two elements:
    • 'ecdh_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the algorithm indicated in 'ecdh_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
    • 'ecdh_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'ecdh_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
  The format of 'key' defined above is consistent with every signature algorithm and ECDH algorithm currently considered in , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of the 'key' parameter can be generalized for possible future registered algorithms having a different set of COSE capabilities.

Furthermore, the following applies.

• The 'exp' parameter MUST be present.
• The 'ace-groupcomm-profile' parameter MUST be present and has value coap_group_oscore_app (PROFILE_TBD), which is defined in of this document.
• The 'creds' parameter, if present, includes the authentication credentials requested by the joining node by means of the 'get_creds' parameter in the Join Request. If the joining node has asked for the authentication credentials of all the group members, i.e., 'get_creds' had value the CBOR simple value "null" (0xf6) in the Join Request, then the Group Manager provides only the authentication credentials of the group members that are relevant to the joining node. That is, in such a case, 'creds' includes only: i) the authentication credentials of the responders currently in the OSCORE group, in case the joining node is configured (also) as requester; and ii) the authentication credentials of the requesters currently in the OSCORE group, in case the joining node is configured (also) as responder or monitor.
• The 'peer_identifiers' parameter includes the OSCORE Sender ID of each group member whose authentication credential is specified in the 'creds' parameter. That is, a group member's Sender ID is used as identifier for that group member (REQ25).
• The 'group_policies' parameter SHOULD be present, and SHOULD include the following elements:
  • "Key Update Check Interval" defined in , with default value 3600;
  • "Expiration Delta" defined in , with default value 0.
• The 'kdc_cred' parameter MUST be present, specifying the Group Manager's authentication credential in its original binary representation (REQ8). The Group Manager's authentication credential MUST be in the format used in the OSCORE group. Also, the authentication credential as well as the included public key MUST be compatible with the signature or ECDH algorithm, and possible associated parameters used in the OSCORE group.
• The 'kdc_nonce' parameter MUST be present, specifying the dedicated nonce N_KDC generated by the Group Manager. For N_KDC, it is RECOMMENDED to use a 8-byte long random nonce.
• The 'kdc_cred_verify' parameter MUST be present, specifying the proof-of-possession (PoP) evidence computed by the Group Manager. The PoP evidence is computed over the nonce N_KDC, which is specified in the 'kdc_nonce' parameter and taken as PoP input. The PoP evidence is computed as defined below (REQ21).
  • If the group is not a pairwise-only group, the PoP evidence MUST be a signature. The Group Manager computes the signature by using the signature algorithm used in the OSCORE group, as well as its own private key associated with the authentication credential specified in the 'kdc_cred' parameter.
  • If the group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . MAC = HKDF(salt, IKM, info, L) The input parameters of HKDF are as follows.
    • salt takes as value the empty byte string.
    • IKM is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of , using the ECDH algorithm used in the OSCORE group. The Group Manager uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the joining node. For X25519 and X448, the procedure is described in .
    • info takes as value the PoP input.
    • L is equal to 8, i.e., the size of the MAC, in bytes.
• The 'group_rekeying' parameter MAY be omitted, if the Group Manager uses the "Point-to-Point" group rekeying scheme registered in as rekeying scheme in the OSCORE group (OPT9). Its detailed use for this profile is defined in of this document. In any other case, the 'group_rekeying' parameter MUST be included.

As a last action, if the Group Manager reassigns Gid values during the group's lifetime (see ), then the Group Manager MUST store the Gid specified in the 'contextId' parameter of the 'key' parameter, as the Birth Gid of the joining node in the joined group (see ). This applies also in case the joining node is in fact re-joining the group; in such a case, the newly determined Birth Gid overwrites the one currently stored.

Receive the Join Response Upon receiving the Join Response, the joining node retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter. The joining node MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter of the Join Response as defined below (REQ21).

• If the group is not a pairwise-only group, the PoP evidence is a signature. The joining node verifies it by using the public key of the Group Manager from the received authentication credential, as well as the signature algorithm used in the OSCORE group and possible corresponding parameters.
• If the group is a pairwise-only group, the PoP evidence is a MAC. The joining node recomputes the MAC through the same process taken by the Group Manager when computing the value of the 'kdc_cred_verify' parameter (see ), with the difference that the joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager from the received authentication credential. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Join Response.

In case of failed verification of the PoP evidence, the joining node MUST stop processing the Join Response and MAY send a new Join Request to the Group Manager (see ). In case of successful verification of the PoP evidence, the joining node uses the information received in the Join Response to set up the Group OSCORE Security Context, as described in . If the following parameters were not included in the 'key' parameter of the Join Response, the joining node considers the default values specified below, consistently with .

• Absent the 'hkdf' parameter, the joining node considers HKDF SHA-256 as HKDF Algorithm to use in the OSCORE group.
• Absent the 'salt' parameter, the joining node considers the empty byte string as Master Salt to use in the OSCORE group.
• Absent the 'group_rekeying' parameter, the joining node considers the "Point-to-Point" group rekeying scheme registered in as the rekeying scheme used in the group (OPT9). Its detailed use for this profile is defined in of this document.

In addition, the joining node maintains an association between each authentication credential retrieved from the 'creds' parameter and the role(s) that the corresponding group member has in the OSCORE group. From then on, the joining node can exchange group messages secured with Group OSCORE as described in . When doing so:

• The joining node MUST NOT process an incoming request message, if protected by a group member whose authentication credential is not associated with the role "Requester".
• The joining node MUST NOT process an incoming response message, if protected by a group member whose authentication credential is not associated with the role "Responder".
• The joining node MUST NOT use the pairwise mode of Group OSCORE to process messages in the group, if the Join Response did not include the 'ecdh_alg' parameter.

If the application requires backward security, the Group Manager MUST generate updated security parameters and group keying material, and provide it to the current group members, upon the new node's joining (see ). In such a case, the joining node is not able to access secure communication in the OSCORE group occurred prior its joining.

Overview of the Group Rekeying Process In a number of cases, the Group Manager has to generate new keying material and distribute it to the group (rekeying), as also discussed in . To this end the Group Manager MUST support the Group Rekeying Process described in of this document, as an instance of the "Point-to-Point" rekeying scheme defined in and registered in . Future documents may define the use of alternative group rekeying schemes for this application profile, together with the corresponding rekeying message formats. The resulting group rekeying process MUST comply with the functional steps defined in . Upon generating the new group keying material and before starting its distribution, the Group Manager MUST increment the version number of the group keying material. When rekeying a group, the Group Manager MUST preserve the current value of the OSCORE Sender ID of each member in that group. The data distributed to a group through a rekeying MUST include:

• The new version number of the group keying material for the group.
• A new Group Identifier (Gid) for the group as introduced in , used as ID Context parameter of the Group OSCORE Common Security Context of that group (see ). Note that the Gid differs from the group name also introduced in , which is a plain, stable and invariant identifier, with no cryptographic relevance and meaning.
• A new value for the Master Secret parameter of the Group OSCORE Common Security Context of the group (see ).
• A set of stale Sender IDs, which allows each rekeyed node to purge authentication credentials and Recipient Contexts used in the group and associated with those Sender IDs. This in turn allows every group member to rely on stored authentication credentials, in order to confidently assert the group membership of other sender nodes, when receiving protected messages in the group (see ). More details on the maintenance of stale Sender IDs are provided in .

Also, the data distributed through a group rekeying MAY include a new value for the Master Salt parameter of the Group OSCORE Common Security Context of that group. The Group Manager MUST rekey the group in the following cases.

• The application requires backward security - In this case, the group is rekeyed when a node joins the group as a new member. Therefore, a joining node cannot access communications in the group prior its joining.
• One or more nodes leave the group - That is, the group is rekeyed when one or more current members spontaneously request to leave the group (see ), or when the Group Manager forcibly evicts them from the group, e.g., due to expired or revoked authorization (see ). Therefore, a leaving node cannot access communications in the group after its leaving, thus ensuring forward security in the group. Due to the set of stale Sender IDs distributed through the rekeying, this ensures that a node owning the latest group keying material does not store the authentication credentials of former group members (see Sections and of ).
• Extension of group lifetime - That is, the group is rekeyed when the expiration time for the group keying material approaches or has passed, if it is appropriate to extend the group operation beyond that.

The Group Manager MAY rekey the group for other reasons, e.g., according to an application-specific rekeying period or scheduling.

Stale OSCORE Sender IDs Throughout the lifetime of every group, the Group Manager MUST maintain a collection of stale Sender IDs for that group. The collection associated with a group MUST include up to N > 1 ordered sets of stale OSCORE Sender IDs. It is up to the application to specify the value of N, possibly on a per-group basis. The N-th set includes the Sender IDs that have become "stale" under the current version V of the group keying material. The (N - 1)-th set refers to the immediately previous version (V - 1) of the group keying material, and so on. In the following cases, the Group Manager MUST add a new element to the most recent set X, i.e., the set associated with the current version V of the group keying material.

• When a current group member obtains a new Sender ID, its old Sender ID is added to X. This happens when the Group Manager assigns a new Sender ID upon request from the group member (see ), or in case the group member re-joins the group (see and ), thus also obtaining a new Sender ID.
• When a current group member leaves the group, its current Sender ID is added to X. This happens when a group member requests to leave the group (see ) or is forcibly evicted from the group (see ).

The value of N can change throughout the lifetime of the group. If the new value N' is smaller than N, the Group Manager MUST preserve the (up to) N' most recent sets in the collection and MUST delete any possible older set from the collection. Finally, the Group Manager MUST perform the following actions, when the group is rekeyed and the group shifts to the next version V' = (V + 1) of the group keying material.

1. The Group Manager rekeys the group. This includes also distributing the set of stale Sender IDs X associated with the old group keying material with version V (see ).
2. After completing the group rekeying, the Group Manager creates a new empty set X' associated with the new version V' of the newly established group keying material, i.e., V' = (V + 1).
3. If the current collection of stale Sender IDs has size N, the Group Manager deletes the oldest set in the collection.
4. The Group Manager adds the new set X' to the collection of stale Sender IDs, as the most recent set.

Interface at the Group Manager The Group Manager provides the interface defined in , with the additional sub-resources defined from to of this document. Furthermore, provides a summary of the CoAP methods admitted to access different resources at the Group Manager, for nodes with different roles in the group or as non members (REQ11). The GROUPNAME segment of the URI path MUST match with the group name specified in the scope entry of the Access Token scope (i.e., 'gname' in ) (REQ7). The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is registered in (REQ10), and can be used to describe group-membership resources and its sub-resources at a Group Manager, e.g., by using a link-format document . Applications can use this common resource type to discover links to group-membership resources for joining OSCORE groups, e.g., by using the approach described in .

ace-group/GROUPNAME/active This resource implements a GET handler.

GET Handler The handler expects a GET request. In addition to what is defined in , the handler verifies that the requesting Client is a current member of the group. If the verification fails, the KDC 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 . The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying the current status of the group, i.e., active or inactive. The payload of the response is formatted as defined in . The method to set the current group status is out of the scope of this document, and is defined for the administrator interface of the Group Manager specified in .

ace-group/GROUPNAME/verif-data This resource implements a GET handler.

GET Handler The handler expects a GET request. In addition to what is defined in , the Group Manager performs the following checks. If the requesting Client is a current group member, 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 . The value of the 'error' field MUST be set to 8 ("Operation permitted only to signature verifiers"). If GROUPNAME denotes a pairwise-only group, the Group Manager MUST reply with a 4.00 (Bad Request) error 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 7 ("Signatures not used in the group"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying data that allow also an external signature verifier to verify signatures of messages protected with the group mode and sent to the group (see Sections and of ). The response MUST have Content-Format set to application/ace-groupcomm+cbor. The payload of the response is a CBOR map, which is formatted as defined in .

ace-group/GROUPNAME/stale-sids This resource implements a FETCH handler.

FETCH Handler The handler expects a FETCH request, whose payload specifies a version number of the group keying material, encoded as an unsigned CBOR integer. In addition to what is defined in , the handler verifies that the requesting Client is a current member of the group. If the verification fails, 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 . The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response, specifying data that allow the requesting Client to delete the Recipient Contexts and authentication credentials associated with former members of the group (see . The payload of the response is formatted as defined in .

Admitted Methods The table in summarizes the CoAP methods admitted to access different resources at the Group Manager, for (non-)members of a group with group name GROUPNAME, and considering different roles. The last two rows of the table apply to a node with node name NODENAME.

Admitted CoAP Methods on the Group Manager Resources

Signature Verifiers Just like any candidate group member, a signature verifier provides the Group Manager with an Access Token, as described in . However, unlike candidate group members, it does not join any OSCORE group, i.e., it does not perform the joining process defined in . After successfully transferring an Access Token to the Group Manager, a signature verifier is allowed to perform only some operations as non-member of a group, and only for the OSCORE groups specified in the validated Access Token. These are the operations specified in , , and . Consistently, in case a node is not a member of the group with group name GROUPNAME and is authorized to be only signature verifier for that group, the Group Manager MUST reply with a 4.03 (Forbidden) error response if that node attempts to access any other endpoint than: /ace-group; ace-group/GROUPNAME/verif-data; /ace-group/GROUPNAME/creds; and ace-group/GROUPNAME/kdc-cred.

Operations Supported by Clients Building on what is defined in , and with reference to the resources at the Group Manager newly defined earlier in of this document, it is expected that a Client minimally supports also the following set of operations and corresponding interactions with the Group Manager (REQ12).

• GET request to ace-group/GROUPNAME/active, in order to check the current status of the group.
• GET request to ace-group/GROUPNAME/verif-data, in order for a signature verifier to retrieve data required to verify signatures of messages protected with the group mode of Group OSCORE and sent to a group (see Sections and of ). Note that this operation is relevant to support only to signature verifiers.
• FETCH request to ace-group/GROUPNAME/stale-sids, in order to retrieve from the Group Manager the data required to delete some of the stored group members' authentication credentials and associated Recipient Contexts (see ). These data are provided as an aggregated set of stale Sender IDs, which are used as specified in .

Additional Interactions with the Group Manager This section defines the possible interactions with the Group Manager, in addition to the group joining specified in .

Retrieve Updated Keying Material At some point, a group member considers the Group OSCORE Security Context invalid and to be renewed. This happens, for instance, after a number of unsuccessful security processing of incoming messages from other group members, or when the Security Context expires as specified by the 'exp' parameter of the Join Response. When this happens, the group member retrieves updated security parameters and group keying material. This can occur in the two different ways described below.

Get Group Keying Material If the group member wants to retrieve only the latest group keying material, it sends a Key Distribution Request to the Group Manager. In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME at the Group Manager. The Group Manager processes the Key Distribution Request according to . The Key Distribution Response is formatted as defined in , with the following additions.

• The 'key' parameter is formatted as defined in of this document, with the difference that it does not include the 'group_SenderId' parameter.
• The 'exp' parameter MUST be present.
• The 'ace-groupcomm-profile' parameter MUST be present and has value coap_group_oscore_app.

Upon receiving the Key Distribution Response, the group member retrieves the updated security parameters and group keying material, and, if they differ from the current ones, uses them to set up the new Group OSCORE Security Context as described in .

Get Group Keying Material and OSCORE Sender ID If the group member wants to retrieve the latest group keying material as well as the OSCORE Sender ID that it has in the OSCORE group, it sends a Key Distribution Request to the Group Manager. In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. The Group Manager processes the Key Distribution Request according to . The Key Distribution Response is formatted as defined in , with the following additions.

• The 'key' parameter is formatted as defined in of this document. In particular, if the requesting group member has exclusively the role of monitor, then the 'key' parameter does not include the 'group_SenderId'. Note that, in any other case, the current Sender ID of the group member is not specified as a separate parameter, but rather specified by 'group_SenderId' within the 'key' parameter.
• The 'exp' parameter MUST be present.

Upon receiving the Key Distribution Response, the group member retrieves the updated security parameters, group keying material and Sender ID, and, if they differ from the current ones, uses them to set up the new Group OSCORE Security Context as described in .

Request to Change Individual Keying Material As discussed in , a group member may at some point exhaust its Sender Sequence Numbers in the OSCORE group. When this happens, the group member MUST send a Key Renewal Request message to the Group Manager, as per . In particular, it sends a CoAP PUT request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. Upon receiving the Key Renewal Request, the Group Manager processes it as defined in , with the following additions. The Group Manager MUST return a 5.03 (Service Unavailable) response in case the OSCORE group identified by GROUPNAME is currently inactive (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 9 ("Group currently not active"). Otherwise, the Group Manager performs one of the following actions.

1. If the requesting group member has exclusively the role of monitor, the Group Manager replies 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 . The value of the 'error' field MUST be set to 1 ("Request inconsistent with the current roles").
2. Otherwise, the Group Manager takes one of the following actions.
   • The Group Manager rekeys the OSCORE group. That is, the Group Manager generates new group keying material for that group (see ), and replies to the group member with a group rekeying message as defined in , providing the new group keying material. Then, the Group Manager rekeys the rest of the OSCORE group, as discussed in . The Group Manager SHOULD perform a group rekeying only if already scheduled to occur shortly, e.g., according to an application-specific rekeying period or scheduling, or as a reaction to a recent change in the group membership. In any other case, the Group Manager SHOULD NOT rekey the OSCORE group when receiving a Key Renewal Request (OPT12).
   • The Group Manager determines and assigns a new OSCORE Sender ID for that group member, and replies with a Key Renewal Response formatted as defined in . In particular, the CBOR Map in the response payload includes a single parameter 'group_SenderId' defined in of this document, specifying the new Sender ID of the group member encoded as a CBOR byte string. Consistently with , the Group Manager MUST assign a new Sender ID that has not been used in the OSCORE group since the latest time when the current Gid value was assigned to the group. Furthermore, the Group Manager MUST add the old, relinquished Sender ID of the group member to the most recent set of stale Sender IDs, in the collection associated with the group (see ). The Group Manager MUST return a 5.03 (Service Unavailable) response in case there are currently no Sender IDs available to assign in the OSCORE group. 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 4 ("No available node identifiers").

Retrieve Authentication Credentials of Group Members A group member or a signature verifier may need to retrieve the authentication credentials of (other) group members. To this end, the group member or signature verifier sends an Authentication Credential Request message to the Group Manager, as per Sections and of . In particular, it sends the request to the endpoint /ace-group/GROUPNAME/creds at the Group Manager. If the Authentication Credential Request uses the method FETCH, the Authentication Credential Request is formatted as defined in . In particular:

• Each element (if any) of the inner CBOR array 'role_filter' is formatted as in the inner CBOR array 'role_filter' of the 'get_creds' parameter of the Join Request when the parameter value is not the CBOR simple value "null" (0xf6) (see ).
• Each element (if any) of the inner CBOR array 'id_filter' is a CBOR byte string, which encodes the OSCORE Sender ID of the group member for which the associated authentication credential is requested (REQ25).

Upon receiving the Authentication Credential Request, the Group Manager processes it as per Section 4.4.1 or Section 4.4.2 of , depending on the request method being FETCH or GET, respectively. Additionally, if the Authentication Credential Request uses the method FETCH, the Group Manager silently ignores node identifiers included in the 'get_creds' parameter of the request that are not associated with any current group member (REQ26). The success Authentication Credential Response is formatted as defined in Section 4.4.1 or Section 4.4.2 of , depending on the request method being FETCH or GET, respectively.

Upload a New Authentication Credential A group member may need to provide the Group Manager with its new authentication credential to use in the group from then on, hence replacing the current one. This can be the case, for instance, if the signature or ECDH algorithm and possible associated parameters used in the OSCORE group have been changed, and the current authentication credential is not compatible with them. To this end, the group member sends an Authentication Credential Update Request message to the Group Manager, as per , with the following addition.

• The group member computes the proof-of-possession (PoP) evidence included in 'client_cred_verify' in the same way taken when preparing a Join Request for the OSCORE group in question, as defined in (REQ14).

In particular, the group member sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/cred at the Group Manager. Upon receiving the Authentication Credential Update Request, the Group Manager processes it as per , with the following additions.

• The N_S challenge used to build the proof-of-possession input is computed as defined in (REQ15).
• The Group Manager verifies the PoP challenge included in 'client_cred_verify' in the same way taken when processing a Join Request for the OSCORE group in question, as defined in (REQ14).
• The Group Manager MUST return a 5.03 (Service Unavailable) response in case the OSCORE group identified by GROUPNAME is currently inactive (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 9 ("Group currently not active").
• If the requesting group member has exclusively the role of monitor, the Group Manager replies with a 4.00 (Bad request) error 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 1 ("Request inconsistent with the current roles").
• If the request is successfully processed, the Group Manager stores the association between i) the new authentication credential of the group member; and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, associated with the OSCORE group together with the OSCORE Sender ID assigned to the group member in the group. The Group Manager MUST keep this association updated over time.

Retrieve the Group Manager's Authentication Credential A group member or a signature verifier may need to retrieve the authentication credential of the Group Manager. To this end, the requesting Client sends a KDC Authentication Credential Request message to the Group Manager. In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/kdc-cred at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group. In addition to what is defined in , the Group Manager MUST respond with a 4.00 (Bad Request) error response, if the requesting Client is not a current group member and GROUPNAME denotes a pairwise-only group. 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 7 ("Signatures not used in the group"). The payload of the 2.05 (Content) KDC Authentication Credential Response is a CBOR map, which is formatted as defined in . In particular, the Group Manager specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge' as defined for the Join Response in of this document. This especially applies to the computing of the proof-of-possession (PoP) evidence included in 'kdc_cred_verify' (REQ21). Upon receiving a 2.05 (Content) KDC Authentication Credential Response, the requesting Client retrieves the Group Manager's authentication credential from the 'kdc_cred' parameter, and proceeds as defined in . In particular, the requesting Client verifies the PoP evidence included in 'kdc_cred_verify' by means of the same method used when processing the Join Response, as defined in of this document (REQ21). Note that a signature verifier would not receive a successful response from the Group Manager, in case GROUPNAME denotes a pairwise-only group.

Retrieve Signature Verification Data A signature verifier may need to retrieve data required to verify signatures of messages protected with the group mode and sent to a group (see Sections and of ). To this end, the signature verifier sends a Signature Verification Data Request message to the Group Manager. In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/verif-data at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the 2.05 (Content) Signature Verification Data Response is a CBOR map, which has the format used for the Join Response message in , with the following differences.

• From the Join Response message, only the parameters 'gkty', 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In particular, the 'key' parameter includes only the following data.
  • The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg', 'sign_alg', 'sign_params'. These parameters MUST be present.
  • The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT be present if the group is a signature-only group. Otherwise, they MUST be present.
• The parameter 'group_enc_key' is also included, with CBOR label defined in . This parameter specifies the Group Encryption Key of the OSCORE Group, encoded as a CBOR byte string. The Group Manager derives the Group Encryption Key from the group keying material, as per . This parameter MUST be present.

In order to verify signatures in the group (see ), the signature verifier relies on: the data retrieved from the 2.05 (Content) Signature Verification Data Response; the public keys of the group members signing the messages to verify, retrieved from those members' authentication credentials that can be obtained as defined in ; and the public key of the Group Manager, retrieved from the Group Manager's authentication credential that can be obtained as defined in . gives an overview of the exchange described above, while shows an example.

Message Flow of Signature Verification Data Request-Response | | GET ace-group/GROUPNAME/verif-data | | | |<--- Signature Verification Data Response: 2.05 (Content) ---| | | ]]>

Example of Signature Verification Data Request-Response

Retrieve the Group Policies A group member may request the current policies used in the OSCORE group. To this end, the group member sends a Policies Request, as per . In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/policies at the Group Manager, where GROUPNAME is the name of the OSCORE group. Upon receiving the Policies Request, the Group Manager processes it as per . The success Policies Response is formatted as defined in .

Retrieve the Keying Material Version A group member may request the current version of the keying material used in the OSCORE group. To this end, the group member sends a Version Request, as per . In particular, it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/num at the Group Manager, where GROUPNAME is the name of the OSCORE group. Upon receiving the Version Request, the Group Manager processes it as per . The success Version Response is formatted as defined in .

Retrieve the Group Status A group member may request the current status of the the OSCORE group, i.e., active or inactive. To this end, the group member sends a Group Status Request to the Group Manager. In particular, the group member sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/active at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the 2.05 (Content) Group Status Response includes the CBOR simple value "true" (0xf5) if the group is currently active, or the CBOR simple value "false" (0xf4) otherwise. The group is considered active if it is set to allow new members to join, and if communication within the group is fine to happen. Upon learning from a 2.05 (Content) response that the group is currently inactive, the group member SHOULD stop taking part in communications within the group, until it becomes active again. Upon learning from a 2.05 (Content) response that the group has become active again, the group member can resume taking part in communications within the group. gives an overview of the exchange described above, while shows an example.

Message Flow of Group Status Request-Response | | | |<---------- Group Status Response: 2.05 (Content) -----------| | | ]]>

Example of Group Status Request-Response

Retrieve Group Names A node may want to retrieve from the Group Manager the group name and the URI of the group-membership resource of a group. This is relevant in the following cases.

• Before joining a group, a joining node may know only the current Group Identifier (Gid) of that group, but not the group name and the URI to the group-membership resource.
• As current group member in several groups, the node has missed a previous group rekeying in one of them (see ). Hence, it retains stale keying material and fails to decrypt received messages exchanged in that group. Such messages do not provide a direct hint to the correct group name, that the node would need in order to retrieve the latest keying material and authentication credentials from the Group Manager (see , and ). However, such messages may specify the current Gid of the group, as value of the 'kid_context' field of the OSCORE CoAP option (see and ).
• As signature verifier, the node also refers to a group name for retrieving the required authentication credentials from the Group Manager (see ). As discussed above, intercepted messages do not provide a direct hint to the correct group name, while they may specify the current Gid of the group, as value of the 'kid_context' field of the OSCORE CoAP option. In such a case, upon intercepting a message in the group, the node requires to correctly map the Gid currently used in the group with the invariant group name. Furthermore, since it is not a group member, the node does not take part to a possible group rekeying. Thus, following a group rekeying and the consequent change of Gid in a group, the node would retain the old Gid value and cannot correctly associate intercepted messages to the right group, especially if acting as signature verifier in several groups. This in turn prevents the efficient verification of signatures, and especially the retrieval of required, new authentication credentials from the Group Manager.

In either case, the node only knows the current Gid of the group, as learned from received or intercepted messages exchanged in the group. As detailed below, the node can contact the Group Manager, and request the group name and URI to the group-membership resource corresponding to that Gid. Then, it can use that information to either join the group as a candidate group member, get the latest keying material as a current group member, or retrieve authentication credentials used in the group as a signature verifier. To this end, the node sends a Group Name and URI Retrieval Request, as per . In particular, the node sends a CoAP FETCH request to the endpoint /ace-group at the Group Manager formatted as defined in . Each element of the CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the group for which the group name and the URI to the group-membership resource are requested. Upon receiving the Group Name and URI Retrieval Request, the Group Manager processes it as per . The success Group Name and URI Retrieval Response is formatted as defined in . In particular, each element of the CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid of the group for which the group name and the URI to the group-membership resource are provided. For each of its groups, the Group Manager maintains an association between the group name and the URI to the group-membership resource on one hand, and only the current Gid for that group on the other hand. That is, the Group Manager does not maintain an association between the former pair and any other Gid for that group than the current, most recent one. gives an overview of the exchanges described above, while shows an example.

Message Flow of Group Name and URI Retrieval Request-Response | | | |<--- Group Name and URI Retrieval Response: 2.05 (Content) -----| | | ]]>

Example of Group Name and URI Retrieval Request-Response

Leave the Group A group member may request to leave the OSCORE group. To this end, the group member sends a Group Leaving Request, as per . In particular, it sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the Group Manager. Upon receiving the Group Leaving Request, the Group Manager processes it as per . Then, the Group Manager performs the follow-up actions defined in of this document.

Removal of a Group Member Other than after a spontaneous request to the Group Manager as described in , a node may be forcibly removed from the OSCORE group, e.g., due to expired or revoked authorization. In either case, if the Group Manager reassigns Gid values during the group's lifetime (see ), the Group Manager "forgets" the Birth Gid currently associated with the leaving node in the OSCORE group. This was stored following the Join Response sent to that node, after its latest (re-)joining of the OSCORE group (see ). If any of the two conditions below holds, the Group Manager MUST inform the leaving node of its eviction as follows. If both conditions hold, the Group Manager MUST inform the leaving node by using only the method corresponding to one of either conditions.

• If, upon joining the group (see ), the leaving node specified a URI in the 'control_uri' parameter defined in , the Group Manager sends a DELETE request targeting the URI specified in the 'control_uri' parameter (OPT7).
• If the leaving node has been observing the associated resource at ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an unsolicited 4.04 (Not Found) error response to the leaving node, as specified in .

Furthermore, the Group Manager might intend to evict all the current group members from the group at once. In such a case, if the Join Responses sent by the Group Manager to nodes joining the group (see ) specify a URI in the 'control_group_uri' parameter defined in , then the Group Manager MUST additionally send a DELETE request targeting the URI specified in the 'control_group_uri' parameter (OPT10). If the leaving node has not exclusively the role of monitor, the Group Manager performs the following actions.

• The Group Manager frees the OSCORE Sender ID value of the leaving node. This value MUST NOT become available for possible upcoming joining nodes in the same group, until the group has been rekeyed and assigned a new Group Identifier (Gid).
• The Group Manager MUST add the relinquished Sender ID of the leaving node to the most recent set of stale Sender IDs, in the collection associated with the group (see ).
• The Group Manager cancels the association between, on one hand, the authentication credential of the leaving node and, on the other hand, the Gid associated with the OSCORE group together with the freed Sender ID value. The Group Manager deletes the authentication credential of the leaving node, if that authentication credential has no remaining association with any pair (Gid, Sender ID).

Then, the Group Manager MUST generate updated security parameters and group keying material, and provide it to the remaining group members (see ). As a consequence, the leaving node is not able to acquire the new security parameters and group keying material distributed after its leaving. The same considerations from apply here as well, considering the Group Manager acting as KDC.

Group Rekeying Process In order to rekey the OSCORE group, the Group Manager distributes a new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for that group. When doing so, the Group Manager MUST increment the version number of the group keying material, before starting its distribution. As per , the Group Manager MAY reassign a Gid to the same group over that group's lifetime, e.g., once the whole space of Gid values has been used for the group in question. If the Group Manager supports reassignment of Gid values and performs it in a group, then the Group Manager additionally takes the following actions.

• Before rekeying the group, the Group Manager MUST check if the new Gid to be distributed coincides with the Birth Gid of any of the current group members (see ).
• If any of such "elder members" is found in the group, the Group Manager MUST evict them from the group. That is, the Group Manager MUST terminate their membership and MUST rekey the group in such a way that the new keying material is not provided to those evicted elder members. This also includes adding their relinquished Sender IDs to the most recent set of stale Sender IDs, in the collection associated with the group (see ), before rekeying the group. Until a further following group rekeying, the Group Manager MUST store the list of those latest-evicted elder members. If any of those nodes re-joins the group before a further following group rekeying occurs, the Group Manager MUST NOT rekey the group upon their re-joining. When one of those nodes re-joins the group, the Group Manager can rely, e.g., on the ongoing secure communication association to recognize the node as included in the stored list.

Across the rekeying execution, the Group Manager MUST preserve the same unchanged OSCORE Sender IDs for all group members intended to remain in the group. This avoids affecting the retrieval of authentication credentials from the Group Manager and the verification of group messages. The Group Manager MUST support the "Point-to-Point" group rekeying scheme registered in , as per the detailed use defined in of this document. Future specifications may define how this application profile can use alternative group rekeying schemes, which MUST comply with the functional steps defined in . The Group Manager MUST indicate the use of such an alternative group rekeying scheme to joining nodes, by means of the 'group_rekeying' parameter included in Join Response messages (see ). It is RECOMMENDED that the Group Manager gets confirmation of successful distribution from the group members, and admits a maximum number of individual retransmissions to non-confirming group members. Once completed the group rekeying process, the Group Manager creates a new empty set X' of stale Sender IDs associated with the version of the newly distributed group keying material. Then, the Group Manager MUST add the set X' to the collection of stale Sender IDs associated with the group (see ). In case the rekeying terminates and some group members have not received the new keying material, they will not be able to correctly process following secured messages exchanged in the group. These group members will eventually contact the Group Manager, in order to retrieve the current keying material and its version. Some of these group members may be in multiple groups, each associated with a different Group Manager. When failing to correctly process messages secured with the new keying material, these group members may not have sufficient information to determine which exact Group Manager they should contact, in order to retrieve the current keying material they are missing. If the Gid is formatted as described in Appendix C of , the Group Prefix can be used as a hint to determine the right Group Manager, as long as no collisions among Group Prefixes are experienced. Otherwise, a group member needs to contact the Group Manager of each group, e.g., by first requesting only the version of the current group keying material (see ) and then possibly requesting the current keying material (see ). Furthermore, some of these group members can be in multiple groups, all of which associated with the same Group Manager. In this case, these group members may also not have sufficient information to determine which exact group they should refer to, when contacting the right Group Manager. Hence, they need to contact a Group Manager multiple times, i.e., separately for each group they belong to and associated with that Group Manager. defines the actions performed by a group member upon receiving the new group keying material. discusses how a group member can realize that it has missed one or more rekeying instances, and the actions it is accordingly required to take.

Sending Rekeying Messages When using the "Point-to-Point" group rekeying scheme, the group rekeying messages MUST have Content-Format set to application/ace-groupcomm+cbor and have the same format used for the Join Response message in , with the following differences. Note that this extends the minimal content of a rekeying message as defined in (OPT14).

• From the Join Response, only the parameters 'gkty', 'key', 'num', 'exp', and 'ace-groupcomm-profile' are present. In particular, the 'key' parameter includes only the following data.
  • The 'ms' parameter, specifying the new OSCORE Master Secret value. This parameter MUST be present.
  • The 'contextId' parameter, specifying the new Gid to use as OSCORE ID Context value. This parameter MUST be present.
  • The 'salt' value, specifying the new OSCORE Master Salt value. This parameter MAY be present.
• The parameter 'stale_node_ids' MUST also be included, with CBOR label defined in . This parameter is encoded as a CBOR array, where each element is encoded as a CBOR byte string. The CBOR array has to be intended as a set, i.e., the order of its elements is irrelevant. The parameter is populated as follows.
  • The Group Manager creates an empty CBOR array ARRAY.
  • The Group Manager considers the collection of stale Sender IDs associated with the group (see ), and takes the most recent set X, i.e., the set associated with the current version of the group keying material about to be relinquished.
  • For each Sender ID in X, the Group Manager encodes it as a CBOR byte string and adds the result to ARRAY.
  • The parameter 'stale_node_ids' takes ARRAY as value.
• The parameters 'creds', 'peer_roles' and 'peer_identifiers' SHOULD be present, if the group rekeying is performed due to one or multiple Clients that have requested to join the group. Following the same semantics used in the Join Response message (see ), the three parameters specify the authentication credential, roles in the group and node identifier of each of the Clients that have requested to join the group. The Group Manager MUST NOT include a non-empty subset of these three parameters.

The Group Manager separately sends a group rekeying message formatted as defined above to each group member to be rekeyed. Each rekeying message MUST be secured with the pairwise secure communication association between the Group Manager and the group member used during the joining process. In particular, each rekeying message can target the 'control_uri' URI path defined in (OPT7), if provided by the intended recipient upon joining the group (see ). This distribution approach requires group members to act (also) as servers, in order to correctly handle unsolicited group rekeying messages from the Group Manager. In particular, if a group member and the Group Manager use OSCORE to secure their pairwise communications, the group member MUST create a Replay Window in its own Recipient Context upon establishing the OSCORE Security Context with the Group Manager, e.g., by means of the OSCORE profile of ACE . Group members and the Group Manager SHOULD additionally support alternative distribution approaches that do not require group members to act (also) as servers. A number of such approaches are defined in . In particular, a group member may use CoAP Observe and subscribe for updates to the group-membership resource of the group, at the endpoint /ace-group/GROUPNAME/ of the Group Manager (see ). Alternatively, a full-fledged Pub-Sub model can be considered , where the Group Manager publishes to a rekeying topic hosted at a Broker, while the group members subscribe to such topic (see ).

Receiving Rekeying Messages Once received the new group keying material, a group member proceeds as follows. Unless otherwise specified, the following is independent of the specifically used group rekeying scheme. The group member considers the stale Sender IDs received from the Group Manager. If the "Point-to-Point" group rekeying scheme as detailed in is used, the stale Sender IDs are specified by the 'stale_node_ids' parameter. After that, as per , the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID. Then, the following cases can occur, based on the version number V' of the new group keying material distributed through the rekeying process. If the "Point-to-Point" group rekeying scheme as detailed in is used, this information is specified by the 'num' parameter.

• The group member has not missed any group rekeying. That is, the old keying material stored by the group member has version number V, while the received new keying material has version number V' = (V + 1). In such a case, the group member simply installs the new keying material and derives the corresponding new Security Context.
• The group member has missed one or more group rekeying instances. That is, the old keying material stored by the group member has version number V, while the received new keying material has version number V' > (V + 1). In such a case, the group member MUST proceed as defined in .
• The group member has received keying material not newer than the stored one. That is, the old keying material stored by the group member has version number V, while the received keying material has version number V' < (V + 1). In such a case, the group member MUST ignore the received rekeying messages and MUST NOT install the received keying material.

Missed Rekeying Instances A group member can realize to have missed one or more rekeying instances in one of the ways discussed below. In the following, V denotes the version number of the old keying material stored by the group member, while V' denotes the version number of the latest, possibly just distributed, keying material. a. The group member has participated to a rekeying process that has distributed new keying material with version number V' > (V + 1), as discussed in . b. The group member has obtained the latest keying material from the Group Manager, as a response to a Key Distribution Request (see ) or to a Join Request when re-joining the group (see ). In particular, V is different than V' specified by the 'num' parameter in the response. c. The group member has obtained the authentication credentials of other group members, through an Authentication Credential Request-Response exchange with the Group Manager (see ). In particular, V is different than V' specified by the 'num' parameter in the response. d. The group member has performed a Version Request-Response exchange with the Group Manager (see ). In particular, V is different than V' specified by the 'num' parameter in the response. In either case, the group member MUST delete the stored keying material with version number V. If case (a) or case (b) applies, the group member MUST perform the following actions.

1. The group member MUST NOT install the latest keying material yet, in case that was already obtained.
2. The group member sends a Stale Sender IDs Request to the Group Manager (see ), specifying the version number V as payload of the request. If the Stale Sender IDs Response from the Group Manager has no payload, the group member MUST remove all the authentication credentials from its list of group members' authentication credentials used in the group, and MUST delete all its Recipient Contexts used in the group. Otherwise, the group member considers the stale Sender IDs specified in the Stale Sender IDs Response from the Group Manager. Then, the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID.
3. The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

If case (c) or case (d) applies, the group member SHOULD perform the following actions.

1. The group member sends a Stale Sender IDs Request to the Group Manager (see ), specifying the version number V as payload of the request. If the Stale Sender IDs Response from the Group Manager has no payload, the group member MUST remove all the authentication credentials from its list of group members' authentication credentials used in the group, and MUST delete all its Recipient Contexts used in the group. Otherwise, the group member considers the stale Sender IDs specified in the Stale Sender IDs Response from the Group Manager. Then, the group member MUST remove every authentication credential associated with a stale Sender ID from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group whose corresponding Recipient ID is a stale Sender ID.
2. The group member obtains the latest keying material with version number V' from the Group Manager. This can happen by sending a Key Distribution Request to the Group Manager (see ) and ).
3. The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

If case (c) or case (d) applies, the group member can alternatively perform the following actions.

1. The group member re-joins the group (see ). When doing so, the group member MUST re-join with the same roles it currently has in the group, and MUST request the Group Manager for the authentication credentials of all the current group members. That is, the 'get_creds' parameter of the Join Request MUST be present and MUST be set to the CBOR simple value "null" (0xf6).
2. When receiving the Join Response (see and ), the group member retrieves the set Z of authentication credentials specified in the 'creds' parameter. Then, the group member MUST remove every authentication credential which is not in Z from its list of group members' authentication credentials used in the group, and MUST delete each of its Recipient Contexts used in the group that does not include any of the authentication credentials in Z.
3. The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.

Retrieve Stale Sender IDs When realizing to have missed one or more group rekeying instances (see ), a node needs to retrieve from the Group Manager the data required to delete some of its stored group members' authentication credentials and Recipient Contexts (see ). These data are provided as an aggregated set of stale Sender IDs, which are used as specified in . In particular, the node sends a CoAP FETCH request to the endpoint /ace-group/GROUPNAME/stale-sids at the Group Manager defined in of this document, where GROUPNAME is the name of the OSCORE group. The payload of the Stale Sender IDs Request MUST include a CBOR unsigned integer. This encodes the version number V of the most recent group keying material stored and installed by the requesting Client, which is older than the latest, possibly just distributed, keying material with version number V'. The handler MUST reply with a 4.00 (Bad Request) error response, if the request is not formatted correctly. Also, the handler MUST respond with a 4.00 (Bad Request) error response, if the specified version number V is greater or equal than the version number V' associated with the latest keying material in the group, i.e., in case V >= V'. Otherwise, the handler responds with a 2.05 (Content) Stale Sender IDs Response. The payload of the response is formatted as defined below, where SKEW = (V' - V + 1).

• The Group Manager considers ITEMS as the current number of sets stored in the collection of stale Sender IDs associated with the group (see ).
• If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a payload.
• Otherwise, the payload of the Stale Sender IDs Response MUST include a CBOR array, where each element is encoded as a CBOR byte string. The CBOR array has to be intended as a set, i.e., the order of its elements is irrelevant. The Group Manager populates the CBOR array as follows.
  • The Group Manager creates an empty CBOR array ARRAY and an empty set X.
  • The Group Manager considers the SKEW most recent sets stored in the collection of stale Sender IDs associated with the group. Note that the most recent set is the one associate to the latest version of the group keying material.
  • The Group Manager copies all the Sender IDs from the selected sets into X. When doing so, the Group Manager MUST discard duplicates. That is, the same Sender ID MUST NOT be present more than once in the final content of X.
  • For each Sender ID in X, the Group Manager encodes it as a CBOR byte string and adds the result to ARRAY.
  • Finally, ARRAY is specified as payload of the Stale Sender IDs Response. Note that ARRAY might result in the empty CBOR array.

gives an overview of the exchange described above, while shows an example.

Message Flow of Stale Sender IDs Request-Response | | FETCH ace-group/GROUPNAME/stale-sids | | | |<---------- Stale Sender IDs Response: 2.05 (Content) -------| | | ]]>

Example of Stale Sender IDs Request-Response

ACE Groupcomm Parameters In addition to those defined in , this application profile defines additional parameters used during the second part of the message exchange with the Group Manager, i.e., after the exchange of Token Transfer Request and Response (see ). The table below summarizes them and specifies the CBOR key to use instead of the full descriptive name. Note that the media type application/ace-groupcomm+cbor MUST be used when these parameters are transported in the respective message fields.

ACE Groupcomm Parameters

Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. The Group Manager is expected to support and understand all the parameters above. Instead, a Client is required to support the new parameters defined in this application profile as specified below (REQ29).

• 'group_senderId' MUST be supported by a Client that intends to join an OSCORE group with the role of Requester and/or Responder.
• 'ecdh_info' MUST be supported by a Client that intends to join a group which uses the pairwise mode of Group OSCORE.
• 'kdc_dh_creds' MUST be supported by a Client that intends to join a group which uses the pairwise mode of Group OSCORE and that does not plan to or cannot rely on an early retrieval of the Group Manager's Diffie-Hellman authentication credential.
• 'group_enc_key' MUST be supported by a Client that intends to join a group which uses the group mode of Group OSCORE or to be signature verifier for that group.
• 'stale_node_ids' MUST be supported.

When the conditional parameters defined in are used with this application profile, a Client must, should or may support them as specified below (REQ30).

• 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has an own authentication credential to use in a group MUST support these parameters.
• 'kdcchallenge'. A Client that has an own authentication credential to use in a group and that provides the Access Token to the Group Manager through a Token Transfer Request (see ) MUST support this parameter.
• 'creds_repo'. This parameter is not relevant for this application profile, since the Group Manager always acts as repository of the group members' authentication credentials.
• 'group_policies'. A Client that is interested in the specific policies used in a group, but that does not know them or cannot become aware of them before joining that group, SHOULD support this parameter.
• 'peer_roles'. A Client MUST support this parameter, since in this application profile it is relevant for Clients to know the roles of the group member associated with each authentication credential.
• 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST support these parameters, since the Group Manager's authentication credential is required to process messages protected with Group OSCORE (see Section 4.3 of ).
• 'mgt_key_material'. A Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent by the Group Manager (e.g., over IP multicast), MUST support this parameter.
• 'control_group_uri'. A Client that supports the hosting of local resources each associated with a group (hence acting as CoAP server) and the reception of one-to-many requests sent to those resources by the Group Manager (e.g., over IP multicast) MUST support this parameter.

ACE Groupcomm Error Identifiers In addition to those defined in , this application profile defines new values 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 7, the Client should stop sending the request in question to the Group Manager. In this application profile, this error is relevant only for a signature verifier, in case it tries to access resources related to a pairwise-only group.
• In case of error 8, the Client should stop sending the request in question to the Group Manager.
• In case of error 9, the Client should wait for a certain (pre-configured) amount of time, before trying re-sending its request to the Group Manager.

Default Values for Group Configuration Parameters This section defines the default values that the Group Manager assumes for the configuration parameters of an OSCORE group, unless differently specified when creating and configuring the group. This can be achieved as specified in .

Common This section always applies, as related to common configuration parameters.

• For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF SHA-256, defined as default in . In the 'hkdf' parameter, this HKDF Algorithm is specified by the HMAC Algorithm HMAC 256/256 (COSE algorithm encoding: 5).
• For the format 'cred_fmt' used for the authentication credentials in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or CWT Claims Set (CCS) , i.e., the COSE Header Parameter 'kcwt' and 'kccs', respectively. [ These COSE Header Parameters are under pending registration requested by draft-ietf-lake-edhoc. ]
• For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as the maximum number of stored sets of stale Sender IDs in the collection associated with the group (see ).

Group Mode This section applies if the group uses (also) the group mode of Group OSCORE.

• For the Signature Encryption Algorithm 'sign_enc_alg' used to encrypt messages protected with the group mode, the Group Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) as default value.

The Group Manager SHOULD use the following default values for the Signature Algorithm 'sign_alg' and related parameters 'sign_params', consistently with the "COSE Algorithms" registry , the "COSE Key Types" registry and the "COSE Elliptic Curves" registry .

• For the Signature Algorithm 'sign_alg' used to sign messages protected with the group mode, the signature algorithm EdDSA .
• For the parameters 'sign_params' of the Signature Algorithm:
  • The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or specified for 'sign_alg'. In particular, this indicates to use the COSE key type OKP and the elliptic curve Ed25519 .
  • The array [[EC2], [EC2, P-256]], in case ES256 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-256.
  • The array [[EC2], [EC2, P-384]], in case ES384 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-384.
  • The array [[EC2], [EC2, P-521]], in case ES512 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-521.
  • The array [[RSA], [RSA]], in case PS256, PS384 or PS512 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type RSA.

Pairwise Mode This section applies if the group uses (also) the pairwise mode of Group OSCORE. For the AEAD Algorithm 'alg' used to encrypt messages protected with the pairwise mode, the Group Manager SHOULD use the same default value defined in , i.e., AES-CCM-16-64-128 (COSE algorithm encoding: 10). For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related parameters 'ecdh_params', the Group Manager SHOULD use the following default values, consistently with the "COSE Algorithms" registry , the "COSE Key Types" registry and the "COSE Elliptic Curves" registry .

• For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to compute static-static Diffie-Hellman shared secrets, the ECDH algorithm ECDH-SS + HKDF-256 specified in .
• For the parameters 'ecdh_params' of the Pairwise Key Agreement Algorithm:
  • The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or specified for 'sign_alg', or in case the group is a pairwise-only group. In particular, this indicates to use the COSE key type OKP and the elliptic curve X25519 .
  • The array [[EC2], [EC2, P-256]], in case ES256 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-256.
  • The array [[EC2], [EC2, P-384]], in case ES384 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-384.
  • The array [[EC2], [EC2, P-521]], in case ES512 is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-521.

Security Considerations Security considerations for this profile are inherited from , the ACE framework for Authentication and Authorization , and the specific transport profile of ACE signalled by the AS, such as and . The following security considerations also apply for this profile.

Management of OSCORE Groups This profile leverages the following management aspects related to OSCORE groups and discussed in the sections of referred below.

• Management of group keying material (see ). The Group Manager is responsible for the renewal and re-distribution of the keying material in the groups of its competence (rekeying). The Group Manager performs a rekeying when one ore more members leave the group, thus preserving forward security and ensuring that the security properties of Group OSCORE are fulfilled. According to the specific application requirements, the Group Manager can also rekey the group upon a new node's joining, in case backward security has also to be preserved.
• Provisioning and retrieval of authentication credentials (see ). The Group Manager acts as repository of authentication credentials of group members, and provides them upon request.
• Synchronization of sequence numbers (see ). This concerns how a responder node that has just joined an OSCORE group can synchronize with the sequence number of requesters in the same group.

Before sending the Join Response, the Group Manager MUST verify that the joining node actually owns the associated private key. To this end, the Group Manager can rely on the proof-of-possession challenge-response defined in . Alternatively, when establishing a secure communication association with the Group Manager, the joining node can provide the Group Manager with its own authentication credential, and use the public key included thereof as asymmetric proof-of-possession key. For example, this is the case when the joining node relies on and authenticates itself during the DTLS handshake with the Group Manager. However, this requires the authentication credential to be in the format used in the OSCORE group, and that both the authentication credential of the joining node and the included public key are compatible with the signature or ECDH algorithm, and possible associated parameters used in the OSCORE group. A node may have joined multiple OSCORE groups under different non-synchronized Group Managers. Therefore, it can happen that those OSCORE groups have the same Group Identifier (Gid). It follows that, upon receiving a Group OSCORE message addressed to one of those groups, the node would have multiple Security Contexts matching with the Gid in the incoming message. It is up to the application to decide how to handle such collisions of Group Identifiers, e.g., by trying to process the incoming message using one Security Context at the time until the right one is found.

Size of Nonces as Proof-of-Possesion Challenge With reference to the Join Request message in , the proof-of-possession (PoP) evidence included in 'client_cred_verify' is computed over an input including also N_C | N_S, where | denotes concatenation. For the N_C challenge, it is RECOMMENDED to use a 8-byte long random nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter of the Join Request, which is always sent over the secure communication association between the joining node and the Group Manager. As defined in , the way the N_S value is computed depends on the particular way the joining node provides the Group Manager with the Access Token, as well as on following interactions between the two.

• If the Access Token has not been provided to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S is computed as a 32-byte long challenge. For an example, see point (2) of .
• If the Access Token has been provided to the Group Manager by means of a Token Transfer Request to the /authz-info endpoint as in , then N_S takes the most recent value provided to the Client by the Group Manager in the 'kdcchallenge' parameter, as specified in point (1) of . This value is provided either in the Token Transfer Response (see ), or in a 4.00 (Bad Request) error response to a following Join Request (see ). In either case, it is RECOMMENDED to use a 8-byte long random challenge as value for N_S.

If we consider both N_C and N_S to take 8-byte long values, the following considerations hold.

• Let us consider both N_C and N_S as taking random values, and the Group Manager to never change the value of the N_S provided to a Client during the lifetime of an Access Token. Then, as per the birthday paradox, the average collision for N_S will happen after 2^32 new transferred Access Tokens, while the average collision for N_C will happen after 2^32 new Join Requests. This amounts to considerably more token provisionings than the expected new joinings of OSCORE groups under a same Group Manager, as well as to considerably more requests to join OSCORE groups from a same Client using a same Access Token under a same Group Manager.
• as well recommend the use of 8-byte random values as well. Unlike in those cases, the values of N_C and N_S considered in this document are not used for as sensitive operations as the derivation of a Security Context, and thus do not have possible implications in the security of AEAD ciphers.

Reusage of Nonces for Proof-of-Possession Input As long as the Group Manager preserves the same N_S value currently associated with an Access Token, i.e., the latest value provided to a Client in a 'kdcchallenge' parameter, the Client is able to successfully reuse the same proof-of-possession (PoP) input for multiple Join Requests to that Group Manager. In particular, the Client can reuse the same N_C value for every Join Request to the Group Manager, and combine it with the same unchanged N_S value. This results in reusing the same PoP input for producing the PoP evidence to include in the 'client_cred_verify' parameter of the Join Requests. Unless the Group Manager maintains a list of N_C values already used by that Client since the latest update to the N_S value associated with the Access Token, the Group Manager can be forced to falsely believe that the Client possesses its own private key at that point in time, upon verifying the PoP evidence in the 'client_cred_verify' parameter.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

OAuth Parameters IANA is asked to register the following entries to the "OAuth Parameters" registry, as per the procedure specified in .

• Parameter name: ecdh_info
• Parameter usage location: client-rs request, rs-client response
• Change Controller: IESG
• Specification Document(s): [RFC-XXXX]

 

• Parameter name: kdc_dh_creds
• Parameter usage location: client-rs request, rs-client response
• Change Controller: IESG
• Specification Document(s): [RFC-XXXX]

OAuth Parameters CBOR Mappings IANA is asked to register the following entries to the "OAuth Parameters CBOR Mappings" registry, as per the procedure specified in .

• Name: ecdh_info
• CBOR Key: TBD (range -256 to 255)
• Value Type: Simple value "null" / Array
• Reference: [RFC-XXXX]

 

• Name: kdc_dh_creds
• CBOR Key: TBD (range -256 to 255)
• Value Type: Simple value "null" / Array
• Reference: [RFC-XXXX]

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

• Name: group_senderId
• CBOR Key: TBD
• CBOR Type: Byte string
• Reference: [RFC-XXXX] ()

 

• Name: ecdh_info
• CBOR Key: TBD
• CBOR Type: Array
• Reference: [RFC-XXXX] ()

 

• Name: kdc_dh_creds
• CBOR Key: TBD
• CBOR Type: Array
• Reference: [RFC-XXXX] ()

 

• Name: group_enc_key
• CBOR Key: TBD
• CBOR Type: Byte string
• Reference: [RFC-XXXX] ()

 

• Name: stale_node_ids
• CBOR Key: TBD
• CBOR Type: Array
• Reference: [RFC-XXXX] ()

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

• Name: Group_OSCORE_Input_Material object
• Key Type Value: GROUPCOMM_KEY_TBD
• Profile: "coap_group_oscore_app", defined in of this document.
• Description: A Group_OSCORE_Input_Material object encoded as described in of this document.
• Reference: [RFC-XXXX] ()

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

• Name: coap_group_oscore_app
• Description: Application profile to provision keying material for participating in group communication protected with Group OSCORE as per .
• CBOR Value: PROFILE_TBD
• Reference: [RFC-XXXX] ()

OSCORE Security Context Parameters IANA is asked to register the following entries in the "OSCORE Security Context Parameters" registry defined in .

• Name: group_SenderId
• CBOR Label: TBD
• CBOR Type: Byte string
• Registry: -
• Description: OSCORE Sender ID assigned to a member of an OSCORE group
• Reference: [RFC-XXXX] ()

 

• Name: cred_fmt
• CBOR Label: TBD
• CBOR Type: Integer
• Registry: COSE Header Parameters
• Description: Format of authentication credentials to be used in the OSCORE group
• Reference: [RFC-XXXX] ()

 

• Name: sign_enc_alg
• CBOR Label: TBD
• CBOR Type: Text string / Integer
• Registry: COSE Algorithms
• Description: OSCORE Signature Encryption Algorithm Value
• Reference: [RFC-XXXX] ()

 

• Name: sign_alg
• CBOR Label: TBD
• CBOR Type: Text string / Integer
• Registry: COSE Algorithms
• Description: OSCORE Signature Algorithm Value
• Reference: [RFC-XXXX] ()

 

• Name: sign_params
• CBOR Label: TBD
• CBOR Type: Array
• Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves
• Description: OSCORE Signature Algorithm Parameters
• Reference: [RFC-XXXX] ()

 

• Name: ecdh_alg
• CBOR Label: TBD
• CBOR Type: Text string / Integer
• Registry: COSE Algorithms
• Description: OSCORE Pairwise Key Agreement Algorithm Value
• Reference: [RFC-XXXX] ()

 

• Name: ecdh_params
• CBOR Label: TBD
• CBOR Type: Array
• Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves
• Description: OSCORE Pairwise Key Agreement Algorithm Parameters
• Reference: [RFC-XXXX] ()

TLS Exporter Labels IANA is asked to register the following entry to the "TLS Exporter Labels" registry defined in and updated in .

• Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app
• DTLS-OK: Y
• Recommended: N
• Reference: [RFC-XXXX] ()

AIF Media-Type Sub-Parameters 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.

• Parameter: Toid
• Name: oscore-gname
• Description/Specification: OSCORE group name
• Reference: [RFC-XXXX]

 

• Parameter: Tperm
• Name: oscore-gperm
• Description/Specification: permissions pertaining OSCORE groups
• Reference: [RFC-XXXX]

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-gname",Tperm="oscore-gperm"
• Encoding: -
• ID: 292 (suggested)
• Reference: [RFC-XXXX]

 

• Media Type: application/aif+json;Toid="oscore-gname",Tperm="oscore-gperm"
• Encoding: -
• ID: 293 (suggested)
• Reference: [RFC-XXXX]

Group OSCORE Roles This document establishes the IANA "Group OSCORE Roles" registry. The registry has been created to use the "Expert Review" registration procedure . Expert review guidelines are provided in . This registry includes the possible roles that nodes can take in an OSCORE group, each in combination with a numeric identifier. These numeric identifiers are used to express authorization information about joining OSCORE groups, as specified in of [RFC-XXXX]. The columns of this registry are:

• Name: A value that can be used in documents for easier comprehension, to identify a possible role that nodes can take in an OSCORE group.
• Value: The numeric identifier for this role. Integer values greater than 65535 are marked as "Private Use", all other values use the registration policy "Expert Review" .
• Description: This field contains a brief description of the role.
• Reference: This contains a pointer to the public specification for the role.

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

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

• Value: "core.osc.gm"
• Description: Group-membership resource of an OSCORE Group Manager.
• Reference: [RFC-XXXX]

Client applications can use this resource type to discover a group membership resource at an OSCORE Group Manager, where to send a request for joining the corresponding OSCORE group.

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

• Value: 7
• Description: Signatures not used in the group.
• Reference: [RFC-XXXX]

 

• Value: 8
• Description: Operation permitted only to signature verifiers.
• Reference: [RFC-XXXX]

 

• Value: 9
• Description: Group currently not active.
• Reference: [RFC-XXXX]

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 role, to verify the correctness of its description against the role as intended in the specification that defined it. Experts 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 roles 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 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] 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] This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. 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. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. 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. 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 specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things. This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path. This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. 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. 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. IANA IANA IANA IANA Informative References 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. SmartThings Ericsson Ericsson The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. 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. RISE AB RISE AB Consultant Ericsson AB Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession and server authentication. 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 a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 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. 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.

Profile Requirements This section lists how this application profile of ACE addresses the requirements defined in Appendix A of .

Mandatory-to-Address Requirements

• REQ1 - Specify the format and encoding of 'scope'. This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format: see and .
• REQ2 - If the AIF format of 'scope' is used, register its specific instance of "Toid" and "Tperm" as Media Type parameters and a corresponding Content-Format, as per the guidelines in : see and .
• REQ3 - if used, specify the acceptable values for 'sign_alg': values from the "Value" column of the "COSE Algorithms" registry .
• REQ4 - If used, specify the acceptable values for 'sign_parameters': format and values from the COSE algorithm capabilities as specified in the "COSE Algorithms" registry .
• REQ5 - If used, specify the acceptable values for 'sign_key_parameters': format and values from the COSE key type capabilities as specified in the "COSE Key Types" registry .
• REQ6 - Specify the acceptable formats for authentication credentials and, if used, the acceptable values for 'cred_fmt': acceptable formats explicitly provide the public key as well as the comprehensive set of information related to the public key algorithm (see and ). Consistent acceptable values for 'cred_fmt' are taken from the "Label" column of the "COSE Header Parameters" registry .
• REQ7 - If the value of the GROUPNAME URI path and the group name in the Access Token scope (gname in ) are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name: not applicable, since a perfect matching is required.
• REQ8 - Define whether the KDC has an authentication credential and if this has to be provided through the 'kdc_cred' parameter, see : yes, as required by the Group OSCORE protocol , see of this document.
• REQ9 - Specify if any part of the KDC interface as defined in is not supported by the KDC: not applicable.
• REQ10 - Register a Resource Type for the root url-path, which is used to discover the correct url to access at the KDC (see ): the Resource Type (rt=) Link Target Attribute value "core.osc.gm" is registered in .
• REQ11 - Define what specific actions (e.g., CoAP methods) are allowed on each resource provided by the KDC interface, depending on whether the Client is a current group member; the roles that a Client is authorized to take as per the obtained access token; and the roles that the Client has as current group member: see .
• REQ12 - Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations: see .
• REQ13 - Specify the encoding of group identifier (see ): CBOR byte string (see ).
• REQ14 - Specify the approaches used to compute and verify the PoP evidence to include in 'client_cred_verify', and which of those approaches is used in which case: see and .
• REQ15 - Specify how the nonce N_S is generated, if the token is not provided to the KDC through the Token Transfer Request to the authz-info endpoint (e.g., if it is used directly to validate TLS instead): see .
• REQ16 - Define the initial value of the 'num' parameter: the initial value MUST be set to 0 when creating the OSCORE group, e.g., as in .
• REQ17 - Specify the format of the 'key' parameter: see .
• REQ18 - Specify acceptable values of the 'gkty' parameter: Group_OSCORE_Input_Material object (see ).
• REQ19 - Specify and register the application profile identifier: coap_group_oscore_app (see ).
• REQ20 - If used, specify the format and content of 'group_policies' and its entries: see .
• REQ21 - Specify the approaches used to compute and verify the PoP evidence to include in 'kdc_cred_verify', and which of those approaches is used in which case: see , and .
• REQ22 - Specify the communication protocol that the members of the group must use: CoAP , also for group communication .
• REQ23 - Specify the security protocols that the group members must use to protect their communication: Group OSCORE .
• REQ24 - Specify how the communication is secured between the Client and KDC: by means of any transport profile of ACE between Client and Group Manager that complies with the requirements in Appendix C of .
• REQ25 - Specify the format of the identifiers of group members: the Sender ID used in the OSCORE group (see and ).
• REQ26 - Specify policies at the KDC to handle member ids that are not included in 'get_creds': see .
• REQ27 - Specify the format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label: see .
• REQ28 - Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already: see .
• REQ29 - Categorize newly defined parameters according to the same criteria of : see .
• REQ30 - Define whether Clients must, should or may support the conditional parameters defined in , and under which circumstances: see .

Optional-to-Address Requirements

• OPT1 (Optional) - If the textual format of 'scope' is used, specify CBOR values to use for abbreviating the role identifiers in the group: not applicable.
• OPT2 (Optional) - Specify additional parameters used in the exchange of Token Transfer Request and Response:
  • 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm parameters, ECDH key parameters and exact format of authentication credentials used in the group, in case the joining node supports the pairwise mode of Group OSCORE (see ).
  • 'kdc_dh_creds', to ask for and retrieve the Group Manager's Diffie-Hellman authentication credentials, in case the joining node supports the pairwise mode of Group OSCORE and the Access Token authorizes to join parwise-only groups (see ).
• OPT3 (Optional) - Specify the negotiation of parameter values for signature algorithm and signature keys, if 'sign_info' is not used: possible early discovery by using the approach based on the CoRE Resource Directory described in .
• OPT4 (Optional) - Specify possible or required payload formats for specific error cases: send a 4.00 (Bad Request) error response to a Join Request (see ).
• OPT5 (Optional) - Specify additional identifiers of error types, as values of the 'error' field in an error response from the KDC: see .
• OPT6 (Optional) - Specify the encoding of 'creds_repo' if the default is not used: no.
• OPT7 (Optional) - Specify the functionalities implemented at the 'control_uri' resource hosted at the Client, including message exchange encoding and other details (see ): see for the eviction of a group member; see for the group rekeying process.
• OPT8 (Optional) - Specify the behavior of the handler in case of failure to retrieve an authentication credential for the specific node: send a 4.00 (Bad Request) error response to a Join Request (see ).
• OPT9 (Optional) - Define a default group rekeying scheme, to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (see ): the "Point-to-Point" rekeying scheme registered in , whose detailed use for this profile is defined in of this document.
• OPT10 (Optional) - Specify the functionalities implemented at the 'control_group_uri' resource hosted at the Client, including message exchange encoding and other details (see ): see for the eviction of multiple group members.
• OPT11 (Optional) - Specify policies that instruct Clients to retain unsuccessfully decrypted messages and for how long, so that they can be decrypted after getting updated keying material: no.
• OPT12 (Optional) - Specify for the KDC to perform group rekeying (together or instead of renewing individual keying material) when receiving a Key Renewal Request: the Group Manager SHOULD NOT perform a group rekeying, unless already scheduled to occur shortly (see ).
• OPT13 (Optional) - Specify how the identifier of a group members's authentication credential is included in requests sent to other group members: no.
• OPT14 (Optional) - Specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see ): see .
• OPT15 (Optional) - Specify if Clients must or should support any of the parameters defined as optional in : no.

Extensibility for Future COSE Algorithms As defined in , future algorithms can be registered in the "COSE Algorithms" registry as specifying none or multiple COSE capabilities. To enable the seamless use of such future registered algorithms, this section defines a general, agile format for:

• Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token Transfer Response (see and );
• The 'sign_params' and 'ecdh_params' parameters within the 'key' parameter (see ), as part of the response payloads used in , , and .

Appendix B of describes the analogous general format for 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response (see of this document). If any of the currently registered COSE algorithms is considered, using this general format yields the same structure defined in this document for the items above, thus ensuring retro-compatibility.

Format of 'ecdh_info_entry' The format of each 'ecdh_info_entry' (see and ) is generalized as follows. Given N the number of elements of the 'ecdh_parameters' array, i.e., the number of COSE capabilities of the ECDH algorithm, then:

• 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', each of which is a CBOR array.
• The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' (i = 0, ..., N-1), is the array of COSE capabilities for the algorithm capability specified in 'ecdh_parameters'[i].

'ecdh_info_entry' with general format

Format of 'key' The format of 'key' (see ) is generalized as follows.

• The 'sign_params' array includes N+1 elements, whose exact structure and value depend on the value of the signature algorithm specified in 'sign_alg'.
  • The first element, i.e., 'sign_params'[0], is the array of the N COSE capabilities for the signature algorithm, as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (see ).
  • Each following element 'sign_params'[i], i.e., with index i > 0, is the array of COSE capabilities for the algorithm capability specified in 'sign_params'[0][i-1].
  For example, if 'sign_params'[0][0] specifies the key type as capability of the algorithm, then 'sign_params'[1] is the array of COSE capabilities for the COSE key type associated with the signature algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (see ).
• The 'ecdh_params' array includes M+1 elements, whose exact structure and value depend on the value of the ECDH algorithm specified in 'ecdh_alg'.
  • The first element, i.e., 'ecdh_params'[0], is the array of the M COSE capabilities for the ECDH algorithm, as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (see ).
  • Each following element 'ecdh_params'[i], i.e., with index i > 0, is the array of COSE capabilities for the algorithm capability specified in 'ecdh_params'[0][i-1].
  For example, if 'ecdh_params'[0][0] specifies the key type as capability of the algorithm, then 'ecdh_params'[1] is the array of COSE capabilities for the COSE key type associated with the ECDH algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (see ).

Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION.

Version -14 to -15

• Alignment with renaming in draft-ietf-ace-key-groupcomm.
• Updated signaling of semantics for binary encoded scopes.
• Considered the upload of Access Tokens in the DTLS 1.3 Handshake.
• Fixes in IANA registrations.
• Editorial fixes.

Version -13 to -14

• Major reordering of the document sections.
• The HKDF Algorithm is specified by the HMAC Algorithm.
• Group communication does not necessarily use IP multicast.
• Generalized AIF data model, also for draft-ace-oscore-gm-admin.
• Clarifications and editorial improvements.

Version -12 to -13

• Renamed parameters about authentication credentials.
• It is optional for the Group Manager to reassign Gids by tracking "Birth Gids".
• Distinction between authentication credentials and public keys.
• Updated IANA considerations related to AIF.
• Updated textual description of registered ACE Scope Semantics value.

Version -11 to -12

• Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'.
• Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft-ietf-ace-key-groupcomm.
• ace-group/ accessible also to non-members that are not Verifiers.
• Clarified what resources are accessible to Verifiers.
• Revised error handling for the newly defined resources.
• Revised use of CoAP error codes.
• Use of "Token Tranfer Request" and "Token Transfer Response".
• New parameter 'rekeying_scheme'.
• Categorization of new parameters and inherited conditional parameters.
• Clarifications on what to do in case of enhanced error responses.
• Changed UCCS to CCS.
• Authentication credentials of just joined Clients can be in rekeying messages.
• Revised names of new IANA registries.
• Clarified meaning of registered CoRE resource type.
• Alignment to new requirements from draft-ietf-ace-key-groupcomm.
• Fixes and editorial improvements.

Version -10 to -11

• Removed redundancy of key type capabilities, from 'sign_info', 'ecdh_info' and 'key'.
• New resource to retrieve the Group Manager's authentication credential.
• New resource to retrieve material for Signature Verifiers.
• New parameter 'sign_enc_alg' related to the group mode.
• 'cred_fmt' takes value from the COSE Header Parameters registry.
• Improved alignment of the Join Response payload with the Group OSCORE Security Context parameters.
• Recycling Group IDs by tracking "Birth GIDs".
• Error handling in case of non available Sender IDs upon joining.
• Error handling in case EdDSA public keys with invalid Y coordinate when the pairwise mode of Group OSCORE is supported.
• Generalized proof-of-possession (PoP) for the joining node's private key; defined Diffie-Hellman based PoP for OSCORE groups using only the pairwise mode.
• Proof-of-possession of the Group Manager's private key in the Join Response.
• Always use 'peer_identifiers' to convey Sender IDs as node identifiers.
• Stale Sender IDs provided when rekeying the group.
• New resource for late retrieval of stale Sender IDs.
• Added examples of message exchanges.
• Revised default values of group configuration parameters.
• Fixes to IANA registrations.
• General format of parameters related to COSE capabilities, supporting future registered COSE algorithms (new Appendix).

Version -09 to -10

• Updated non-recycling policy of Sender IDs.
• Removed policies about Sender Sequence Number synchronization.
• 'control_path' renamed to 'control_uri'.
• Format of 'get_pub_keys' aligned with draft-ietf-ace-key-groupcomm.
• Additional way to inform of group eviction.
• Registered semantics identifier for extended scope format.
• Extended error handling, with error type specified in some error responses.
• Renumbered requirements.

Version -08 to -09

• The url-path "ace-group" is used.
• Added overview of admitted methods on the Group Manager resources.
• Added exchange of parameters relevant for the pairwise mode of Group OSCORE.
• The signed value for 'client_cred_verify' includes also the scope.
• Renamed the key material object as Group_OSCORE_Input_Material object.
• Replaced 'clientId' with 'group_SenderId'.
• Added message exchange for Group Names request-response.
• No reassignment of Sender ID and Gid in the same OSCORE group.
• Updates on group rekeying contextual with request of new Sender ID.
• Signature verifiers can also retrieve Group Names and URIs.
• Removed group policy about supporting Group OSCORE in pairwise mode.
• Registration of the resource type rt="core.osc.gm".
• Update list of requirements.
• Clarifications and editorial revision.

Version -07 to -08

• AIF specific data model to express scope entries.
• A set of roles is checked as valid when processing the Join Request.
• Updated format of 'get_pub_keys' in the Join Request.
• Payload format and default values of group policies in the Join Response.
• Updated payload format of the FETCH request to retrieve authentication credentials.
• Default values for group configuration parameters.
• IANA registrations to support the AIF specific data model.

Version -06 to -07

• Alignments with draft-ietf-core-oscore-groupcomm.
• New format of 'sign_info', using the COSE capabilities.
• New format of Join Response parameters, using the COSE capabilities.
• Considerations on group rekeying.
• Editorial revision.

Version -05 to -06

• Added role of external signature verifier.
• Parameter 'rsnonce' renamed to 'kdcchallenge'.
• Parameter 'kdcchallenge' may be omitted in some cases.
• Clarified difference between group name and OSCORE Gid.
• Removed the role combination ["requester", "monitor"].
• Admit implicit scope and audience in the Authorization Request.
• New format for the 'sign_info' parameter.
• Scope not mandatory to include in the Join Request.
• Group policy about supporting Group OSCORE in pairwise mode.
• Possible individual rekeying of a single requesting node combined with a group rekeying.
• Security considerations on reusage of signature challenges.
• Addressing optional requirement OPT12 from draft-ietf-ace-key-groupcomm
• Editorial improvements.

Version -04 to -05

• Nonce N_S also in error responses to the Join Requests.
• Supporting single Access Token for multiple groups/topics.
• Supporting legal requesters/responders using the 'peer_roles' parameter.
• Registered and used dedicated label for TLS Exporter.
• Added method for uploading a new authentication credential to the Group Manager.
• Added resource and method for retrieving the current group status.
• Fixed inconsistency in retrieving group keying material only.
• Clarified retrieval of keying material for monitor-only members.
• Clarification on incrementing version number when rekeying the group.
• Clarification on what is re-distributed with the group rekeying.
• Security considerations on the size of the nonces used for the signature challenge.
• Added CBOR values to abbreviate role identifiers in the group.

Version -03 to -04

• New abstract.
• Moved general content to draft-ietf-ace-key-groupcomm
• Terminology: node name; node resource.
• Creation and pointing at node resource.
• Updated Group Manager API (REST methods and offered services).
• Size of challenges 'cnonce' and 'rsnonce'.
• Value of 'rsnonce' for reused or non-traditionally-posted tokens.
• Removed reference to RFC 7390.
• New requirements from draft-ietf-ace-key-groupcomm
• Editorial improvements.

Version -02 to -03

• New sections, aligned with the interface of ace-key-groupcomm .
• Exchange of information on the signature algorithm and related parameters, during the Token POST (Section 4.1).
• Nonce 'rsnonce' from the Group Manager to the Client (Section 4.1).
• Client PoP signature in the Key Distribution Request upon joining (Section 4.2).
• Local actions on the Group Manager, upon a new node's joining (Section 4.2).
• Local actions on the Group Manager, upon a node's leaving (Section 12).
• IANA registration in ACE Groupcomm Parameters registry.
• More fulfilled profile requirements (Appendix A).

Version -01 to -02

• Editorial fixes.
• Changed: "listener" to "responder"; "pure listener" to "monitor".
• Changed profile name to "coap_group_oscore_app", to reflect it is an application profile.
• Added the 'type' parameter for all requests to a Join Resource.
• Added parameters to indicate the encoding of authentication credentials.
• Challenge-response for proof-of-possession of signature keys (Section 4).
• Renamed 'key_info' parameter to 'sign_info'; updated its format; extended to include also parameters of the signature key (Section 4.1).
• Code 4.00 (Bad request), in responses to joining nodes providing an invalid authentication credential (Section 4.3).
• Clarifications on provisioning and checking of authentication credentials (Sections 4 and 6).
• Extended discussion on group rekeying and possible different approaches (Section 7).
• Extended security considerations: proof-of-possession of signature keys; collision of OSCORE Group Identifiers (Section 8).
• Registered three entries in the IANA registry "Sequence Number Synchronization Method" (Section 9).
• Registered one public key encoding in the "ACE Public Key Encoding" IANA registry (Section 9).

Version -00 to -01

• Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1).
• Added negotiation of signature algorithm/parameters between Client and Group Manager (Section 4).
• Updated format of the Key Distribution Response as a whole (Section 4.3).
• Added parameter 'cs_params' in the 'key' parameter of the Key Distribution Response (Section 4.3).
• New IANA registrations in the "ACE Authorization Server Request Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE Security Context Parameters" registry and "ACE Groupcomm Profile" registry (Section 9).

Acknowledgments The authors sincerely thank , , , , , , , , , , and for their comments and feedback. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE.