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 following:¶

• The terms and concepts described in the ACE framework [RFC9200] and in the Authorization Information Format (AIF) [RFC9237] 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 concepts described in the Constrained Application Protocol (CoAP) [RFC7252]. 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 described in Concise Data Definition Language (CDDL) [RFC8610], CBOR [RFC8949], and CBOR Object Signing and Encryption (COSE) [RFC9052] [RFC9053] [RFC9338].¶

A node interested in participating in group communication, as well as one that is already participating as a group member, is interchangeably denoted as "Client".¶

This document also uses the following terms.¶

Group:

A set of nodes that share common keying material and security parameters used to protect their communications with one another. That is, the term refers to a "security group".¶

This term is not to be confused with an "application group", which has relevance at the application level and whose members share a common pool of resources or content. Examples of application groups are the set of all nodes deployed in a same physical room or the set of nodes registered to a pub-sub topic.¶

This term is also not to be confused with a "multicast group", which has relevance at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of a multicast group is the set of nodes that are configured to receive messages that are sent to the group's associated IP multicast address.¶

The same security group might be associated with multiple application groups. Also, the same application group can be associated with multiple security groups. Further details and considerations on the mapping between the three types of groups are out of the scope of this document.¶

Key Distribution Center (KDC):

The entity responsible for managing one or multiple groups, with particular reference to the group membership and the keying material to use for protecting group communications.¶

Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below.¶

Group name:

The identifier of a group as a text string encoded as UTF-8 [RFC3629]. Once established, it is invariant. It is used in the interactions between the Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC.¶

GROUPNAME:

The text string used in URIs to identify a group. Once established, it is invariant. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide.¶

Group identifier:

The identifier of the group keying material used in a group. Unlike group name and GROUPNAME, this identifier changes over time when the group keying material is updated.¶

Node name:

The identifier of a node as a text string encoded as UTF-8 [RFC3629] and consistent with the semantics of URI path segments (see Section 3.3 of [RFC3986]). Once established, it is invariant. It is used in the interactions between the Client and RS, as well as to identify a member of a group. A node name is always unique among the node names of the current nodes within a group.¶

NODENAME:

The text string used in URIs to identify a member of a group. Once established, it is invariant. Its value coincides with the node name of the associated group member.¶

This document additionally uses the following terminology:¶

Transport profile:

A profile of an ACE as per Section 5.8.4.3 of [RFC9200]. A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods if it supports proof-of-possession access tokens, etc. Transport profiles of ACE include, for instance, those described in [RFC9202], [RFC9203], and [RFC9431].¶

Application profile:

A profile that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation, and distribution of keying material. An application profile may define specific procedures and message formats.¶

Authentication credential:

The set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs), CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [C509-CERT].¶

Individual keying material:

Information pertaining exclusively to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be an identifier that the secure communication protocol employs to uniquely identify a node as a group member (e.g., a cryptographic key identifier uniquely associated with the group member in question). The specific nature and format of individual keying material used in a group is defined in the application profiles of this specification. The individual keying material of a group member is not related to the secure association between that group member and the KDC.¶

Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations.¶

3.1. Authorization Request

The Authorization Request sent from the Client to the AS is defined in Section 5.8.1 of [RFC9200] and MAY contain the following parameters, which, if included, MUST have the format and value as specified below.¶

• 'scope': specifying the names of the groups that the Client requests to access and optionally the roles that the Client requests to have in those groups.¶

  This parameter is encoded as a CBOR byte string, which wraps a CBOR array of scope entries. All the scope entries are specified according to the same format, i.e., either the AIF format or the textual format defined below.¶

  • If the AIF format is used, each scope entry is encoded as per [RFC9237], i.e., as a CBOR array [Toid, Tperm]. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name and MUST be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group.¶

    The AIF format is the default format for application profiles of this specification and is preferable for those that aim for a compact encoding of scope. This is especially desirable for application profiles defining several roles, with the Client possibly asking for multiple roles combined.¶

    Figure 4 shows an example in CDDL notation [RFC8610] where scope uses the AIF format.¶

  • If the textual format is used, each scope entry is a CBOR array formatted as follows.¶

    • As the first element, the group name, encoded as a CBOR text string.¶
    • Optionally, as the second element, the role or CBOR array of roles that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated with its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).¶

    Figure 5 shows an example in CDDL notation where scope uses the textual format with the group name and role identifiers encoded as CBOR text strings.¶

  It is REQUIRED for application profiles of this specification to specify the exact format and encoding of scope (REQ1). 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.¶

  If the application profile uses the AIF format, it is also REQUIRED to register its specific instance of "Toid" and "Tperm", as well as the corresponding media type and Content-Format, as per the guidelines in [RFC9237] (REQ2).¶

  If the application profile uses the textual format, it MAY additionally specify CBOR values to use for abbreviating the role identifiers (OPT1).¶

• 'audience': with an identifier of the KDC.¶

As defined in [RFC9200], other additional parameters can be included if necessary.¶

;# include rfc9237

gname = tstr

permissions = uint .bits roles

roles = &(
   Requester: 1,
   Responder: 2,
   Monitor: 3,
   Verifier: 4
)

scope_entries = AIF-Generic<gname, permissions>

scope = bstr .cbor scope_entries

gname = tstr

role = tstr

scope_entry = [ gname , ? ( role / [ 2*role ] ) ]

scope_entries = [ * scope_entry ]

scope = bstr .cbor scope_entries

3.2. Authorization Response

The AS processes the Authorization Request as defined in Section 5.8.2 of [RFC9200], especially verifying that the Client is authorized to access the specified groups with the requested roles or possibly a subset of those.¶

In case of successful verification, the Authorization Response sent from the AS to the Client is also defined in Section 5.8.2 of [RFC9200]. Note that the parameter 'expires_in' MAY be omitted if the application defines how the expiration time is communicated to the Client via other means or if it establishes a default value.¶

Additionally, when included, the following parameter MUST have the corresponding values:¶

• 'scope' has the same format and encoding of 'scope' in the Authorization Request, as defined in Section 3.1. If this parameter is not present, the granted scope is equal to the one requested in Section 3.1.¶

The proof-of-possession access token (in 'access_token' above) MUST contain the following parameters:¶

• a confirmation claim (for example, see 'cnf' defined in Section 3.1 of [RFC8747] for CWT);¶
• an expiration time claim (for example, see 'exp' defined in Section 3.1.4 of [RFC8392] for CWT); and¶

