Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.rfc-editor.org/rfc/rfc9594.xml below:

• The terms and concepts described in the ACE framework and in the Authorization Information Format (AIF) to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS).
• The terms and concepts described in the Constrained Application Protocol (CoAP) . The term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol".
• The terms and concepts described in Concise Data Definition Language (CDDL) , CBOR , and CBOR Object Signing and Encryption (COSE) .

Group:

A set of nodes that share common keying material and security parameters used to protect their communications with one another. That is, the term refers to a "security group". This term is not to be confused with an "application group", which has relevance at the application level and whose members share a common pool of resources or content. Examples of application groups are the set of all nodes deployed in a same physical room or the set of nodes registered to a pub-sub topic. This term is also not to be confused with a "multicast group", which has relevance at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of a multicast group is the set of nodes that are configured to receive messages that are sent to the group's associated IP multicast address. The same security group might be associated with multiple application groups. Also, the same application group might be associated with multiple security groups. Further details and considerations on the mapping between the three types of groups are out of the scope of this document.

Key Distribution Center (KDC):

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

Group name:

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

GROUPNAME:

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

Group identifier:

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

Node name:

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

NODENAME:

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

Transport profile:

A profile of the ACE framework as per . 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. Transport profiles of ACE include, for instance, those described in , , and .

Application profile:

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

Authentication credential:

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

Individual keying material:

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

• Client (C): A node that wants to join a group and take part in group communication with other group members. Within the group, the Client can have different roles.
• Authorization Server (AS): As per the AS defined in the ACE framework , it enforces access policies that prescribe whether a node is allowed to join a given group or not and with what roles and rights (e.g., write and/or read).
• Key Distribution Center (KDC): An entity that maintains the keying material to protect group communications and provides it to Clients authorized to join a given group. During the first phase of the process (), the KDC takes the role of the RS in the ACE framework. During the second phase of the process (), which is not based on the ACE framework, the KDC distributes the keying material. In addition, the KDC provides the latest keying material to group members when requested or, if required by the application, when group membership changes.
• Group members: Nodes that have joined a group where they take part in group communication with one another, protecting it with the group keying material obtained from the KDC.
• Dispatcher: An entity through which the Clients communicate with the group when sending a message intended for multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. The Dispatcher does not have access to the group keying material. A single-recipient message intended for only one group member may be delivered by alternative means, i.e., with no assistance from the Dispatcher. Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for group communication that delivers group messages as multiple unicast messages to all group members; and an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. If it consists of an explicit entity, such as a pub-sub Broker or a message relayer, the Dispatcher is comparable to an untrusted on-path intermediary; as such, it is able to see the messages sent by Clients in the group but not able to decrypt them and read their plain content.

• Authorizing a Client to join the group () and providing it with the group keying material to communicate with the other group members (),
• Allowing a group member to retrieve group keying material (Sections and ),
• Allowing a group member to retrieve authentication credentials of other group members () and to provide an updated authentication credential (),
• Allowing a group member to leave the group (),
• Evicting a group member from the group (), and
• Renewing and redistributing the group keying material (rekeying), e.g., upon a membership change in the group ( ). Rekeying the group may result in a temporary misalignment of the keying material stored by the different group members. Different situations where this can happen and how they can be handled are discussed in .

1. The joining node requests an access token from the AS in order to access one or more group-membership resources at the KDC and hence join the associated groups. This exchange between the Client and AS MUST be secured, as specified by the transport profile of ACE used between the Client and KDC. Based on the response from the AS, the joining node will establish or continue using a secure communication association with the KDC.
2. The joining node transfers authentication and authorization information to the KDC by transferring the obtained access token. This is typically achieved by including the access token in a request sent to the /authz-info endpoint at the KDC. Once this exchange is completed, the joining node MUST have a secure communication association established with the KDC before joining a group under that KDC. This exchange and the following secure communications between the Client and the KDC MUST occur in accordance with the transport profile of ACE used between the Client and KDC, such as the DTLS transport profile of ACE or the OSCORE transport profile of ACE .
3. The joining node starts the joining process to become a member of the group by sending a request to the related group-membership resource at the KDC. Based on the application requirements and policies, the KDC may perform a group rekeying by generating new group keying material and distributing it to the current group members through the rekeying scheme used in the group. At the end of the joining process, the joining node has received the parameters and group keying material from the KDC to securely communicate with the other group members. Also, the KDC has stored the association between the authorization information from the access token and the secure communication association with the joining node.
4. The joining node and the KDC maintain the secure communication association to support possible future communications. These especially include key management operations, such as the retrieval of updated keying material or the participation in a group rekeying process.
5. The joining node can communicate securely with the other group members by using the keying material obtained in step 3.

