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 [I-D.ietf-ace-oauth-authz] and [RFC8152], such as Authorization Server (AS) and Resource Server (RS).¶

This document additionally uses the following terminology:¶

• Transport profile, to indicate a profile of ACE as per Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. 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. Tranport profiles of ACE include, for instance, [I-D.ietf-ace-oscore-profile], [I-D.ietf-ace-dtls-authorize] 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 (re-)distribution of keying material. An application profile may define specific procedures and message formats.¶

3.1. Authorization Request

The Authorization Request sent from the Client to the AS is as defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the following parameters, which, if included, MUST have the corresponding values:¶

• 'scope', containing the identifier of the specific group(s), or topic(s) in the case of pub-sub, that the Client wishes to access, and optionally the role(s) that the Client wishes to take.¶

  This value is a CBOR byte string, encoding a CBOR array of one or more entries.¶

  An entry has as value a CBOR array, which contains:¶

  • As first element, the identifier of the specific group or topic.¶
  • 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 to its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).¶

  In each entry, the encoding of the group or topic identifier (REQ1) and of the role identifiers (REQ2) is application specific, and part of the requirements for the application profile.¶

  In particular, the application profile may specify CBOR values to use for abbreviating role identifiers (OPT7).¶

  The CDDL definition of scope, using as example group identifier encoded as byte string and role identifier as text string, is given in Figure 4.¶

• 'audience', with an identifier of a KDC.¶
• 'req_cnf', as defined in Section 3.1 of [I-D.ietf-ace-oauth-params], optionally containing the public key or a reference to the public key of the Client, if it wishes to communicate that to the AS.¶

• Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary.¶

As in [I-D.ietf-ace-oauth-authz], these parameters are included in the payload, which is formatted as a CBOR map. The Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz] is used.¶

gid = bstr

role = tstr

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

scope = << [ + scope_entry ] >>

3.2. Authorization Response

The Authorization Response sent from the AS to the Client is as defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the following parameters:¶

• 'access_token', containing the proof-of-possession access token.¶
• 'cnf' if symmetric keys are used, not present if asymmetric keys are used. This parameter is defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of-possession key that the Client is supposed to use with the KDC.¶
• 'rs_cnf' if asymmetric keys are used, not present if symmetric keys are used. This parameter is as defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains information about the public key of the KDC.¶
• 'expires_in', contains the lifetime in seconds of the access token. This parameter 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, the Authorization Response MAY contain the following parameters, which, if included, MUST have the corresponding values:¶

• 'scope' containing the granted scope, if different from the scope requested by the client. This parameter has the same format and encoding of 'scope' in the Authorization Request, defined in Section 3.1.¶
• Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary.¶

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.13 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same encoding as 'scope' parameter above. Additionally, this claim has the same value of the 'scope' parameter if the parameter is present in the message, or it takes the value of 'scope' in the Authorization Request otherwise.¶

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

As in [I-D.ietf-ace-oauth-authz], these parameters are included in the payload, which is formatted as a CBOR map. The Content-Format "application/ace+cbor" is used.¶

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

3.3. Token Post

The Client sends a CoAP POST request including the access token to the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. If the specific transport profile of ACE defines it, the Client MAY use a different endpoint than /authz-info at the KDC to post the access token to.¶

Optionally, the Client might want to request necessary information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group. In such a case, the joining node MAY ask for that information to the KDC in this same request. To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ace+cbor". The payload of the message MUST be formatted as a CBOR map, including the access token and the following parameters:¶

• 'sign_info' defined in Section 3.3.1.¶
• 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple value Null, to require information on the exact encoding of public keys used in the group.¶

Alternatively, the joining node may retrieve this information by other means.¶

After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz].¶

The payload of the 2.01 response is a CBOR map. If the access token contains a role that requires the Client to send its own public key to the KDC when joining the group, the CBOR map MUST include the parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying a dedicated challenge N_S generated by the KDC. The Client uses this challenge to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4). Note that the payload format of the response deviates from the default as defined in the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]).¶