• a scope claim (for example, see 'scope' registered in Section 8.14 of [RFC9200] for CWT).¶

  This claim specifies the same access control information as in the 'scope' parameter of the Authorization Response if the parameter is present in the message. If the parameter is not present, the claim specifies the access control information as in the 'scope' parameter of the Authorization Request, if present, or the default scope that the AS is granting the Client, if not present.¶

  By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, as defined in Section 3.1.¶

  Optionally, an alternative extended format of scope defined in Section 7 can be used. This format explicitly signals the semantics used to express the actual access control information, which has to be parsed. This enables a Resource Server to correctly process a received access token, also in case:¶

  • the Resource Server implements a KDC that supports multiple application profiles of this specification using different scope semantics and/or¶
  • the Resource Server implements further services beyond a KDC for group communication using different scope semantics.¶

  If the Authorization Server is aware that this applies to the Resource Server for which the access token is issued, the Authorization Server SHOULD use the extended format of scope defined in Section 7.¶

The access token MAY additionally contain other claims that the transport profile of ACE or other optional parameters require.¶

When receiving an Authorization Request from a Client that was previously authorized and for which the AS still stores a valid non-expired access token, the AS MAY reply with that token. Note that it is up to application profiles of ACE to make sure that reposting the same access token does not cause reuse of keying material between nodes (for example, that is accomplished with the use of random nonces in [RFC9203]).¶

3.3. Token Transferring

The Client sends a Token Transfer Request to the KDC, i.e., a CoAP POST request including the access token and targeting the authz-info endpoint (see Section 5.10.1 of [RFC9200]).¶

Note that this request deviates from the one defined in [RFC9200], since it allows asking the KDC for additional information concerning the authentication credentials used in the group to ensure source authentication, as well as for possible additional group parameters.¶

The joining node MAY ask for this information from the KDC through the same Token Transfer Request. In this case, the message MUST have the Content-Format set to application/ace+cbor as defined in Section 8.16 of [RFC9200], and the message payload MUST be formatted as a CBOR map, which MUST include the access token. The CBOR map MAY additionally include the following parameter, which, if included, MUST have the format and value as specified below.¶

• 'sign_info': defined in Section 3.3.1, specifying the CBOR simple value "null" (0xf6) to request information about the signature algorithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the Client has been authorized to join.¶

Alternatively, such information may be pre-configured on the joining node or may be retrieved by alternative means. For example, the joining node may have performed an early group discovery process and obtained the link to the associated group-membership resource at the KDC, along with attributes that describe the group configuration (e.g., see [OSCORE-DISCOVERY]).¶

After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. Hence, the KDC replies to the Client with a Token Transfer Response, i.e., a CoAP 2.01 (Created) response.¶

The Token Transfer Response MUST have Content-Format "application/ace+cbor", and its payload is a CBOR map. Note that this deviates from what is defined in the ACE framework, where the response from the authz-info endpoint is defined as conveying no payload (see Section 5.10.1 of [RFC9200]).¶

If a scope entry in the access token specifies a role that requires the Client to send its own authentication credential to the KDC when joining the related group, then the CBOR map MUST include the parameter 'kdcchallenge' defined in Section 3.3.2, specifying a dedicated challenge N_S generated by the KDC.¶

Later, when joining the group (see Section 4.3.1.1), the Client uses the 'kdcchallenge' value and additional information to build a proof-of-possession (PoP) input. In turn, this is used to compute PoP evidence, which the Client also provides to the KDC in order to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4.3.1).¶

While storing the access token, the KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from the Client (see Section 4.3.1.1) to be able to verify the PoP evidence provided during the join process and thus that the Client possesses its own private key. The KDC deletes the 'kdcchallenge' value associated with the Client upon deleting the access token (e.g., upon its expiration, see Section 5.10.3 of [RFC9200]).¶

The same 'kdcchallenge' value MAY be reused several times by the Client to generate new PoP evidence, e.g., in case the Client provides the KDC with a new authentication credential while being a group member (see Section 4.9.1.1) or joins a different group where it intends to use a different authentication credential. Therefore, it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' value after the first join is processed as well. If, upon receiving a Join Request from a Client, the KDC has already discarded the 'kdcchallenge' value, that will trigger an error response with a newly generated 'kdcchallenge' value that the Client can use to restart the join process, as specified in Section 4.3.1.1.¶

If 'sign_info' is included in the Token Transfer Request, the KDC SHOULD include the 'sign_info' parameter in the Token Transfer Response, as per the format defined in Section 3.3.1. Note that the field 'id' of each 'sign_info_entry' specifies the name or array of group names to which that 'sign_info_entry' applies. As an exception, the KDC MAY omit the 'sign_info' parameter in the Token Transfer Response even if 'sign_info' is included in the Token Transfer Request in case none of the groups that the Client is authorized to join use signatures to achieve source authentication.¶

Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g., according to the used transport profile of ACE. Application profiles of this specification MAY define additional parameters to use within this exchange (OPT2).¶

Application profiles of this specification MAY define alternative specific negotiations of parameter values for the signature algorithm and signature keys if 'sign_info' is not used (OPT3).¶

If allowed by the used transport profile of ACE, the Client may provide the Access Token to the KDC by other means than the Token Transfer Request. An example is the DTLS transport profile of ACE, where the Client can provide the access token to the KDC during the secure session establishment (see Section 3.3.2 of [RFC9202]).¶

sign_info = sign_info_req / sign_info_resp

sign_info_req  = null                  ; in the Token Transfer
                                       ; Request to the KDC

sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer
                                       ; Response from the KDC

sign_info_entry =
[
  id : gname / [ + gname ],
  sign_alg : int / tstr,
  sign_parameters : [ any ],
  sign_key_parameters : [ + parameter : any ],
  cred_fmt : int / null
]

gname = tstr

4.1. Interface at the KDC

The KDC provides its interface by hosting the following resources. Note that the root url-path "ace-group" used hereafter is a default name; implementations are not required to use this name and can define their own instead.¶

If request messages sent to the KDC as well as success response messages from the KDC include a payload and specify a Content-Format, those messages MUST have Content-Format set to application/ace-groupcomm+cbor, as defined in Section 11.2. CBOR labels for the message parameters are defined in Section 8.¶