• 'scope': specifying the names of the groups that the Client requests to access and optionally the roles that the Client requests to have in those groups. This parameter is encoded as a CBOR byte string, which wraps a CBOR array of scope entries. All the scope entries are specified according to the same format, i.e., either the Authorization Information Format (AIF) or the textual format defined below.
  • If AIF is used, each scope entry is encoded as per , i.e., as a CBOR array [Toid, Tperm]. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name and MUST be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group. AIF is the default format for application profiles of this specification and is preferable for those that aim for a compact encoding of scope. This is especially desirable for application profiles defining several roles, with the Client possibly asking for multiple roles combined. shows an example in CDDL notation where scope uses AIF.
  • If the textual format is used, each scope entry is a CBOR array formatted as follows.
    • As the first element, the group name, encoded as a CBOR text string.
    • Optionally, as the second element, the role or CBOR array of roles that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated with its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).
    shows an example in CDDL notation where scope uses the textual format with the group name and role identifiers encoded as CBOR text strings.
  It is REQUIRED for application profiles of this specification to specify the exact format and encoding of scope ( REQ1 ). This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format. If the application profile uses AIF, 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 ( 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.

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

• a confirmation claim (for example, see 'cnf' defined in for CWTs)
• an expiration time claim (for example, see 'exp' defined in for CWTs)
• a scope claim (for example, see 'scope' registered in for CWTs) If the 'scope' parameter is present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter. Instead, if the 'scope' parameter is not present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter of the Authorization Request, if the parameter is present therein, or the default scope that the AS is granting the Client otherwise. By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, as defined in . Optionally, an alternative extended format of scope defined in can be used. This format explicitly signals the semantics used to express the actual access control information, which has to be parsed. This enables a Resource Server to correctly process a received access token, also in case:
  • The Resource Server implements a KDC that supports multiple application profiles of this specification using different scope semantics and/or
  • The Resource Server implements further services beyond a KDC for group communication using different scope semantics.
  If the Authorization Server is aware that this applies to the Resource Server for which the access token is issued, the Authorization Server SHOULD use the extended format of scope defined in .

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

• The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next four elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.
• The second element 'sign_alg' is a CBOR integer or a text string that indicates the signature algorithm used in the groups identified by the 'gname' values. It is REQUIRED for application profiles to define specific values that this parameter can take ( REQ3 ), which are selected from the set of signing algorithms of the "COSE Algorithms" registry .
• The third element 'sign_parameters' is a CBOR array that indicates the parameters of the signature algorithm used in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is REQUIRED for application profiles to define the possible values and structure for the elements of this parameter ( REQ4 ).
• The fourth element 'sign_key_parameters' is a CBOR array that indicates the parameters of the key used with the signature algorithm in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is REQUIRED for application profiles to define the possible values and structure for the elements of this parameter ( REQ5 ).
• The fifth element 'cred_fmt' either is a CBOR integer indicating the format of authentication credentials used in the groups identified by the 'gname' values or is the CBOR simple value null (0xf6), which indicates that the KDC does not act as a repository of authentication credentials for group members. Its acceptable integer values are taken from the "Label" column of the "COSE Header Parameters" registry , with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). It is REQUIRED for application profiles to define specific values to use for this parameter, consistently with the acceptable formats of authentication credentials ( REQ6 ).

• /ace-group : the path of this root resource is invariant once the resource is established. Its employment indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints. A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in . Clients may be authorized to access this resource even without being members of any group managed by the KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers). The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in and can be used to describe the interface provided by this root resource. The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the resource /ace-group and returns a link to such a resource in link-format . Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: ".well-known" Uri-Path: "core" Uri-Query: "if=ace.groups" Response: Header: Content (Code=2.05) Content-Format: 40 (application/link-format) Payload: <coap://[2001:db8::ab]/ace-group>;if="ace.groups"
• /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with the name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, and it contains the symmetric group keying material of 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 Sections and , respectively. The Interface Description (if=) Link Target Attribute value "ace.group" is registered in and can be used to describe the interface provided by a group-membership resource. The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the group-membership resource /ace-group/gp1 and returns a link to such a resource in link-format . Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: ".well-known" Uri-Path: "core" Uri-Query: "if=ace.group" Response: Header: Content (Code=2.05) Content-Format: 40 (application/link-format) Payload: <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group" If it is not required that the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in ) coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name in order to refer to the correct group ( REQ7 ).
• /ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with the name GROUPNAME. This resource is created only in case the KDC acts as a repository of authentication credentials for group members. As a group member, a Client can access this resource in order to retrieve the authentication credentials of other group members. That is, the Client can retrieve the authentication credentials of all the current group members or a subset of them by specifying filter criteria. These operations are described in Sections and , respectively. Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.
• /ace-group/GROUPNAME/kdc-cred : the path of this resource is invariant once the resource is established. This resource contains the authentication credential of the KDC for the group with the name GROUPNAME. This resource is created only in case the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED for application profiles to define whether the KDC has such an associated authentication credential ( REQ8 ). As a group member, a Client can access this resource in order to retrieve the current authentication credential of the KDC. This operation is described in . Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.
• /ace-group/GROUPNAME/policies : the path of this resource is invariant once the resource is established. This resource contains the group policies of the group with the name GROUPNAME. A Client can access this resource as a group member in order to retrieve the group policies. This operation is described in .
• /ace-group/GROUPNAME/num : the path of this resource is invariant once the resource is established. This resource contains the current version number for the symmetric group keying material of the group with the name GROUPNAME. A Client can access this resource as a group member in order to retrieve the version number of the keying material currently used in the group. This operation is described in .
• /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /ace-group/GROUPNAME is hosted for each group member of the group with the name GROUPNAME. Each such resource is identified by the node name NODENAME of the associated group member and contains the group keying material and the individual keying material for that group member. A Client as a group member can access this resource in order to retrieve the current group keying material together with its individual keying material, request new individual keying material to use in the group, and leave the group. These operations are described in Sections , , and , respectively.
• /ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resource is invariant once the resource is established. This resource contains the individual authentication credential for the node with the name NODENAME as a group member of the group with the name GROUPNAME. A Client can access this resource in order to upload at the KDC a new authentication credential to use in the group. This operation is described in . 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.

