Key Provisioning for Group Communication using 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 [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 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 CBOR [RFC8949] and COSE [RFC9052][RFC9053] [I-D.ietf-cose-countersign].¶

A principal interested to participate in group communication as well as already participating as a group member is interchangeably denoted as "Client" or "node".¶

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

  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 two types of group 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 invariant once established identifier of a group. It is used in the interactions between 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 invariant once established text string used in URIs. 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 invariant once established identifier of a node. It is used in the interactions between Client and RS and to identify a member of a group. Within the same group, a node name is always unique among the node names of all the current members of that group.¶
• NODENAME: the invariant once established text string used in URIs to identify a member a group. Its value coincides with the node name of the associated group member.¶

This document additionally uses the following terminology:¶

• Transport profile, to indicate a profile of 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, [RFC9203], [RFC9202] and [I-D.ietf-ace-mqtt-tls-profile].¶
• Application 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, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].¶

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 format and value as specified below.¶

• 'scope', specifying the name 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 one or more scope entries. All the scope entries are specified according to a 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]. 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 to a compact encoding of scope. This is desirable especially for application profiles defining several roles, with the Client possibly requesting 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 first element, the group name, encoded as a CBOR text string.¶
    • Optionally, as 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 group name and role identifiers encoded as CBOR text strings.¶

  It is REQUIRED of application profiles of this specificaton 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.¶

gname = tstr

permissions = uint . bits roles

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

scope_entry = AIF_Generic<gname, permissions>

scope = << [ + scope_entry ] >>

gname = tstr

role = tstr

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

scope = << [ + scope_entry ] >>

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, 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 (see for example 'cnf' defined in Section 3.1 of [RFC8747] for CWT);¶
• an expiration time claim (see for example 'exp' defined in Section 3.1.4 of [RFC8392] for CWT);¶

