Key Management for OSCORE Groups in ACE

1.1. 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 [RFC2119][RFC8174] 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 [I-D.ietf-ace-oauth-authz] and in the Authorization Information Format (AIF) [I-D.ietf-ace-aif] to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. 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 [I-D.ietf-ace-key-groupcomm], for provisioning and renewing keying material in group communication scenarios.¶
• The terms and concepts described in CBOR [RFC8949] and COSE [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs].¶
• The terms and concepts described in CoAP [RFC7252] and group communication for CoAP [I-D.ietf-core-groupcomm-bis]. 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 [RFC8613] and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. These include the concept of 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.¶

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 [I-D.ietf-core-oscore-groupcomm].¶
• Signature verifier: entity external to the OSCORE group and intended to verify the signature of messages exchanged in the group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). An authorized signature verifier does not join the OSCORE group as an actual member, yet it can retrieve the public keys of the current group members from the Group Manager.¶
• Signature-only group: an OSCORE group that uses only the group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).¶
• Pairwise-only group: an OSCORE group that uses only the pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]).¶

2.1. Overview of the Joining Process

A node performs the steps described in Section 4.3.1.1 of [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The format and processing of messages exchanged among the participants are further specified in Section 4 and Section 6 of this document.¶

2.2. 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 Section 3.2 of [I-D.ietf-core-oscore-groupcomm].¶

To this end the Group Manager MUST support the Group Rekeying Process described in Section 20 of this document, as an instance of the "Point-to-Point" rekeying scheme defined in Section 6.1 of [I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm]. 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 Section 3.2 of [I-D.ietf-core-oscore-groupcomm].¶

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 [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the Group OSCORE Common Security Context of that group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

  Note that the Gid differs from the group name also introduced in [I-D.ietf-ace-key-groupcomm], 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 Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶
• A set of stale Sender IDs, which allows each rekeyed node to purge public keys and Recipient Contexts used in the group and associated to those Sender IDs. This in turn allows every group member to rely on owned public keys to confidently assert the group membership of other sender nodes, when receiving protected messages in the group (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). More details on the maintenance of stale Sender IDs are provided in Section 2.2.1.¶

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 rekeying 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 Section 18), or when the Group Manager forcibly evicts them from the group, e.g., due to expired or revoked authorization (see Section 19). 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 public keys of former group members (see Sections 3.2 and 10.1 of [I-D.ietf-core-oscore-groupcomm]).¶

• 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-dependent rekeying period or scheduling.¶

4.1. Authorization Request

The Authorization Request message is as defined in Section 3.1 of [I-D.ietf-ace-key-groupcomm], 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 Section 3. 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, computed as defined in Section 3 from the numerical abbreviations defined in Figure 1 for each requested role (REQ1).¶

4.2. Authorization Response

The Authorization Response message is as defined in Section 3.2 of [I-D.ietf-ace-key-groupcomm], 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 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 Section 4.1.¶

Furthermore, if the AS uses the extended format of scope defined in Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of the Access Token, the first element of the CBOR sequence [RFC8742] MUST be the CBOR integer with value SEM_ID_TBD, defined in Section 25.13 of this document (REQ28). This indicates that the second element of the CBOR sequence, as conveying the actual access control information, follows the scope semantics defined for this application profile in Section 3 of this document.¶

5.1. ace-group/GROUPNAME/active

This resource implements a GET handler.¶

5.2. ace-group/GROUPNAME/verif-data

This resource implements a GET handler.¶

5.3. ace-group/GROUPNAME/stale-sids

This resource implements a FETCH handler.¶

5.4. Admitted Methods

The table in Figure 2 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.¶

+---------------------------------+--------+-------+-------+-------+
|   Resource                      | Type1  | Type2 | Type3 | Type4 |
+---------------------------------+--------+-------+-------+-------+
| ace-group/                      | F      | F     | F     | F     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/            | G Po   | G Po  | Po *  | Po    |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/active      | G      | G     | -     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/verif-data  | -      | -     | G     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/pub-key     | G F    | G F   | G F   | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/kdc-pub-key | G      | G     | G     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/stale-sids  | F      | F     | -     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/policies    | G      | G     | -     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/num         | G      | G     | -     | -     |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/      | G Pu D | G D   | -     | -     |
|           NODENAME              |        |       |       |       |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/      | Po     | -     | -     | -     |
|           NODENAME/pub-key      |        |       |       |       |
+---------------------------------+--------+-------+-------+-------+

Type1 = Member as Requester and/or Responder        |  G  = GET
Type2 = Member as Monitor                           |  F  = FETCH
Type3 = Non-member (authorized to be Verifier)      |  Po = POST
        (*) = cannot join the group as Verifier     |  Pu = PUT
Type4 = Non-member (not authorized to be Verifier)  |  D  = DELETE

5.5. Operations Supported by Clients

Building on what is defined in Section 4.1.1 of [I-D.ietf-ace-key-groupcomm], and with reference to the resources at the Group Manager newly defined earlier in Section 5 of this document, it is expected that a Client minimally supports also the following set of operations and corresponding interactions with the Group (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 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). 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' public keys and Recipient Contexts (see Section 5.3.1). This data is provided as an aggregated set of stale Sender IDs, which are used as specified in Section 20.3.¶

6.1. Token Transferring

The exchange of Token Transfer Request and Response is defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm]. 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 (OPT2):¶

  • 'ecdh_info' defined in Section 6.1.1 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 about the exact encoding of public keys 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 [I-D.ietf-core-oscore-groupcomm].¶
  • 'gm_dh_pub_keys' defined in Section 6.1.2 of this document, with value the CBOR simple value 'null' (0xf6) to request the Diffie-Hellman public keys of the Group Manager 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 [I-D.ietf-core-oscore-groupcomm].¶

  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 Section 6.2).¶

  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 a combination of the two, 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 [COSE.Algorithms].¶
  • '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 [COSE.Algorithms] (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 [COSE.Key.Types] (REQ5).¶

  • 'pub_key_enc' takes value from the "Label" column of the "COSE Header Parameters" registry [COSE.Header.Parameters] (REQ6). Consistently with Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable values denote an encoding that MUST explicitly provide the full 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 public key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings 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-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B of [I-D.ietf-ace-key-groupcomm] 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 Section 6.1.1. 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 NOT include 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 'gm_dh_pub_keys' 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 'gm_dh_pub_keys' parameter in the Token Transfer Response, as per the format defined in Section 6.1.2. Otherwise, if 'gm_dh_pub_keys' is included in the Token Transfer Request, the Group Manager MAY include the 'gm_dh_pub_keys' parameter in the Token Transfer Response. Note that the field 'id' specifies the group name, or array of group names, for which the corresponding 'gm_dh_pub_keys' applies to.¶