• FETCH request to /ace-group/ in order to retrieve group names associated with group identifiers.
• POST and GET requests to /ace-group/GROUPNAME/ in order to join a group (POST) and later retrieve the current group keying material as a group member (GET).
• GET and FETCH requests to /ace-group/GROUPNAME/creds in order to retrieve the authentication credentials of all the other group members (GET) or only some of them by filtering (FETCH). While retrieving authentication credentials remains possible by using GET requests, retrieval by filtering allows Clients to greatly limit the size of exchanged messages.
• GET request to /ace-group/GROUPNAME/num in order to retrieve the current version of the group keying material as a group member.
• DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order to leave the group.

• GET request to /ace-group/GROUPNAME/kdc-cred in order to retrieve the current authentication credential of the KDC. This is relevant only if the KDC has an associated authentication credential and this is required for the correct group operation.
• GET request to /ace-group/GROUPNAME/policies in order to retrieve the current group policies as a group member.
• GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to retrieve the current group keying material and individual keying material. The former can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see above).
• POST request to /ace-group/GROUPNAME/nodes/NODENAME in order to ask for new individual keying material. Alternatively, the Client could obtain new individual keying material by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group or on the application profile of this specification, the Client might simply not be associated with any individual keying material.
• POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order to provide the KDC with a new authentication credential. Alternatively, the Client could provide a new authentication credential by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group, the Client might simply not have an associated authentication credential to provide.

• the scope specified in the access token includes a scope entry related to the group name GROUPNAME associated with the targeted resource and
• the set of roles specified in that scope entry allows the Client to perform the requested operation on the targeted resource ( REQ11 ).

• It MUST include the Custom Problem Detail entry 'ace-groupcomm-error', which is registered in of this document. This entry is formatted as a CBOR map including only one field, namely 'error-id'. The map key for 'error-id' is the CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR integer specifying the error that occurred at the KDC. This value is taken from the "Value" column of the "ACE Groupcomm Errors" registry defined in of this document. The CDDL notation of the 'ace-groupcomm-error' entry is given below. ace-groupcomm-error = { &(error-id: 0) => int }
• It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see ). In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, diagnostic description of the error occurred at the KDC. The diagnostic text is intended for software engineers as well as for device and network operators in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.

• 'gid': its value is encoded as a CBOR array, containing one or more group identifiers. The exact encoding of the group identifier MUST be specified by the application profile ( REQ13 ). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.

• 'gid': its value is encoded as a CBOR array, containing zero or more group identifiers. The handler indicates that those are the identifiers it is sending group names for. This CBOR array is a subset of the 'gid' array in the FETCH request.
• 'gname': its value is encoded as a CBOR array, containing zero or more group names. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.
• 'guri': its value is encoded as a CBOR array, containing zero or more URIs, each indicating a group-membership resource. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.

• 'scope': its value specifies the name of the group that the Client is attempting to join and the roles that the client wishes to have in the group. This value is encoded as a CBOR byte string wrapping one scope entry, as defined in .
• 'get_creds': it is included if the Client wishes to receive the authentication credentials of the current group members from the KDC. This parameter may be included in the Join Request if the KDC stores the authentication credentials of the group members, while it is not useful to include it if the Client obtains those authentication credentials through alternative means, e.g., from the AS. Note that including this parameter might result in a following Join Response of a large size, which can be inconvenient for resource-constrained devices. If the Client wishes to retrieve the authentication credentials of all the current group members, the 'get_creds' parameter MUST encode the CBOR simple value null (0xf6). Otherwise, if the Client wishes to retrieve the authentication credentials of nodes with specific roles, the 'get_creds' parameter MUST encode a non-empty CBOR array containing the three elements 'inclusion_flag', 'role_filter', and 'id_filter', as defined below.
  • The first element, namely 'inclusion_flag', encodes the CBOR simple value true (0xf5) if the Client wishes to receive the authentication credentials of the nodes having their node identifier specified in 'id_filter' (i.e., selection by inclusive filtering). Instead, this element encodes the CBOR simple value false (0xf4) if the Client wishes to receive the authentication credentials of the nodes that do not have the node identifiers specified in the third element 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value true (0xf5).
  • The second element, namely 'role_filter', is a CBOR array. Each element of the array contains one role or a combination of roles for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of the specified roles or combination of roles (i.e., having any of those single roles or at least all the roles indicated in any of those combinations of roles). For example, the array ["role1", "role2+role3"] indicates that the Client wishes to receive the authentication credentials of all group members that have at least "role1" or at least both "role2" and "role3". In the Join Request, this parameter is a non-empty array.
  • The third element, namely 'id_filter', is a CBOR array. Each element of the array contains a node identifier of a group member for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of the nodes that have or do not have the specified node identifiers based on the value of 'inclusion_flag' (i.e., as a selection by inclusive or exclusive filtering). In the Join Request, the Client does not filter authentication credentials based on node identifiers, so this parameter is an empty array. In fact, when first joining the group, the Client is not expected or capable to express a filter based on node identifiers of other group members. Instead, when already a group member and sending a Join Request to rejoin, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, since it can rather retrieve authentication credentials associated with specific group identifiers as defined in .
  The CDDL definition of 'get_creds' is given in ; as an example, it uses node identifiers encoded as CBOR byte strings, role identifiers encoded as CBOR text strings, and combinations of roles encoded as CBOR arrays of role identifiers. Note that, for this handler, 'inclusion_flag' is always set to true and the array of roles 'role_filter' is always non-empty, while the array of node identifiers 'id_filter' is always empty. However, this is not necessarily the case for other handlers using the 'get_creds' parameter. CDDL Definition of 'get_creds', Using an Example Node Identifier Encoded as bstr and Role as tstr 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]