• a scope claim (see for example '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, or as in the 'scope' parameter of the Authorization Request otherwise.¶

  By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, 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, and according to which this 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 requires, or other optional parameters.¶

When receiving an Authorization Request from a Client that was previously authorized, and for which the AS still owns 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 re-posting the same token does not cause re-use of keying material between nodes (for example, that is done 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 to ask 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 Content-Format set to application/ace+cbor 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 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, signature algorithm parameters, signature key parameters and about 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, together with attributes descriptive of the group configuration (see, e.g., [I-D.tiloca-core-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 the access token contains a role that requires the Client to send its own authentication credential to the KDC when joining the group, 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. This is in turn used to compute a PoP evidence, which the Client also provides to the Group Manager in order to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4.3.1).¶

The KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from it (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 same 'kdcchallenge' value MAY be reused several times by the Client, to generate a new PoP evidence, e.g., in case the Client provides the Group Manager 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 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, for which that 'sign_info_entry' applies to. 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 uses 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 : [ 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. The Interface Description (if=) Link Target Attribute value "ace.group" is registered in Section 11.5 and can be used to describe this interface.¶

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, defined in Section 11.2. CBOR labels for the message parameters are defined in Section 8.¶

• /ace-group : this resource is invariant once established, and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same resource, 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.¶

• /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages, and contains the symmetric group keying material for that group.¶

  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 Section 4.3.1.1 and Section 4.3.2.1, respectively.¶

  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, 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 : this resource is invariant once established, and contains the authentication credentials of all the members of the group with name GROUPNAME.¶

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

  A Client can access this resource in order to retrieve the authentication credentials of other group members, in addition to when joining the group. 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 Section 4.4.2.1 and Section 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 : this resource is invariant once established, and contains the authentication credential of the KDC for the group with 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 of application profiles to define whether the KDC has such an associated authentication credential (REQ8).¶

  A Client can interact with this resource in order to retrieve the current authentication credential of the KDC, in addition to when joining the group.¶

  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 : this resource is invariant once established, and contains the group policies of the group with 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 : this resource is invariant once established, and contains the current version number for the symmetric group keying material of the group with 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 name GROUPNAME. Each of such resources 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 the individual keying material; request new individual keying material to use in the group; and leave the group. These operations are described in Section 4.8.1.1, Section 4.8.2.1, and Section 4.8.3.1, respectively.¶

• /ace-group/GROUPNAME/nodes/NODENAME/cred : this resource is invariant once established, and contains the individual authentication credential for the node with name NODENAME, as group member of the group with 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 of 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 resources and their handlers.¶

It is REQUIRED of the application profiles of this specification to register a Resource Type for the root url-path (REQ10). This Resource Type can be used to discover the correct url to access at the KDC. This Resource Type can also be used at the GROUPNAME sub-resource, to indicate different application profiles for different groups.¶

It is REQUIRED of the 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).¶

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": [01, 02] }

Response:

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

4.3. /ace-group/GROUPNAME

This resource implements the POST and GET and handlers.¶

inclusion_flag = bool

role = tstr
comb_role = [ 2*role ]
role_filter = [ *(role / comb_role) ]

id = bstr
id_filter = [ *id ]

get_creds = null / [ inclusion_flag, role_filter, id_filter]

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

+----------+----------------+---------+-------------------------+
| Name     | Key Type Value | Profile | Description             |
+----------+----------------+---------+-------------------------+
| Reserved | 0              |         | This value is reserved  |
+----------+----------------+---------+-------------------------+

+--------------+-------+----------+----------------------+------------+
|     Name     | CBOR  |   CBOR   |     Description      | Reference  |
|              | label |   type   |                      |            |
+--------------+-------+----------+----------------------+------------+
| Sequence     | TBD   | tstr/int | Method for recipient | [RFC-XXXX] |
| Number       |       |          | group members to     |            |
| Synchroniza- |       |          | synchronize with     |            |
| tion Method  |       |          | sequence numbers of  |            |
|              |       |          | of sender group      |            |
|              |       |          | members. Its value   |            |
|              |       |          | is taken from the    |            |
|              |       |          | 'Value' column of    |            |
|              |       |          | the Sequence Number  |            |
|              |       |          | Synchronization      |            |
|              |       |          | Method registry      |            |
+--------------+-------+----------+----------------------+------------+
| Key Update   | TBD   | int      | Polling interval in  | [RFC-XXXX] |
| Check        |       |          | seconds, for group   |            |
| Interval     |       |          | members to check at  |            |
|              |       |          | the KDC if the       |            |
|              |       |          | latest group keying  |            |
|              |       |          | material is the one  |            |
|              |       |          | that they own        |            |
+--------------+-------+----------+----------------------+------------+
| Expiration   | TBD   | uint     | Number of seconds    | [RFC-XXXX] |
| Delta        |       |          | from 'exp' until the |            |
|              |       |          | specified UTC        |            |
|              |       |          | date/time after      |            |
|              |       |          | which group members  |            |
|              |       |          | MUST stop using the  |            |
|              |       |          | group keying         |            |
|              |       |          | material they own to |            |
|              |       |          | verify incoming      |            |
|              |       |          | messages             |            |
+--------------+-------+----------|----------------------|------------+

+-------+----------------+-------------------------------+------------+
| Value |      Name      |          Description          | Reference  |
+-------+----------------+-------------------------------+------------+
|   0   | Point-to-Point | The KDC individually targets  | [RFC-XXXX] |
|       |                | each node to rekey, using the |            |
|       |                | pairwise secure communication |            |
|       |                | association with that node    |            |
+-------+----------------+-------------------------------+------------+

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'6df49c495409a9b5', "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 being a CBOR byte strings):
  { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200,
    "creds": [ AUTH_CRED_1, AUTH_CRED_2 ],
    "peer_roles": ["sender", ["sender", "receiver"]],
    "peer_identifiers": [ ID1, ID2 ] }

Client                                                              KDC
   |                                                                 |
   |----- Key Distribution Request: POST /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: "pub-key"
Content-Format: "application/ace-groupcomm+cbor"
Payload:
  { "get_creds": [true, [], [ ID3 ]] }

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
  { "creds": [ AUTH_CRED_3 ],
    "peer_roles": [ "receiver" ],
    "peer_identifiers": [ ID3 ] }

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: "pub-key"
Payload: -

Response:

Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
  { "num": 5,
    "creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ],
    "peer_roles": ["sender", ["sender", "receiver"], "receiver"],
    "peer_identifiers": [ ID1, ID2, ID3 ] }

4.5. ace-group/GROUPNAME/kdc-cred

This resource implements a GET handler.¶

Group
Member                                                         KDC
  |                                                             |
  |             KDC Authentication Credential Request           |
  |------------------------------------------------------------>|
  |              GET ace-group/GROUPNAME/gm-pub-key             |
  |                                                             |
  |<-- 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-pub-key"
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'25a8991cd700ac01',
    "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)
Content-Format: "application/ace-groupcomm+cbor"
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/ace-groupcomm+cbor and is formatted as defined in Section 4. The value of the 'error' 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" 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" 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.¶

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: "pub-key"
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'9ff7684414affcc8',
    "client_cred_verify": POP_EVIDENCE }

Response:

Header: Changed (Code=2.04)
Payload: -

6.1. Point-to-Point Group Rekeying

This approach 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, that 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, co-existing 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, this 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/ace-groupcomm+cbor and is formatted as defined in Section 4. The value of the 'error' 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 to 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 Section 4.3.2 and Section 4.8.1, respectively).¶

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][RFC2627]. That is, each rekeying message might be, and likely is, intended to 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). Typically, this pays off in large-scale groups, where the introduced performance overhead is less than what experienced by rekeying the group in a point-to-point fashion (see Section 6.1).¶

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 a number of 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 with a multicast address where the KDC will send the rekeying messages for that group; '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 intended also to 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 multicast URI specified in the 'control_group_uri' parameter of the Join Response (see Section 4.3.1).¶

  If a particular rekeying message is intended to 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 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 the specifically used delivery method, the group rekeying scheme can perform a possible roll-over of the administrative keying material through the same sent rekeying messages. Actually, such a roll-over 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 owns only a subset of the overall administrative keying material, 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 owned 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 owned 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 to all the rekeyed group members, but also any new administrative keys that: i) are pertaining to and supposed to be owned by the target group members; and ii) had to be updated since leaving group members own the previous version.¶

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

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, e.g., Appendix B.2 of [RFC8613] or Appendix E of [I-D.ietf-core-oscore-groupcomm]. Such a mechanism aids the recipient group member also 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 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 to communications in a group even without 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 now own their private keys.¶