The KDC MUST store the 'kdcchallenge' value associated to the Client at least until it receives a join request from it (see Section 4.2), to be able to verify the proof of possession. The same challenge MAY be reused several times by the Client, to generate new proof of possessions, e.g. in case of update of the public key, or to join a different group with a different key, so it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' after the first join is processed as well. If the KDC has already discarded the 'kdcchallenge', that will trigger an error response with a newly generated 'kdcchallenge' that the client can use to restart the join process, as specified in Section 4.2.¶

If either of 'sign_info' or 'pub_key_enc' were included in the request, the KDC MAY include the 'sign_info' parameter defined in Section 3.3.1, optionally including the 'pub_key_enc' parameter Section 3.3.2.¶

The 'sign_info' parameter MUST be present if the POST request included the 'sign_info' parameter and/or the pub_key_enc with value Null. The encoding of the 'sign_info' parameter in the response is defined in Section 3.3.2. Note that the field 'id' takes the value of the group identifier for which the 'sign_info' applies to, in this specification.¶

Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g. according to the signalled transport profile of ACE.¶

Applications of this specification MAY define alternative specific negotiations of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2).¶

   sign_info_req = nil

   sign_info_res = [ + sign_info_entry ]

   sign_info_entry =
   [
     id : gid / [ + gid ],
     sign_alg : int / tstr / nil,
     sign_parameters : any / nil,
     sign_key_parameters : any / nil,
     ? pub_key_enc_res = int / nil
   ]

   gid = bstr

   pub_key_enc_req = nil

4.1. Interface at the KDC

The KDC is configured with the following resources. Note that the root url-path "ace-group" given here are default names: implementations are not required to use these names, and can define their own instead. The Interface Description (if=) Link Target Attribute value ace-group is registered (Section 8.9) and can be used to describe this inferface.¶

• /ace-group : this resource is fixed and indicates that this specification is used. Other applications that run on a KDC implementing this specification MUST NOT use this same resource.¶
• /ace-group/GROUPNAME : one sub-resource to /ace-group is implemented for each group the KDC manages. These resources are identified by the group identifiers of the groups the KDC manages (in this example, the group identifier has value "GROUPNAME"). These resources support GET and POST method.¶
• /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and supports GET and FETCH methods.¶
• /ace-group/GROUPNAME/policies: this sub-resource is fixed and supports the GET method.¶
• /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and supports the GET method.¶
• /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-group/GROUPNAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value "NODENAME"). These resources support GET, PUT and DELETE methods.¶
• /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value "NODENAME"). These resources support the POST method.¶

The details for the handlers of each resource are given in the following sections. These endpoints are used to perform the operations introduced in Section 4.¶

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

+--------------+-------+----------|--------------------|------------+
|      Name    | CBOR  |   CBOR   |    Description     | Reference  |
|              | label |   type   |                    |            |
|--------------+-------+----------|--------------------|------------|
| Sequence     | TBD1  | tstr/int | Method for a re-   | [[this     |
| Number       |       |          | cipient node to    | document]] |
| Synchroniza- |       |          | synchronize with   |            |
| tion Method  |       |          | sequence numbers   |            |
|              |       |          | of a sender node.  |            |
|              |       |          | Its value is taken |            |
|              |       |          | from the 'Value'   |            |
|              |       |          | column of the      |            |
|              |       |          | Sequence Number    |            |
|              |       |          | Synchronization    |            |
|              |       |          | Method registry    |            |
|              |       |          |                    |            |
| Key Update   | TBD2  |   int    | Polling interval   | [[this     |
| Check        |       |          | in seconds, to     | document]] |
| Interval     |       |          | check for new      |            |
|              |       |          | keying material at |            |
|              |       |          | the KDC            |            |
+--------------+-------+----------|--------------------|------------+

id = bstr

role = tstr

comb_role = [ 2*role ]

get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] / [ ]

4.2. Joining Exchange

Figure 8 gives an overview of the Joining exchange between Client and KDC, when the Client first joins a group.¶

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