• 'client_cred': encoded as a CBOR byte string, whose value is the original binary representation of the Client's authentication credential. This parameter MUST be present if the KDC is managing (collecting from and distributing to Clients) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. It is REQUIRED for application profiles to define the specific formats that are acceptable to use for authentication credentials in the group ( REQ6 ).
• 'cnonce': encoded as a CBOR byte string, whose value is a dedicated nonce N_C generated by the Client. This parameter MUST be present.
• 'client_cred_verify': encoded as a CBOR byte string. This parameter MUST be present if the 'client_cred' parameter is present and no authentication credential associated with the Client's access token can be retrieved for that group. The value of the CBOR byte string is the proof-of-possession (PoP) evidence computed by the Client over the following PoP input: the scope (encoded as a CBOR byte string) concatenated with N_S (encoded as a CBOR byte string) concatenated with N_C (encoded as a CBOR byte string), where:
  • scope is either specified in the 'scope' parameter above, if present, or a default scope entry that the handler is expected to know otherwise;
  • N_S is the challenge received from the KDC in the 'kdcchallenge' parameter of the 2.01 (Created) response to the Token Transfer Request (see ), encoded as a CBOR byte string; and
  • N_C is the nonce generated by the Client and specified in the 'cnonce' parameter above, encoded as a CBOR byte string.
  An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in . A possible type of PoP evidence is a signature that the Client computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'client_cred' parameter. Application profiles of this specification MUST specify the exact approaches used to compute the PoP evidence to include in 'client_cred_verify' and MUST specify which of those approaches is used in which case ( REQ14 ). If the access token was not provided to the KDC through a Token Transfer Request (e.g., the access token is instead transferred during the establishment of a secure communication association), it is REQUIRED of the specific application profile to define how the challenge N_S is generated ( REQ15 ).
• 'creds_repo': it can be present if the format of the Client's authentication credential conveyed in the 'client_cred' parameter is a certificate. In such a case, this parameter has as its value the URI of the certificate. This parameter is encoded as a CBOR text string. Alternative specific encodings of this parameter MAY be defined in application profiles of this specification ( OPT6 ).
• 'control_uri': its value is a full URI, encoded as a CBOR text string. A default url-path is /ace-group/GROUPNAME/node, although implementations can use different ones instead. The URI MUST NOT have url-path /ace-group/GROUPNAME. If 'control_uri' is specified in the Join Request, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDC MAY use this URI to send CoAP requests to the Client (acting as a CoAP server in this exchange), for example, for one-to-one provisioning of new group keying material when performing a group rekeying (see ) or to inform the Client of its removal from the group (see ). In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name is specified in the 'scope' parameter of the Join Request, if present therein. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications ( OPT7 ).

• If the access token was provided through a Token Transfer Request (see ) but the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see ), the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format "application/ace-groupcomm+cbor". The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value, which is specified in the 'kdcchallenge' parameter. The KDC MUST store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).
• The KDC checks the authentication credential to be valid for the group identified by GROUPNAME. That is, it checks that the authentication credential has the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication credential incompatible with the group configuration").
• The KDC verifies the PoP evidence conveyed in the 'client_cred_verify' parameter. Application profiles of this specification MUST specify the exact approaches used to verify the PoP evidence and MUST specify which of those approaches is used in which case ( REQ14 ). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid proof-of-possession evidence").

• The handler adds the Client to the list of current members of the group.
• The handler assigns a name NODENAME to the Client and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-group/GROUPNAME/nodes/NODENAME.
• The handler associates the node identifier NODENAME with the access token and the secure communication association for the Client.

• If the KDC manages the group members' authentication credentials:
  • The handler associates the retrieved Client's authentication credential with the tuple composed of the node name NODENAME, the group name GROUPNAME, and the access token.
  • The handler adds the retrieved Client's authentication credential to the list of authentication credentials stored for the group identified by GROUPNAME. If such a list already includes an authentication credential for the Client, but a different authentication credential is specified in the 'client_cred' parameter, then the handler MUST replace the old authentication credential in the list with the one specified in the 'client_cred' parameter.
• If backward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC MUST generate new group keying material and securely distribute it to the current group members (see ).
• The handler returns a successful Join Response, as defined below, which contains the symmetric group keying material, the group policies, and the authentication credentials of the current members of the group if the KDC manages those and the Client requested those.

• 'gkty': identifying the key type of the keying material specified in the 'key' parameter. This parameter is encoded as a CBOR integer or a CBOR text string. Possible values are taken from the "Key Type Value" column of the "ACE Groupcomm Key Types" registry defined in of this specification. Implementations MUST verify that the key type specified by this parameter matches the application profile being used and, if applicable, that such an application profile is listed in the "Profile" column of the "ACE Groupcomm Key Types" registry for the key type in question.
• 'key': containing the keying material used for securing the group communication or information required to derive such keying material.
• 'num': containing the current version number of the group keying material, encoded as a CBOR integer. The version number has a value that increases in a strictly monotonic way as the group keying material changes. The application profile MUST define the initial value of the version number ( REQ16 ).

