Draft: draft-ietf-ace-key-groupcomm-oscore

Commentary: Also integrating the section / content restructuring proposed in
This document defines an application profile of the ACE framework for
Authentication and Authorization, to request and provision keying
material in group communication scenarios that are based on CoAP and
secured with Group Object Security for Constrained RESTful
Environments (OSCORE).  This application profile delegates the
authentication and authorization of Clients that join an OSCORE group
through a Resource Server acting as Group Manager for that group.
This application profile leverages protocol-specific transport
profiles of ACE to achieve communication security, server
authentication and proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 Access Token.
This document defines an application profile of the ACE framework for
Authentication and Authorization, to request and provision keying
material in group communication scenarios that are based on CoAP and
are secured with Group Object Security for Constrained RESTful
Environments (Group OSCORE).  This application profile delegates the
authentication and authorization of Clients, that join an OSCORE
group through a Resource Server acting as Group Manager for that
group.  This application profile leverages protocol-specific
transport profiles of ACE to achieve communication security, server
authentication and proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 Access Token.
As described in I-D.ietf-core-oscore-groupcomm, Group OSCORE is used
to protect CoAP group communication over IP multicast I-D.ietf-core-
groupcomm-bis.  This relies on a Group Manager, which is responsible
for managing an OSCORE group and enables the group members to
exchange CoAP messages secured with Group OSCORE.  The Group Manager
can be responsible for multiple groups, coordinates the joining
process of new group members, and is entrusted with the distribution
and renewal of group keying material.
As described in I-D.ietf-core-oscore-groupcomm, Group OSCORE is used
to protect CoAP group communication I-D.ietf-core-groupcomm-bis,
which can employ, for example, IP multicast as underlying data
transport.  This relies on a Group Manager, which is responsible for
managing an OSCORE group and enables the group members to exchange
CoAP messages secured with Group OSCORE.  The Group Manager can be
responsible for multiple groups, coordinates the joining process of
new group members, and is entrusted with the distribution and renewal
of group keying material.
This document is an application profile of I-D.ietf-ace-key-
groupcomm, which itself builds on the ACE framework for
Authentication and Authorization I-D.ietf-ace-oauth-authz.  Message
exchanges among the participants as well as message formats and
processing follow what specified in I-D.ietf-ace-key-groupcomm for
provisioning and renewing keying material in group communication
scenarios, where Group OSCORE is used to protect CoAP group
communication over IP multicast.
This document is an application profile of I-D.ietf-ace-key-
groupcomm, which itself builds on the ACE framework for
Authentication and Authorization I-D.ietf-ace-oauth-authz.  Message
exchanges among the participants as well as message formats and
processing follow what specified in I-D.ietf-ace-key-groupcomm for
provisioning and renewing keying material in group communication
scenarios, where Group OSCORE is used to protect CoAP group
communication.
Group communication for CoAP over IP multicast has been enabled in I-
D.ietf-core-groupcomm-bis and can be secured with Group Object
Security for Constrained RESTful Environments (OSCORE) RFC8613 as
described in I-D.ietf-core-oscore-groupcomm.  A network node joins an
OSCORE group by interacting with the responsible Group Manager.  Once
registered in the group, the new node can securely exchange messages
with other group members.
This document describes how to use I-D.ietf-ace-key-groupcomm and I-
D.ietf-ace-oauth-authz to perform a number of authentication,
authorization and key distribution actions, as overviewed in
Section 2 of I-D.ietf-ace-key-groupcomm, when the considered group is
specifically an OSCORE group.
Group communication for CoAP has been enabled in I-D.ietf-core-
groupcomm-bis and can be secured with Group Object Security for
Constrained RESTful Environments (Group OSCORE) as specified in I-
D.ietf-core-oscore-groupcomm.  A network node joins an OSCORE group
by interacting with the responsible Group Manager.  Once registered
in the group, the new node can securely exchange messages with other
group members.
This document describes how to use I-D.ietf-ace-key-groupcomm and I-
D.ietf-ace-oauth-authz to perform a number of authentication,
authorization and key distribution actions as overviewed in Section 2
of I-D.ietf-ace-key-groupcomm, when the considered group is
specifically an OSCORE group.
A node performs the steps described in Sections 3 and 4.3.1.1 of I-
D.ietf-ace-key-groupcomm in order to obtain an authorization for
joining an OSCORE group and then to join that group.  The format and
processing of messages exchanged during such steps are further
specified in sec-joining-node-to-AS and sec-joining-node-to-GM of
this document.
profile-req lists the specifications on this application profile of
ACE, based on the requirements defined in Appendix A of I-D.ietf-ace-
key-groupcomm.
A node performs the steps described in Section 4.3.1.1 of I-D.ietf-
ace-key-groupcomm in order to join an OSCORE group.  The format and
processing of messages exchanged among the participants are further
specified in sec-joining-node-to-AS and sec-joining-node-to-GM of
this document.
A set of stale Sender IDs, which allows each rekeyed node to purge
authentication credentials and Recipient Contexts used in the
group and associated with those Sender IDs.  This in turn allows
every group member to rely on stored authentication credentials to
confidently assert the group membership of other sender nodes,
when receiving protected messages in the group (see Section 3.2 of
I-D.ietf-core-oscore-groupcomm).  More details on the maintenance
of stale Sender IDs are provided in sssec-stale-sender-ids.
The Group Manager MUST rekeying the group in the following cases.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-dependent rekeying period or scheduling.
The N-th set includes the Sender IDs that have become "stale" under
the current version V of the group keying material.  The (N-1)-th set
refers to the immediately previous version (V - 1) of the group
keying material, and so on.
Building on Section 3.1 of I-D.ietf-ace-key-groupcomm, this section
defines the exact format and encoding of scope to use.
To this end, this profile uses the Authorization Information Format
(AIF) I-D.ietf-ace-aif, and defines the following AIF specific data
model AIF-OSCORE-GROUPCOMM.
the set of N numbers is converted into the single value R, by
taking each numeric identifier X_1, X_2, ..., X_N to the power
of two, and then computing the inclusive OR of the binary
representations of all the power values.
Future specifications that define new roles MUST register a
corresponding numeric identifier in the "Group OSCORE Roles" registry
defined in ssec-iana-group-oscore-roles-registry of this document.
This section describes how the joining node interacts with the AS in
order to be authorized to join an OSCORE group under a given Group
Manager.  In particular, it considers a joining node that intends to
contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined
in Sections 3.1 and 3.2 of I-D.ietf-ace-key-groupcomm.  Note that
what is defined in I-D.ietf-ace-key-groupcomm applies, and only
additions or modifications to that specification are defined here.
The interface provided by the Group Manager extends the original
interface defined in Section 4.1 of I-D.ietf-ace-key-groupcomm for
the KDC, as specified in sec-interface-GM of this document.
In addition to those defined in Section 8 of I-D.ietf-ace-key-
groupcomm, additional parameters are defined in this document and
summarized in ace-groupcomm-params.
In addition to those defined in Section 9 of I-D.ietf-ace-key-
groupcomm, additional error identifiers are defined in this
document and summarized in error-types.
Finally, profile-req lists the specifications on this application
profile of ACE, based on the requirements defined in Appendix A of I-
D.ietf-ace-key-groupcomm.
Building on Section 3.1 of I-D.ietf-ace-key-groupcomm, this section
defines the exact format and encoding of scope used in this profile.
Furthermore, this document defines the new AIF specific data model
AIF-OSCORE-GROUPCOMM, that this profile MUST use to format and encode
scope entries.
In particular, the following holds for each scope entry.
The object identifier ("Toid") is specialized as a CBOR item
specifying the name of the groups pertaining to the scope entry.
The permission set ("Tperm") is specialized as a CBOR unsigned
integer with value R, specifying the permissions that the Client
wishes to have in the groups indicated by "Toid".
More specifically, the following applies when, as defined in this
document, a scope entry includes as set of permissions the set of
roles to take in an OSCORE group.
The object identifier ("Toid") is a CBOR text string, specifying
the group name for the scope entry.
The permission set ("Tperm") is a CBOR unsigned integer with value
R, specifying the role(s) that the Client wishes to take in the
group (REQ1).  The value R is computed as follows.
The set of N numbers is converted into the single value R, by
taking two to the power of each numeric identifier X_1, X_2,
..., X_N, and then computing the inclusive OR of the binary
representations of all the power values.
The following CDDL RFC8610 notation defines a scope entry that uses
the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group
OSCORE roles from those in fig-role-values.
Future specifications that define new Group OSCORE roles MUST
register a corresponding numeric identifier in the "Group OSCORE
Roles" registry defined in ssec-iana-group-oscore-roles-registry of
this document.
Note that the value 0 is not available to use as numeric identifier
to specify a Group OSCORE role.  It follows that, when expressing
Group OSCORE roles to take in a group as per this document, a scope
entry has the least significant bit of "Tperm" always set to 0.
This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model.
That is, for each scope entry, the least significant bit of "Tperm"
set to 0 explicitly identifies the scope entry as exactly expressing
a set of Group OSCORE roles ("Tperm"), pertaining to a single group
whose name is specified by the string literal in "Toid".
Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model, I-
D.ietf-ace-oscore-gm-admin defines the format of scope entries for
Administrator Clients that wish to access an admin interface at the
Group Manager.  In such scope entries, the least significant bit of
"Tperm" is always set to 1.
The joining node is going to join the group exclusively as
monitor, i.e., it is not going to send messages to the group.  In
this case, the joining node is not required to provide its own
authentication credential to the Group Manager, which thus does
not have to perform any check related to the format of the
authentication credential, to a signature or ECDH algorithm, and
to possible parameters associated with the algorithm and the
public key.  In case the joining node still provides an
authentication credential in the 'client_cred' parameter of the
Joining Request (see ssec-join-req-sending), the Group Manager
silently ignores that parameter, as well as the related parameters
'cnonce' and 'client_cred_verify'.
The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication association.
In this case, upon performing a joining process with that Group
Manager for the first time, the joining node specifies its own
authentication credential in the 'client_cred' parameter of the
Joining Request (see ssec-join-req-sending).
This section builds on Section 3 of I-D.ietf-ace-key-groupcomm and is
organized as follows.
First, ssec-auth-req and ssec-auth-resp describe how the joining node
interacts with the AS, in order to be authorized to join an OSCORE
group under a given Group Manager and to obtain an Access Token.
Then, ssec-token-post describes how the joining node transfers the
obtained Access Token to the Group Manager.  The following considers
a joining node that intends to contact the Group Manager for the
first time.
Note that what is defined in Section 3 of I-D.ietf-ace-key-groupcomm
applies, and only additions or modifications to that specification
are defined in this document.
The set of requested roles is expressed as a single CBOR
unsigned integer.  This is computed as defined in sec-
format-scope, from the numerical abbreviations of each
requested role defined in the "Group OSCORE Roles" registry,
for which this document defines the entry in fig-role-values
(REQ1).
The set of requested roles is expressed as a single CBOR
unsigned integer.  This is computed as defined in sec-
format-scope, from the numerical abbreviations of each
requested role defined in the "Group OSCORE Roles" registry,
for which this document defines the entries in fig-role-
values (REQ1).
The AS MUST include the 'scope' parameter, when the value included
in the Access Token differs from the one specified by the joining
node in the request.  In such a case, the second element of each
scope entry MUST be present, and specifies the set of roles that
the joining node is actually authorized to take in the OSCORE
group for that scope entry, encoded as specified in ssec-auth-req.
The AS MUST include the 'scope' parameter, when the value included
in the Access Token differs from the one specified by the joining
node in the Authorization Request.  In such a case, the second
element of each scope entry MUST be present, and specifies the set
of roles that the joining node is actually authorized to take in
the OSCORE group for that scope entry, encoded as specified in
ssec-auth-req.
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allows also a signature
verifier to verify signatures of messages protected with the group
mode and sent to the group (see Sections 3.1 and 8.5 of I-D.ietf-
core-oscore-groupcomm).  The response MUST have Content-Format set to
application/ace-groupcomm+cbor.  The payload of the response is a
CBOR map, which is formatted as defined in sec-verif-data.
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allows the requesting client
to delete the Recipient Contexts and authentication credentials
associated with former members of the group (see Section 3.2 of I-
D.ietf-core-oscore-groupcomm.  The payload of the response is
formatted as defined in sec-retrieve-stale-sids.
Building on what is defined in Section 4.1.1 of I-D.ietf-ace-key-
groupcomm, and with reference to the resources at the Group Manager
newly defined earlier in sec-interface-GM of this document, it is
expected that a Client minimally supports also the following set of
operations and corresponding interactions with the Group (REQ12).
GET request to ace-group/GROUPNAME/active , in order to check the
current status of the group.
GET request to ace-group/GROUPNAME/verif-data , in order for a
signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 3.1 and 8.5 of I-D.ietf-core-oscore-
groupcomm).  Note that this operation is relevant to support only
to signature verifiers.
FETCH request to ace-group/GROUPNAME/stale-sids , in order to
retrieve from the Group Manager the data required to delete some
of the stored group members' authentication credentials and
Recipient Contexts (see stale-sids-fetch).  This data is provided
as an aggregated set of stale Sender IDs, which are used as
specified in missed-rekeying.
The rest of this section describes the interactions between the
joining node and the Group Manager, i.e., the transferring of the
Access Token to the Group Manager and the Request-Response exchange
to join the OSCORE group.  The message exchange between the joining
node and the Group Manager consists of the messages defined in
Sections 3.3 and 4.3.1.1 of I-D.ietf-ace-key-groupcomm.  Note that
what is defined in I-D.ietf-ace-key-groupcomm applies, and only
additions or modifications to that specification are defined here.
Just like any candidate group member, a signature verifier provides
the Group Manager with an Access Token, as described in ssec-token-
post.  However, unlike candidate group members, it does not join any
OSCORE group, i.e., it does not perform the joining process defined
in ssec-join-req-sending.
Consistently, in case a node is non-member of the group with group
name GROUPNAME and is authorized to be only signature verifier for
that group, the Group Manager MUST reply with a 4.03 (Forbidden)
error response if that node attempts to access any other endpoint
than: /ace-group/GROUPNAME/pub-key; ace-group/GROUPNAME/gm-pub-key;
ace-group/GROUPNAME/verif-data; and /ace-group.
The exchange of Token Transfer Request and Response is defined in
Section 3.3 of I-D.ietf-ace-key-groupcomm.  In addition to that, the
following applies.
'ecdh_info' defined in ecdh-info of this document, with value
the CBOR simple value "null" (0xf6) to request information
about the ECDH algorithm, the ECDH algorithm parameters, the
ECDH key parameters and about the exact format of
authentication credentials used in the groups that the client
has been authorized to join.  This is relevant in case the
joining node supports the pairwise mode of Group OSCORE I-
D.ietf-core-oscore-groupcomm.
The exchange of Token Transfer Request and Token Transfer Response is
defined in Section 3.3 of I-D.ietf-ace-key-groupcomm.  In addition to
that, the following applies.
'ecdh_info' defined in ecdh-info of this document, with value
the CBOR simple value "null" (0xf6) to request information
about the ECDH algorithm, the ECDH algorithm parameters, the
ECDH key parameters and the exact format of authentication
credentials used in the groups that the Client has been
authorized to join.  This is relevant in case the joining node
supports the pairwise mode of Group OSCORE I-D.ietf-core-
oscore-groupcomm.
The 'kdcchallenge' parameter MAY be omitted from the Token
Transfer Response, if the 'scope' of the Access Token specifies
only the role "monitor" or only the role "verifier" or only a
combination of the two, for each and every of the specified
groups.
The 'kdcchallenge' parameter MAY be omitted from the Token
Transfer Response, if the 'scope' of the Access Token specifies
only the role "monitor" or only the role "verifier" or only the
two roles combined, for each and every of the specified groups.
The fifth element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group
identified by 'gname'.  It takes value from the "Label" column of
the "COSE Header Parameters" registry COSE.Header.Parameters
(REQ6).  Acceptable values denote a format that MUST provide the
public key as well as the comprehensive set of information related
to the public key algorithm, including, e.g., the used elliptic
curve (when applicable).  The same considerations and guidelines
for the 'pub_key_enc' element of 'sign_info' (see ssec-token-post)
apply.
The fifth element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group
identified by 'gname'.  It takes value from the "Label" column of
the "COSE Header Parameters" registry COSE.Header.Parameters
(REQ6).  Acceptable values denote a format that MUST provide the
public key as well as the comprehensive set of information related
to the public key algorithm, including, e.g., the used elliptic
curve (when applicable).  The same considerations and guidelines
for the 'pub_key_enc' element of 'sign_info' apply (see ssec-
token-post).
The second element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group
identified by 'gname'.  It takes value from the "Label" column of
the "COSE Header Parameters" registry COSE.Header.Parameters
(REQ6).  Acceptable values denote a format that MUST explicitly
provide the public key as well as comprehensive set of information
related to the public key algorithm, including, e.g., the used
elliptic curve (when applicable).  The same considerations and
guidelines for the 'pub_key_enc' element of 'sign_info' (see ssec-
token-post) apply.
The second element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group
identified by 'gname'.  It takes value from the "Label" column of
the "COSE Header Parameters" registry COSE.Header.Parameters
(REQ6).  Acceptable values denote a format that MUST explicitly
provide the public key as well as comprehensive set of information
related to the public key algorithm, including, e.g., the used
elliptic curve (when applicable).  The same considerations and
guidelines for the 'pub_key_enc' element of 'sign_info' apply (see
ssec-token-post).
The joining node requests to join the OSCORE group by sending a
Joining Request message to the related group-membership resource at
the Group Manager, as per Section 4.3.1.1 of I-D.ietf-ace-key-
groupcomm.
Additionally to what defined in Section 4.3.1 of I-D.ietf-ace-key-
groupcomm, the following applies.
This section describes the interactions between the joining node and
the Group Manager to join an OSCORE group.  The message exchange
between the joining node and the Group Manager consists of the
messages defined in Section 4.3.1.1 of I-D.ietf-ace-key-groupcomm.
Note that what is defined in I-D.ietf-ace-key-groupcomm applies, and
only additions or modifications to that specification are defined in
this document.
The joining node requests to join the OSCORE group by sending a
Joining Request message to the related group-membership resource at
the Group Manager, as per Section 4.3.1.1 of I-D.ietf-ace-key-
groupcomm.  Additionally to what is defined in Section 4.3.1 of I-
D.ietf-ace-key-groupcomm, the following applies.
If the provisioning of the Access Token to the Group Manager has
relied on the DTLS profile of ACE I-D.ietf-ace-dtls-authorize with
the Access Token as content of the "psk_identity" field of the
ClientKeyExchange message RFC6347, N_S is an exporter value
computed as defined in Section 7.5 of RFC8446.  Specifically, N_S
is exported from the DTLS session between the joining node and the
Group Manager, using an empty 'context_value', 32 bytes as
'key_length', and the exporter label "EXPORTER-ACE-Sign-Challenge-
coap-group-oscore-app" defined in ssec-iana-tls-esporter-label-
registry of this document.
If the provisioning of the Access Token to the Group Manager has
relied on the DTLS profile of ACE I-D.ietf-ace-dtls-authorize with
the Access Token as content of the "psk_identity" field of the
ClientKeyExchange message RFC6347, then N_S is an exporter value
computed as defined in Section 7.5 of RFC8446.  Specifically, N_S
is exported from the DTLS session between the joining node and the
Group Manager, using an empty 'context_value', 32 bytes as
'key_length', and the exporter label "EXPORTER-ACE-Sign-Challenge-
coap-group-oscore-app" defined in ssec-iana-tls-esporter-label-
registry of this document.
The Group Manager MUST return a 5.03 (Service Unavailable)
response in case the OSCORE group that the joining node has been
trying to join is currently inactive (see ssec-resource-active).
The response MUST have Content-Format set to application/ace-
groupcomm+cbor and is formatted as defined in Section 4.1.2 of I-
D.ietf-ace-key-groupcomm.  The value of the 'error' field MUST be
set to 9 ("Group currently not active").
In case the joining node is not going to join the group
exclusively as monitor, the Group Manager MUST return a 5.03
(Service Unavailable) response if there are currently no OSCORE
Sender IDs available to assign in the OSCORE group.  The response
MUST have Content-Format set to application/ace-groupcomm+cbor and
is formatted as defined in Section 4.1.2 of I-D.ietf-ace-key-
groupcomm.  The value of the 'error' field MUST be set to 4 ("No
available node identifiers").
In case the joining node is not going to join the group
exclusively as monitor and the Joining Request does not include
the 'client_cred' parameter, the joining process fails if the
Group Manager either: i) does not store an authentication
credential with an accepted format for the joining node; or ii)
stores multiple authentication credentials with an accepted format
for the joining node.
In order to verify the PoP evidence contained in
'client_cred_verify', the Group Manager proceeds as follows.
As public key of the joining node, the Group Manager uses
either the one included in the authentication credential
retrieved from the 'client_cred' parameter of the Joining
Request, or the one from the already stored authentication
credential as acquired from previous interactions with the
joining node.
The Group Manager verifies the PoP evidence as defined below.
If the group is not a pairwise-only group, the PoP evidence
is a signature.  The Group Manager verifies it by using the
public key of the joining node, as well as the signature
algorithm used in the OSCORE group and possible
corresponding parameters.
If the group is a pairwise-only group, the PoP evidence is a
MAC.  The Group Manager recomputes the MAC through the same
process taken by the joining node when preparing the value
of the 'client_cred_verify' parameter for the Joining
Request (see ssec-join-req-sending), with the difference
that the Group Manager uses its own Diffie-Hellman private
key and the Diffie-Hellman public key of the joining node.
The verification succeeds if and only if the recomputed MAC
is equal to the MAC conveyed as PoP evidence in the Joining
Request.
A 4.00 (Bad Request) error response from the Group Manager to the
joining node MUST have content format application/ace-
groupcomm+cbor.  The response payload is a CBOR map formatted as
follows.
If the group uses (also) the group mode of Group OSCORE, the
CBOR map MUST contain the 'sign_info' parameter, whose CBOR
label is defined in Section 8 of I-D.ietf-ace-key-groupcomm.
This parameter has the same format of 'sign_info_res' defined
in Section 3.3.1 of I-D.ietf-ace-key-groupcomm.  In particular,
it includes a single element 'sign_info_entry' pertaining to
the OSCORE group that the joining node has tried to join with
the Joining Request.
If the group uses (also) the pairwise mode of Group OSCORE, the
CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR
label is defined in ssec-iana-ace-groupcomm-parameters-
registry.  This parameter has the same format of
'ecdh_info_res' defined in ecdh-info.  In particular, it
includes a single element 'ecdh_info_entry' pertaining to the
OSCORE group that the joining node has tried to join with the
Joining Request.
If the group is a pairwise-only group, the CBOR map MUST
contain the 'kdc_dh_creds' parameter, whose CBOR label is
defined in ssec-iana-ace-groupcomm-parameters-registry.  This
parameter has the same format of 'kdc_dh_creds_res' defined in
gm-dh-info.  In particular, it includes a single element
'kdc_dh_creds_entry' pertaining to the OSCORE group that the
joining node has tried to join with the Joining Request.
The CBOR map MAY include the 'kdcchallenge' parameter, whose
CBOR label is defined in Section 8 of I-D.ietf-ace-key-
groupcomm.  If present, this parameter is a CBOR byte string,
which encodes a newly generated 'kdcchallenge' value that the
Client can use when preparing a Joining Request (see ssec-join-
req-sending).  In such a case the Group Manager MUST store the
newly generated value as the 'kdcchallenge' value associated
with the joining node, possibly replacing the currently stored
value.
The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case the 'scope' parameter is not present in the
Joining Request, or if it is present and specifies any set of
roles not included in the following list: "requester",
"responder", "monitor", ("requester", "responder").  Future
specifications that define a new role MUST define possible sets of
roles including the new one and existing ones, that are acceptable
to specify in the 'scope' parameter of a Joining Request.
The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case the Joining Request includes the 'client_cred'
parameter but does not include both the 'cnonce' and
'client_cred_verify' parameters.
The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case an eligible authentication credential for the
joining node is neither present in the 'client_cred' parameter nor
already stored.
The Group Manager MAY reply with a 4.00 (Bad Request) error
response in case all the following conditions hold.
Is for the elliptic curve Ed448 and has its Y coordinate
equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see
Section 4.2 of RFC7748.
This prevents the acceptance of Ed25519 and Ed448 public keys that
cannot be successfully converted to Montgomery coordinates, and
thus cannot be used for the derivation of pairwise keys (see
Section 2.4.1 of I-D.ietf-core-oscore-groupcomm).
The 'client_cred' parameter MUST include an authentication
credential in the format indicated by the Group Manager.  Also,
the authentication credential as well as the included public
key MUST be compatible with the signature or ECDH algorithm,
and possible associated parameters.
The 'client_cred_verify' parameter MUST include a PoP evidence
computed as described in ssec-join-req-sending, by using the
private key associated with the authentication credential
specified in the current 'client_cred' parameter, with the
signature or ECDH algorithm, and possible associated parameters
indicated by the Group Manager.  If the error response from the
Group Manager includes the 'kdcchallenge' parameter, the
joining node MUST use its content as new N_S challenge to
compute the PoP evidence.
As PoP input, the Group Manager uses the value of the 'scope'
parameter from the Joining Request 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.  In particular, N_S is
determined as described in sssec-challenge-value, while N_C is the
nonce provided in the 'cnonce' parameter of the Joining Request.
As public key of the joining node, the Group Manager uses either
the one included in the authentication credential retrieved from
the 'client_cred' parameter of the Joining Request, or the one
from the already stored authentication credential as acquired from
previous interactions with the joining node (see sec-public-keys-
of-joining-nodes).
If the group is not a pairwise-only group, the PoP evidence is a
signature.  The Group Manager verifies it by using the public key
of the joining node, as well as the signature algorithm used in
the OSCORE group and possible corresponding parameters.
If the group is a pairwise-only group, the PoP evidence is a MAC.
The Group Manager recomputes the MAC through the same process
taken by the joining node when preparing the value of the
'client_cred_verify' parameter for the Joining Request (see ssec-
join-req-sending), with the difference that the Group Manager uses
its own Diffie-Hellman private key and the Diffie-Hellman public
key of the joining node.  The verification succeeds if and only if
the recomputed MAC is equal to the MAC conveyed as PoP evidence in
the Joining Request.
There are currently no OSCORE Sender IDs available to assign in
the OSCORE group and, at the same time, the joining node is not
going to join the group exclusively as monitor.  The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of I-D.ietf-ace-key-
groupcomm.  The value of the 'error' field MUST be set to 4 ("No
available node identifiers").
The OSCORE group that the joining node has been trying to join is
currently inactive (see ssec-resource-active).  The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of I-D.ietf-ace-key-
groupcomm.  The value of the 'error' field MUST be set to 9
("Group currently not active").
The 'client_cred' parameter is present in the Joining Request and
its value is not an eligible authentication credential (e.g., it
is not of the format accepted in the group).
The Group Manager does not store an eligible authentication
credential (e.g., of the format accepted in the group) for the
joining node.
The Group Manager stores multiple eligible authentication
credentials (e.g., of the format accepted in the group) for the
joining node.
The 'scope' parameter is not present in the Joining Request, or it
is present and specifies any set of roles not included in the
following list: "requester", "responder", "monitor", ("requester",
"responder").  Future specifications that define a new role for
members of OSCORE groups MUST define possible sets of roles
(including the new role and existing roles) that are acceptable to
specify in the 'scope' parameter of a Joining Request.
The Joining Request includes the 'client_cred' parameter but does
not include both the 'cnonce' and 'client_cred_verify' parameters.
Is for the elliptic curve Ed448 and has its Y coordinate equal
to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see
Section 4.2 of RFC7748.
If the group uses (also) the group mode of Group OSCORE, the CBOR
map MUST contain the 'sign_info' parameter, whose CBOR label is
defined in Section 8 of I-D.ietf-ace-key-groupcomm.  This
parameter has the same format of 'sign_info_res' defined in
Section 3.3.1 of I-D.ietf-ace-key-groupcomm.  In particular, it
includes a single element 'sign_info_entry' pertaining to the
OSCORE group that the joining node has tried to join with the
Joining Request.
If the group uses (also) the pairwise mode of Group OSCORE, the
CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR label
is defined in ssec-iana-ace-groupcomm-parameters-registry.  This
parameter has the same format of 'ecdh_info_res' defined in ecdh-
info.  In particular, it includes a single element
'ecdh_info_entry' pertaining to the OSCORE group that the joining
node has tried to join with the Joining Request.
If the group is a pairwise-only group, the CBOR map MUST contain
the 'kdc_dh_creds' parameter, whose CBOR label is defined in ssec-
iana-ace-groupcomm-parameters-registry.  This parameter has the
same format of 'kdc_dh_creds_res' defined in gm-dh-info.  In
particular, it includes a single element 'kdc_dh_creds_entry'
pertaining to the OSCORE group that the joining node has tried to
join with the Joining Request.
The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR
label is defined in Section 8 of I-D.ietf-ace-key-groupcomm.  If
present, this parameter is a CBOR byte string, which encodes a
newly generated 'kdcchallenge' value that the Client can use when
preparing a Joining Request (see ssec-join-req-sending).  In such
a case the Group Manager MUST store the newly generated value as
the 'kdcchallenge' value associated with the joining node,
possibly replacing the currently stored value.
The 'client_cred' parameter MUST include an authentication
credential in the format indicated by the Group Manager.  Also,
the authentication credential as well as the included public key
MUST be compatible with the signature or ECDH algorithm, and
possible associated parameters.
The 'client_cred_verify' parameter MUST include a PoP evidence
computed as described in ssec-join-req-sending, by using the
private key associated with the authentication credential
specified in the current 'client_cred' parameter, with the
signature or ECDH algorithm, and possible associated parameters
indicated by the Group Manager.  If the error response from the
Group Manager includes the 'kdcchallenge' parameter, the joining
node MUST use its content as new N_S challenge to compute the PoP
evidence.
The Group Manager selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node.  The
Group Manager MUST NOT assign an OSCORE Sender ID to the joining
node if this joins the group exclusively with the role of monitor,
according to what specified in the Access Token (see ssec-auth-
resp).
The Group Manager selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node.  The
Group Manager MUST NOT assign an OSCORE Sender ID to the joining
node if this joins the group exclusively with the role of monitor,
according to what is specified in the Access Token (see ssec-auth-
resp).
The 'hkdf' parameter, if present, has as value the HKDF
Algorithm used in the OSCORE group.  This parameter MAY be
omitted, if the HKDF Algorithm used in the group is HKDF SHA-
256.  Otherwise, this parameter MUST be present.
The 'hkdf' parameter, if present, specifies the HKDF Algorithm
used in the OSCORE group.  The HKDF Algorithm is specified by
the HMAC Algorithm value.  This parameter MAY be omitted, if
the HKDF Algorithm used in the group is HKDF SHA-256.
Otherwise, this parameter MUST be present.
The 'contextId' parameter MUST be present and has as value the
Group Identifier (Gid), i.e., the OSCORE ID Context of the
OSCORE group.  This parameter MUST be present.
The 'group_senderId' parameter, if present, has as value the
OSCORE Sender ID assigned to the joining node by the Group
Manager, as described above.  This parameter MUST NOT be
present if the node joins the OSCORE group exclusively with the
role of monitor, according to what specified in the Access
Token (see ssec-auth-resp).  In any other case, this parameter
MUST be present.
The 'cred_fmt' parameter MUST be present and specifies the
format of authentication credentials used in the OSCORE group.
It takes value from the "Label" column of the "COSE Header
Parameters" registry COSE.Header.Parameters (REQ6).
Consistently with Section 2.3 of I-D.ietf-core-oscore-
groupcomm, acceptable values denote a format that MUST
explicitly provide the public key as well as the comprehensive
set of information related to the public key algorithm,
including, e.g., the used elliptic curve (when applicable).
The 'contextId' parameter has as value the Group Identifier
(Gid), i.e., the OSCORE ID Context of the OSCORE group.  This
parameter MUST be present.
The 'group_senderId' parameter has as value the OSCORE Sender
ID assigned to the joining node by the Group Manager, as
described above.  This parameter MUST be present if and only if
the node does not join the OSCORE group exclusively with the
role of monitor, according to what is specified in the Access
Token (see ssec-auth-resp).
The 'cred_fmt' parameter specifies the format of authentication
credentials used in the OSCORE group.  This parameter MUST be
present and it takes value from the "Label" column of the "COSE
Header Parameters" registry COSE.Header.Parameters (REQ6).
Consistently with Section 2.3 of I-D.ietf-core-oscore-
groupcomm, acceptable values denote a format that MUST
explicitly provide the public key as well as the comprehensive
set of information related to the public key algorithm,
including, e.g., the used elliptic curve (when applicable).
The 'sign_enc_alg' parameter MUST NOT be present if the OSCORE
group is a pairwise-only group.  Otherwise, it MUST be present
and specifies the Signature Encryption Algorithm used in the
OSCORE group to encrypt messages protected with the group mode.
This parameter takes values from the "Value" column of the
"COSE Algorithms" registry COSE.Algorithms.
The 'sign_alg' parameter MUST NOT be present if the OSCORE
group is a pairwise-only group.  Otherwise, it MUST be present
and specifies the Signature Algorithm used to sign messages in
the OSCORE group.  This parameter takes values from the "Value"
column of the "COSE Algorithms" registry COSE.Algorithms.
The 'key' parameter MUST also include the following parameters, if
and only if the OSCORE group is not a pairwise-only group.
The 'sign_enc_alg' parameter, specifying the Signature
Encryption Algorithm used in the OSCORE group to encrypt
messages protected with the group mode.  This parameter takes
values from the "Value" column of the "COSE Algorithms"
registry COSE.Algorithms.
The 'sign_alg' parameter, specifying the Signature Algorithm
used to sign messages in the OSCORE group.  This parameter
takes values from the "Value" column of the "COSE Algorithms"
registry COSE.Algorithms.
The 'alg' parameter MUST NOT be present if the OSCORE group is
a signature-only group.  Otherwise, it MUST be present and
specifies the AEAD Algorithm used in the OSCORE group to
encrypt messages protected with the pairwise mode.
The 'ecdh_alg' parameter MUST NOT be present if the OSCORE
group is a signature-only group.  Otherwise, it MUST be present
and specifies the Pairwise Key Agreement Algorithm used in the
OSCORE group.  This parameter takes values from the "Value"
column of the "COSE Algorithms" registry COSE.Algorithms.
The 'key' parameter MUST also include the following parameters, if
and only if the OSCORE group is not a signature-only group.
The 'alg' parameter, specifying the AEAD Algorithm used in the
OSCORE group to encrypt messages protected with the pairwise
mode.
The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement
Algorithm used in the OSCORE group.  This parameter takes
values from the "Value" column of the "COSE Algorithms"
registry COSE.Algorithms.
Furthermore, the following applies.
As a last action, if the Group Manager reassigns Gid values during
the group's lifetime (see Section 3.2.1.1 of I-D.ietf-core-oscore-
groupcomm), the Group Manager MUST store the Gid specified in the
'contextId' parameter of the 'key' parameter, as the Birth Gid of the
joining node in the joined group (see Section 3 of I-D.ietf-core-
oscore-groupcomm).  This applies also in case the node is in fact re-
joining the group; in such a case, the newly determined Birth Gid
overwrites the one currently stored.
In case of successful verification of the PoP evidence, the joining
node uses the information received in the Joining Response to set up
the Group OSCORE Security Context, as described in Section 2 of I-
D.ietf-core-oscore-groupcomm.  If the following parameters were not
included in the 'key' parameter of the Joining Response, the joining
node considers the following default values, consistently with
Section 3.2 of RFC8613.
If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and
provide it to the current group members upon the new node's joining
(see sec-group-rekeying-process).  As a consequence, the joining node
is not able to access secure communication in the OSCORE group
occurred prior its joining.
The joining node is going to join the group exclusively as
monitor, i.e., it is not going to send messages to the group.  In
this case, the joining node is not required to provide its own
authentication credential to the Group Manager, which thus does
not have to perform any check related to the format of the
authentication credential, to a signature or ECDH algorithm, and
to possible parameters associated with the algorithm and the
public key.  In case that joining node still provides an
authentication credential in the 'client_cred' parameter of the
Joining Request (see ssec-join-req-sending), the Group Manager
silently ignores that parameter, as well as the related parameters
'cnonce' and 'client_cred_verify'.
The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication association.
In this case, upon performing a joining process with that Group
Manager for the first time, the joining node specifies its own
authentication credential in the 'client_cred' parameter of the
Joining Request targeting the group-membership endpoint (see ssec-
join-req-sending).
As a last action, if the Group Manager reassigns Gid values during
the group's lifetime (see Section 3.2.1.1 of I-D.ietf-core-oscore-
groupcomm), then the Group Manager MUST store the Gid specified in
the 'contextId' parameter of the 'key' parameter, as the Birth Gid of
the joining node in the joined group (see Section 3 of I-D.ietf-core-
oscore-groupcomm).  This applies also in case the joining node is in
fact re-joining the group; in such a case, the newly determined Birth
Gid overwrites the one currently stored.
In case of successful verification of the PoP evidence, the joining
node uses the information received in the Joining Response to set up
the Group OSCORE Security Context, as described in Section 2 of I-
D.ietf-core-oscore-groupcomm.  If the following parameters were not
included in the 'key' parameter of the Joining Response, the joining
node considers the default values specified below, consistently with
Section 3.2 of RFC8613.
If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and
provide it to the current group members, upon the new node's joining
(see sec-group-rekeying-process).  In such a case, the joining node
is not able to access secure communication in the OSCORE group
occurred prior its joining.
A set of stale Sender IDs, which allows each rekeyed node to purge
authentication credentials and Recipient Contexts used in the
group and associated with those Sender IDs.  This in turn allows
every group member to rely on stored authentication credentials,
in order to confidently assert the group membership of other
sender nodes, when receiving protected messages in the group (see
Section 3.2 of I-D.ietf-core-oscore-groupcomm).  More details on
the maintenance of stale Sender IDs are provided in sssec-stale-
sender-ids.
The Group Manager MUST rekey the group in the following cases.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-specific rekeying period or scheduling.
The N-th set includes the Sender IDs that have become "stale" under
the current version V of the group keying material.  The (N - 1)-th
set refers to the immediately previous version (V - 1) of the group
keying material, and so on.
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow also an external
signature verifier to verify signatures of messages protected with
the group mode and sent to the group (see Sections 3.1 and 8.5 of I-
D.ietf-core-oscore-groupcomm).  The response MUST have Content-Format
set to application/ace-groupcomm+cbor.  The payload of the response
is a CBOR map, which is formatted as defined in sec-verif-data.
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow the requesting Client
to delete the Recipient Contexts and authentication credentials
associated with former members of the group (see Section 3.2 of I-
D.ietf-core-oscore-groupcomm.  The payload of the response is
formatted as defined in sec-retrieve-stale-sids.
Just like any candidate group member, a signature verifier provides
the Group Manager with an Access Token, as described in ssec-token-
post.  However, unlike candidate group members, it does not join any
OSCORE group, i.e., it does not perform the joining process defined
in sec-joining-node-to-GM.
Consistently, in case a node is not a member of the group with group
name GROUPNAME and is authorized to be only signature verifier for
that group, the Group Manager MUST reply with a 4.03 (Forbidden)
error response if that node attempts to access any other endpoint
than: /ace-group; ace-group/GROUPNAME/verif-data; /ace-
group/GROUPNAME/pub-key; and ace-group/GROUPNAME/kdc-pub-key.
Building on what is defined in Section 4.1.1 of I-D.ietf-ace-key-
groupcomm, and with reference to the resources at the Group Manager
newly defined earlier in sec-interface-GM of this document, it is
expected that a Client minimally supports also the following set of
operations and corresponding interactions with the Group Manager
(REQ12).
GET request to ace-group/GROUPNAME/active, in order to check the
current status of the group.
GET request to ace-group/GROUPNAME/verif-data, in order for a
signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 3.1 and 8.5 of I-D.ietf-core-oscore-
groupcomm).  Note that this operation is relevant to support only
to signature verifiers.
FETCH request to ace-group/GROUPNAME/stale-sids, in order to
retrieve from the Group Manager the data required to delete some
of the stored group members' authentication credentials and
associated Recipient Contexts (see stale-sids-fetch).  These data
are provided as an aggregated set of stale Sender IDs, which are
used as specified in missed-rekeying.
This section defines the possible interactions with the Group
Manager, in addition to the group joining specified in sec-joining-
node-to-GM.
The 'key' parameter is formatted as defined in ssec-join-resp of
this document.  In particular, if the requesting group member has
exclusively the role of monitor, no 'group_SenderId' is specified
within the 'key' parameter.
Note that, in any other case, the current Sender ID of the group
member is not specified as a separate parameter, but rather
specified as 'group_SenderId' within the 'key' parameter.
The 'key' parameter is formatted as defined in ssec-join-resp of
this document.  In particular, if the requesting group member has
exclusively the role of monitor, then the 'key' parameter does not
include the 'group_SenderId'.
Note that, in any other case, the current Sender ID of the group
member is not specified as a separate parameter, but rather
specified by 'group_SenderId' within the 'key' parameter.
The Group Manager SHOULD perform a group rekeying only if
already scheduled to occur shortly, e.g., according to an
application-dependent rekeying period or scheduling, or as a
reaction to a recent change in the group membership.  In any
other case, the Group Manager SHOULD NOT rekey the OSCORE group
when receiving a Key Renewal Request (OPT12).
The Group Manager SHOULD perform a group rekeying only if
already scheduled to occur shortly, e.g., according to an
application-specific rekeying period or scheduling, or as a
reaction to a recent change in the group membership.  In any
other case, the Group Manager SHOULD NOT rekey the OSCORE group
when receiving a Key Renewal Request (OPT12).
A group member may need to provide the Group Manager with its new
authentication credential to use in the group from then on, hence
replacing the current one.  This can be the case, for instance, if
the signature or ECDH algorithm, and possible associated parameters
used in the OSCORE group have been changed, and the current
authentication credential is not compatible with them.
A group member may need to provide the Group Manager with its new
authentication credential to use in the group from then on, hence
replacing the current one.  This can be the case, for instance, if
the signature or ECDH algorithm and possible associated parameters
used in the OSCORE group have been changed, and the current
authentication credential is not compatible with them.
The N_S challenge used to build the proof-of-possession input is
computed as per point (1) in sssec-challenge-value (REQ15).
The N_S challenge used to build the proof-of-possession input is
computed as defined in sssec-challenge-value (REQ15).
For each of its groups, the Group Manager maintains an association
between the group name and the URI to the group-membership resource
on one hand, and only the current Gid for that group on the other
hand.  That is, the Group Manager MUST NOT maintain an association
between the former pair and any other Gid for that group than the
current, most recent one.
For each of its groups, the Group Manager maintains an association
between the group name and the URI to the group-membership resource
on one hand, and only the current Gid for that group on the other
hand.  That is, the Group Manager does not maintain an association
between the former pair and any other Gid for that group than the
current, most recent one.
Upon receiving the Group Leaving Request, the Group Manager processes
it as per Section 4.8.3 of I-D.ietf-ace-key-groupcomm.  Then, the
Group Manager performs the follow-up actions defined in sec-leaving.
Upon receiving the Group Leaving Request, the Group Manager processes
it as per Section 4.8.3 of I-D.ietf-ace-key-groupcomm.  Then, the
Group Manager performs the follow-up actions defined in sec-leaving
of this document.
If any of the two conditions below holds, the Group Manager MUST
inform the leaving node of its eviction as follows.  If both
conditions hold, the Group Manager MUST inform the leaving node only
once, using either of the corresponding methods.
If any of the two conditions below holds, the Group Manager MUST
inform the leaving node of its eviction as follows.  If both
conditions hold, the Group Manager MUST inform the leaving node by
using only the method corresponding to one of either conditions.
If, when sending Joining Responses to nodes joining the group (see
ssec-join-resp) the Group Manager specifies a URI in the
'control_group_uri' parameter defined in Section 4.3.1 of I-
D.ietf-ace-key-groupcomm, the Group Manager sends a DELETE request
targeting the URI specified in the 'control_group_uri' parameter
(OPT10).
Furthermore, the Group Manager might intend to evict all the current
group members from the group at once.  In such a case, if the Joining
Responses sent by the Group Manager to nodes joining the group (see
ssec-join-resp) specify a URI in the 'control_group_uri' parameter
defined in Section 4.3.1 of I-D.ietf-ace-key-groupcomm, then the
Group Manager MUST additionally send a DELETE request targeting the
URI specified in the 'control_group_uri' parameter (OPT10).
Finally, missed-rekeying discusses how a group member can realize
that it has missed one or more rekeying instances, and the actions it
is accordingly required to take.
The group rekeying messages MUST have Content-Format set to
application/ace-groupcomm+cbor and have the same format used for the
Joining Response message in ssec-join-resp, with the following
differences.  Note that this extends the minimal content of a
rekeying message as defined in Section 6 of I-D.ietf-ace-key-
groupcomm (OPT14).
receiving-rekeying-msg defines the actions performed by a group
member upon receiving the new group keying material. missed-rekeying
discusses how a group member can realize that it has missed one or
more rekeying instances, and the actions it is accordingly required
to take.
When using the "Point-to-Point" group rekeying scheme, the group
rekeying messages MUST have Content-Format set to application/ace-
groupcomm+cbor and have the same format used for the Joining Response
message in ssec-join-resp, with the following differences.  Note that
this extends the minimal content of a rekeying message as defined in
Section 6 of I-D.ietf-ace-key-groupcomm (OPT14).
The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers'
SHOULD be present, if the group rekeying is performed due to one
or multiple Clients that have requested join the group.  Following
the same semantics used in the Joining Response message (see ssec-
join-resp), the three parameters specify the authentication
credential, roles in the group and node identifier of each of the
Clients that have requested to join the group.  The Group Manager
MUST NOT include a non-empty subset of these three parameters.
Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member
used during the joining process.  In particular, each rekeying
message can target the 'control_uri' URI path defined in
Section 4.3.1 of I-D.ietf-ace-key-groupcomm (OPT7), if provided by
the intended recipient upon joining the group (see ssec-join-req-
sending).
The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers'
SHOULD be present, if the group rekeying is performed due to one
or multiple Clients that have requested to join the group.
Following the same semantics used in the Joining Response message
(see ssec-join-resp), the three parameters specify the
authentication credential, roles in the group and node identifier
of each of the Clients that have requested to join the group.  The
Group Manager MUST NOT include a non-empty subset of these three
parameters.
Each rekeying message MUST be secured with the pairwise secure
communication association between the Group Manager and the group
member used during the joining process.  In particular, each rekeying
message can target the 'control_uri' URI path defined in
Section 4.3.1 of I-D.ietf-ace-key-groupcomm (OPT7), if provided by
the intended recipient upon joining the group (see ssec-join-req-
sending).
Once received the new group keying material, a group member proceeds
as follows.
The group member considers the stale Sender IDs received from the
Group Manager.  If the group rekeying scheme defined in sending-
rekeying-msg is used, the stale Sender IDs are specified by the
'stale_node_ids' parameter.
Once received the new group keying material, a group member proceeds
as follows.  Unless otherwise specified, the following is independent
of the specifically used group rekeying scheme.
The group member considers the stale Sender IDs received from the
Group Manager.  If the "Point-to-Point" group rekeying scheme as
detailed in sending-rekeying-msg is used, the stale Sender IDs are
specified by the 'stale_node_ids' parameter.
Then, the following cases can occur, based on the version number V'
of the new group keying material distributed through the rekeying
process.  If the group rekeying scheme defined in sending-rekeying-
msg is used, this information is specified by the 'num' parameter.
Then, the following cases can occur, based on the version number V'
of the new group keying material distributed through the rekeying
process.  If the "Point-to-Point" group rekeying scheme as detailed
in sending-rekeying-msg is used, this information is specified by the
'num' parameter.
The group member obtains the latest keying material with version
number V' from the Group Manager.  This can happen by sending a
Key Distribution Request to the Group Manager (see ssec-updated-
key-only), or by re-joining the group (see ssec-join-req-sending).
The group member obtains the latest keying material with version
number V' from the Group Manager.  This can happen by sending a
Key Distribution Request to the Group Manager (see ssec-updated-
key-only) and ssec-updated-and-individual-key).
When realizing to have missed one or more group rekeying instances
(see missed-rekeying), a node needs to retrieve from the Group
Manager the data required to delete some of its stored group members'
authentication credentials and Recipient Contexts (see stale-sids-
fetch).  This data is provided as an aggregated set of stale Sender
IDs, which are used as specified in missed-rekeying.
When realizing to have missed one or more group rekeying instances
(see missed-rekeying), a node needs to retrieve from the Group
Manager the data required to delete some of its stored group members'
authentication credentials and Recipient Contexts (see stale-sids-
fetch).  These data are provided as an aggregated set of stale Sender
IDs, which are used as specified in missed-rekeying.
The handler MUST reply with a 4.00 (Bad Request) error response, if
the request is not formatted correctly.  Also, the handler MUST
respond with a 4.00 (Bad Request) error response, if the specified
version number V is greater or equal than the version number V'
associated with the latest keying material in the group, i.e., if V
>= V'.
The handler MUST reply with a 4.00 (Bad Request) error response, if
the request is not formatted correctly.  Also, the handler MUST
respond with a 4.00 (Bad Request) error response, if the specified
version number V is greater or equal than the version number V'
associated with the latest keying material in the group, i.e., in
case V >= V'.
Clients are required to support the new parameters defined in this
application profile as specified below (REQ29).
In addition to those defined in Section 8 of I-D.ietf-ace-key-
groupcomm, this application profile defines additional parameters
used during the second part of the message exchange with the Group
Manager, i.e., after the exchange of Token Transfer Request and
Response (see ssec-token-post).  The table below summarizes them and
specifies the CBOR key to use instead of the full descriptive name.
Note that the media type application/ace-groupcomm+cbor MUST be used
when these parameters are transported in the respective message
fields.
The Group Manager is expected to support and understand all the
parameters above.  Instead, a Client is required to support the new
parameters defined in this application profile as specified below
(REQ29).
When the conditional parameters defined in Section 8 of I-D.ietf-ace-
key-groupcomm are used with this application profile, Clients must,
should or may support them as specified below (REQ30).
When the conditional parameters defined in Section 8 of I-D.ietf-ace-
key-groupcomm are used with this application profile, a Client must,
should or may support them as specified below (REQ30).
'group_policies'.  A Client that is interested in the specific
policies used in a group, but that does not know them or cannot
become aware of them before joining that group SHOULD support this
parameter.
'group_policies'.  A Client that is interested in the specific
policies used in a group, but that does not know them or cannot
become aware of them before joining that group, SHOULD support
this parameter.
'mgt_key_material'.  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, MUST support this
parameter.
'control_group_uri'.  A Client that support the hosting of local
resources each associated with a group (hence acting as CoAP
server) and the reception of one-to-many requests sent to those
resources by the Group Manager (e.g., over IP multicast) MUST
support this parameter.
In addition to what is defined in Section 9 of I-D.ietf-ace-key-
groupcomm, this application profile defines new values that the Group
Manager can include as error identifiers, in the 'error' field of an
error response with Content-Format application/ace-groupcomm+cbor.
'mgt_key_material'.  A Client that supports an advanced rekeying
scheme possibly used in the group, such as based on one-to-many
rekeying messages sent by the Group Manager (e.g., over IP
multicast), MUST support this parameter.
'control_group_uri'.  A Client that supports the hosting of local
resources each associated with a group (hence acting as CoAP
server) and the reception of one-to-many requests sent to those
resources by the Group Manager (e.g., over IP multicast) MUST
support this parameter.
In addition to those defined in Section 9 of I-D.ietf-ace-key-
groupcomm, this application profile defines new values that the Group
Manager can include as error identifiers, in the 'error' field of an
error response with Content-Format application/ace-groupcomm+cbor.
In case of error 7, the Client should stop sending the request in
question to the Group Manager.  In this application profile, this
error is relevant only for a signature verifiers, in case it tries
to access resources related to a pairwise-only group.
In case of error 7, the Client should stop sending the request in
question to the Group Manager.  In this application profile, this
error is relevant only for a signature verifier, in case it tries
to access resources related to a pairwise-only group.
For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the
same default value defined in Section 3.2 of RFC8613, i.e., HKDF
SHA-256 (COSE algorithm encoding: -10).
For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF
SHA-256, defined as default in Section 3.2 of RFC8613.  In the
'hkdf' parameter, this HKDF Algorithm is specified by the HMAC
Algorithm HMAC 256/256 (COSE algorithm encoding: 5).
For the Signature Encryption Algorithm 'sign_enc_alg' used to
encrypted messages protected with the group mode, the Group
Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10)
as default value.
For the Signature Encryption Algorithm 'sign_enc_alg' used to
encrypt messages protected with the group mode, the Group Manager
SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) as
default value.
The array , in case EdDSA is assumed or
specified for 'sign_alg'.  In particular, this indicates to use
the COSE key type OKP and the elliptic curve X25519 RFC8032.
The array , in case EdDSA is assumed or
specified for 'sign_alg', or in case the group is a pairwise-
only group.  In particular, this indicates to use the COSE key
type OKP and the elliptic curve X25519 RFC8032.
Management of group keying material (see Section 3.2 of I-D.ietf-
core-oscore-groupcomm).  The Group Manager is responsible for the
renewal and re-distribution of the keying material in the groups
of its competence (rekeying).  According to the specific
application requirements, this can include rekeying the group upon
changes in its membership.  In particular, renewing the group
keying material is required upon a new node's joining or a current
node's leaving, in case backward security and forward security
have to be preserved, respectively.
Management of group keying material (see Section 3.2 of I-D.ietf-
core-oscore-groupcomm).  The Group Manager is responsible for the
renewal and re-distribution of the keying material in the groups
of its competence (rekeying).
The Group Manager performs a rekeying when one ore more members
leave the group, thus preserving forward security and ensuring
that the security properties of Group OSCORE are fulfilled.
According to the specific application requirements, the Group
Manager can also rekey the group upon a new node's joining, in
case backward security has also to be preserved.
Alternatively, when establishing a secure communication association
with the Group Manager, the joining node can provide the Group
Manager with its own authentication credential, and use the public
key included thereof as asymmetric proof-of-possession key, e.g., as
in Section 3.2.2 of I-D.ietf-ace-dtls-authorize in case the joining
node authenticates itself during the DTLS handshake with the the
Group Manager.  However, this requires the authentication credential
to be in the format used in the OSCORE group, and that both the
authentication credential and the included public key are compatible
with the signature or ECDH algorithm, and possible associated
parameters used in the OSCORE group.
Alternatively, when establishing a secure communication association
with the Group Manager, the joining node can provide the Group
Manager with its own authentication credential, and use the public
key included thereof as asymmetric proof-of-possession key.  For
example, this is the case when the joining node relies on
Section 3.2.2 of I-D.ietf-ace-dtls-authorize and authenticates itself
during the DTLS handshake with the Group Manager.  However, this
requires the authentication credential to be in the format used in
the OSCORE group, and that both the authentication credential of the
joining node and the included public key are compatible with the
signature or ECDH algorithm, and possible associated parameters used
in the OSCORE group.
For the N_C challenge, it is RECOMMENDED to use a 8-byte long random
nonce.  Furthermore, N_C is always conveyed in the 'cnonce' parameter
of the Joining Request, which is always sent over the secure
communication channel between the joining node and the Group Manager.
For the N_C challenge, it is RECOMMENDED to use a 8-byte long random
nonce.  Furthermore, N_C is always conveyed in the 'cnonce' parameter
of the Joining Request, which is always sent over the secure
communication association between the joining node and the Group
Manager.
If the Access Token has been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as
in ssec-token-post, then N_S takes the most recent value provided
to the client by the Group Manager in the 'kdcchallenge'
parameter, as specified in point (1) of sssec-challenge-value.
This is provided either in the Token Transfer Response (see ssec-
token-post), or in a 4.00 (Bad Request) error response to a
following Joining Request (see ssec-join-req-processing).  In
either case, it is RECOMMENDED to use a 8-byte long random
challenge as value for N_S.
If the Access Token has been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as
in ssec-token-post, then N_S takes the most recent value provided
to the Client by the Group Manager in the 'kdcchallenge'
parameter, as specified in point (1) of sssec-challenge-value.
This value is provided either in the Token Transfer Response (see
ssec-token-post), or in a 4.00 (Bad Request) error response to a
following Joining Request (see ssec-join-req-processing).  In
either case, it is RECOMMENDED to use a 8-byte long random
challenge as value for N_S.
Clarity and correctness of registrations.  Experts are expected to
check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the considered role, to
verify the correctness of its description against the role as
intended in the specification that defined it.  Expert should
consider requesting an opinion on the correctness of registered
parameters from the Authentication and Authorization for
Constrained Environments (ACE) Working Group and the Constrained
RESTful Environments (CoRE) Working Group.
Clarity and correctness of registrations.  Experts are expected to
check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the considered role, to
verify the correctness of its description against the role as
intended in the specification that defined it.  Experts should
consider requesting an opinion on the correctness of registered
parameters from the Authentication and Authorization for
Constrained Environments (ACE) Working Group and the Constrained
RESTful Environments (CoRE) Working Group.