If not previously established, the Client and the KDC MUST first establish a pairwise secure communication channel (REQ16). This can be achieved, for instance, by using a transport profile of ACE. The Joining exchange MUST occur over that secure channel. The Client and the KDC MAY use that same secure channel to protect further pairwise communications that must be secured.¶

The secure communication protocol is REQUIRED to establish the secure channel by using the proof-of-possession key bound to the access token. As a result, the proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC.¶

To join the group, the Client sends a CoAP POST request to the /ace-group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group identifier of the group to join, formatted as specified in Section 4.1.2.1. This group identifier is the same as the scope entry corresponding to that group, specified in the 'scope' parameter of the Authorization Request/Response, or it can be retrieved from it. Note that, in case of successful joining, the Client will receive the URI to retrieve individual or group keying material and to leave the group in the Location-Path option of the response.¶

If the node is joining a group for the first time, and the KDC maintains the public keys of the group members, the Client is REQUIRED to send its own public key and proof of possession ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The request is only accepted if both public key and proof of possession are provided. If a node re-joins a group with the same access token and the same public key, it can omit to send the public key and the proof of possession, or just omit the proof of possession, and the KDC will be able to retrieve its public key associated to its token for that group (if the key has been discarded, the KDC will reply with 4.00 Bad Request, as specified in Section 4.1.2.1). If a node re-joins a group but wants to update its own public key, it needs to send both public key and proof of possession.¶

If the application requires backward security, the KDC MUST generate new group keying material and securely distribute it to all the current group members, upon a new node's joining the group. To this end, the KDC uses the message format of the response defined in Section 4.1.2.2. Application profiles may define alternative ways of retrieving the keying material, such as sending separate requests to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, Section 4.1.4.1). After distributing the new group keying material, the KDC MUST increment the version number of the keying material.¶

4.3. Retrieval of Updated Keying Material

When any of the following happens, a node MUST stop using the owned group keying material to protect outgoing messages, and SHOULD stop using it to decrypt and verify incoming messages.¶

• Upon expiration of the keying material, according to what indicated by the KDC with the 'exp' (and possibly the 'exp_delta') parameter in a Joining Response, or to a pre-configured value.¶
• Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC.¶
• Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by the KDC, that the Client was not able to receive or decrypt.¶

In either case, if it wants to continue participating in the group communication, the node has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.1.6.2.¶

Note that policies can be set up, so that the Client sends a Key Re-Distribution request to the KDC only after a given number of received messages could not be decrypted (because of failed decryption processing or inability to retrieve the necessary keying material).¶

It is application dependent and pertaining to the particular message exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these policies, to instruct clients to retain incoming messages and for how long (OPT4). This allows clients to possibly decrypt such messages after getting updated keying material, rather than just consider them non valid messages to discard right away.¶

The same Key Distribution Request could also be sent by the Client without being triggered by a failed decryption of a message, if the Client wants to be sure that it has the latest group keying material. If that is the case, the Client will receive from the KDC the same group keying material it already has in memory.¶

Figure 9 gives an overview of the exchange described above.¶

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

Alternatively, the re-distribution of keying material can be initiated by the KDC, which e.g.:¶

• Can make the ace-group/GROUPNAME/nodes/NODENAME resource Observable, and send notifications to Clients when the keying material is updated.¶
• Can send the payload of the Key Distribution Response in one or multiple multicast POST requests to the members of the group, using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627].¶
• Can send unicast POST requests to each Client over a secure channel, with the same payload as the Key Distribution Response. When sending such requests, the KDC can target the URI path possibly provided by the intended recipient upon joining the group, as specified in the 'control_path' parameter of the Joining Request (see Section 4.1.2.1).¶
• Can act as a publisher in a pub-sub scenario, and update the keying material by publishing on a specific topic on a broker, which all the members of the group are subscribed to.¶

Note that these methods of KDC-initiated key distribution have different security properties and require different security associations.¶

4.4. Retrieval of New Keying Material