Note that, other than through the above parameters as defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm], 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 by using the approach described in [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and the link to the associated group-membership resource at the Group Manager (OPT3).¶

ecdh_info = ecdh_info_req / ecdh_info_resp

ecdh_info_req = nil                   ; in the Token Transfer
                                      ; Request to the KDC

ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer
                                      ; Response from the KDC

ecdh_info_entry =
[
  id : gname / [ + gname ],
  ecdh_alg : int / tstr,
  ecdh_parameters : [ any ],
  ecdh_key_parameters : [ any ],
  pub_key_enc = int
]

gname = tstr

gm_dh_pub_keys = gm_dh_pub_keys_req / gm_dh_pub_keys_resp

gm_dh_pub_keys_req = nil                        ; in the Token
                                                ; Transfer Request to
                                                ; the Group Manager

gm_dh_pub_keys_res = [ + gm_dh_pub_keys_entry ] ; in the Token
                                                ; Transfer Response
                                                ; from the Group
                                                ; Manager

gm_dh_pub_keys_entry =
[
  id : gname / [ + gname ],
  pub_key_enc = int,
  pub_key = bstr
]

gname = tstr

6.2. Send the Joining Request

The joining node requests to join the OSCORE group by sending a Joining Request message to the related group-membership resource at the Group Manager, as per Section 4.3.1.1 of [I-D.ietf-ace-key-groupcomm].¶

Additionally to what defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the following applies.¶

• The 'scope' parameter MUST be included. Its value encodes one scope entry with the format defined in Section 3, indicating the group name and the role(s) that the joining node wants to take in the group.¶

• The 'get_pub_keys' parameter is present only if the joining node wants to retrieve the public keys of the group members from the Group Manager during the joining process (see Section 7). Otherwise, this parameter MUST NOT be present.¶

  If this parameter is present and its value is non-null, 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 Section 3.¶

• '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 Section 6.2.1.¶

  • 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 [RFC5869].¶

    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 [NIST-800-56A], 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 Section 5 of [RFC7748].¶
    • info takes as value the PoP input.¶
    • L is equal to 8, i.e., the size of the MAC, in bytes.¶

6.3. Receive the Joining Request

The Group Manager processes the Joining Request as defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following additions.¶

• The Group Manager MUST return a 5.03 (Service Unavailable) response in case the OSCORE group that the joining node has been trying to join is currently inactive (see Section 5.1). The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be set to 9 ("Group currently not active").¶
• In case the joining node is not going to join the group exclusively as monitor, the Group Manager MUST return a 5.03 (Service Unavailable) response if there are currently no OSCORE 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 Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be set to 4 ("No available node identifiers").¶
• In case the joining node is not going to join the group exclusively as monitor and the Joining Request does not include the 'client_cred' parameter, the joining process fails if the Group Manager either: i) does not store a public key with an accepted format for the joining node; or ii) stores multiple public keys with an accepted format for the joining node.¶

• In order to verify the PoP evidence contained in 'client_cred_verify', the Group Manager proceeds as follows.¶

  • As PoP input, the Group Manager uses the value of the 'scope' parameter from the Joining 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 Section 6.2.1, while N_C is the nonce provided in the 'cnonce' parameter of the Joining Request;¶
  • As public key of the joining node, the Group Manager uses either the one retrieved from the 'client_cred' parameter of the Joining Request, or the one already stored as acquired from previous interactions with the joining node.¶

  • The Group Manager verifies the PoP evidence as defined below.¶

    • 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 Joining Request (see Section 6.2), 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 Joining Request.¶