• /ace-group : the path of this root resource is invariant once the resource is established and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints.¶

  A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in Section 4.2.1.1.¶

  Clients may be authorized to access this resource even without being members of any group at the KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers).¶

  The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in Section 11.5 and can be used to describe the interface provided by this root resource.¶

  The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the resource /ace-group and returns a link to such a resource in link-format [RFC6690].¶

  Request:
  
  Header: GET (Code=0.01)
  Uri-Host: "kdc.example.com"
  Uri-Path: ".well-known"
  Uri-Path: "core"
  Uri-Query: "if=ace.groups"
  
  Response:
  
  Header: Content (Code=2.05)
  Content-Format: 40 (application/link-format)
  Payload:
    <coap://[2001:db8::ab]/ace-group>;if="ace.groups"
  

  ¶

• /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with the name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, of which it contains the symmetric group keying material.¶

  A Client can access this resource in order to join the group with name GROUPNAME or later as a group member to retrieve the current group keying material. These operations are described in Sections 4.3.1.1 and 4.3.2.1, respectively.¶

  The Interface Description (if=) Link Target Attribute value "ace.group" is registered in Section 11.5 and can be used to describe the interface provided by a group-membership resource.¶

  The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the group-membership resource /ace-group/gp1 and returns a link to such a resource in link-format [RFC6690].¶

  Request:
  
  Header: GET (Code=0.01)
  Uri-Host: "kdc.example.com"
  Uri-Path: ".well-known"
  Uri-Path: "core"
  Uri-Query: "if=ace.group"
  
  Response:
  
  Header: Content (Code=2.05)
  Content-Format: 40 (application/link-format)
  Payload:
    <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
  

  ¶

  If it is not required that the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in Section 3.2) coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name in order to refer to the correct group (REQ7).¶

• /ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with the name GROUPNAME.¶

  This resource is created only in case the KDC acts as a repository of authentication credentials for group members.¶

  As a group member, a Client can access this resource in order to retrieve the authentication credentials of other group members. That is, the Client can retrieve the authentication credentials of all the current group members or a subset of them by specifying filter criteria. These operations are described in Sections 4.4.2.1 and 4.4.1.1, respectively.¶

  Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.¶

• /ace-group/GROUPNAME/kdc-cred : the path of this resource is invariant once the resource is established. This resource contains the authentication credential of the KDC for the group with the name GROUPNAME.¶

  This resource is created only in case the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED for application profiles to define whether the KDC has such an associated authentication credential (REQ8).¶

  As a group member, a Client can access this resource in order to retrieve the current authentication credential of the KDC.¶

  Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.¶

• /ace-group/GROUPNAME/policies : the path of this resource is invariant once the resource is established. This resource contains the group policies of the group with the name GROUPNAME.¶

  A Client can access this resource as a group member in order to retrieve the group policies. This operation is described in Section 4.6.1.1.¶

• /ace-group/GROUPNAME/num : the path of this resource is invariant once the resource is established. This resource contains the current version number for the symmetric group keying material of the group with the name GROUPNAME.¶

  A Client can access this resource as a group member in order to retrieve the version number of the keying material currently used in the group. This operation is described in Section 4.7.1.1.¶

• /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /ace-group/GROUPNAME is hosted for each group member of the group with the name GROUPNAME. Each such resource is identified by the node name NODENAME of the associated group member and contains the group keying material and the individual keying material for that group member.¶

  A Client as a group member can access this resource in order to retrieve the current group keying material together with its individual keying material, request new individual keying material to use in the group, and leave the group. These operations are described in Sections 4.8.1.1, 4.8.2.1, and 4.8.3.1, respectively.¶

• /ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resource is invariant once the resource is established. This resource contains the individual authentication credential for the node with the name NODENAME as a group member of the group with the name GROUPNAME.¶

  A Client can access this resource in order to upload at the KDC a new authentication credential to use in the group. This operation is described in Section 4.9.1.1.¶

  This resource is not created if the group member does not have an authentication credential to use in the group or if the KDC does not store the authentication credentials of group members.¶

The KDC is expected to fully provide the interface defined above. It is otherwise REQUIRED for the application profiles of this specification to indicate which resources are not hosted, i.e., which parts of the interface defined in this section are not supported by the KDC (REQ9). Application profiles of this specification MAY extend the KDC interface by defining additional handlers, as well as defining additional resources and their handlers.¶

It is REQUIRED for application profiles of this specification to register a Resource Type for the group-membership resource (REQ10), i.e., the group-membership resource at /ace-group/GROUPNAME. This Resource Type can be used to discover the correct URL for sending a Join Request to the KDC. This Resource Type can also be used to indicate which specific application profile of this specification is used by a specific group-membership resource at the KDC.¶

It is REQUIRED for application profiles of this specification to 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 (see Section 3.1), and the roles that the Client has as current group member (REQ11).¶

Response:

Header: Service Unavailable (Code=5.03)
Content-Format: application/concise-problem-details+cbor
Payload:
{
  / title /                -1: "No available node identifiers",
  / detail /               -2: "Things will change after a
                                group rekeying; try later",
  / ace-groupcomm-error /   0: {
    / error-id /  0: 4 / "No available node identifiers" /,
  }
}

4.2. /ace-group

This resource implements the FETCH handler.¶

Client                                                         KDC
   |                                                            |
   |------------ Group Name and URI Retrieval Request: -------->|
   |                      FETCH /ace-group                      |
   |                                                            |
   |<-- Group Name and URI Retrieval Response: 2.05 (Content) --|
   |                                                            |

Request:

Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
  { "gid": [1, 2] }

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
  { "gid": [1, 2], "gname": ["group1", "group2"],
    "guri": ["/ace-group/g1", "/ace-group/g2"] }

4.3. /ace-group/GROUPNAME

This resource implements the POST and GET handlers.¶

scope, N_S, and N_C expressed in CBOR diagnostic notation:
  scope = h'826667726f7570316673656e646572'
  N_S   = h'018a278f7faab55a'
  N_C   = h'25a8991cd700ac01'


scope, N_S, and N_C as CBOR encoded byte strings:
  scope = 0x4f826667726f7570316673656e646572
  N_S   = 0x48018a278f7faab55a
  N_C   = 0x4825a8991cd700ac01

PoP input:
  0x4f 826667726f7570316673656e646572
    48 018a278f7faab55a 48 25a8991cd700ac01