• 'exp': its value specifies the expiration time of the group keying material specified in the 'key' parameter, encoded as a CBOR unsigned integer. The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in . After the time indicated in this parameter, group members MUST NOT use the group keying material specified in the 'key' parameter. The group members can retrieve the latest group keying material from the KDC.
• 'exi': its value specifies the residual lifetime of the group keying material, encoded as a CBOR unsigned integer. If the 'exp' parameter is included, this parameter MUST also be included. The value represents the residual lifetime of the group keying material specified in the 'key' parameter, i.e., it is the number of seconds between the current time at the KDC and the time when the keying material expires (as specified in the 'exp' parameter, if present). A Client determines the expiration time of the keying material by adding the seconds specified in the 'exi' parameter to its current time upon receiving the Join Response containing the 'exi' parameter. After such an expiration time, the Client MUST NOT use the group keying material specified in the 'key' parameter. The Client can retrieve the latest group keying material from the KDC.

• 'ace_groupcomm_profile': its value is encoded as a CBOR integer and MUST be used to uniquely identify the application profile for group communication. Applications of this specification MUST register an application profile identifier and the related value for this parameter in the "ACE Groupcomm Profiles" registry ( REQ19 ). ACE Groupcomm Profiles Name Description CBOR Value Reference Reserved This value is reserved 0 RFC 9594
• 'creds': it MUST be present if 'get_creds' was present in the Join Request; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array specifying the authentication credentials of the group members, i.e., of all of them or of the ones selected according to the 'get_creds' parameter in the Join Request. In particular, each element of the array is a CBOR byte string, whose value is the original binary representation of a group member's authentication credential. It is REQUIRED for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group ( REQ6 ).
• 'peer_roles': it SHOULD be present if 'creds' is also present; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (at most, the number of members in the group). The i-th element of the array specifies the role(s) that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, each array element is encoded like the role element of a scope entry, which is consistent with the used format (see ). This parameter MAY be omitted if the Client can rely on other means to unambiguously gain knowledge of the role of each group member whose associated authentication credential is specified in the 'creds' parameter. For example, all such group members may have the same role in the group joined by the Client, and such a role can be unambiguously assumed by the Client (e.g., based on what is defined in the used application profile of this specification). As another example, each of the authentication credentials specified in the 'creds' parameter can indicate the role(s) that the corresponding group member has in the group joined by the Client. When receiving the authentication credential of a Client in the 'client_cred' parameter of a Join Request (see ) or of an Authentication Credential Update Request (see ), the KDC is not expected to check that the authentication credential indicates the role(s) that the Client can have or has in the group in question. When preparing a Join Response, the KDC can decide whether to include the 'peer_roles' parameter, depending on the specific set of authentication credentials specified in the 'creds' parameter of that Join Response.
• 'peer_identifiers': it MUST be present if 'creds' is also present; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (at most, the number of members in the group). The i-th element of the array specifies the node identifier that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, the i-th array element is encoded as a CBOR byte string, whose value is the node identifier of the group member. The specific format of node identifiers of group members is specified by the application profile ( REQ25 ).
• 'group_policies': its value is encoded as a CBOR map, whose elements specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The possible elements of the CBOR map are registered in the "ACE Groupcomm Policies" registry defined in of this specification. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in . Application profiles of this specification MUST specify the format and default values for the entries of the CBOR map conveyed in the 'group_policies' parameter ( REQ20 ). ACE Groupcomm Policies Name CBOR Label CBOR Type Description Reference Sequence Number Synchronization Method 0 int or tstr Method for recipient group members to synchronize with sequence numbers of sender group members. Its value is taken from the "Value" column of the "Sequence Number Synchronization Method" registry. RFC 9594 Key Update Check Interval 1 int Polling interval in seconds, for group members to check at the KDC if the latest group keying material is the one that they store. RFC 9594 Expiration Delta 2 uint Number of seconds from 'exp' until a UTC date/time, after which group members MUST stop using the group keying material that they store to decrypt incoming messages. RFC 9594
• 'kdc_cred': its value is the original binary representation of the KDC's authentication credential, encoded as a CBOR byte string. This parameter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED for application profiles to define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter ( REQ8 ). If the KDC has an authentication credential as required for the correct group operation, the KDC's authentication credential MUST have the same format used for the authentication credentials of the group members. It is REQUIRED for application profiles to define the specific formats that are acceptable to use for the authentication credentials in the group ( REQ6 ).
• 'kdc_nonce': its value is a dedicated nonce N_KDC generated by the KDC, encoded as a CBOR byte string. This parameter MUST be present if the 'kdc_cred' parameter is present.
• 'kdc_cred_verify': its value is as defined below and is encoded as a CBOR byte string. This parameter MUST be present if the 'kdc_cred' parameter is present. The value of this parameter is the proof-of-possession (PoP) evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:
  • N_C is the nonce generated by the Client and specified in the 'cnonce' parameter of the Join Request.
  • N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.
  An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in . A possible type of PoP evidence is a signature that the KDC computes by using its own private key, whose corresponding public key is specified in the authentication credential conveyed in the 'kdc_cred' parameter. Application profiles of this specification MUST specify the approaches used by the KDC to compute the PoP evidence to include in 'kdc_cred_verify' and MUST specify which of those approaches is used in which case ( REQ21 ).
