Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)
Extracted elements (29)
This specification deliberately defines only general message formats and the KDC interface, delegating keying material formats, role definitions, PoP computation, and credential format constraints to separate application profiles. This two-layer design supports diverse group communication approaches (multicast CoAP, pub-sub) without requiring changes to the core key-distribution framework.
During or immediately after a rekeying, different group members may temporarily hold different versions of the group keying material, causing a misalignment. Section 6.3 describes the scenarios where this can occur and how members can detect and recover from it, typically by retrieving the latest keying material from the KDC using the version number ('num') as a reference.
All request messages sent to the KDC and all success response messages from the KDC that include a payload and specify a Content-Format MUST use Content-Format 'application/ace-groupcomm+cbor' (registered in Section 11.2). CBOR map keys for parameters are defined in Section 8.
Application profiles of this specification are REQUIRED to address a set of mandatory compliance points (REQ1–REQ18) including: defining the scope format and encoding (REQ1), registering AIF instances if used (REQ2), specifying acceptable signature algorithms and key types (REQ3–REQ5), defining acceptable authentication credential formats (REQ6), specifying PoP evidence computation and verification (REQ14), and defining the initial keying material version number (REQ16).
If a scope entry in the access token specifies a role requiring the Client to send its authentication credential when joining, the Token Transfer Response MUST include the 'kdcchallenge' parameter containing a freshly generated challenge N_S. The KDC MUST store this value at least until it receives the corresponding Join Request.
If backward security is prescribed (new members must not access prior communications), the KDC MUST generate new group keying material and distribute it to existing members before completing the join. If forward security is required (departing members must not access future communications), a rekeying MUST occur on every departure or eviction.
The exchange between the Client and AS MUST be secured as specified by the transport profile of ACE used between the Client and KDC. The joining node MUST have a secure communication association established with the KDC before joining a group, and all subsequent communications with the KDC MUST occur in accordance with that transport profile.
The Join Request (POST to /ace-group/GROUPNAME) MUST include 'cnonce' (a Client-generated nonce N_C as CBOR byte string). 'client_cred' (the Client's authentication credential as CBOR byte string) MUST be present when the KDC manages member credentials and the Client's role requires sending messages; 'client_cred_verify' MUST accompany 'client_cred' when no pre-stored credential is available.
The Join Response MUST contain 'gkty' (key type integer or text string from the ACE Groupcomm Key Types registry), 'key' (the group keying material in the application-profile-defined format), and 'num' (current keying material version as a CBOR integer that strictly increases with each change). The response code is 2.01 (Created) for newly added members, 2.04 (Changed) for rejoining members.
The proof-of-possession access token in the Authorization Response MUST contain a confirmation claim, an expiration time claim, and a scope claim specifying the groups and roles the Client is authorized to access. The scope claim encoding must match the scope format negotiated with the AS.
Upon receiving any request, the KDC MUST verify it holds a valid access token for the Client (else reply 4.01 Unauthorized) and, for group-specific resources, that the token's scope authorizes the requested operation on that group (else reply 4.03 Forbidden). If the request is malformed, the KDC MUST reply with 4.00 Bad Request; unknown or unexpected fields MUST be silently ignored.
Error responses from the KDC that convey error-specific information MUST use Content-Format 'application/concise-problem-details+cbor' and MUST include the Custom Problem Detail entry 'ace-groupcomm-error', which is a CBOR map with a single 'error-id' field (key 0, value int) drawn from the ACE Groupcomm Errors registry.
Group rekeying can be performed point-to-point (Section 6.1), where the KDC sends new keying material individually to each group member via their 'control_uri', or one-to-many (Section 6.2), where the KDC uses a group communication channel and protects the rekeying messages with a rekeying-scheme-specific protection mechanism registered in the ACE Groupcomm Rekeying Schemes registry.
The /ace-group FETCH handler accepts a request with 'gid' (CBOR array of group identifiers) and returns a CBOR map with parallel arrays 'gid', 'gname' (text strings), and 'guri' (text strings), mapping each requested identifier to its group name and group-membership resource URI. If no matching group is found, the response payload is a zero-length CBOR byte string (0x40).
The 'control_uri' parameter in a Join Request specifies a URI at the Client acting as a CoAP server. The KDC MAY use this URI to push one-to-one rekeying material (Section 6.1) or to notify the Client of its removal from the group (Section 5). The URI MUST NOT be /ace-group/GROUPNAME.
The extended scope format defined in Section 7 wraps the actual scope with an explicit semantic tag, enabling a KDC that implements multiple application profiles (with different scope semantics) or additional services to correctly parse the access token's scope claim. The AS SHOULD use this format when aware that the RS needs to disambiguate scope semantics.
The 'get_creds' parameter in the Join Request is either the CBOR simple value null (0xf6) to retrieve all member credentials, or a three-element CBOR array [inclusion_flag (bool), role_filter ([role/comb_role]*), id_filter ([bstr]*)] for filtered retrieval. In initial Join Requests, inclusion_flag is always true and id_filter is always empty.
The Join Response SHOULD include 'exp' (expiration time of keying material, CBOR unsigned integer seconds since Unix epoch) and 'exi' (residual lifetime in seconds as of KDC response time). If 'exp' is present, 'exi' MUST also be present. After 'exp', group members MUST NOT use that keying material.
The KDC interface consists of a fixed resource hierarchy: /ace-group (root, FETCH), /ace-group/GROUPNAME (group-membership, POST/GET), /ace-group/GROUPNAME/creds (member credentials, GET/FETCH), /ace-group/GROUPNAME/kdc-cred (KDC credential, GET), /ace-group/GROUPNAME/policies (GET), /ace-group/GROUPNAME/num (keying material version, GET), /ace-group/GROUPNAME/nodes/NODENAME (per-member, GET/POST/DELETE), and /ace-group/GROUPNAME/nodes/NODENAME/cred (credential upload, POST).
The 'kdcchallenge' parameter is an optional field in the Token Transfer Response from /authz-info; it carries a KDC-generated nonce N_S that the Client incorporates into the PoP input when computing 'client_cred_verify' in the Join Request. The same value MAY be reused by the Client for subsequent credential uploads.
The 'sign_info' parameter is exchanged between the Client and /authz-info endpoint. In a Token Transfer Request it is the CBOR simple value null (0xf6); in the Token Transfer Response it is a CBOR array of 'sign_info_entry' elements, each associating one or more group names with their signature algorithm, algorithm parameters, key parameters, and authentication credential format.
The 'ACE Groupcomm Errors' registry (Section 11.12) and 'ACE Groupcomm Rekeying Schemes' registry (Section 11.13) are created by this document. Error identifiers (integer values) map to named error conditions (e.g., 2 = 'Authentication credential incompatible with group configuration', 3 = 'Invalid PoP evidence', 4 = 'No available individual keying material'). Rekeying scheme entries identify supported algorithms for one-to-many rekeying.
The 'ACE Groupcomm Key Types' registry (Section 11.8) maps key type names to integer values for use in the 'gkty' parameter of Join Responses. Value 0 is reserved by this document. Application profiles MUST register entries with name, key type value, associated profile, and description.
The 'ACE Groupcomm Parameters' registry (Section 11.7) is created by this document, mapping CBOR integer abbreviations to named message parameters (e.g., 'gid'=0, 'gname'=1, 'guri'=2, 'scope'=4, 'get_creds'=7, 'client_cred'=8, 'cnonce'=9, 'client_cred_verify'=10, 'key'=18, 'num'=19, 'exp'=20, 'sign_info'=26, 'kdcchallenge'=39). New entries require Expert Review.
The 'ACE Groupcomm Profiles' registry (Section 11.9) and 'ACE Groupcomm Policies' registry (Section 11.10) and 'Sequence Number Synchronization Methods' registry (Section 11.11) are created by this document; each requires an Expert Review for new entries and ties into the application-profile extensibility framework.
All group communications must be protected using the keying material obtained from the KDC. The KDC is trusted to provide authentic, fresh keying material; the ACE transport profile's secure channel ensures only authorized members receive it. Loss of group keying material confidentiality undermines the security of all group messages protected with that material.
Group keying material must be updated upon membership changes to enforce backward and forward security guarantees. Block-wise transfers (Section 10.3) of keying material introduce a window where partial keying material is available to the Client; implementations must ensure atomicity or handle partial-delivery failures to avoid security degradation.
Each 'sign_info_entry' is a CBOR array of five elements: 'id' (tstr or array of tstr group names), 'sign_alg' (int or tstr from COSE Algorithms registry), 'sign_parameters' (CBOR array), 'sign_key_parameters' (CBOR array of at least one element), and 'cred_fmt' (int from COSE Header Parameters registry, or null if KDC does not store member credentials).
The PoP evidence in 'client_cred_verify' is computed over the byte-string concatenation: bstr(scope) || bstr(N_S) || bstr(N_C), where scope is from the Join Request's 'scope' field (or a default), N_S is the 'kdcchallenge' value from the Token Transfer Response, and N_C is the Client nonce from 'cnonce'. Application profiles MUST specify the exact computation method.