N_C and N_KDC expressed in CBOR diagnostic notation:
  N_C   = h'25a8991cd700ac01'
  N_KDC = h'cef04b2aa791bc6d'


N_C and N_KDC as CBOR encoded byte strings:
  N_C   = 0x4825a8991cd700ac01
  N_KDC = 0x48cef04b2aa791bc6d

PoP input:
  0x48 25a8991cd700ac01 48 cef04b2aa791bc6d

Client                                                     KDC
   |                                                        |
   |-------- Join Request: POST /ace-group/GROUPNAME ------>|
   |                                                        |
   |<------------ Join Response: 2.01 (Created) ----------- |
   | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |

Request:

Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
         with AUTH_CRED and POP_EVIDENCE being CBOR byte strings):
  { "scope": << [ "group1", ["sender", "receiver"] ] >> ,
    "get_creds": [true, ["sender"], []], "client_cred": AUTH_CRED,
    "cnonce": h'25a8991cd700ac01', "client_cred_verify": POP_EVIDENCE }

Response:

Header: Created (Code=2.01)
Content-Format: "application/ace-groupcomm+cbor"
Location-Path: "kdc.example.com"
Location-Path: "g1"
Location-Path: "nodes"
Location-Path: "c101"
Payload (in CBOR diagnostic notation,
         with KEY, AUTH_CRED_1, AUTH_CRED_2,
         ID_1, and ID_2 being CBOR byte strings):
  { "gkty": 13, "key": KEY, "num": 12, "exp": 1924992000,
    "exi": 2592000, "creds": [ AUTH_CRED_1, AUTH_CRED_2 ],
    "peer_roles": ["sender", ["sender", "receiver"]],
    "peer_identifiers": [ ID1, ID2 ] }

Client                                                              KDC
   |                                                                 |
   |------ Key Distribution Request: GET /ace-group/GROUPNAME ------>|
   |                                                                 |
   |<----------- Key Distribution Response: 2.05 (Content) --------- |
   |                                                                 |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
         with KEY being a CBOR byte strings):
  { "gkty": 13, "key": KEY, "num": 12 }

4.4. /ace-group/GROUPNAME/creds

This resource implements the GET and FETCH handlers.¶

Client                                                      KDC
   |                                                         |
   |            Authentication Credential Request:           |
   |-------------------------------------------------------->|
   |             FETCH /ace-group/GROUPNAME/creds            |
   |                                                         |
   |<-- Authentication Credential Response: 2.05 (Created) --|
   |                                                         |

Request:

Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
  { "get_creds": [true, [], [ ID_2, ID_3 ]] }

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
         with AUTH_CRED_2, AUTH_CRED_3,
         ID_2, and ID_3 being CBOR byte strings):
  { "creds": [ AUTH_CRED_2, AUTH_CRED_3, ],
    "peer_roles": [ ["sender", "receiver"], "receiver" ],
    "peer_identifiers": [ ID_2, ID_3 ] }

Client                                                      KDC
   |                                                         |
   |            Authentication Credential Request:           |
   |-------------------------------------------------------->|
   |              GET /ace-group/GROUPNAME/creds             |
   |                                                         |
   |<-- Authentication Credential Response: 2.05 (Content) --|
   |                                                         |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
         with AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3,
         ID_1, ID_2, and ID_3 being CBOR byte strings):
  { "num": 5,
    "creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ],
    "peer_roles": ["sender", ["sender", "receiver"], "receiver"],
    "peer_identifiers": [ ID_1, ID_2, ID_3 ] }

4.5. /ace-group/GROUPNAME/kdc-cred

This resource implements a GET handler.¶

N_C and N_KDC expressed in CBOR diagnostic notation:
  N_C   = h'25a8991cd700ac01'
  N_KDC = h'0b7db12aaff56da3'


N_C and N_KDC as CBOR encoded byte strings:
  N_C   = 0x4825a8991cd700ac01
  N_KDC = 0x480b7db12aaff56da3

PoP input:
  0x48 25a8991cd700ac01 48 0b7db12aaff56da3

Group
Member                                                         KDC
  |                                                             |
  |             KDC Authentication Credential Request           |
  |------------------------------------------------------------>|
  |               GET /ace-group/GROUPNAME/kdc-cred             |
  |                                                             |
  |<-- KDC Authentication Credential Response: 2.05 (Content) --|
  |                                                             |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "kdc-cred"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with AUTH_CRED_KDC
         and POP_EVIDENCE being CBOR byte strings):
  {
    "kdc_nonce": h'0b7db12aaff56da3',
    "kdc_cred": AUTH_CRED_KDC,
    "kdc_cred_verify": POP_EVIDENCE
  }

4.6. /ace-group/GROUPNAME/policies

This resource implements the GET handler.¶

Client                                                       KDC
   |                                                          |
   |-- Policies Request: GET /ace-group/GROUPNAME/policies -->|
   |                                                          |
   |<----------- Policies Response: 2.05 (Content) -----------|
   |                                                          |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "policies"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload(in CBOR diagnostic notation):
  { "group_policies": {"exp-delta": 120} }

4.7. /ace-group/GROUPNAME/num

This resource implements the GET handler.¶

Client                                                     KDC
   |                                                        |
   |---- Version Request: GET /ace-group/GROUPNAME/num ---->|
   |                                                        |
   |<---------- Version Response: 2.05 (Content) -----------|
   |                                                        |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "num"
Payload: -

Response:

Header: Content (Code=2.05)
Payload(in CBOR diagnostic notation):
  13

4.8. /ace-group/GROUPNAME/nodes/NODENAME

This resource implements the GET, PUT, and DELETE handlers.¶

In addition to what is defined in Section 4.1.2, each of the handlers performs the following two verifications.¶

• The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").¶
• The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.¶

Client                                                          KDC
   |                                                             |
   |------------------ Key Distribution Request: --------------->|
   |           GET /ace-group/GROUPNAME/nodes/NODENAME           |
   |                                                             |
   |<-------- Key Distribution Response: 2.05 (Content) ---------|
   |                                                             |

Request:

Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
         with KEY and IND_KEY being CBOR byte strings,
         and "ind-key" being the profile-specified label
         for individual keying material):
  { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }

Client                                                    KDC
   |                                                       |
   |---------------- Key Renewal Request: ---------------->|
   |        PUT /ace-group/GROUPNAME/nodes/NODENAME        |
   |                                                       |
   |<-------- Key Renewal Response: 2.05 (Content) --------|
   |                                                       |