• 'rekeying_scheme': identifying the rekeying scheme that the KDC uses to provide new group keying material to the group members. The value of this parameter is encoded as a CBOR integer and is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in of this specification. ACE Groupcomm Rekeying Schemes Value Name Description Reference 0 Point-to-Point The KDC individually targets each node to rekey, using the pairwise secure communication association with that node RFC 9594 Application profiles of this specification MAY define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response ( OPT9 ).
• 'mgt_key_material': encoded as a CBOR byte string and containing the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This parameter MUST NOT be present if the 'rekeying_scheme' parameter is not present and the application profile does not specify a default group rekeying scheme to use in the group. Some simple rekeying schemes may not require specific administrative keying material to be provided, e.g., the basic "Point-to-Point" group rekeying scheme (see ). In more advanced group rekeying schemes, the administrative keying material can be composed of multiple keys organized, for instance, into a logical tree hierarchy, whose root key is the only administrative key shared by all the group members. In such a case, each group member is exclusively associated with one leaf key in the hierarchy and stores only the administrative keys from the associated leaf key all the way up along the path to the root key. That is, different group members can be provided with a different subset of the overall administrative keying material. It is expected from separate documents to define how the advanced group rekeying scheme, possibly indicated in the 'rekeying_scheme' parameter, is used by an application profile of this specification. This includes defining the format of the administrative keying material to specify in 'mgt_key_material' consistently with the group rekeying scheme and the application profile in question.
• 'control_group_uri': its value is a full URI, encoded as a CBOR text string. The URI MUST specify addressing information intended to reach all the members in the group. For example, this can be a multicast IP address, optionally together with a port number that, if omitted, defaults to 5683, i.e., the default port number for the "coap" URI scheme (see ). The URI MUST include GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, although implementations can use different ones instead. The URI MUST NOT have url-path /ace-group/GROUPNAME/nodes. If 'control_group_uri' is included in the Join Response, the Clients supporting this parameter act as CoAP servers, host a resource at this specific URI, and listen to the specified addressing information. The KDC MAY use this URI to send one-to-many CoAP requests to the Client group members (acting as CoAP servers in this exchange), for example, for one-to-many provisioning of new group keying material when performing a group rekeying (see ) or to inform the Clients of their removal from the group (see ). In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name was specified in the 'scope' parameter of the Join Request, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications ( OPT10 ).

• 'get_creds': its value is encoded as in , with the following modifications.
  • The arrays 'role_filter' and 'id_filter' MUST NOT both be empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_creds' parameter has such a format, the request MUST be considered malformed, and the KDC MUST reply with a 4.00 (Bad Request) error response. Note that a group member can retrieve the authentication credentials of all the current group members by sending a GET request to the same KDC resource instead (see ).
  • The element 'inclusion_flag' encodes the CBOR simple value true (0xf5) or false (0xf4), as defined in .
  • The array 'role_filter' can be empty if the Client does not wish to filter the requested authentication credentials based on the roles of the group members.
  • The array 'id_filter' contains zero or more node identifiers of group members for the group identified by GROUPNAME, as defined in . The array may be empty if the Client does not wish to filter the requested authentication credentials based on the node identifiers of the group members.

• If the 'inclusion_flag' encodes the CBOR simple value true (0xf5), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and/or have their node identifier specified in 'id_filter'.
• If the 'inclusion_flag' encodes the CBOR simple value false (0xf4), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and, at the same time, do not have their node identifier specified in 'id_filter'.

• The role identifier matches with one of those indicated in the request; note that the request can specify a combination of roles, in which case the handler selects only the group members that have all the roles included in the combination.
• The node identifier matches with one of those indicated in the request or does not match with any of those, which is consistent with the value of the element 'inclusion_flag'.

• 'num': encoding the version number of the current group keying material.
• 'creds': encoding the list of authentication credentials of the selected group members.
• 'peer_roles': encoding the role(s) that each of the selected group members has in the group. This parameter SHOULD be present, and it MAY be omitted according to the same criteria defined for the Join Response (see ).
• 'peer_identifiers': encoding the node identifier that each of the selected group members has in the group.

• The KDC silently ignores those node identifiers.
• The KDC retains authentication credentials of group members for a given amount of time after their leaving before discarding them. As long as such authentication credentials are retained, the KDC provides them to a requesting Client. If the KDC adopts this policy, the application profile MUST also specify the amount of time during which the KDC retains the authentication credential of a former group member after its leaving, possibly on a per-member basis.

• 'kdc_cred: specifying the KDC's authentication credential. This parameter is encoded like the 'kdc_cred' parameter in the Join Response (see ).
• 'kdc_nonce': specifying a nonce generated by the KDC. This parameter is encoded like the 'kdc_nonce' parameter in the Join Response (see ).
• 'kdc_cred_verify': specifying the PoP evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:
  • N_C is the nonce generated by the Client group member such that: i) the nonce was specified in the 'cnonce' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; and ii) the KDC stored the nonce as a 'clientchallenge' value associated with the Client after sending the corresponding Join Response (see ).
  • N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.
  An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in . The PoP evidence is computed by means of the same method used for computing the PoP evidence that was included in the Join Response for this Client (see ). Application profiles of this specification MUST specify the exact approaches used by the KDC to compute the PoP evidence to include in the 'kdc_cred_verify' parameter and MUST specify which of those approaches is used in which case ( REQ21 ). If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profile MUST specify how external signature verifiers provide the KDC with a self-generated nonce to use as N_C ( REQ21 ).