Further security considerations are specific of 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

Due to different reasons, 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 group keying material latest upon its expiration. Before then, the KDC may also renew the group keying material on a regular or periodical fashion.¶

The KDC should renew the group keying material upon a group membership change. Since the minimum number of group members is one, the KDC should provide also a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC should provide new group keying material also 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.¶

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, or 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 member.¶

The KDC should renew the group keying material in case it has rebooted, even in case 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 rather rely on each group member asking for the new group keying material (see Section 4.3.2.1 and Section 4.8.1.1), or rather 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 re-joining the group at high rates, or often asking the KDC for new indidivual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temperorarily) 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].¶

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

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 group the 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 registers 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 CBOR map containing the protocol parameters defined in [RFC-XXXX].¶

Security considerations: See Section 10 of this document.¶

Interoperability considerations: n/a¶

Published specification: [RFC-XXXX]¶

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

Fragment identifier considerations: N/A¶

Additional information: N/A¶

Person & email address to contact for further information: [email protected]¶

Intended usage: COMMON¶

Restrictions on usage: None¶

Author: Francesca Palombini [email protected]¶

Change controller: IESG¶

11.2. CoAP Content-Formats

IANA is asked to register the following entry to the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.¶

Media Type: application/ace-groupcomm+cbor¶

Encoding: -¶

ID: TBD¶

Reference: [RFC-XXXX]¶

11.3. OAuth Parameters

IANA is asked to register 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: IESG¶
• Specification Document(s): [RFC-XXXX]¶

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

11.4. OAuth Parameters CBOR Mappings

IANA is asked to register 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: TBD (range -256 to 255)¶
• Value Type: Simple value "null" / array¶
• Reference: [RFC-XXXX]¶

• Name: kdcchallenge¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: Byte string¶
• Reference: [RFC-XXXX]¶

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

IANA is asked to register the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "CoRE Parameters" registry group.¶

• Attribute Value: ace.group¶
• Description: The 'ace group' interface is used to provision keying material and related information and policies to members of a group using the Ace framework.¶
• Reference: [RFC-XXXX]¶

11.6. ACE Groupcomm Parameters

This specification establishes the "ACE Groupcomm Parameters" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13.¶

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 CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a string.¶
• 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 by the values in Section 8. The Reference column for all of these entries refers to sections of this document.¶

11.7. ACE Groupcomm Key Types