Request:

Header: PUT (Code=0.03)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with IND_KEY being a
         CBOR byte string, and "ind-key" being the profile-specified
         label for individual keying material):
  { "ind-key": IND_KEY }

4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred

This resource implements the POST handler.¶

scope, N_S, and N_C expressed in CBOR diagnostic notation:
  scope = h'826667726f7570316673656e646572'
  N_S   = h'018a278f7faab55a'
  N_C   = h'0446baefc56111bf'


scope, N_S, and N_C as CBOR encoded byte strings:
  scope = 0x4f826667726F7570316673656E646572
  N_S   = 0x48018a278f7faab55a
  N_C   = 0x480446baefc56111bf

PoP input:
  0x4f 826667726f7570316673656e646572
    48 018a278f7faab55a 48 0446baefc56111bf

Client                                                          KDC
|                                                                |
|----------- Authentication Credential Update Request: --------->|
|         POST /ace-group/GROUPNAME/nodes/NODENAME/cred          |
|                                                                |
|<-- Authentication Credential Update Response: 2.04 (Changed) --|
|                                                                |

Request:

Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Uri-Path: "cred"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with AUTH_CRED
         and POP_EVIDENCE being CBOR byte strings):
  { "client_cred": AUTH_CRED, "cnonce": h'0446baefc56111bf',
    "client_cred_verify": POP_EVIDENCE }

Response:

Header: Changed (Code=2.04)
Payload: -

6.1. Point-to-Point Group Rekeying

A point-to-point group rekeying consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE.¶

This is the approach taken by the basic "Point-to-Point" group rekeying scheme, which the KDC can explicitly signal in the Join Response (see Section 4.3.1), through the 'rekeying_scheme' parameter specifying the value 0.¶

When taking this approach in the group identified by GROUPNAME, the KDC can practically deliver the rekeying messages to the target group members in different, coexisting ways.¶

• The KDC SHOULD make the /ace-group/GROUPNAME resource Observable [RFC7641]. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource.¶

  In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member as a notification of group termination. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 6 ("Group deleted").¶

• If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see Section 4.3.1), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI.¶

  A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDC SHOULD provide a URI in the 'control_uri' parameter of the Join Request upon joining the group.¶

If the KDC has to send a rekeying message to a target group member, but this did not include the 'control_uri' parameter in the Join Request and is not a registered observer for the /ace-group/GROUPNAME resource, then that target group member would not be able to participate in the group rekeying. Later on, after having repeatedly failed to successfully exchange secure messages in the group, that group member can retrieve the current group keying material from the KDC by sending a GET request to /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME (see Sections 4.3.2 and 4.8.1, respectively).¶

Figure 34 provides an example of point-to-point group rekeying. In particular, the example makes the following assumptions:¶

• The group currently consists of four group members, namely C1, C2, C3, and C4.¶
• Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".¶
• Before the group rekeying is performed, the keying material used in the group has version number num=5.¶
• The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.¶

In the example, the KDC individually rekeys the group members intended to remain in the group (i.e., C1, C2, and C4) by means of one rekeying message each.¶

6.2. One-to-Many Group Rekeying

This section provides high-level recommendations on how the KDC can rekey a group by means of a more efficient and scalable group rekeying scheme, e.g., [RFC2093], [RFC2094], and [RFC2627]. That is, each rekeying message might be, and likely is, intended for multiple target group members, and thus can be delivered to the whole group, although possible to decrypt only for the actual target group members.¶

This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages and to additionally sign them to ensure source authentication (see Section 6.2.1).¶

Compared to a group rekeying performed in a point-to-point fashion (see Section 6.1), a one-to-many group rekeying typically pays off in large-scale groups due to the reduced time for completing the rekeying, a more efficient utilization of network resources, and a reduced performance overhead at the KDC. To different extents, it also requires individual group members to locally perform additional operations in order to handle the administrative keying material and verify source authentication of rekeying messages. Therefore, one-to-many group rekeying schemes and their employment ought to ensure that the experienced performance overhead on the group members also remains bearable for resource-constrained devices.¶

The exact set of rekeying messages to send, their content and format, the administrative keying material to use to protect them, as well as the set of target group members depend on the specific group rekeying scheme and are typically affected by the reason that has triggered the group rekeying. Details about the data content and format of rekeying messages have to be defined by separate documents profiling the use of the group rekeying scheme in the context of the used application profile of this specification.¶

When one of these group rekeying schemes is used, the KDC provides related information to a Client joining the group in the Join Response message (see Section 4.3.1). In particular, 'rekeying_scheme' identifies the rekeying scheme used in the group (if no default can be assumed); 'control_group_uri', if present, specifies a URI whose addressing information is, e.g., a multicast IP address, where the KDC will send the rekeying messages for that group by reaching all the group members; and 'mgt_key_material' specifies a subset of the administrative keying material intended for that particular joining Client to have, as used to protect the rekeying messages sent to the group when also intended for that joining Client.¶

Rekeying messages can be protected at the application layer by using COSE and the administrative keying material as prescribed by the specific group rekeying scheme (see Section 6.2.1). After that, the delivery of protected rekeying messages to the intended target group members can occur in different ways, such as the following ones.¶

Over multicast -

In this case, the KDC simply sends a rekeying message as a CoAP request addressed to the URI specified in the 'control_group_uri' parameter of the Join Response (see Section 4.3.1).¶

If a particular rekeying message is intended for a single target group member, the KDC may alternatively protect the message using the security association with that group member and deliver the message like when using the "Point-to-Point" group rekeying scheme (see Section 6.1).¶

Through a pub-sub communication model -

In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC.¶

In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeying process as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy).¶

The setup of rekeying topics at the broker as well as the discovery of the topics at the broker for group members are application specific. A possible way is for the KDC to provide such information in the Join Response message (see Section 4.3.1) by means of a new parameter analogous to 'control_group_uri' and specifying the URI(s) of the rekeying topic(s) that a group member has to subscribe to at the broker.¶

Regardless of the specifically used delivery method, the group rekeying scheme can perform a possible rollover of the administrative keying material through the same sent rekeying messages. Actually, such a rollover occurs every time a group rekeying is performed upon the leaving of group members, which have to be excluded from future communications in the group.¶