• 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 "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
• The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.

• Upon expiration of the keying material, according to what is indicated by the KDC through the 'exp' and/or 'exi' parameter (e.g., in a Join 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.

• Not providing the Client with newly generated individual keying material, but rather rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.
• Both providing the Client with newly generated individual keying material, as well as rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.

• The handler associates the authentication credential from the 'client_cred' parameter of the request with the node identifier NODENAME, as well as with the access token associated with the node identified by NODENAME.
• In the stored list of group members' authentication credentials for the group identified by GROUPNAME, the handler replaces the authentication credential of the node identified by NODENAME with the authentication credential specified in the 'client_cred' parameter of the request.

1. The Client explicitly asks to leave the group, as defined in .
2. The node has been found compromised or is suspected so. The KDC is expected to determine that a group member has to be evicted either through its own means or based on information that it obtains from a trusted source (e.g., an Intrusion Detection System or an issuer of authentication credentials). Additional mechanics, protocols, and interfaces at the KDC that can support this are out of the scope of this document.
3. The Client's authorization to be a group member with the current roles is not valid anymore, i.e., the access token has expired or has been revoked. If the AS provides token introspection (see ), the KDC can optionally use it and check whether the Client is still authorized.

• The KDC removes the Client from the list of current members of the group. When doing so, the KDC deletes the currently stored value of 'clientchallenge' for that Client, which was specified in the latest Join Request that the Client sent to the KDC in order to join the group (see ).
• In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client if it acts as a repository of authentication credentials for group members.
• If the removed Client is registered as an observer of the group-membership resource at /ace-group/GROUPNAME, the KDC removes the Client from the list of observers of that resource.
• If the sub-resource /nodes/NODENAME was created for the removed Client, the KDC deletes that sub-resource. In case of forced eviction, i.e., for cases 2 and 3 above, the KDC MAY explicitly inform the removed Client by means of the following methods.
  • If the evicted Client implements the 'control_uri' resource (see ), the KDC sends a DELETE request to that resource, targeting the URI specified in the 'control_uri' parameter of the Join Request (see ).
  • If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see ), the KDC sends an unsolicited 4.04 (Not Found) error response, which does not include the Observe Option and indicates that the observed resource has been deleted (see ). The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 5 ("Group membership terminated").
• If forward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC MUST generate new group keying material and securely distribute it to all the current group members except the leaving node (see ).

• The KDC SHOULD make the /ace-group/GROUPNAME resource observable . Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource. In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member as a notification of group termination. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 6 ("Group deleted").
• If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see ), 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 specify a URI in the 'control_uri' parameter of the Join Request upon joining the group.

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

Over multicast -

In this case, the KDC simply sends a rekeying message as a CoAP request addressed to the URI specified in the 'control_group_uri' parameter of the Join Response (see ). If a particular rekeying message is intended for a single target group member, the KDC may alternatively protect the message using the secure communication association with that group member and deliver the message like when using the "Point-to-Point" group rekeying scheme (see ).

Through a pub-sub communication model -

In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a Broker server. Following their group joining, the group members subscribe to the rekeying topic at the Broker, thus receiving the group rekeying messages as they are published by the KDC. In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeying process as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy). The setup of rekeying topics at the Broker as well as the discovery of the topics at the Broker for group members are application specific. A possible way is for the KDC to provide such information in the Join Response message (see ) 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.

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

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

• The encryption algorithm SHOULD be the same one used to protect communications in the group.
• The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.
• A Base IV is also included with the same size of the AEAD nonce considered by the encryption algorithm to use.

• The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.
• The plaintext is the actual data content of the current rekeying message.
• The Additional Authenticated Data (AAD) is empty unless otherwise specified by separate documents profiling the use of the group rekeying scheme.
• Since the KDC is the only sender of rekeying messages, the AEAD nonce can be computed as follows, where NONCE_SIZE is the size in bytes of the AEAD nonce. Separate documents profiling the use of the group rekeying scheme may define alternative ways to compute the AEAD nonce. The KDC considers the following values.
  • COUNT: as a 2-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeying instance and is incremented after each use of the encryption key.
  • NEW_NUM: as the version number of the new group keying material to distribute in this rekeying instance, left-padded with zeros to exactly NONCE_SIZE - 2 bytes.
  Then, the KDC computes a Partial IV as the byte string concatenation of COUNT and NEW_NUM in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV. In order to comply with the security requirements of AEAD encryption algorithms, the KDC MUST NOT reuse the same pair (AEAD encryption key, AEAD nonce). For example, this includes not using the same encryption key from the administrative keying material more than 2 ¹⁶ times during the same rekeying instance.
• The protected header of the COSE_Encrypt0 object MUST include the following parameters.
  • 'alg': specifying the used encryption algorithm.
  • 'kid': specifying the identifier of the encryption key from the administrative keying material used to protect the current rekeying message.
• The unprotected header of the COSE_Encrypt0 object MUST include the 'Partial IV' parameter with the value of the Partial IV computed above.

• The Countersign_structure contains the context text string "CounterSignature0".
• The private key of the KDC is used as the signing key.
• The payload is the ciphertext of the COSE_Encrypt0 object.
• The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.
• The protected header of the signing object MUST include the parameter 'alg', which specifies the used signature algorithm.