This specification establishes the "ACE Groupcomm Key Types" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13.¶

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.¶
• 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.¶
• References: This contains a pointer to the public specification for the format of the keying material, if one exists.¶

This registry has been initially populated by the values in Figure 10. The specification column for all of these entries will be this document.¶

11.8. ACE Groupcomm Profiles

This specification establishes the "ACE Groupcomm Profiles" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13. 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. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. 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.¶

11.9. ACE Groupcomm Policies

This specification establishes the "ACE Groupcomm Policies" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13. 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. Key map labels MUST be unique. The label can be a positive integer, a negative integer or a string. Integer values between 0 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values greater than 65535 and 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 will be initially populated by the values in Figure 11.¶

11.10. Sequence Number Synchronization Methods

This specification establishes the "Sequence Number Synchronization Methods" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13. 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.¶
• 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.11. ACE Groupcomm Errors

This specification establishes the "ACE Groupcomm Errors" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13. 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. The value MUST be unique. The value can be a positive integer or a negative integer. Integer values between 0 and 255 are designated as Standards Track Document required. Integer values 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 by the values in Section 9. The Reference column for all of these entries refers to this document.¶

11.12. ACE Groupcomm Rekeying Schemes

This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.13. 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. The value MUST be unique. The value can be a positive integer or a negative integer. Integer values between 0 and 255 are designated as Standards Track Document required. Integer values 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 by the value in Figure 12.¶

11.13. 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. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. 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 assignment. 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 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 root url-path, which is used to discover the correct url to access at 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 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 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 (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 Section 4.3.1).¶
• REQ22: Specify the communication protocol the members of the group must use (e.g., multicast CoAP).¶
• 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 Client and KDC. Optionally, specify 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 Section 4.3.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' field in an error response from the KDC.¶
• 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).¶
• OPT15: Optionally, specify if Clients must or should support any of the parameters defined as optional in this specification (see Section 8).¶

B.1. Format of 'sign_info_entry'

The format of each 'sign_info_entry' (see Section 3.3.1) is generalized as follows. Given N the number of elements of the 'sign_parameters' array, i.e., the number of COSE capabilities of the signature algorithm, then:¶

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

sign_info_entry =
[
  id : gname / [ + gname ],
  sign_alg : int / tstr,
  sign_parameters : [ alg_capab_1 : any,
                      alg_capab_2 : any,
                      ...,
                      alg_capab_N : any],
  sign_capab_1 : [ any ],
  sign_capab_2 : [ any ],
  ...,
  sign_capab_N : [ any ],
  cred_fmt = int / null
]

gname = tstr

C.1. Version -15 to -16

• Distinction between authentication credentials and public keys.¶
• Consistent renaming of parameters and URI paths.¶
• Updated format of scope entries when using AIF.¶
• Updated signaling of semantics for binary encoded scopes.¶
• Editorial fixes.¶

C.2. Version -14 to -15

• Fixed nits.¶

C.3. Version -13 to -14

• Clarified scope and goal of the document in abstract and introduction.¶
• Overall clarifications on semantics of operations and parameters.¶
• Major restructuring in the presentation of the KDC interface.¶
• Revised error handling, also removing redundant text.¶
• Imported parameters and KDC resource about the KDC's public key from draft-ietf-ace-key-groupcomm-oscore.¶
• New parameters 'group_rekeying_scheme' and 'control_group_uri'.¶
• Provided example of administrative keying material transported in 'mgt_key_material'.¶
• Reasoned categorization of parameters, as expected support by ACE Clients.¶
• Reasoned categorization of KDC functionalities, as minimally/optional to support for ACE Clients.¶
• Guidelines on enhanced error responses using 'error' and 'error_description'.¶
• New section on group rekeying, discussing at a high-level a basic one-to-one approach and possible one-to-many approaches.¶
• Revised and expanded security considerations, also about the KDC.¶
• Updated list of requirements for application profiles.¶
• Several further clarifications and editorial improvements.¶

C.4. Version -05 to -13