From a high-level point of view, each group member stores only a subset of the overall administrative keying material, which is obtained upon joining the group. Then, when a group rekeying occurs:¶

• Each rekeying message is protected by using a (most convenient) key from the administrative keying material such that: i) the used key is not stored by any node leaving the group, i.e., the key is safe to use and does not have to be renewed and ii) the used key is stored by all the target group members that indeed have to be provided with new group keying material to protect communications in the group.¶
• Each rekeying message includes not only the new group keying material intended for all the rekeyed group members but also any new administrative keys that: i) are pertaining to and supposed to be stored by the target group members and ii) had to be updated since leaving group members to store the previous version.¶

Further details depend on the specific rekeying scheme used in the group.¶

Figure 35 provides an example of a one-to-many group rekeying over multicast. In particular, the example makes the following assumptions:¶

• The group currently consists of four group members, namely C1, C2, C3, and C4.¶
• Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".¶
• Each group member, when joining the group, received from the KDC a URI in the 'control_group_uri' parameter, specifying the multicast address MULT_ADDR and url-path "grp-mrek".¶
• Before the group rekeying is performed, the keying material used in the group has version number num=5.¶
• The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.¶

In the example, the KDC determines that the most convenient way to perform a group rekeying that evicts C3 is as follows.¶

First, the KDC sends one rekeying message over multicast to the multicast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message is denoted with dashed lines. The message is protected with a non-compromised key from the administrative keying material that only C1 and C2 store. Therefore, even though all the group members receive this message, only C1 and C2 are able to decrypt it. The message includes: the new group keying material with version number num=6 and new keys from the administrative keying material to replace those stored by the group members C1, C2, and C3.¶

After that, the KDC sends one rekeying message addressed individually to C4 and with url-path "grp-rek". In the figure, the message is denoted with a dotted line. The message is protected with the secure association shared between C4 and the KDC. The message includes: the new group keying material with version number num=6 and new keys from the administrative keying material to replace those stored by both C4 and C3.¶

6.3. Misalignment of Group Keying Material

A group member can receive a message shortly after the group has been rekeyed and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members.¶

In the first case, the sender protects a message using the old group keying material. However, the recipient receives the message after having received the new group keying material, hence not being able to correctly process it. A possible way to limit the impact of this issue is to preserve the old, recent group keying material for a maximum amount of time defined by the application, during which it is used solely for processing incoming messages. By doing so, the recipient can still temporarily process received messages also by using the old, retained group keying material. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old, retained group keying material. Therefore, a conservative application policy should not admit the storage of old group keying material. Eventually, the sender will have obtained the new group keying material too and can possibly resend the message protected with such keying material.¶

In the second case, the sender protects a message using the new group keying material, but the recipient receives that message before having received the new group keying material. Therefore, the recipient would not be able to correctly process the message and hence discards it. If the recipient receives the new group keying material shortly after that and the application at the sender endpoint performs retransmissions, the former will still be able to receive and correctly process the message. In any case, the recipient should actively ask the KDC for the latest group keying material according to an application-defined policy, for instance, after a given number of unsuccessfully decrypted incoming messages.¶

10.1. Secure Communication in the Group

When a group member receives a message from a certain sender for the first time since joining the group, it needs to have a mechanism in place to avoid replayed messages and to assert their freshness, e.g., as described in Appendix B.1.2 of [RFC8613] or Section 10 of [GROUP-OSCORE]. Such a mechanism also aids the recipient group member in case it has rebooted and lost the security state used to protect previous group communications with that sender.¶

By its nature, the KDC is invested with a large amount of trust, since it acts as a generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material.¶

A compromised KDC would thus put the attacker in the same position, which also means that:¶

• The attacker can generate and control new group keying material, hence possibly rekeying the group and evicting certain group members as part of a broader attack.¶
• The attacker can actively participate in communications in a group, even without having been authorized to join it, and can allow further unauthorized entities to do so.¶
• The attacker can build erroneous associations between node identifiers and group members' authentication credentials.¶

On the other hand, as long as the security protocol used in the group ensures source authentication of messages (e.g., by means of signatures), the KDC is not able to impersonate group members since it does not have their private keys.¶

Further security considerations are specific to the communication and security protocols used in the group, and thus have to be provided by those protocols and complemented by the application profiles of this specification using them.¶

10.2. Update of Group Keying Material

The KDC can generate new group keying material and provide it to the group members (rekeying) through the rekeying scheme used in the group, as discussed in Section 6.¶

In particular, the KDC must renew the latest group keying material upon its expiration. Before then, the KDC MAY also renew the group keying material on a regular or periodical fashion.¶

Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. As a possible exception, the KDC may not rekey the group upon the joining of a new group member if the application does not require backward security. As another possible exception discussed more in detail later in this section, the KDC may rely on a rekeying policy that reasonably takes into account the expected rate of group membership changes and the duration of a group rekeying.¶

Since the minimum number of group members is one, the KDC SHOULD provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC SHOULD also provide new group keying material to a Client that remains the only member in the group after the leaving of other group members.¶

Note that the considerations in Section 10.1 about dealing with replayed messages still hold, even in case the KDC rekeys the group upon every single joining of a new group member. However, if the KDC has renewed the group keying material upon a group member's joining and the time interval between the end of the rekeying process and that member's joining is sufficiently small, then that group member is also on the safe side, since it would not accept replayed messages protected with the old group keying material previous to its joining.¶

Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see Section 4.3.1.1), the joining node becomes able to read any message that was exchanged in the group and protected with that keying material. This is the case if the KDC provides the current group members with the new, latest keying material before completing the joining procedure. However, the joining node is not able to read messages exchanged in the group and protected with keying material older than the one provided in the Join Response, i.e., having a strictly lower version number NUM.¶

A node that has left the group should not expect any of its outgoing messages to be successfully processed if received by other nodes in the group after its leaving due to a possible group rekeying occurring before the message reception.¶

The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at each and every group membership change, for instance, if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.¶

However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:¶

• Newly joining group members would be able to access the keying material used before their joining, and thus they could access past group communications if they have recorded old exchanged messages. This might still be acceptable for some applications and in situations where the new group members are freshly deployed through strictly controlled procedures.¶
• The leaving group members would remain able to access upcoming group communications, as protected with the current keying material that has not been updated. This is typically undesirable, especially if the leaving group member is compromised or suspected to be, and it might have an impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.¶