• 'scope'
• 'cnonce'
• 'gkty'
• 'key'
• 'num'
• 'exp'
• 'exi'
• 'gid'
• 'gname'
• 'guri'
• 'creds'
• 'peer_identifiers'
• 'ace_groupcomm_profile'
• 'control_uri'
• 'rekeying_scheme'

• 'get_creds': That is, not supporting this parameter would yield the inconvenient and undesirable behavior where: i) the Client does not ask for the other group members' authentication credentials upon joining the group (see ); and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see ).

• 'client_cred' and 'client_cred_verify': These parameters are relevant for a Client that has an authentication credential to use in a joined group.
• 'kdcchallenge': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that provides the access token to the KDC through a Token Transfer Request (see ).
• 'creds_repo': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that makes it available from a key repository different than the KDC.
• 'group_policies': This parameter is relevant for a Client that is interested in the specific policies used in a group, but it does not know them or cannot become aware of them before joining that group.
• 'peer_roles': This parameter is relevant for a Client that has to know about the roles of other group members, especially when retrieving and handling their corresponding authentication credentials.
• 'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify': These parameters are relevant for a Client that joins a group for which, as per the used application profile of this specification, the KDC has an associated authentication credential and this is required for the correct group operation.
• 'mgt_key_material': This parameter is relevant for a Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent over IP multicast.
• 'control_group_uri': This parameter is relevant for a Client that also acts as a CoAP server supporting: i) the hosting of a dedicated resource for each group that the Client is interested to be a part of; and ii) the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast), as targeting multiple members of the corresponding group. Examples of related management operations that the KDC can perform by this means are the eviction of group members and the execution of a group rekeying process through an advanced rekeying scheme, such as based on one-to-many rekeying messages.

• In case of error 0, the Client should stop sending the request in question to the KDC. Rather, the Client should first join the targeted group. If it has not happened already, this first requires the Client to obtain an appropriate access token authorizing access to the group and provide it to the KDC.
• In case of error 1, the Client as a group member should rejoin the group with all the roles needed to perform the operation in question. This might require the Client to first obtain a new access token and provide it to the KDC, if the current access token does not authorize the Client to take those roles in the group. For operations admitted to a Client that is not a group member (e.g., an external signature verifier), the Client should first obtain a new access token authorizing to also have the missing roles.
• In case of error 2, the Client has to obtain or self-generate a different asymmetric key pair, as aligned to the public key algorithm and parameters used in the targeted group. After that, the Client should provide the KDC with its new authentication credential, which is consistent with the format used in the targeted group and including the new public key.
• In case of error 3, the Client should ensure to compute its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. In an unattended setup, it might not be possible for a Client to autonomously diagnose the error and take an effective next action to address it.
• In case of error 4, the Client should wait for a certain (pre-configured) amount of time before trying to resend its request to the KDC.
• In case of error 5, the Client may try joining the group again. This might require the Client to first obtain a new access token and provide it to the KDC, e.g., if the current access token has expired.
• In case of error 6, the Client should clean up its state regarding the group, just like if it has left the group with no intention to rejoin it.

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

• 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 impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.

Type name:

application

Subtype name:

ace-groupcomm+cbor

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

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

Security considerations:

See of RFC 9594.

Interoperability considerations:

N/A

Published specification:

RFC 9594

Applications that use this media type:

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

Fragment identifier considerations:

N/A

Additional information:

N/A

Person & email address to contact for further information:

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

Intended usage:

COMMON

Restrictions on usage:

None

Author/Change controller:

IETF

Provisional registration:

No

Content Type:

application/ace-groupcomm+cbor

Content Coding:

-

ID:

261

Reference:

RFC 9594

Name:

sign_info

Parameter Usage Location:

client-rs request, rs-client response

Change Controller:

IETF

Reference:

RFC 9594

Name:

kdcchallenge

Parameter Usage Location:

rs-client response

Change Controller:

IETF

Reference:

RFC 9594

Name:

sign_info

CBOR Key:

45

Value Type:

Null or array

Reference:

RFC 9594

Name:

kdcchallenge

CBOR Key:

46

Value Type:

byte string

Reference:

RFC 9594

Value:

ace.groups

Description:

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

Reference:

of RFC 9594

Value:

ace.group

Description:

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

Reference:

of RFC 9594

Key Value:

0

Name:

ace-groupcomm-error

Brief Description:

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

Change Controller:

IETF

Reference:

RFC 9594,

Name:

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

CBOR Key:

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

CBOR Type:

This field 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 field contains a pointer to the public specification for the item.

Name:

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

Key Type Value:

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

Profile:

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

Description:

This field contains a brief description of the keying material.

Reference:

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

Name:

The name of the application profile.

Description:

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

CBOR Value:

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

Reference:

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

Name:

The name of the group communication policy.

CBOR Label:

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

CBOR Type:

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

Description:

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

Reference:

This field contains a pointer to the public specification for this group communication policy and its format, if one exists.

Name:

The name of the sequence number synchronization method.

Value:

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

Description:

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

Reference:

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

Value:

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

Description:

This field contains a brief description of the error.

Reference:

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

Value:

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

Name:

The name of the group rekeying scheme.

Description:

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

Reference:

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

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
• Specifications are required for the Standards Track range of point assignment. Specifications should exist for Specification Required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
• Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of the device it will be used on, and the number of code points left that encode to that size.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4