Beside possible expiration and depending on what part of the keying material is no longer eligible to be used, the client may need to communicate to the KDC its need for that part to be renewed. For example, if the Client uses an individual key to protect outgoing traffic and has to renew it, the node may request a new one, or new input material to derive it, without renewing the whole group keying material.¶

To this end, the client performs a Key Renewal Request/Response exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME is the group identifier and NODENAME is the node's name, and formatted as defined in Section 4.1.6.2.¶

Figure 10 gives an overview of the exchange described above.¶

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

Note the difference between the Key Distribution Request and the Key Renewal Request: while the first one only triggers distribution (the renewal might have happened independently, e.g. because of expiration), the second one triggers the KDC to produce new individual keying material for the requesting node.¶

Furthermore, policies can be set up so that, upon receiving a Key Renewal Request, the KDC replies to the client with an error response, and then performs a complete group rekeying (OPT8).¶

4.5. Retrieval of Public Keys and Roles for Group Members

In case the KDC maintains the public keys of group members, a node in the group can contact the KDC to request public keys and roles of either all group members or a specified subset, by sending a CoAP GET or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the KDC, where GROUPNAME is the group identifier, and formatted as defined in Section 4.1.3.2 and Section 4.1.3.1.¶

When receiving a Public Key Response, the requesting group member stores (or updates) the public keys (in the 'pub_keys' parameter) and roles (in the 'peer_roles' parameter) of the group members.¶

Figure 11 and Figure 12 give an overview of the exchanges described above.¶

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

Client                                                      KDC
   |                                                         |
   |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->|
   |                                                         |
   |<--------- Public Key Response: 2.05 (Created) ----------|
   |                                                         |

4.6. Update of Public Key

In case the KDC maintains the public keys of group members, a node in the group can contact the KDC to upload a new public key to use in the group, and replace the currently stored one.¶

To this end, the Client performs a Public Key Update Request/Response exchange with the KDC, i.e. it sends a CoAP POST request to the /ace-group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where GROUPNAME is the group identifier and NODENAME is the node's name.¶

The request is formatted as specified in Section 4.1.7.1.¶

Figure Figure 13 gives an overview of the exchange described above.¶

Client                                                           KDC
|                                                                 |
|-------------- Public Key Update Request: ---------------------->|
|      POST ace-group/GROUPNAME/nodes/NODENAME/pub-key            |
|                                                                 |
|<------- Public Key Update Response: 2.04 (Changed) -------------|
|                                                                 |

If the application requires backward security, the KDC MUST generate new group keying material and securely distribute it to all the current group members, upon a group member updating its own public key. To this end, the KDC uses the message format of the response defined in Section 4.1.2.2. Application profiles may define alternative ways of retrieving the keying material, such as sending separate requests to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, Section 4.1.4.1). After distributing the new group keying material, the KDC MUST increment the version number of the keying material.¶

Additionally, after updating its own public key, a group member MAY send a number of the later requests including an identifier of the updated public key, to signal nodes that they need to retrieve it. How that is done depends on the group communication protocol used, and therefore is application profile specific (OPT10).¶

4.7. Retrieval of Group Policies

A node in the group can contact the KDC to retrieve the current group policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/policies endpoint at the KDC, where GROUPNAME is the group identifier, and formatted as defined in Section 4.1.4.1¶

Figure 14 gives an overview of the exchange described above.¶

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

4.8. Retrieval of Keying Material Version

A node in the group can contact the KDC to request information about the version number of the symmetric group keying material, by sending a CoAP GET request to the /ace-group/GROUPNAME/ctx-num endpoint at the KDC, where GROUPNAME is the group identifier, formatted as defined in Section 4.1.5.1. In particular, the version is incremented by the KDC every time the group keying material is renewed.¶

Figure 15 gives an overview of the exchange described above.¶

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

4.9. Group Leaving Request

A node can actively request to leave the group. In this case, the Client sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the group identifier and NODENAME is the node's name, formatted as defined in Section 4.1.6.3¶

Alternatively, a node may be removed by the KDC, without having explicitly asked for it. This is further discussed in Section 5.¶