The KDC should renew the group keying material in case it has rebooted, even if it stores the whole group keying material in persistent storage. This assumes that the secure associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.¶

However, if the KDC relies on Observe notifications to distribute the new group keying material, the KDC would have lost all the current ongoing Observations with the group members after rebooting, and the group members would continue using the old group keying material. Therefore, the KDC will rely on each group member asking for the new group keying material (see Sections 4.3.2.1 and 4.8.1.1) or perform a group rekeying by actively sending rekeying messages to group members as discussed in Section 6.¶

The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying. Such actions can include leaving and/or rejoining the group at high rates or often asking the KDC for new individual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.¶

The KDC also needs to have a congestion control mechanism in place in order to avoid network congestion upon distributing new group keying material. For example, CoAP and Observe give guidance on such mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641].¶

10.3. Block-Wise Considerations

If the Block-Wise CoAP options [RFC7959] are used and the keying material is updated in the middle of a Block-Wise transfer, the sender of the blocks just changes the group keying material to the updated one and continues the transfer. As long as both sides get the new group keying material, updating the group keying material in the middle of a transfer will not cause any issue. Otherwise, the sender will have to transmit the message again when receiving an error message from the recipient.¶

Compared to a scenario where the transfer does not use Block-Wise, depending on how fast the group keying material is changed, the group members might consume a larger amount of the network bandwidth by repeatedly resending the same blocks, which might be problematic.¶

11.1. Media Type Registrations

This specification has registered the 'application/ace-groupcomm+cbor' media type for messages of the protocols defined in this document following the ACE exchange and carrying parameters encoded in CBOR. This registration follows the procedures specified in [RFC6838].¶

Type name:

application¶

Subtype name:

ace-groupcomm+cbor¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

Must be encoded as a CBOR map containing the parameters defined in RFC 9594.¶

Security considerations:

See Section 10 of RFC 9594.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9594¶

Applications that use this media type:

The type is used by Authorization Servers, Clients, and Resource Servers that support the ACE groupcomm framework as specified in RFC 9594.¶

Fragment identifier considerations:

N/A¶

Additional information:

N/A¶

Person & email address to contact for further information:

ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author/Change controller:

IETF¶

Provisional registration:

No¶

11.2. CoAP Content-Formats

IANA has registered the following entry in the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.¶

Content Type:

application/ace-groupcomm+cbor¶

Content Coding:

-¶

ID:

261¶

Reference:

RFC 9594¶

11.3. OAuth Parameters

IANA has registered the following entries in the "OAuth Parameters" registry, following the procedure specified in Section 11.2 of [RFC6749].¶

Parameter name:

sign_info¶

Parameter usage location:

client-rs request, rs-client response¶

Change Controller:

IETF¶

Specification Document(s):

RFC 9594¶

Parameter name:

kdcchallenge¶

Parameter usage location:

rs-client response¶

Change Controller:

IETF¶

Specification Document(s):

RFC 9594¶

11.4. OAuth Parameters CBOR Mappings

IANA has registered the following entries in the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in Section 8.10 of [RFC9200].¶

Name:

sign_info¶

CBOR Key:

45¶

Value Type:

Null or array¶

Reference:

RFC 9594¶

Name:

kdcchallenge¶

CBOR Key:

46¶

Value Type:

byte string¶

Reference:

RFC 9594¶

11.5. Interface Description (if=) Link Target Attribute Values

IANA has registered the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "CoRE Parameters" registry group.¶

Value:

ace.groups¶

Description:

The KDC interface at the parent resource of group-membership resources is used to retrieve names of security groups using the ACE framework.¶

Reference:

Section 4.1 of RFC 9594¶

Value:

ace.group¶

Description:

The KDC interface at a group-membership resource is used to provision keying material and related information and policies to members of the corresponding security group using the ACE framework.¶

Reference:

Section 4.1 of RFC 9594¶

11.6. Custom Problem Detail Keys Registry

IANA has registered the following entry in the "Custom Problem Detail Keys" registry within the "CoRE Parameters" registry group.¶

Key Value:

0¶

Name:

ace-groupcomm-error¶

Brief Description:

Carry RFC 9594 problem details in a Concise Problem Details data item.¶

Change Controller:

IETF¶

Reference:

RFC 9594, Section 4.1.2¶

11.7. ACE Groupcomm Parameters

This specification has established the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Name:

This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.¶

CBOR Key:

This is the value used as the CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

CBOR Type:

This contains the CBOR type of the item or a pointer to the registry that defines its type when that depends on another item.¶

Reference:

This contains a pointer to the public specification for the item.¶

This registry has been initially populated with the values in Table 5.¶

11.8. ACE Groupcomm Key Types

This specification establishes the "ACE Groupcomm Key Types" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Name:

This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.¶

Key Type Value:

This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

Profile:

This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the "Name" column of the "ACE Groupcomm Profiles" registry.¶

Description:

This field contains a brief description of the keying material.¶

Reference:

This contains a pointer to the public specification for the format of the keying material, if one exists.¶

This registry has been initially populated with the value in Table 1.¶

11.9. ACE Groupcomm Profiles

This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Name:

The name of the application profile to be used as value of the profile attribute.¶

Description:

Text giving an overview of the application profile and the context it is developed for.¶

CBOR Value:

CBOR abbreviation for the name of this application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

Reference:

This contains a pointer to the public specification of the abbreviation for this application profile, if one exists.¶

This registry has been initially populated with the value in Table 2.¶

11.10. ACE Groupcomm Policies

This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Name:

The name of the group communication policy.¶

CBOR Label:

The value to be used to identify this group communication policy. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

CBOR Type:

The CBOR type used to encode the value of this group communication policy.¶

Description:

This field contains a brief description for this group communication policy.¶

Reference:

This field contains a pointer to the public specification providing the format of the group communication policy, if one exists.¶

This registry has been initially populated with the values in Table 3.¶

11.11. Sequence Number Synchronization Methods

This specification establishes the "Sequence Number Synchronization Methods" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Name:

The name of the sequence number synchronization method.¶

Value:

The value to be used to identify this sequence number synchronization method. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

Description:

This field contains a brief description for this sequence number synchronization method.¶

Reference:

This field contains a pointer to the public specification describing the sequence number synchronization method.¶

11.12. ACE Groupcomm Errors

This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Value:

The value to be used to identify the error. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