• 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 Section 8 of [I-D.ietf-ace-key-groupcomm]. This parameter has the same format of 'sign_info_res' defined in Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. 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 Joining 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 Section 25.3. This parameter has the same format of 'ecdh_info_res' defined in Section 6.1.1. 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 Joining Request.¶
  • If the group is a pairwise-only group, the CBOR map MUST contain the 'gm_dh_pub_keys' parameter, whose CBOR label is defined in Section 25.3. This parameter has the same format of 'gm_dh_pub_keys_res' defined in Section 6.1.2. In particular, it includes a single element 'gm_dh_pub_keys_entry' pertaining to the OSCORE group that the joining node has tried to join with the Joining Request.¶
  • The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. If present, this parameter is a CBOR byte string, which encodes a newly generated 'kdcchallenge' value that the Client can use when preparing a Joining Request (see Section 6.2). In such a case the Group Manager MUST store the newly generated value as the 'kdcchallenge' value associated to the joining node, possibly replacing the currently stored value.¶
• The Group Manager MUST reply with a 4.00 (Bad Request) error response in case the 'scope' parameter is not present in the Joining Request, or if 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 MUST define possible sets of roles including the new one and existing ones, that are acceptable to specify in the 'scope' parameter of a Joining Request.¶
• The Group Manager MUST reply with a 4.00 (Bad Request) error response in case the Joining Request includes the 'client_cred' parameter but does not include both the 'cnonce' and 'client_cred_verify' parameters.¶
• The Group Manager MUST reply with a 4.00 (Bad Request) error response in case an eligible public key for the joining node is neither present in the 'client_cred' parameter nor already stored.¶

• 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 [RFC8032].¶

  • The public key of the joining node from the 'client_cred' parameter:¶

    • Is for the elliptic curve Ed25519 and has its Y coordinate equal to -1 or 1 (mod p), with p = (2^255 - 19), see Section 4.1 of [RFC7748]; 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 Section 4.2 of [RFC7748].¶

  This prevents 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 Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]).¶

• When receiving a 4.00 (Bad Request) error response, the joining node SHOULD send a new Joining Request to the Group Manager, where:¶

  • The 'cnonce' parameter MUST include a new dedicated nonce N_C generated by the joining node.¶
  • The 'client_cred' parameter MUST include a public key compatible with the encoding, signature or ECDH algorithm, and possible associated parameters indicated by the Group Manager.¶
  • The 'client_cred_verify' parameter MUST include a PoP evidence computed as described in Section 6.2, by using the public key indicated 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.¶

6.4. Send the Joining Response

If the processing of the Joining Request described in Section 6.3 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 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm].¶

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 specified in the Access Token (see Section 4.2).¶

  Consistently with Section 3.2.1 of [I-D.ietf-core-oscore-groupcomm], 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 to the group (see Section 2.2.1).¶
• The Group Manager stores the association between i) the public key of the joining node; and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, associated to 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 Joining Response is formatted as defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following additions:¶

• The 'gkty' parameter identifies a key of type "Group_OSCORE_Input_Material object", defined in Section 25.4 of this document.¶

• The 'key' parameter includes what the joining node needs in order to set up the Group OSCORE Security Context as per Section 2 of [I-D.ietf-core-oscore-groupcomm].¶

  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 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it contains the additional parameters 'group_senderId', 'pub_key_enc', 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and 'ecdh_params' defined in Section 25.6 of this document.¶

  More specifically, the 'key' parameter is composed as follows.¶

  • The 'hkdf' parameter, if present, has as value the HKDF Algorithm used in the OSCORE group. 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 MUST be present and 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, if present, has as value the OSCORE Sender ID assigned to the joining node by the Group Manager, as described above. This parameter MUST NOT be present if the node joins the OSCORE group exclusively with the role of monitor, according to what specified in the Access Token (see Section 4.2). In any other case, this parameter MUST be present.¶

  • The 'pub_key_enc' parameter MUST be present and specifies the encoding of public keys used in the OSCORE group. It takes value from the "Label" column of the "COSE Header Parameters" registry [COSE.Header.Parameters] (REQ6). Consistently with Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable values denote an encoding that MUST explicitly provide the full 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 public key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings 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 'sign_enc_alg' parameter MUST NOT be present if the OSCORE group is a pairwise-only group. Otherwise, it MUST be present and specifies 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 [COSE.Algorithms].¶
  • The 'sign_alg' parameter MUST NOT be present if the OSCORE group is a pairwise-only group. Otherwise, it MUST be present and specifies the Signature Algorithm used to sign messages in the OSCORE group. This parameter takes values from the "Value" column of the "COSE Algorithms" registry [COSE.Algorithms].¶

  • The 'sign_params' parameter MUST NOT be present if the OSCORE group is a pairwise-only group. Otherwise, it MUST be present and specifies 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 [COSE.Algorithms].¶
    • '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 [COSE.Key.Types].¶
  • The 'alg' parameter MUST NOT be present if the OSCORE group is a signature-only group. Otherwise, it MUST be present and specifies the AEAD Algorithm used in the OSCORE group to encrypt messages protected with the pairwise mode.¶
  • The 'ecdh_alg' parameter MUST NOT be present if the OSCORE group is a signature-only group. Otherwise, it MUST be present and specifies the Pairwise Key Agreement Algorithm used in the OSCORE group. This parameter takes values from the "Value" column of the "COSE Algorithms" registry [COSE.Algorithms].¶

  • The 'ecdh_params' parameter MUST NOT be present if the OSCORE group is a signature-only group. Otherwise, it MUST be present and specifies 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 [COSE.Algorithms].¶
    • '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 [COSE.Key.Types].¶

  The format of 'key' defined above is consistent with every signature algorithm and ECDH algorithm currently considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B 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.¶