7.1. Update of 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 keying material. However, the recipient receives the message after having received the new keying material, hence not being able to correctly process it. A possible way to ameliorate this issue is to preserve the old, recent, keying material for a maximum amount of time defined by the application. By doing so, the recipient can still try to process the received message using the old retained keying material as second attempt. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old retained keying material. Therefore, a conservative application policy should not admit the storage of old keying material.¶

In the second case, the sender protects a message using the new keying material, but the recipient receives that request before having received the new keying material. Therefore, the recipient would not be able to correctly process the request and hence discards it. If the recipient receives the new 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 an updated keying material according to an application-defined policy, for instance after a given number of unsuccessfully decrypted incoming messages.¶

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

7.2. Block-Wise Considerations

If the block-wise 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 keying material to the updated one and continues the transfer. As long as both sides get the new keying material, updating 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 keying material is changed, the nodes might consume a larger amount of the network bandwidth resending the blocks again and again, which might be problematic.¶

8.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: none¶

Optional parameters: none¶

Encoding considerations: Must be encoded as CBOR map containing the protocol parameters defined in [this document].¶

Security considerations: See Section 7 of this document.¶

Interoperability considerations: n/a¶

Published specification: [this document]¶

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 [this document].¶

Additional information:¶

Magic number(s): n/a¶

File extension(s): .ace-groupcomm¶

Macintosh file type code(s): n/a¶

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

Intended usage: COMMON¶

Restrictions on usage: None¶

Author: Francesca Palombini francesca.palombini@ericsson.com¶

Change controller: IESG¶

8.2. CoAP Content-Formats Registry

This specification registers the following entry to the "CoAP Content-Formats" registry, within the "CoRE Parameters" registry:¶

Media Type: application/ace-groupcomm+cbor¶

Encoding: -¶

ID: TBD¶

Reference: [this document]¶

8.3. ACE Authorization Server Request Creation Hints Registry

IANA is asked to register the following entries in the "ACE Authorization Server Request Creation Hints" Registry defined in Section 8.1 of [I-D.ietf-ace-oauth-authz].¶

• Name: sign_info¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: any¶
• Reference: [[This specification]]¶
• Name: pub_key_enc¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: integer¶
• Reference: [[This specification]]¶
• Name: kdcchallenge¶
• CBOR Key: TBD (range -256 to 255)¶
• Value Type: byte string¶
• Reference: [[This specification]]¶

8.4. ACE Groupcomm Parameters Registry

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

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 6. The Reference column for all of these entries refers to sections of this document.¶

8.5. ACE Groupcomm Key Registry

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

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 Profile" 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 5. The specification column for all of these entries will be this document.¶

8.6. ACE Groupcomm Profile Registry

This specification establishes the "ACE Groupcomm Profile" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 8.10. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, 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.¶

8.7. ACE Groupcomm Policy Registry

This specification establishes the "ACE Groupcomm Policy" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 8.10. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, 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 of 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 6.¶

8.8. Sequence Number Synchronization Method Registry

This specification establishes the "Sequence Number Synchronization Method" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are provided in Section 8.10. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, 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.¶

8.9. Interface Description (if=) Link Target Attribute Values Registry

This specification registers the following entry to the "Interface Description (if=) Link Target Attribute Values Registry" registry, within the "CoRE Parameters" registry:¶

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

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

B.1. Version -04 to -05

• Updated uppercase/lowercase URI segments for KDC resources.¶
• Supporting single Access Token for multiple groups/topics.¶
• Added 'control_path' parameter in the Joining 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 OPT4.¶
• 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 OPT8.¶
• Editorial improvements.¶

B.2. Version -03 to -04

• Revised RESTful interface, as to methods and parameters.¶
• Extended processing of joining 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.¶

B.3. Version -02 to -03

• Exchange of information on the countersignature 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 Joining Request upon joining (Section 4.1.2.1).¶
• Revised text on group member removal (Section 5).¶
• Added more profile requirements (Appendix A).¶

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

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