Description:

This field contains a brief description of the error.¶

Reference:

This field contains a pointer to the public specification defining the error, if one exists.¶

This registry has been initially populated with the values in Table 6. The "Reference" column for all of these entries refers to this document.¶

11.13. ACE Groupcomm Rekeying Schemes

This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert Review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

Value:

The value to be used to identify the group rekeying scheme. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

Name:

The name of the group rekeying scheme.¶

Description:

This field contains a brief description of the group rekeying scheme.¶

Reference:

This field contains a pointer to the public specification defining the group rekeying scheme, if one exists.¶

This registry has been initially populated with the value in Table 4.¶

11.14. Expert Review Instructions

The IANA registries established in this document are 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:¶

• 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. The zones tagged as "Private Use" are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.¶
• Specifications are required for the standards track range of point assignment. Specifications should exist for Specification Required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶
• Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of the device it will be used on, and the number of code points left that encode to that size.¶

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

REQ2:

If the AIF format of 'scope' is used, register its specific instance of "Toid" and "Tperm" as media type parameters and a corresponding Content-Format, as per the guidelines in [RFC9237].¶

REQ3:

If used, specify the acceptable values for 'sign_alg' (see Section 3.3).¶

REQ4:

If used, specify the acceptable values for 'sign_parameters' (see Section 3.3).¶

REQ5:

If used, specify the acceptable values for 'sign_key_parameters' (see Section 3.3).¶

REQ6:

Specify the acceptable formats for authentication credentials and, if used, the acceptable values for 'cred_fmt' (see Section 3.3).¶

REQ7:

If the value of the GROUPNAME URI path and the group name in the access token scope (gname in Section 3.2) are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name (see Section 4.1).¶

REQ8:

Define whether the KDC has an authentication credential and if this has to be provided through the 'kdc_cred' parameter (see Section 4.3.1).¶

REQ9:

Specify if any part of the KDC interface as defined in this document is not supported by the KDC (see Section 4.1).¶

REQ10:

Register a Resource Type for the group-membership resource, which is used to discover the correct URL for sending a Join Request to the KDC (see Section 4.1).¶

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 (see Section 3.1); and the roles that the Client has as a current group member.¶

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

REQ13:

Specify the encoding of the group identifier (see Section 4.2.1).¶

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

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

REQ16:

Define the initial value of the 'num' parameter (see Section 4.3.1).¶

REQ17:

Specify the format of the 'key' parameter and register a corresponding entry in the "ACE Groupcomm Key Types" IANA registry (see Section 4.3.1).¶

REQ18:

Specify the acceptable values of the 'gkty' parameter (see Section 4.3.1).¶

REQ19:

Specify and register the application profile identifier (see Section 4.3.1).¶

REQ20:

If used, specify the format and content of 'group_policies' and its entries. Specify the policies' default values (see Section 4.3.1).¶

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 Sections 4.3.1 and 4.5.1). If external signature verifiers are supported, specify how those provide a nonce to the KDC to be used for computing the PoP evidence (see Section 4.5.1).¶

REQ22:

Specify the communication protocol that the members of the group must use (e.g., CoAP for group communication).¶

REQ23:

Specify the security protocol the group members must use to protect their communication (e.g., group OSCORE). This must provide encryption, integrity, and replay protection.¶

REQ24:

Specify how the communication is secured between the Client and KDC. Optionally, specify a transport profile of ACE [RFC9200] to use between Client and KDC (see Section 4.3.1.1).¶

REQ25:

Specify the format of the identifiers of group members (see Sections 4.3.1 and 4.4.1).¶

REQ26:

Specify policies at the KDC to handle ids that are not included in 'get_creds' (see Section 4.4.1).¶

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

REQ28:

Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already (see Section 7).¶

REQ29:

Categorize newly defined parameters according to the same criteria of Section 8.¶

REQ30:

Define whether Clients must, should, or may support the conditional parameters defined in Section 8 and under which circumstances.¶

A.2. Optional-to-Address Requirements

OPT1:

Optionally, if the textual format of 'scope' is used, specify CBOR values to use for abbreviating the role identifiers in the group (see Section 3.1).¶

OPT2:

Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response (see Section 3.3).¶

OPT3:

Optionally, specify the negotiation of parameter values for signature algorithm and signature keys if 'sign_info' is not used (see Section 3.3).¶

OPT4:

Optionally, specify possible or required payload formats for specific error cases.¶

OPT5:

Optionally, specify additional identifiers of error types as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see Section 4.1.2).¶

OPT6:

Optionally, specify the encoding of 'creds_repo' if the default is not used (see Section 4.3.1).¶

OPT7:

Optionally, 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).¶

OPT8:

Optionally, specify the behavior of the handler in case of failure to retrieve an authentication credential for the specific node (see Section 4.3.1).¶

OPT9:

Optionally, define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (see Section 4.3.1).¶

OPT10:

Optionally, 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).¶

OPT11:

Optionally, specify policies that instruct Clients to retain messages and for how long if they are unsuccessfully decrypted (see Section 4.8.1.1). This makes it possible to decrypt such messages after getting updated keying material.¶

OPT12:

Optionally, specify for the KDC to perform group rekeying (together or instead of renewing individual keying material) when receiving a Key Renewal Request (see Section 4.8.2.1).¶

OPT13:

Optionally, specify how the identifier of a group member's authentication credential is included in requests sent to other group members (see Section 4.9.1.1).¶

OPT14:

Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see Section 6).¶

B.1. Format of 'sign_info_entry'

The format of each 'sign_info_entry' (see Section 3.3.1) is generalized as follows.¶

• 'sign_parameters' includes N >= 0 elements, each of which is a COSE capability of the signature algorithm indicated in 'sign_alg'.¶

  In particular, 'sign_parameters' has 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_parameters' is replaced by N elements 'sign_capab', each of which is a CBOR array.¶

  The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'sign_parameters'[i].¶

  In particular, each 'sign_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'sign_parameters'[i].¶

  Such a COSE capabilities array is currently defined for the algorithm capability COSE key type in the "Capabilities" column of the "COSE Key Types" registry [COSE.Key.Types].¶

sign_info_entry =
[
    id : gname / [ + gname ],
    sign_alg : int / tstr,
    sign_parameters : [ * alg_capab : any ],
  * sign_capab : [ * capab : any ],
    cred_fmt : int / null
]

gname = tstr