• 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 Section 25.5 of this document.¶

• The 'pub_keys' parameter, if present, includes the public keys requested by the joining node by means of the 'get_pub_keys' parameter in the Joining Request.¶

  If the joining node has asked for the public keys of all the group members, i.e., 'get_pub_keys' had value the CBOR simple value 'null' (0xf6) in the Joining Request, then the Group Manager provides only the public keys of the group members that are relevant to the joining node. That is, in such a case, 'pub_keys' includes only: i) the public keys of the responders currently in the OSCORE group, in case the joining node is configured (also) as requester; and ii) the public keys 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 public key is specified in the 'pub_keys' 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 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with default value 3600;¶
  • "Expiration Delta" defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with default value 0.¶
• The 'kdc_cred' parameter MUST be present, specifying the Group Manager's public key in its original binary representation (REQ8). The Group Manager's public key MUST be compatible with the encoding, 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 to the public key 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 [RFC5869].¶

    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 [NIST-800-56A], 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 Section 5 of [RFC7748].¶
    • 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 Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying scheme in the OSCORE group (OPT9). Its detailed use for this profile is defined in Section 20 of this document. In any other case, the 'group_rekeying' parameter MUST be included.¶

As a last action, 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 Section 3 of [I-D.ietf-core-oscore-groupcomm]). This applies also in case the node is in fact re-joining the group; in such a case, the newly determined Birth Gid overwrites the one currently stored.¶

6.5. Receive the Joining Response

Upon receiving the Joining Response, the joining node retrieves the Group Manager's public key 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 Joining 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, 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 Section 6.4), with the difference that the joining node uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Group Manager. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Joining Response.¶

In case of failed verification of the PoP evidence, the joining node MUST stop processing the Joining Response and MAY send a new Joining Request to the Group Manager (see Section 6.2).¶

In case of successful verification of the PoP evidence, the joining node uses the information received in the Joining Response to set up the Group OSCORE Security Context, as described in Section 2 of [I-D.ietf-core-oscore-groupcomm]. If the following parameters were not included in the 'key' parameter of the Joining Response, the joining node considers the following default values, consistently with Section 3.2 of [RFC8613].¶

• 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 Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying scheme used in the group (OPT9). Its detailed use for this profile is defined in Section 20 of this document.¶

In addition, the joining node maintains an association between each public key retrieved from the 'pub_keys' 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 [I-D.ietf-core-oscore-groupcomm]. When doing so:¶

• The joining node MUST NOT process an incoming request message, if protected by a group member whose public key is not associated to the role "Requester".¶
• The joining node MUST NOT process an incoming response message, if protected by a group member whose public key is not associated to the role "Responder".¶
• The joining node MUST NOT use the pairwise mode of Group OSCORE to process messages in the group, if the Joining 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 Section 20). As a consequence, the joining node is not able to access secure communication in the OSCORE group occurred prior its joining.¶

8.1. Retrieve of 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 Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution Response is formatted as defined in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm], with the following additions.¶

• The 'key' parameter is formatted as defined in Section 6.4 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 Section 2 of [I-D.ietf-core-oscore-groupcomm].¶

8.2. Retrieve of 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 Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution Response is formatted as defined in Section 4.8.1 of [I-D.ietf-ace-key-groupcomm], with the following additions.¶

• The 'key' parameter is formatted as defined in Section 6.4 of this document. In particular, if the requesting group member has exclusively the role of monitor, no 'group_SenderId' is specified within the 'key' parameter.¶

  Note that, in any other case, the current Sender ID of the group member is not specified as a separate parameter, but rather specified as '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 Section 2 of [I-D.ietf-core-oscore-groupcomm].¶

20.1. Sending Rekeying Messages

The group rekeying messages MUST have Content-Format set to application/ace-groupcomm+cbor and have the same format used for the Joining Response message in Section 6.4, with the following differences. Note that this extends the minimal content of a rekeying message as defined in Section 6 of [I-D.ietf-ace-key-groupcomm] (OPT14).¶