• Incremental revision of the KDC interface.¶
• Removed redundancy in parameters about signature algorithm and signature keys.¶
• Node identifiers always indicated with 'peer_identifiers'.¶
• Format of public keys changed from raw COSE Keys to be certificates, CWTs or CWT Claims Set (CCS). Adapted parameter 'pub_key_enc'.¶
• Parameters and functionalities imported from draft-ietf-key-groupcomm-oscore where early defined.¶
• Possible provisioning of the KDC's Diffie-Hellman public key in response to the Token transferring to /authz-info.¶
• Generalized proof-of-possession evidence, to be not necessarily a signature.¶
• Public keys of group members may be retrieved filtering by role and/or node identifier.¶
• Enhanced error handling with error code and error description.¶
• Extended "typed" format for the 'scope' claim, optional to use.¶
• Editorial improvements.¶

C.5. Version -04 to -05

• Updated uppercase/lowercase URI segments for KDC resources.¶
• Supporting single Access Token for multiple groups/topics.¶
• Added 'control_uri' parameter in the Join Request.¶
• Added 'peer_roles' parameter to support legal requesters/responders.¶
• Clarification on stopping using owned keying material.¶
• Clarification on different reasons for processing failures, related policies, and requirement OPT11.¶
• Added a KDC sub-resource for group members to upload a new public key.¶
• Possible group rekeying following an individual Key Renewal Request.¶
• Clarified meaning of requirement REQ3; added requirement OPT12.¶
• Editorial improvements.¶

C.6. Version -03 to -04

• Revised RESTful interface, as to methods and parameters.¶
• Extended processing of Join Request, as to check/retrieval of public keys.¶
• Revised and extended profile requirements.¶
• Clarified specific usage of parameters related to signature algorithms/keys.¶
• Included general content previously in draft-ietf-ace-key-groupcomm-oscore¶
• Registration of media type and content format application/ace-group+cbor¶
• Editorial improvements.¶

C.7. Version -02 to -03

• Exchange of information on the signature algorithm and related parameters, during the Token POST (Section 3.3).¶
• Restructured KDC interface, with new possible operations (Section 4).¶
• Client PoP signature for the Join Request upon joining (Section 4.1.2.1).¶
• Revised text on group member removal (Section 5).¶
• Added more profile requirements (Appendix A).¶

C.8. Version -01 to -02

• Editorial fixes.¶
• Distinction between transport profile and application profile (Section 1.1).¶
• New parameters 'sign_info' and 'pub_key_enc' to negotiate parameter values for signature algorithm and signature keys (Section 3.3).¶
• New parameter 'type' to distinguish different Key Distribution Request messages (Section 4.1).¶
• New parameter 'client_cred_verify' in the Key Distribution Request to convey a Client signature (Section 4.1).¶
• Encoding of 'pub_keys_repos' (Section 4.1).¶
• Encoding of 'mgt_key_material' (Section 4.1).¶
• Improved description on retrieval of new or updated keying material (Section 6).¶
• Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).¶
• Extended security considerations (Sections 10.1 and 10.2).¶
• New "ACE Public Key Encoding" IANA registry (Section 11.2).¶
• New "ACE Groupcomm Parameters" IANA registry (Section 11.3), populated with the entries in Section 8.¶
• New "Ace Groupcomm Request Type" IANA registry (Section 11.4), populated with the values in Section 9.¶
• New "ACE Groupcomm Policy" IANA registry (Section 11.7) populated with two entries "Sequence Number Synchronization Method" and "Key Update Check Interval" (Section 4.2).¶
• Improved list of requirements for application profiles (Appendix A).¶

C.9. Version -00 to -01

• Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1).¶
• Defined error handling on the KDC (Sections 4.2 and 6.2).¶
• Updated format of the Key Distribution Response as a whole (Section 4.2).¶
• Generalized format of 'pub_keys' in the Key Distribution Response (Section 4.2).¶
• Defined format for the message to request leaving the group (Section 5.2).¶
• Renewal of individual keying material and methods for group rekeying initiated by the KDC (Section 6).¶
• CBOR type for node identifiers in 'get_pub_keys' (Section 7.1).¶
• Added section on parameter identifiers and their CBOR keys (Section 8).¶
• Added request types for requests to a Join Response (Section 9).¶
• Extended security considerations (Section 10).¶
• New IANA registries "ACE Groupcomm Key registry", "ACE Groupcomm Profile registry", "ACE Groupcomm Policy registry" and "Sequence Number Synchronization Method registry" (Section 11).¶
• Added appendix about requirements for application profiles of ACE on group communication (Appendix A).¶