• From the Joining 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 Section 25.3. 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 to the group (see Section 2.2.1), and takes the most recent set X, i.e., the set associated to 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 'pub_keys', 'peer_roles' and 'peer_identifiers' SHOULD be present, if the group rekeying is performed due to one or multiple Clients that have requested join the group. Following the same semantics used in the Joining Response message (see Section 6.4), the three parameters specify the public key, 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 channel 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 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by the intended recipient upon joining the group (see Section 6.2).¶

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 [RFC8613] 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 [I-D.ietf-ace-oscore-profile].¶

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 Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group member may use CoAP Observe [RFC7641] and subscribe for updates to the group-membership resource of the group, at the endpoint /ace-group/GROUPNAME/ of the Group Manager (see Section 6.1 of [I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub model can be considered [I-D.ietf-core-coap-pubsub], where the Group Manager publishes to a rekeying topic hosted at a Broker, while the group members subscribe to such topic (see Section 6.2 of [I-D.ietf-ace-key-groupcomm]).¶

20.2. Receiving Rekeying Messages

Once received the new group keying material, a group member proceeds as follows.¶

The group member considers the stale Sender IDs received from the Group Manager. If the group rekeying scheme defined in Section 20.1 is used, the stale Sender IDs are specified by the 'stale_node_ids' parameter.¶

After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], the group member MUST remove every public key associated to a stale Sender ID from its list of group members' public keys 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 group rekeying scheme defined in Section 20.1 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 owned 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 owned 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 Section 20.3.¶
• The group member has received keying material not newer than the stored one. That is, the stored keying material owned 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.¶

20.3. 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 Section 20.2.¶

b. The group member has obtained the latest keying material from the Group Manager, as a response to a Key Distribution Request (see Section 8.1) or to a Joining Request when re-joining the group (see Section 6.2). In particular, V is different than V' specified by the 'num' parameter in the response.¶

c. The group member has obtained the public keys of other group members, through a Public Key Request-Response exchange with the Group Manager (see Section 10). 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 Section 15). 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 Section 20.3.1), 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 public keys from its list of group members' public keys 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 public key associated to a stale Sender ID from its list of group members' public keys 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 Section 20.3.1), 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 public keys from its list of group members' public keys 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 public key associated to a stale Sender ID from its list of group members' public keys 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 Section 8.1), or by re-joining the group (see Section 6.2).¶
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 Section 6.2). 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 public keys of all the current group members. That is, the 'get_pub_keys' parameter of the Joining Request MUST be present and MUST be set to the CBOR simple value 'null' (0xf6).¶

2. When receiving the Joining Response (see Section 6.5 and Section 6.5), the group member retrieves the set Z of public keys specified in the 'pub_keys' parameter.¶

   Then, the group member MUST remove every public key which is not in Z from its list of group members' public keys used in the group, and MUST delete each of its Recipient Contexts used in the group that does not include any of the public keys in Z.¶

3. The group member installs the latest keying material with version number V' and derives the corresponding new Security Context.¶

                                                              Group
Node                                                         Manager
  |                                                             |
  |                   Stale Sender IDs Request                  |
  |------------------------------------------------------------>|
  |             FETCH ace-group/GROUPNAME/stale-sids            |
  |                                                             |
  |<---------- Stale Sender IDs Response: 2.05 (Content) -------|
  |                                                             |

   Request:

   Header: FETCH (Code=0.05)
   Uri-Host: "kdc.example.com"
   Uri-Path: "ace-group"
   Uri-Path: "g1"
   Uri-Path: "stale-sids"
   Payload (in CBOR diagnostic notation):
     42

   Response:

   Header: Content (Code=2.05)
   Payload (in CBOR diagnostic notation):
     [h'01', h'fc', h'12ab', h'de44', h'ff']

23.1. Common

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

• For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the same default value defined in Section 3.2 of [RFC8613], i.e., HKDF SHA-256 (COSE algorithm encoding: -10).¶

• For the format 'pub_key_enc' used to encode the public keys in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or CWT Claims Set (CCS) [RFC8392], 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 to the group (see Section 2.2.1).¶

23.2. 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 encrypted 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 [COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves].¶

• For the Signature Algorithm 'sign_alg' used to sign messages protected with the group mode, the signature algorithm EdDSA [RFC8032].¶

• 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 [RFC8032].¶
  • The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] 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 [RFC6979] 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 [RFC6979] 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 [RFC8017] is specified for 'sign_alg'. In particular, this indicates to use the COSE key type RSA.¶

23.3. 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 Section 3.2 of [RFC8613], 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 [COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves].¶

• 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 Section 6.3.1 of [I-D.ietf-cose-rfc8152bis-algs].¶

• 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'. In particular, this indicates to use the COSE key type OKP and the elliptic curve X25519 [RFC8032].¶
  • The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] 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 [RFC6979] 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 [RFC6979] is specified for 'sign_alg'. In particular, this indicates to use the COSE key type EC2 and the elliptic curve P-521.¶

24.1. Management of OSCORE Groups

This profile leverages the following management aspects related to OSCORE groups and discussed in the sections of [I-D.ietf-core-oscore-groupcomm] referred below.¶

• Management of group keying material (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager is responsible for the renewal and re-distribution of the keying material in the groups of its competence (rekeying). According to the specific application requirements, this can include rekeying the group upon changes in its membership. In particular, renewing the group keying material is required upon a new node's joining or a current node's leaving, in case backward security and forward security have to be preserved, respectively.¶
• Provisioning and retrieval of public keys (see Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key repository of public keys of group members, and provides them upon request.¶
• Synchronization of sequence numbers (see Section 6.3 of [I-D.ietf-core-oscore-groupcomm]). 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 Joining 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 Section 6. Alternatively, the joining node can use its own public key as asymmetric proof-of-possession key to establish a secure channel with the Group Manager, e.g., as in Section 3.2.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires such proof-of-possession key to be compatible with the encoding, as well as with the signature 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.¶

24.2. Size of Nonces as Proof-of-Possesion Challenge

With reference to the Joining Request message in Section 6.2, 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 Joining Request, which is always sent over the secure communication channel between the joining node and the Group Manager.¶

As defined in Section 6.2.1, 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 Section 6.1, then N_S is computed as a 32-byte long challenge. For an example, see point (2) of Section 6.2.1.¶
• 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 Section 6.1, 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 Section 6.2.1. This is provided either in the Token Transfer Response (see Section 6.1), or in a 4.00 (Bad Request) error response to a following Joining Request (see Section 6.3). 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 Joining 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.¶
• Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of [RFC8613] 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.¶

24.3. Reusage of Nonces for Proof-of-Possession Input

As long as the Group Manager preserves the same N_S value currently associated to 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 Joining Requests to that Group Manager.¶

In particular, the Client can reuse the same N_C value for every Joining 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 Joining 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 to 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.¶

25.1. OAuth Parameters

IANA is asked to register the following entries to the "OAuth Parameters" registry, as per the procedure specified in Section 11.2 of [RFC6749].¶

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

• Parameter name: gm_dh_pub_keys¶
• Parameter usage location: client-rs request, rs-client response¶
• Change Controller: IESG¶
• Specification Document(s): [[This specification]]¶

25.2. 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 Section 8.10 of [I-D.ietf-ace-oauth-authz].¶

• Name: ecdh_info¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: Simple value null / array¶
• Reference: [[This specification]]¶

• Name: gm_dh_pub_keys¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: Simple value null / array¶
• Reference: [[This specification]]¶

25.3. ACE Groupcomm Parameters

IANA is asked to register the following entry to the "ACE Groupcomm Parameters" registry defined in Section 11.7 of [I-D.ietf-ace-key-groupcomm].¶

• Name: group_senderId¶
• CBOR Key: TBD¶
• CBOR Type: Byte string¶
• Reference: [[This document]] (Section 9)¶

• Name: ecdh_info¶
• CBOR Key: TBD¶
• CBOR Type: Array¶
• Reference: [[This document]] (Section 6.3)¶

• Name: gm_dh_pub_keys¶
• CBOR Key: TBD¶
• CBOR Type: Array¶
• Reference: [[This document]] (Section 6.3)¶

• Name: group_enc_key¶
• CBOR Key: TBD¶
• CBOR Type: Byte String¶
• Reference: [[This document]] (Section 5.2.1)¶

• Name: stale_node_ids¶
• CBOR Key: TBD¶
• CBOR Type: Array¶
• Reference: [[This document]] (Section 20)¶

25.4. ACE Groupcomm Key Types

IANA is asked to register the following entry to the "ACE Groupcomm Key Types" registry defined in Section 11.8 of [I-D.ietf-ace-key-groupcomm].¶

• Name: Group_OSCORE_Input_Material object¶
• Key Type Value: GROUPCOMM_KEY_TBD¶
• Profile: "coap_group_oscore_app", defined in Section 25.5 of this document.¶
• Description: A Group_OSCORE_Input_Material object encoded as described in Section 6.4 of this document.¶
• Reference: [[This document]] (Section 6.4)¶

25.5. ACE Groupcomm Profiles

IANA is asked to register the following entry to the "ACE Groupcomm Profiles" registry defined in Section 11.9 of [I-D.ietf-ace-key-groupcomm].¶

• Name: coap_group_oscore_app¶
• Description: Application profile to provision keying material for participating in group communication protected with Group OSCORE as per [I-D.ietf-core-oscore-groupcomm].¶
• CBOR Value: PROFILE_TBD¶
• Reference: [[This document]] (Section 6.4)¶

25.6. OSCORE Security Context Parameters

IANA is asked to register the following entries in the "OSCORE Security Context Parameters" registry defined in Section 9.4 of [I-D.ietf-ace-oscore-profile].¶

• Name: group_SenderId¶
• CBOR Label: TBD¶
• CBOR Type: bstr¶
• Registry: -¶
• Description: OSCORE Sender ID assigned to a member of an OSCORE group¶
• Reference: [[This document]] (Section 6.4)¶

• Name: pub_key_enc¶
• CBOR Label: TBD¶
• CBOR Type: integer¶
• Registry: COSE Header Parameters¶
• Description: Encoding of Public Keys to be used in the OSCORE group¶
• Reference: [[This document]] (Section 6.4)¶

• Name: sign_enc_alg¶
• CBOR Label: TBD¶
• CBOR Type: tstr / int¶
• Registry: COSE Algorithms¶
• Description: OSCORE Signature Encryption Algorithm Value¶
• Reference: [[This document]] (Section 6.4)¶

• Name: sign_alg¶
• CBOR Label: TBD¶
• CBOR Type: tstr / int¶
• Registry: COSE Algorithms¶
• Description: OSCORE Signature Algorithm Value¶
• Reference: [[This document]] (Section 6.4)¶

• Name: sign_params¶
• CBOR Label: TBD¶
• CBOR Type: array¶
• Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves¶
• Description: OSCORE Signature Algorithm Parameters¶
• Reference: [[This document]] (Section 6.4)¶

• Name: ecdh_alg¶
• CBOR Label: TBD¶
• CBOR Type: tstr / int¶
• Registry: COSE Algorithms¶
• Description: OSCORE Pairwise Key Agreement Algorithm Value¶
• Reference: [[This document]] (Section 6.4)¶

• 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: [[This document]] (Section 6.4)¶

25.7. TLS Exporter Labels

IANA is asked to register the following entry to the "TLS Exporter Labels" registry defined in Section 6 of [RFC5705] and updated in Section 12 of [RFC8447].¶

• Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app¶
• DTLS-OK: Y¶
• Recommended: N¶
• Reference: [[This document]] (Section 6.2.1)¶

25.8. AIF

IANA is asked to register the following entry to the "Toid" registry within the "AIF" registry group defined in Section 5.2 of [I-D.ietf-ace-aif].¶

• Name: oscore-group-name¶
• Description/Specification: group name of the OSCORE group, as specified in [[This document]].¶

IANA is asked to register the following entry to the "Tperm" registry within the "AIF" registry group defined in Section 5.2 of [I-D.ietf-ace-aif].¶

• Name: oscore-group-roles¶
• Description/Specification: role(s) of the member of the OSCORE group, as specified in [[This document]].¶

25.9. Media Type Registrations

This document registers the 'application/aif-groupcomm-oscore+cbor' media type for the AIF specific data model AIF-OSCORE-GROUPCOMM defined in Section 3 of [[This document]]. This registration follows the procedures specified in [RFC6838].¶

These media type has parameters for specifying the object identifier ("Toid") and set of permissions ("Tperm") defined for the AIF-generic model in [I-D.ietf-ace-aif]; default values are the values "oscore-group-name" for "Toid" and "oscore-group-roles" for "Tperm".¶

Type name: application¶

Subtype name: aif-groupcomm-oscore+cbor¶

Required parameters: "Toid", "Tperm"¶

Optional parameters: N/A¶

Encoding considerations: Must be encoded as a CBOR array, each element of which is an array [Toid, Tperm] as defined in Section 3 of [[This document]].¶

Security considerations: See Section 24 of [[This document]].¶

Interoperability considerations: N/A¶

Published specification: [[This document]]¶

Applications that use this media type: The type is used by applications that want to express authorization information about joining OSCORE groups, as specified in [[This document]].¶

Fragment identifier considerations: N/A¶

Additional information: N/A¶

Person & email address to contact for further information: iesg@ietf.org¶

Intended usage: COMMON¶

Restrictions on usage: None¶

Author: Marco Tiloca marco.tiloca@ri.se¶

Change controller: IESG¶

Provisional registration? No¶

25.10. CoAP Content-Format

IANA is asked to register the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group:¶

Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group-name",Tperm"oscore-group-roles"¶

Encoding: -¶

ID: TBD¶

Reference: [[This document]]¶

25.11. Group OSCORE Roles

This document establishes the IANA "Group OSCORE Roles" registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 25.15.¶

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 Section 3 of [[This document]].¶

The columns of this registry are:¶

• Name: A value that can be used in documents for easier comprehension, to identify a possible 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" [RFC8126].¶
• 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 Figure 1.¶

The Reference column for all of these entries will be [[This document]].¶

25.12. 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: [[This document]]¶

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.¶

25.13. ACE Scope Semantics

IANA is asked to register the following entry in the "ACE Scope Semantics" registry defined in Section 11.12 of [I-D.ietf-ace-key-groupcomm].¶

• Value: SEM_ID_TBD¶
• Description: Access to OSCORE groups through the ACE Group Manager.¶
• Reference: [[This document]]¶

25.14. ACE Groupcomm Errors

IANA is asked to register the following entry in the "ACE Groupcomm Errors" registry defined in Section 11.13 of [I-D.ietf-ace-key-groupcomm].¶

• Value: 7¶
• Description: Signatures not used in the group.¶
• Reference: [[This document]]¶

• Value: 8¶
• Description: Operation permitted only to signature verifiers.¶
• Reference: [[This document]]¶

• Value: 9¶
• Description: Group currently not active.¶
• Reference: [[This document]]¶

25.15. 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. Expert should consider requesting an opinion on the correctness of registered parameters from the Authentication and Authorization for Constrained Environments (ACE) Working Group and the Constrained RESTful Environments (CoRE) Working Group.¶

  Entries that do not meet these objective of clarity and completeness should not be registered.¶

• Duplicated registration and point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments.¶
• Experts should take into account the expected usage of 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.¶

A.1. 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 Section 3 and Section 4.1.¶
• REQ2 - If the AIF format of 'scope' is used, register its specific instance of "Toid" and "Tperm", as well as the corresponding Media Type and Content-Format, as per the guidelines in [I-D.ietf-ace-aif]: see Section 25.8, Section 25.9 and Section 25.10.¶
• REQ3 - if used, specify the acceptable values for 'sign_alg': values from the "Value" column of the "COSE Algorithms" registry [COSE.Algorithms].¶
• 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 [COSE.Algorithms].¶
• 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 [COSE.Key.Types].¶
• REQ6 - Specify the acceptable formats for encoding public keys and, if used, the acceptable values for 'pub_key_enc': acceptable formats explicitly provide the full set of information related to the public key algorithm (see Section 6.1 and Section 6.4). Consistent acceptable values for 'pub_key_enc' are taken from the "Label" column of the "COSE Header Parameters" registry [COSE.Header.Parameters].¶
• REQ7 - If the value of the GROUPNAME URI path and the group name in the Access Token scope (gname in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) 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 a public key and if this has to be provided through the 'kdc_cred' parameter, see Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see Section 6.4 of this document.¶
• REQ9 - Specify if any part of the KDC interface as defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm] 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 Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type (rt=) Link Target Attribute value "core.osc.gm" is registered in Section 25.12.¶
• 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 Section 5.4.¶
• REQ12 - Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations (see Section 5.5).¶
• REQ13 - Specify the encoding of group identifier (see Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string (see Section 17).¶
• 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 Section 6.2 and Section 6.3.¶
• 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 Section 6.2.1.¶
• 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 [I-D.ietf-ace-oscore-gm-admin].¶
• REQ17 - Specify the format of the 'key' parameter: see Section 6.4.¶
• REQ18 - Specify acceptable values of the 'gkty' parameter: Group_OSCORE_Input_Material object (see Section 6.4).¶
• REQ19 - Specify and register the application profile identifier: coap_group_oscore_app (see Section 25.5).¶
• REQ20 - If used, specify the format and content of 'group_policies' and its entries: see Section 6.4.¶
• 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 Section 6.4, Section 6.5 and Section 12.¶
• REQ22 - Specify the communication protocol that the members of the group must use: CoAP [RFC7252], possibly over IP multicast [I-D.ietf-core-groupcomm-bis].¶
• REQ23 - Specify the security protocols that the group members must use to protect their communication: Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶
• REQ24 - Specify how the communication is secured between the Client and KDC: by means of any transport profile of ACE [I-D.ietf-ace-oauth-authz] between Client and Group Manager that complies with the requirements in Appendix C of [I-D.ietf-ace-oauth-authz].¶
• REQ25 - Specify the format of the identifiers of group members: the Sender ID used in the OSCORE group (see Section 6.4 and Section 10).¶
• REQ26 - Specify policies at the KDC to handle member ids that are not included in 'get_pub_keys': see Section 10.¶
• 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 Section 9.¶
• REQ28 - Specify and register the identifier of newly defined semantics for binary scopes: see Section 25.13.¶
• REQ29 - Categorize newly defined parameters according to the same criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see Section 21.¶
• REQ30 - Define whether Clients must, should or may support the conditional parameters defined in Section 8 of [I-D.ietf-ace-key-groupcomm], and under which circumstances: see Section 21.¶

A.2. 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 encoding of public keys used in the group, in case the joining node supports the pairwise mode of Group OSCORE (see Section 6.1).¶
  • 'gm_dh_pub_keys', to ask for and retrieve the Group Manager's Diffie-Hellman public keys, in case the the joining node supports the pairwise mode of Group OSCORE and the Access Token authorizes to join parwise-only groups (see Section 6.1).¶
• 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 [I-D.tiloca-core-oscore-discovery].¶
• OPT4 (Optional) - Specify possible or required payload formats for specific error cases: send a 4.00 (Bad Request) error response to a Joining Request (see Section 6.3).¶
• OPT5 (Optional) - Specify additional identifiers of error types, as values of the 'error' field in an error response from the KDC: see Section 25.14.¶
• OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' 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 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of a group member; see Section 20 for the group rekeying process.¶
• OPT8 (Optional) - Specify the behavior of the handler in case of failure to retrieve a public key for the specific node: send a 4.00 (Bad Request) error response to a Joining Request (see Section 6.3).¶
• OPT9 (Optional) - Define a default group rekeying scheme, to refer to in case the 'rekeying_scheme' parameter is not included in the Joining Response (see Section 4.3.1.1 of [I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm], whose detailed use for this profile is defined in Section 20 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 Section 4.3.1 of [I-D.ietf-ace-key-groupcomm]): see Section 19 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 Section 9).¶
• OPT13 (Optional) - Specify how the identifier of a group members's public key 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 Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see Section 20.1.¶
• OPT15 (Optional) - Specify if Clients must or should support any of the parameters defined as optional in Section 8 of [I-D.ietf-ace-key-groupcomm]: no.¶

B.1. Format of 'ecdh_info_entry'

The format of each 'ecdh_info_entry' (see Section 6.1 and Section 6.1.1) 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 =
[
  id : gname / [ + gname ],
  ecdh_alg : int / tstr,
  ecdh_parameters : [ alg_capab_1 : any,
                      alg_capab_2 : any,
                      ...,
                      alg_capab_N : any],
  ecdh_capab_1 : [ any ],
  ecdh_capab_2 : [ any ],
  ...,
  ecdh_capab_N : [ any ],
  pub_key_enc = int / nil
]

gname = tstr

B.2. Format of 'key'

The format of 'key' (see Section 6.4) 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 [COSE.Algorithms] (see Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs]).¶
  • 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 to the signature algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry [COSE.Key.Types] (see Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]).¶

• 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 [COSE.Algorithms] (see Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs]).¶
  • 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 to the ECDH algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry [COSE.Key.Types] (see Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]).¶

C.1. Version -11 to -12

• Clarified semantics of 'ecdh_info' and 'gm_dh_pub_keys'.¶
• 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.¶
• Public keys 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.¶

C.2. 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 public key.¶
• New resource to retrieve material for Signature Verifiers.¶
• New parameter 'sign_enc_alg' related to the group mode.¶
• 'pub_key_enc' takes value from the COSE Header Parameters registry.¶
• Improved alignment of the Joining 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 Joining 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).¶

C.3. 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.¶

C.4. 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.¶

C.5. Version -07 to -08

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

C.6. Version -06 to -07

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

C.7. 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 Joining 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.¶

C.8. Version -04 to -05

• Nonce N_S also in error responses to the Joining 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 public key 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.¶

C.9. 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.¶

C.10. 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).¶

C.11. 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 public keys.¶
• 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 public key (Section 4.3).¶
• Clarifications on provisioning and checking of public keys (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).¶

C.12. 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).¶