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

Commentary: In Section 3.3.1 of ace - key - groupcomm , the definition of ' signinfoentry ' adheres with the existing COSE algorithm . However , future COSE algorithms may admit zero or more than one capabilities , beyond Key Type . That would need to be reflected with additional , corresponding arrays following ' signkeyparameters ' . At the same time , REQ4 and REQ5 leave the details about specified properties to application profiles . The same applies also to the specific content of ' key ' in the Joining Response , whose details are also left to application profiles ( REQ10 ) . Considering exactly Group OSCORE , this can be addressed in ace - key - groupcomm - oscore as done in core - oscore - groupcomm , where Appendix H defines a future - friendly template for the same kind of extension , there with respect to parameters in the OSCORE Security Context and to elements in the externalaad . Following the same rationale , the ' signparameters ' arrays after ' signparameters ' would be as many as the elements of ' signparameters ' , i.e. one for each capability of the signature algorithm . The same thing can be done for ' ecdhinfoentry ' , i.e. the ' ecdhparameters ' arrays after ' ecdhparameters ' would be as many as the elements of ' ecdhparameters ' , i.e. one for each capability of the ECDH algorithm . The same logic applies to corresponding parameters in the ' key ' element of responses from ace - group / GROUPNAME ( e.g.    ) and from ace - group / GROUPNAME / nodes / NODENAME , ' csparams ' , ' cskeyparams ' , ' ecdhparams ' and ' ecdhkey_params ' . Like in core - oscore - groupcomm , applying this template to any of today 's existing COSE algorithms results in the exact parameters and formats detailed in the document body . 
 Can somebody help me unsubscribe ? My brother was a member of this group . He has died and I need to monitor this email , but I have know access to his user name / password . All I have is his email address :   August Cellars 503.554.6766 x102 desk 503.789.7404 cell 
 I will respond to  out of band . 
 This applies to ' signinfo ' and ' ecdhinfo ' in the response to the Token POST , as well as to ' key : cs_params ' in the Joining Response .
This specification 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
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 specification 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 over IP multicast.
The terms and concepts for protection and processing of CoAP
messages through OSCORE RFC8613 and through Group OSCORE I-D.ietf-
core-oscore-groupcomm in group communication scenarios.  These
include the concept of Group Manager, as the entity responsible
for a set of groups where communications are secured with Group
OSCORE.  In this specification, the Group Manager acts as Resource
Server.
The terms and concepts for protection and processing of CoAP
messages through OSCORE RFC8613 and through Group OSCORE I-D.ietf-
core-oscore-groupcomm in group communication scenarios.  These
include the concept of Group Manager, as the entity responsible
for a set of groups where communications are secured with Group
OSCORE.  In this document, the Group Manager acts as Resource
Server.
Signature verifier: entity external to the OSCORE group and
intended to verify the countersignature of messages exchanged in
the group.  An authorized signature verifier does not join the
OSCORE group as an actual member, yet it can retrieve the public
keys of the current group members from the Group Manager.
Signature verifier: entity external to the OSCORE group and
intended to verify the signature of messages exchanged in the
group (see Sections 3.1 and 8.5 of I-D.ietf-core-oscore-
groupcomm).  An authorized signature verifier does not join the
OSCORE group as an actual member, yet it can retrieve the public
keys of the current group members from the Group Manager.
Signature-only group: an OSCORE group that uses only the group
mode (see Section 8 of I-D.ietf-core-oscore-groupcomm).
Pairwise-only group: an OSCORE group that uses only the pairwise
mode (see Section 9 of I-D.ietf-core-oscore-groupcomm).
This specification 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 defined in Section 2
of I-D.ietf-ace-key-groupcomm, for an OSCORE group.
The node wishing to join the OSCORE group, i.e. the joining node,
is the Client.
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 defined in Section 2
of I-D.ietf-ace-key-groupcomm, for an OSCORE group.
The node wishing to join the OSCORE group, i.e., the joining node,
is the Client.
In particular, communications between the Client and the Group
Manager leverage protocol-specific transport profiles of ACE to
achieve communication security, proof-of-possession and server
authentication.  It is expected that, in the commonly referred base-
case of this specification, the transport profile to use is pre-
configured and well-known to nodes participating in constrained
applications.
In particular, communications between the Client and the Group
Manager leverage protocol-specific transport profiles of ACE to
achieve communication security, proof-of-possession and server
authentication.  It is expected that, in the commonly referred base-
case of this document, the transport profile to use is pre-configured
and well-known to nodes participating in constrained applications.
If the application requires backward and forward security, the Group
Manager MUST generate new keying material and distribute it to the
group (rekeying) upon membership changes.
That is, the group is rekeyed when a node joins the group as a new
member, or after a current member leaves the group.  By doing so, a
joining node cannot access communications in the group prior its
joining, while a leaving node cannot access communications in the
group after its leaving.
In a number of cases, the Group Manager has to generate new keying
material and distribute it to the group (rekeying), as also discussed
in Section 3.2 of I-D.ietf-core-oscore-groupcomm.
To this end the Group Manager MUST support the Group Rekeying Process
described in sec-group-rekeying-process of this document.  Future
application profiles may define alternative rekeying message formats
and group rekeying schemes, which MUST comply with the functional
steps defined in Section 3.2 of I-D.ietf-core-oscore-groupcomm.
Upon generating the new group keying material and before starting its
distribution, the Group Manager MUST increment the version number of
the group keying material.  When rekeying a group, the Group Manager
MUST preserve the current value of the OSCORE Sender ID of each
member in that group.
The new version number of the group keying material for the group.
A new value for the Master Secret parameter of the Group OSCORE
Common Security Context of that group (see Section 2 of I-D.ietf-
core-oscore-groupcomm).
Also, the distributed keying material MAY include a new value for the
Master Salt parameter of the Group OSCORE Common Security Context of
that group.
Upon generating the new group keying material and before starting its
distribution, the Group Manager MUST increment the version number of
the group keying material.  When rekeying a group, the Group Manager
MUST preserve the current value of the Sender ID of each member in
that group.
The Group Manager MUST support the Group Rekeying Process described
in sec-group-rekeying-process.  Future application profiles may
define alternative message formats and distribution schemes to
perform group rekeying.
A new value for the Master Secret parameter of the Group OSCORE
Common Security Context of the group (see Section 2 of I-D.ietf-
core-oscore-groupcomm).
A set of stale Sender IDs, so that each rekeyed node can delete
the Recipient Contexts and public keys associated to former
members of 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.
This allows every group member to rely on owned public keys to
confidently assert the group membership of other sender nodes,
when receiving protected messages in the group.
Also, the data distributed through a group rekeying MAY include a new
value for the Master Salt parameter of the Group OSCORE Common
Security Context of that group.
The Group Manager MUST rekeying the group in the following cases.
The application requires backward security - In this case, the
group is rekeyed when a node joins the group as a new member.
Therefore, a joining node cannot access communications in the
group prior its joining.
One or more nodes leave the group - That is, the group is rekeyed
when one or more current members spontaneously request to leave
the group (see sec-leave-req), or when the Group Manager forcibly
evicts them from the group, e.g., due to expired or revoked
authorization (see sec-leaving).  Therefore, a leaving node cannot
access communications in the group after its leaving, thus
ensuring forward security in the group.
Due to the set of stale Sender IDs distributed through the
rekeying, this ensures that a node owning the latest group keying
material does not store the public keys of former group members
(see Sections 3.2 and 10.1 of I-D.ietf-core-oscore-groupcomm).
Extension of group lifetime - That is, the group is rekeyed when
the expiration time for the group keying material approaches or
has passed, if it is appropriate to extend the group operation
beyond that.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-dependent rekeying period or scheduling.
Throughout the lifetime of every group, the Group Manager MUST
maintain a collection of stale Sender IDs for that group.
The collection associated to a group MUST include up to N > 0 ordered
sets of stale OSCORE Sender IDs.  It is up to the application to
specify the value of N, possibly on a per-group basis.
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.
In the following cases, the Group Manager MUST add a new element to
the most recent set X, i.e., the set associated to the current
version V of the group keying material.
When a current group member obtains a new Sender ID, its old
Sender ID is added to X.  This happens when the Group Manager
assigns a new Sender ID upon request from the group member (see
sec-new-key), or in case the group member re-joins the group (see
ssec-join-req-sending and ssec-join-resp), thus also obtaining a
new Sender ID.
When a current group member leaves the group, its current Sender
ID is added to X.  This happens when a group member requests to
leave the group (see sec-leave-req) or is forcibly evicted from
the group (see sec-leaving).
The value of N can change throughout the lifetime of the group.  If
the new value N' is smaller than N, the Group Manager MUST preserve
the N' most recent sets in the collection and MUST delete the (N -
N') oldest sets.
Finally, the Group Manager MUST perform the following actions, when
the group is rekeyed and the group shifts to the next version V' = (V
+ 1) of the group keying material.
The Group Manager rekeys the group.  This includes also
distributing the set of stale Sender IDs X associated to the old
group keying material with version V (see ssec-overview-group-
rekeying-process).
After completing the group rekeying, the Group Manager creates a
new empty set X' associated to the new version V' of the newly
established group keying material, i.e., V' = (V + 1).
If the current collection of stale Sender IDs has size N, the
Group Manager deletes the oldest set in the collection.
The Group Manager adds the new set X' to the collection of stale
Sender IDs, as the most recent set.
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
specification.
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.
The AS MUST include the 'expires_in' parameter.  Other means for
the AS to specify the lifetime of Access Tokens are out of the
scope of this specification.
The AS MUST include the 'expires_in' parameter.  Other means for
the AS to specify the lifetime of Access Tokens are out of the
scope of this document.
Furthermore, if the AS uses the extended format of scope defined in
Section 6 of I-D.ietf-ace-key-groupcomm for the 'scope' claim of the
Access Token, the first element of the CBOR sequence RFC8742 MUST be
the CBOR integer with value SEM_ID_TBD, defined in iana-scope-
semantics of this specification (REQ23).  This indicates that the
second element of the CBOR sequence, as conveying the actual access
control information, follows the scope semantics defined for this
application profile in sec-format-scope of this specification.
The Group Manager provides the interface defined in Section 4.1 of I-
D.ietf-ace-key-groupcomm, with one additional sub-resource defined in
ssec-resource-active of this specification.
The GROUPNAME segment of the URI path MUST match with the group name
specified in the scope entry of the Access Token scope (i.e. 'gname'
in Section 3.1 of I-D.ietf-ace-key-groupcomm) (REQ1).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in iana-rt (REQ7), and can be used to describe group-
membership resources and its sub-resources at a Group Manager, e.g.
by using a link-format document RFC6690.
Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g. by using
the approach described in I-D.tiloca-core-oscore-discovery.
Furthermore, if the AS uses the extended format of scope defined in
Section 6 of I-D.ietf-ace-key-groupcomm for the 'scope' claim of the
Access Token, the first element of the CBOR sequence RFC8742 MUST be
the CBOR integer with value SEM_ID_TBD, defined in iana-scope-
semantics of this document (REQ24).  This indicates that the second
element of the CBOR sequence, as conveying the actual access control
information, follows the scope semantics defined for this application
profile in sec-format-scope of this document.
The Group Manager provides the interface defined in Section 4.1 of I-
D.ietf-ace-key-groupcomm, with the additional sub-resources defined
from ssec-resource-active to ssec-resource-stale-sids of this
document.
The GROUPNAME segment of the URI path MUST match with the group name
specified in the scope entry of the Access Token scope (i.e., 'gname'
in Section 3.1 of I-D.ietf-ace-key-groupcomm) (REQ1).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in iana-rt (REQ7), and can be used to describe group-
membership resources and its sub-resources at a Group Manager, e.g.,
by using a link-format document RFC6690.
Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g., by using
the approach described in I-D.tiloca-core-oscore-discovery.
The Group Manager verifies that the group name in the /ace-
group/GROUPNAME/active path is a subset of the 'scope' stored in the
Access Token associated to the requesting client.
The Group Manager also verifies that the roles granted to the
requesting client in the group allow it to perform this operation on
this resource (REQ8).  If either verification fails, the Group
Manager MUST respond with a 4.01 (Unauthorized) error message.
The handler verifies that the group name in the /ace-group/GROUPNAME/
active path is a subset of the 'scope' stored in the Access Token
associated to the requesting client.
The handler also verifies that the roles granted to the requesting
client in the group allow it to perform this operation on this
resource (REQ8).  If either verification fails, the Group Manager
MUST respond with a 4.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content)
message containing the CBOR simple value True if the group is
currently active, or the CBOR simple value False otherwise.  The
group is considered active if it is set to allow new members to join,
and if communication within the group is fine to happen.
The method to set the current group status, i.e. active or inactive,
is out of the scope of this specification, and is defined for the
administrator interface of the Group Manager specified in I-D.ietf-
ace-oscore-gm-admin.
If the verifications above succeed, the handler returns a 2.05
(Content) message, specifying the current status of the group, i.e.,
active or inactive.  The payload of the response is formatted as
defined in sec-status.
The method to set the current group status is out of the scope of
this document, and is defined for the administrator interface of the
Group Manager specified in I-D.ietf-ace-oscore-gm-admin.
The handler verifies that the group name in the /ace-group/GROUPNAME/
gm-pub-key path is a subset of the 'scope' stored in the Access Token
associated to the requesting client.
If the requesting client is not a current group member and GROUPNAME
denotes a pairwise-only group, the Group Manager MUST respond with a
4.00 (Bad Request) error message.  The response MUST have Content-
Format set to application/ace-groupcomm+cbor and is formatted as
defined in Section 4 of I-D.ietf-ace-key-groupcomm.  The value of the
'error' field MUST be set to 7 ("Signatures not used in the group").
If the verifications above succeed, the handler returns a 2.05
(Content) message, specifying the Group Manager's public key together
with a proof-of-possession evidence.  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-gm-pub-
key.
The handler verifies that the group name in the /ace-group/GROUPNAME/
verif-data path is a subset of the 'scope' stored in the Access Token
associated to the requesting client.
If the requesting client is a current group member, the Group Manager
MUST respond with a 4.01 (Unauthorized) error message.  The response
MUST have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4 of I-D.ietf-ace-key-groupcomm.  The
value of the 'error' field MUST be set to 8 ("Operation permitted
only to signature verifiers").
If GROUPNAME denotes a pairwise-only group, the Group Manager MUST
respond with a 4.00 (Bad Request) error message.  The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4 of I-D.ietf-ace-key-groupcomm.  The
value of the 'error' field MUST be set to 7 ("Signatures not used in
the group").
If the verifications above succeed, the handler returns a 2.05
(Content) message, 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.
This resource implements a FETCH handler.
The handler expects a FETCH request, whose payload specifies a
version number of the group keying material, encoded as an unsigned
CBOR integer.
The handler verifies that the group name in the /ace-group/GROUPNAME/
stale-sids path is a subset of the 'scope' stored in the Access Token
associated to the requesting client.
Additionally, the handler verifies that the requesting client is a
current member of the group.  If verification fails, the Group
Manager MUST respond with a 4.01 (Unauthorized) error message.  The
response MUST have Content-Format set to application/ace-
groupcomm+cbor and is formatted as defined in Section 4 of I-D.ietf-
ace-key-groupcomm.  The value of the 'error' field MUST be set to 0
("Operation permitted only to group members").
If the verifications above succeed, the handler returns a 2.05
(Content) message, specifying data that allows the requesting client
to delete the Recipient Contexts and public keys associated to 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.
The rest of this section describes the interactions between the
joining node and the Group Manager, i.e. the sending of the Access
Token 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 Section 3.3 and 4.3 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 rest of this section describes the interactions between the
joining node and the Group Manager, i.e., the sending of the Access
Token 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 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.
A signature verifier provides the Group Manager with an Access Token,
as described in ssec-token-post, just as any another joining node
does.  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.  After successfully posting an Access Token, a
signature verifier is authorized to perform only the operations
specified in sec-pub-keys, to retrieve the public keys of group
members, and only for the OSCORE groups specified in the validated
Access Token.  The Group Manager MUST respond with a 4.01
(Unauthorized) error message, in case a signature verifier attempts
to access any other endpoint than /ace-group/GROUPNAME/pub-key at the
Group Manager.
A signature verifier provides the Group Manager with an Access Token,
as described in ssec-token-post, just as any another joining node
does.  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.  After successfully posting an Access
Token, a signature verifier is authorized to perform only the
operations specified in sec-pub-keys, to retrieve the public keys of
group members, and only for the OSCORE groups specified in the
validated Access Token.  The Group Manager MUST respond with a 4.01
(Unauthorized) error message, in case a signature verifier attempts
to access any other endpoint than /ace-group/GROUPNAME/pub-key at the
Group Manager.
'gm_dh_pub_keys' defined in gm-dh-info, encoding the CBOR
simple value Null to require the Diffie-Hellman public key of
the Group Manager in the group, in case the joining node
supports the pairwise mode of Group OSCORE I-D.ietf-core-
oscore-groupcomm.
'sign_alg_capab', encoded as a CBOR array.  Its format and
value are the same of the COSE capabilities for the
algorithm indicated in 'sign_alg', as specified for that
algorithm in the "Capabilities" column of the "COSE
Algorithms" Registry COSE.Algorithms (REQ4).
'sign_key_type_capab', encoded as a CBOR array.  Its format
and value are the same of the COSE capabilities for the COSE
key type of the keys used with the algorithm indicated in
'sign_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" Registry
COSE.Key.Types (REQ4).
'sign_key_parameters' is a CBOR array.  Its format and value
are the same of the COSE capabilities for the COSE key type of
the keys used with the algorithm indicated in 'sign_alg', as
specified for that key type in the "Capabilities" column of the
"COSE Key Types" Registry COSE.Key.Types (REQ5).
'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation
Key' column of the "CWT Confirmation Method" Registry
CWT.Confirmation.Methods, so indicating that public keys in the
OSCORE group are encoded as COSE Keys I-D.ietf-cose-rfc8152bis-
struct.  Future specifications may define additional values for
this parameter.
If 'ecdh_info' is included in the request, the Group Manager MAY
include the 'ecdh_info' parameter defined in ecdh-info, with the
same encoding.  Note that the field 'id' takes as value the group
name, or array of group names, for which the corresponding
'ecdh_info_entry' applies to.
Note that, other than through the above parameters as defined in
Section 3.3 of I-D.ietf-ace-key-groupcomm, the joining node MAY have
previously retrieved this information by other means, e.g. by using
the approach described in I-D.tiloca-core-oscore-discovery to
discover the OSCORE group and the link to the associated group-
membership resource at the Group Manager (OPT2).
Additionally, if allowed by the used transport profile of ACE, the
joining node may instead provide the Access Token to the Group
Manager by other means, e.g. during a secure session establishment
(see Section 3.3.2 of I-D.ietf-ace-dtls-authorize).
The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post
response message defined in Section 5.10.1. of I-D.ietf-ace-oauth-
authz.
'id' MUST NOT refer to OSCORE groups that are pairwise-only
groups.
'sign_parameters' is a CBOR array.  Its format and value are
the same of the COSE capabilities array for the algorithm
indicated in 'sign_alg', as specified for that algorithm in the
"Capabilities" column of the "COSE Algorithms" Registry
COSE.Algorithms (REQ4).
'sign_key_parameters' is a CBOR array.  Its format and value
are the same of the COSE capabilities array for the COSE key
type of the keys used with the algorithm indicated in
'sign_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" Registry
COSE.Key.Types (REQ5).
'pub_key_enc' 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 an encoding that MUST
explicitly provide the full set of information related to the
public key algorithm, including, e.g., the used elliptic curve
(when applicable).
This format is consistent with every signature algorithm currently
considered in I-D.ietf-cose-rfc8152bis-algs, i.e., with algorithms
that have only the COSE key type as their COSE capability.
Appendix B of I-D.ietf-ace-key-groupcomm describes how the format
of each 'sign_info_entry' can be generalized for possible future
registered algorithms having a different set of COSE capabilities.
If 'ecdh_info' is included in the request, the Group Manager MAY
include in the response the 'ecdh_info' parameter defined in ecdh-
info, with the same encoding.  Note that the field 'id' takes as
value the group name, or array of group names, for which the
corresponding 'ecdh_info_entry' applies to.
If 'gm_dh_pub_keys' is included in the request and any of the
groups that the client has been authorized to join is a pairwise-
only group, then the Group Manager MUST include in the response
the 'gm_dh_pub_keys' parameter defined in gm-dh-info, with the
same encoding.  Otherwise, the Group Manager MAY include the
'gm_dh_pub_keys' parameter.  Note that the field 'id' takes as
value the group name, or array of group names, for which the
corresponding 'gm_dh_pub_keys' applies to.
Note that, other than through the above parameters as defined in
Section 3.3 of I-D.ietf-ace-key-groupcomm, the joining node MAY have
previously retrieved this information by other means.  For example,
information conveyed in the 'sign_info' and 'ecdh_info' parameters
can be obtained by using the approach described in I-D.tiloca-core-
oscore-discovery, to discover the OSCORE group and the link to the
associated group-membership resource at the Group Manager (OPT2).
Additionally, if allowed by the used transport profile of ACE, the
joining node may instead provide the Access Token to the Group
Manager by other means, e.g., during a secure session establishment
(see Section 3.3.2 of I-D.ietf-ace-dtls-authorize).
The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post
response message defined in Section 5.10.1 of I-D.ietf-ace-oauth-
authz.
The first element 'id' is the group name of the OSCORE group or an
array of group names for the OSCORE groups for which the specified
information applies.
The second element 'ecdh_alg' is an CBOR integer or a CBOR text
string indicating the ECDH algorithm used in the OSCORE group
identified by 'gname'.  Values are taken from the "Value" column
of the "COSE Algorithms" Registry COSE.Algorithms.
The third element 'ecdh_parameters' is a CBOR array indicating the
parameters of the ECDH algorithm used in the OSCORE group
identified by 'gname'.  The CBOR array includes the following two
elements, and its exact content depends on the value of the
'ecdh_alg' element.
'ecdh_alg_capab', encoded as a CBOR array.  Its format and
value are the same of the COSE capabilities for the algorithm
indicated in 'ecdh_alg', as specified for that algorithm in the
"Capabilities" column of the "COSE Algorithms" Registry
COSE.Algorithms.
'ecdh_key_type_capab', encoded as a CBOR array.  Its format and
value are the same of the COSE capabilities for the COSE key
type of the keys used with the algorithm indicated in
'ecdh_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" Registry
COSE.Key.Types.
The fourth element 'ecdh_key_parameters' is a CBOR array
indicating the parameters of the keys used with the ECDH algorithm
in the OSCORE group identified by 'gname'.  Its content depends on
the value of 'ecdh_alg'.  In particular, its format and value are
the same of the COSE capabilities for the COSE key type of the
keys used with the algorithm indicated in 'ecdh_alg', as specified
for that key type in the "Capabilities" column of the "COSE Key
Types" Registry COSE.Key.Types.
The fifth element 'pub_key_enc' is CBOR integer indicating the
encoding of public keys used in the OSCORE group identified by
'gname'.  It takes value 1 ("COSE_Key") from the 'Confirmation
Key' column of the "CWT Confirmation Method" Registry
CWT.Confirmation.Methods, so indicating that public keys in the
OSCORE group are encoded as COSE Keys I-D.ietf-cose-rfc8152bis-
struct.  Future specifications may define additional values for
this parameter.
Additionally to what defined in I-D.ietf-ace-key-groupcomm, the
following applies.
The first element 'id' is the group name of the OSCORE group or an
array of group names for the OSCORE groups for which the specified
information applies.  In particular 'id' MUST NOT refer to OSCORE
groups that are signature-only groups.
The second element 'ecdh_alg' is a CBOR integer or a CBOR text
string indicating the ECDH algorithm used in the OSCORE group
identified by 'gname'.  Values are taken from the "Value" column
of the "COSE Algorithms" Registry COSE.Algorithms.
The third element 'ecdh_parameters' is a CBOR array indicating the
parameters of the ECDH algorithm used in the OSCORE group
identified by 'gname'.  Its format and value are the same of the
COSE capabilities array for the algorithm indicated in 'ecdh_alg',
as specified for that algorithm in the "Capabilities" column of
the "COSE Algorithms" Registry COSE.Algorithms.
The fourth element 'ecdh_key_parameters' is a CBOR array
indicating the parameters of the keys used with the ECDH algorithm
in the OSCORE group identified by 'gname'.  Its content depends on
the value of 'ecdh_alg'.  In particular, its format and value are
the same of the COSE capabilities array for the COSE key type of
the keys used with the algorithm indicated in 'ecdh_alg', as
specified for that key type in the "Capabilities" column of the
"COSE Key Types" Registry COSE.Key.Types.
The fifth element 'pub_key_enc' is a CBOR integer indicating the
encoding of public keys 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 an encoding that MUST explicitly provide
the full 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.
This format is consistent with every ECDH algorithm currently
considered in I-D.ietf-cose-rfc8152bis-algs, i.e., with algorithms
that have only the COSE key type as their COSE capability. sec-
future-cose-algs of this document describes how the format of each
'ecdh_info_entry' can be generalized for possible future registered
algorithms having a different set of COSE capabilities.
The 'gm_dh_pub_keys' parameter is an OPTIONAL parameter of the Token
Post response message defined in Section 5.10.1 of I-D.ietf-ace-
oauth-authz.
This parameter is used to require and retrieve from the Group Manager
its Diffie-Hellman public key used in the OSCORE group.  The Group
Manager has specifically a Diffie-Hellman public key if and only if
the OSCORE group is a pairwise-only group.  In this case, the early
retrieval of the Group Manager's public key is necessary in order for
the joining node to prove the possession of its own private key, upon
joining the group (see ssec-join-req-sending).
When used in the request, the 'gm_dh_pub_keys' parameter encodes the
CBOR simple value Null, to require the Diffie-Hellman public key that
the Group Manager uses in the OSCORE group.
The CDDL notation RFC8610 of the 'gm_dh_pub_keys' parameter formatted
as in the request is given below.
The 'gm_dh_pub_keys' parameter of the 2.01 (Created) response is a
CBOR array of one or more elements.  The number of elements is at
most the number of OSCORE groups the client has been authorized to
join.
Each element 'gm_dh_pub_keys_entry' contains information about the
Group Manager's Diffie-Hellman public keys, for one or more OSCORE
groups that are pairwise-only groups and that the client has been
authorized to join.  Each element is formatted as follows.
The first element 'id' is the group name of the OSCORE group or an
array of group names for the OSCORE groups for which the specified
information applies.  In particular 'id' MUST refer exclusively to
OSCORE groups that are pairwise-only groups.
The second element 'pub_key_enc' is a CBOR integer indicating the
encoding of public keys 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 an encoding that MUST explicitly provide
the full 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 third element 'pub_key' is a CBOR byte string, which encodes
the Group Manager's Diffie-Hellman public key in its original
binary representation made available to other endpoints in the
group.  In particular, the original binary representation complies
with the encoding specified by the 'pub_key_enc' parameter.  Note
that the public key provides the full set of information related
to its public key algorithm, i.e., the ECDH algorithm used in the
OSCORE group as pairwise key agreement algorithm.
The CDDL notation RFC8610 of the 'gm_dh_pub_keys' parameter formatted
as in the response is given below.
Additionally to what defined in Section 4.1.2.1 of I-D.ietf-ace-key-
groupcomm, the following applies.
The signature encoded in the 'client_cred_verify' parameter is
computed by the joining node by using the same private key and
countersignature algorithm it intends to use for signing messages
in the OSCORE group.  Moreover, N_S is as defined in sssec-
challenge-value.
The proof-of-possession (PoP) evidence included in
'client_cred_verify' is computed as defined below (REQ20).  In
either case, the N_S used to build the PoP input is as defined in
sssec-challenge-value.
If the group is not a pairwise-only group, the PoP evidence
MUST be a signature.  The joining node computes the signature
by using the same private key and signature algorithm it
intends to use for signing messages in the OSCORE group.
IKM is computed as a cofactor Diffie-Hellman shared secret,
see Section 5.7.1.2 of NIST-800-56A, using the ECDH
algorithm used in the OSCORE group.  The joining node uses
its own Diffie-Hellman private key and the Diffie-Hellman
public key of the Group Manager.  For X25519 and X448, the
procedure is described in Section 5 of RFC7748.
If the Token posting 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 specification.
If the Token posting 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.
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 of I-
D.ietf-ace-key-groupcomm.  The value of the 'error' field MUST be
set to 7 ("Group currently not active").
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 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 of I-D.ietf-ace-key-
groupcomm.  The value of the 'error' field MUST be set to 4 ("No
available node identifiers").
the public key of the joining node, either retrieved from the
'client_cred' parameter, or already stored as acquired from
previous interactions with the joining node.
A 4.00 (Bad Request) response from the Group Manager to the
joining node MUST have content format application/ace+cbor.  The
response payload is a CBOR map which MUST contain the 'sign_info'
parameter, including 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 supports the pairwise mode of
Group OSCORE, the CBOR map MUST contain also the 'ecdh_info'
parameter, including a single element 'ecdh_info_entry' pertaining
to the OSCORE group that the joining node has tried to join with
the Joining Request.
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 retrieved from the 'client_cred' parameter of
the Joining Request, or the one already stored 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) 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 7 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 uses (also) the pairwise mode of Group OSCORE, the
CBOR map MUST contain the 'gm_dh_pub_keys' parameter, whose
CBOR label is defined in ssec-iana-ace-groupcomm-parameters-
registry.  This parameter has the same format of
'gm_dh_pub_keys_res' defined in gm-dh-info.  In particular, it
includes a single element 'gm_dh_pub_keys_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 7 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 to
the joining node, possibly replacing the currently stored
value.
The Group Manager MUST return a 4.00 (Bad Request) response in
case it cannot retrieve a public key with an accepted format for
the joining node, either from the 'client_cred' parameter or as
already stored.
The 'client_cred' parameter MUST include a public key
compatible with the encoding, countersignature algorithm and
possible associated parameters indicated by the Group Manager.
The 'client_cred_verify' parameter MUST include a signature
computed as described in ssec-join-req-sending, by using the
public key indicated in the current 'client_cred' parameter,
with the countersignature algorithm and possible associated
parameters indicated by the Group Manager.  If the error
response from the Group Manager included the 'kdcchallenge'
parameter, the joining node MUST use its content as new N_S
challenge to compute the signature.
The Group Manager MUST return a 4.00 (Bad Request) response in
case an eligible public key for the joining node is neither
present in the 'client_cred' parameter nor already stored.
The Group Manager MAY return a 4.00 (Bad Request) response in case
all the following conditions hold.
The OSCORE group supports the pairwise mode of Group OSCORE.
The OSCORE group uses EdDSA public keys RFC8032.
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.3.1 of I-D.ietf-core-oscore-groupcomm).
The 'client_cred' parameter MUST include a public key
compatible with the encoding, signature or ECDH algorithm, and
possible associated parameters indicated by the Group Manager.
The 'client_cred_verify' parameter MUST include a PoP evidence
computed as described in ssec-join-req-sending, by using the
public key indicated 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.  If
the joining node is recognized as a current group member, e.g.
through the ongoing secure communication association, the Group
Manager MUST assign a new Sender ID different than the one
currently used by the joining node in the OSCORE group.
Consistently with Section 3 of I-D.ietf-core-oscore-groupcomm, the
Group Manager MUST assign a Sender ID that has never been assigned
before in the OSCORE group under the current Gid value.
The Group Manager MUST NOT assign a 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 stores the association between i) the public key
of the joining node; and ii) the Group Identifier (Gid), i.e. the
OSCORE ID Context, associated to the OSCORE group together with
the OSCORE Sender ID assigned to the joining node in the group.
The Group Manager MUST keep this association updated over time.
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).
Consistently with Section 3.1 of I-D.ietf-core-oscore-groupcomm,
the Group Manager MUST assign a OSCORE Sender ID that has not been
used in the OSCORE group since the latest time when the current
Gid value was assigned to the group.
If the joining node is recognized as a current group member, e.g.,
through the ongoing secure communication association, the
following also applies.
The Group Manager MUST assign a new OSCORE Sender ID different
than the one currently used by the joining node in the OSCORE
group.
The Group Manager MUST add the old, relinquished OSCORE Sender
ID of the joining node to the most recent set of stale Sender
IDs, in the collection associated to the group (see sssec-
stale-sender-ids).
The Group Manager stores the association between i) the public key
of the joining node; and ii) the Group Identifier (Gid), i.e., the
OSCORE ID Context, associated to the OSCORE group together with
the OSCORE Sender ID assigned to the joining node in the group.
The Group Manager MUST keep this association updated over time.
The 'gkty' parameter identifies a key of type
"Group_OSCORE_Input_Material object", defined in ssec-iana-
groupcomm-key-registry of this specification.
This parameter has as value a Group_OSCORE_Input_Material object,
which is defined in this specification and extends the
OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of I-D.ietf-ace-oscore-profile.  In particular, it
contains the additional parameters 'group_senderId' 'cs_alg',
'cs_params', 'cs_key_params', 'cs_key_enc', 'ecdh_alg',
'ecdh_params' and 'ecdh_key_params' defined in ssec-iana-security-
context-parameter-registry of this specification.
The 'ms' parameter MUST be present and includes the OSCORE
Master Secret value used in the OSCORE group.
The 'hkdf' parameter, if present, has as value the KDF
algorithm used in the OSCORE group.
The 'alg' parameter, if present, has as value the AEAD
algorithm used in the OSCORE group.
The 'salt' parameter, if present, has as value the OSCORE
Master Salt used in the OSCORE group.
The 'contextId' parameter MUST be present and has as value the
Group Identifier (Gid), i.e. the OSCORE ID Context of the
OSCORE group.
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 is not present if
the node joins the 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 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the OSCORE group.
This parameter takes values from the "Value" column of the
"COSE Algorithms" Registry COSE.Algorithms.
'sign_alg_capab', with the same encoding as defined in ssec-
token-post.  The value is the same as in the Token Post
response where the 'sign_parameters' value was non-null.
'sign_key_type_capab', with the same encoding as defined in
ssec-token-post.  The value is the same as in the Token Post
response where the 'sign_parameters' value was non-null.
The 'cs_key_params' parameter MAY be present and specifies the
parameters for the key used with the counter signature
algorithm.  This parameter is a CBOR array, with the same non-
null encoding and value as 'sign_key_parameters' of the ssec-
token-post.
The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members.  This
parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry CWT.Confirmation.Methods, so
indicating that public keys in the OSCORE group are encoded as
COSE Keys I-D.ietf-cose-rfc8152bis-struct.  Future
specifications may define additional values for this parameter.
If this parameter is not present, 1 ("COSE_Key") MUST be
assumed as default value.
The 'ecdh_alg' parameter, if present, specifies the ECDH
algorithm used in the OSCORE group, if this supports the
pairwise mode of Group OSCORE.  This parameter takes values
from the "Value" column of the "COSE Algorithms" Registry
COSE.Algorithms.  This parameter MUST be present if the OSCORE
group supports the pairwise mode of Group OSCORE, and MUST NOT
be present otherwise.
'ecdh_alg_capab', with the same encoding as defined in ecdh-
info.  The value is the same as in the Token Post response
where the ecdh_parameters' value is non-null.
'ecdh_key_type_capab', with the same encoding as defined in
ecdh-info.  The value is the same as in the Token Post
response where the 'ecdh_parameters' value is non-null.
The 'ecdh_key_params' parameter, if present, specifies the
parameters for the key used with the ECDH algorithm.  It MUST
be present if the 'ecdh_alg' parameter is present, and MUST NOT
be present otherwise.  This parameter is a CBOR array, with the
same non-null encoding and value of 'ecdh_key_parameters'
defined in ecdh-info.
The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (TBD3), which is defined in ssec-iana-
groupcomm-profile-registry of this specification.
The 'pub_keys' parameter, if present, includes the public keys
requested by the joining node by means of the 'get_pub_keys'
parameter in the Joining Request.  If public keys are encoded as
COSE_Keys, each of them has as 'kid' the Sender ID that the
corresponding owner has in the OSCORE group, thus used as group
member identifier encoded as a CBOR byte string (REQ12).
If the joining node has asked for the public keys of all the group
members, i.e. 'get_pub_keys' had value Null in the Joining
Request, then the Group Manager provides only the public keys of
the group members that are relevant to the joining node.  That is,
in such a case, 'pub_keys' includes only: i) the public keys of
the responders currently in the OSCORE group, in case the joining
node is configured (also) as requester; and ii) the public keys of
the requesters currently in the OSCORE group, in case the joining
node is configured (also) as responder or monitor.
The 'gkty' parameter identifies a key of type
"Group_OSCORE_Input_Material object", defined in ssec-iana-
groupcomm-key-registry of this document.
This parameter has as value a Group_OSCORE_Input_Material object,
which is defined in this document and extends the
OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of I-D.ietf-ace-oscore-profile.  In particular, it
contains the additional parameters 'group_senderId',
'pub_key_enc', 'sign_enc_alg', 'sign_alg', 'sign_params',
'ecdh_alg' and 'ecdh_params' defined in ssec-iana-security-
context-parameter-registry of this document.
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 'salt' parameter, if present, has as value the OSCORE
Master Salt used in the OSCORE group.  This parameter MAY be
omitted, if the Master Salt used in the group is the empty byte
string.  Otherwise, this parameter MUST be present.
The 'ms' parameter includes the OSCORE Master Secret value used
in the OSCORE group.  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 'pub_key_enc' parameter MUST be present and specifies the
encoding of public keys 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 an encoding that MUST explicitly provide the full
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.
'sign_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the Signature
Algorithm indicated in 'sign_alg', as specified for that
algorithm in the "Capabilities" column of the "COSE
Algorithms" Registry COSE.Algorithms.
'sign_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key
type of the keys used with the Signature Algorithm indicated
in 'sign_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" Registry
COSE.Key.Types.
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.
'ecdh_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the algorithm
indicated in 'ecdh_alg', as specified for that algorithm in
the "Capabilities" column of the "COSE Algorithms" Registry
COSE.Algorithms.
'ecdh_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key
type of the keys used with the algorithm indicated in
'ecdh_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" Registry
COSE.Key.Types.
The format of 'key' defined above is consistent with every
signature algorithm and ECDH algorithm currently considered in I-
D.ietf-cose-rfc8152bis-algs, i.e., with algorithms that have only
the COSE key type as their COSE capability. sec-future-cose-algs
of this document describes how the format of the 'key' parameter
can be generalized for possible future registered algorithms
having a different set of COSE capabilities.
The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (PROFILE_TBD), which is defined in
ssec-iana-groupcomm-profile-registry of this document.
The 'pub_keys' parameter, if present, includes the public keys
requested by the joining node by means of the 'get_pub_keys'
parameter in the Joining Request.
If the joining node has asked for the public keys of all the group
members, i.e., 'get_pub_keys' had value Null in the Joining
Request, then the Group Manager provides only the public keys of
the group members that are relevant to the joining node.  That is,
in such a case, 'pub_keys' includes only: i) the public keys of
the responders currently in the OSCORE group, in case the joining
node is configured (also) as requester; and ii) the public keys of
the requesters currently in the OSCORE group, in case the joining
node is configured (also) as responder or monitor.
The 'peer_identifiers' parameter, if present, includes the OSCORE
Sender ID of each group member whose public key is specified in
the 'pub_keys' parameter.  That is, a group member's Sender ID is
used as identifier for that group member (REQ12).
Finally, 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.  In
addition, the joining node maintains an association between each
public key retrieved from the 'pub_keys' parameter and the role(s)
that the corresponding group member has in the OSCORE group.
Furthermore, the CBOR map in the payload of the Joining Response MUST
also include the following new parameters, defined in ssec-iana-ace-
groupcomm-parameters-registry of this document.
The 'kdc_nonce' parameter, which is a CBOR byte string encoding a
dedicated nonce N_KDC generated by the Group Manager.  For N_KDC,
it is RECOMMENDED to use a 8-byte long random nonce.
The 'kdc_cred' parameter, which is a CBOR byte string encoding the
Group Manager's public key in its original binary representation.
The Group Manager's public key MUST be compatible with the
encoding, signature or ECDH algorithm, and possible associated
parameters used in the OSCORE group.
The 'kdc_cred_verify' parameter, which is a CBOR byte string
encoding a proof-of-possession (PoP) evidence computed by the
Group Manager.  The PoP evidence is computed over the nonce N_KDC,
which is specified in the 'kdc_nonce' parameter and taken as PoP
input.  The PoP evidence is computed as defined below.
If the group is not a pairwise-only group, the PoP evidence
MUST be a signature.  The Group Manager computes the signature
by using the signature algorithm used in the OSCORE group, as
well as its own private key associated to the public key
specified in the 'kdc_cred' parameter.
IKM is computed as a cofactor Diffie-Hellman shared secret,
see Section 5.7.1.2 of NIST-800-56A, using the ECDH
algorithm used in the OSCORE group.  The Group Manager uses
its own Diffie-Hellman private key and the Diffie-Hellman
public key of the joining node.  For X25519 and X448, the
procedure is described in Section 5 of RFC7748.
As a last action, 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.1 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.
Upon receiving the Joining Response, the joining node retrieves the
Group Manager's public key from the 'kdc_cred' parameter.  The
joining node MUST verify the proof-of-possession (PoP) evidence
specified in the 'kdc_cred_verify' parameter of the Joining Response
as defined below.
If the group is not a pairwise-only group, the PoP evidence is a
signature.  The joining node verifies it by using the public key
of the Group Manager, 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 joining node recomputes the MAC through the same process taken
by the Group Manager when computing the value of the
'kdc_cred_verify' parameter (see ssec-join-resp), with the
difference that the joining node uses its own Diffie-Hellman
private key and the Diffie-Hellman public key of the Group
Manager.  The verification succeeds if and only if the recomputed
MAC is equal to the MAC conveyed as PoP evidence in the Joining
Response.
In case of failed verification of the PoP evidence, the joining node
MUST stop processing the Joining Response and MAY send a new Joining
Request to the Group Manager (see ssec-join-req-sending).
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.
Absent the 'hkdf' parameter, the joining node considers HKDF
SHA-256 as HKDF Algorithm to use in the OSCORE group.
Absent the 'salt' parameter, the joining node considers the empty
byte string as Master Salt to use in the OSCORE group.
In addition, the joining node maintains an association between each
public key retrieved from the 'pub_keys' parameter and the role(s)
that the corresponding group member has in the OSCORE group.
Source authentication of a message sent within the group and
protected with Group OSCORE is ensured by means of a digital counter
signature embedded in the message (in group mode), or by integrity-
protecting the message with pairwise keying material derived from the
asymmetric keys of sender and recipient (in pairwise mode).
Source authentication of a message sent within the group and
protected with Group OSCORE is ensured by means of a digital
signature embedded in the message (in group mode), or by integrity-
protecting the message with pairwise keying material derived from the
asymmetric keys of sender and recipient (in pairwise mode).
The joining node is going to join the group exclusively as
monitor.  That is, it is not going to send messages to the group,
and hence to produce signatures with its own private key.  In this
case, the joining node is not required to provide its own public
key to the Group Manager, which thus does not have to perform any
check related to the public key encoding, or to a countersignature
algorithm and possible associated parameters for that joining
node.  In case that joining node still provides a public key 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 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
public key to the Group Manager, which thus does not have to
perform any check related to the public key encoding, to a
signature or ECDH algorithm, and to possible associated
parameters.  In case that joining node still provides a public key
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 proof-of-possession key is not compatible with the encoding
or with the counter signature algorithm and possible associated
parameters used in the OSCORE group.  In this case, the joining
node MUST provide a different compatible public key to the
Group Manager in the 'client_cred' parameter of the Joining
Request (see ssec-join-req-sending).  Then, the Group Manager
performs consistency checks on this latest provided public key
as per ssec-join-req-processing and, in case of success,
considers it as the public key associated to the joining node
in the OSCORE group.
The proof-of-possession key is not compatible with the
encoding, or with the signature or algorithm, and with possible
associated parameters used in the OSCORE group.  In this case,
the joining node MUST provide a different compatible public key
to the Group Manager in the 'client_cred' parameter of the
Joining Request (see ssec-join-req-sending).  Then, the Group
Manager performs consistency checks on this latest provided
public key as per ssec-join-req-processing and, in case of
success, considers it as the public key associated to the
joining node in the OSCORE group.
The 'key' parameter is formatted as defined in ssec-join-resp of
this specification, with the difference that it does not include
the 'group_SenderId' parameter.
The 'key' parameter is formatted as defined in ssec-join-resp of
this document, with the difference that it does not include the
'group_SenderId' parameter.
If the group member wants to retrieve the latest group keying
material as well as the Sender ID that it has in the OSCORE group, it
sends a Key Distribution Request to the Group Manager.
If the group member wants to retrieve the latest group keying
material as well as the OSCORE Sender ID that it has in the OSCORE
group, it sends a Key Distribution Request to the Group Manager.
The 'key' parameter is formatted as defined in ssec-join-resp of
this specification.  In particular, if the requesting group member
has exclusively the role of monitor, no 'group_SenderId' is
specified 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, no 'group_SenderId' is specified
within the 'key' parameter.
The Group Manager MUST return a 5.03 (Service Unavailable) response
in case the OSCORE group identified by GROUPNAME 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 of I-D.ietf-ace-key-groupcomm.  The value of the
'error' field MUST be set to 7 ("Group currently not active").
If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.00 (Unauthorized)
error response.  The response MUST have Content-Format set to
application/ace-groupcomm+cbor and is formatted as defined in
Section 4 of I-D.ietf-ace-key-groupcomm.  The value of the 'error'
field MUST be set to 1 ("Request inconsistent with the current
roles").
The Group Manager MUST return a 5.03 (Service Unavailable) response
in case the OSCORE group identified by GROUPNAME 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 of I-D.ietf-ace-key-groupcomm.  The value of the
'error' field MUST be set to 9 ("Group currently not active").
If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.01 (Unauthorized)
error response.  The response MUST have Content-Format set to
application/ace-groupcomm+cbor and is formatted as defined in
Section 4 of I-D.ietf-ace-key-groupcomm.  The value of the 'error'
field MUST be set to 1 ("Request inconsistent with the current
roles").
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 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 (OPT9).
The Group Manager determines and assigns a new Sender ID for
that group member, and replies with a Key Renewal Response
formatted as defined in Section 4.1.6.1 of I-D.ietf-ace-key-
groupcomm.  In particular, the CBOR Map in the response payload
includes a single parameter 'group_SenderId' defined in ssec-
iana-ace-groupcomm-parameters-registry of this document,
specifying the new Sender ID of the group member encoded as a
CBOR byte string.
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 (OPT9).
The Group Manager determines and assigns a new OSCORE Sender ID
for that group member, and replies with a Key Renewal Response
formatted as defined in Section 4.1.6.1 of I-D.ietf-ace-key-
groupcomm.  In particular, the CBOR Map in the response payload
includes a single parameter 'group_SenderId' defined in ssec-
iana-ace-groupcomm-parameters-registry of this document,
specifying the new Sender ID of the group member encoded as a
CBOR byte string.
Consistently with Section 2.4.3.1 of I-D.ietf-core-oscore-
groupcomm, the Group Manager MUST assign a new Sender ID that
has never been assigned before in the OSCORE group under the
current Gid value.
Consistently with Section 2.4.3.1 of I-D.ietf-core-oscore-
groupcomm, the Group Manager MUST assign a new Sender ID that
has not been used in the OSCORE group since the latest time
when the current Gid value was assigned to the group.
Furthermore, the Group Manager MUST add the old, relinquished
Sender ID of the group member to the most recent set of stale
Sender IDs, in the collection associated to the group (see
sssec-stale-sender-ids).
Each element (if any) of the inner CBOR array 'id_filter' is a
CBOR byte string (REQ12), which encodes the Sender ID of the group
member for which the associated public key is requested.
Upon receiving the Public Key Request, the Group Manager processes it
as per Section 4.1.3.1 or 4.1.3.2 of I-D.ietf-ace-key-groupcomm,
depending on the request method being FETCH or GET, respectively.
Additionally, if the Public Key Request uses the method FETCH, the
Group Manager silently ignores node identifiers included in the
'get_pub_keys' parameter of the request that are not associated to
any current group member.
The success Public Key Response is formatted as defined in
Section 4.1.3.1 or 4.1.3.2 of I-D.ietf-ace-key-groupcomm, depending
on the request method being FETCH or GET, respectively.
A group member may need to provide the Group Manager with its new
public key to use in the group from then on, hence replacing the
current one.  This can be the case, for instance, if the
countersignature algorithm and possible associated parameters used in
the OSCORE group have been changed, and the current public key is not
compatible with them.
To this end, the group member sends a Public Key Update Request
message to the Group Manager, as per Section 4.7 of I-D.ietf-ace-key-
groupcomm.  In particular, it sends a CoAP POST request to the
endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group
Manager.
Each element (if any) of the inner CBOR array 'id_filter' is a
CBOR byte string, which encodes the OSCORE Sender ID of the group
member for which the associated public key is requested (REQ12).
Upon receiving the Public Key Request, the Group Manager processes it
as per Section 4.1.3.1 or Section 4.1.3.2 of I-D.ietf-ace-key-
groupcomm, depending on the request method being FETCH or GET,
respectively.  Additionally, if the Public Key Request uses the
method FETCH, the Group Manager silently ignores node identifiers
included in the 'get_pub_keys' parameter of the request that are not
associated to any current group member.
The success Public Key Response is formatted as defined in
Section 4.1.3.1 or Section 4.1.3.2 of I-D.ietf-ace-key-groupcomm,
depending on the request method being FETCH or GET, respectively.
A group member may need to provide the Group Manager with its new
public key 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 public key is not compatible
with them.
To this end, the group member sends a Public Key Update Request
message to the Group Manager, as per Section 4.7 of I-D.ietf-ace-key-
groupcomm, with the following addition.
The group member computes the proof-of-possession (PoP) evidence
included in 'client_cred_verify' in the same way taken when
preparing a Joining Request for the OSCORE group in question, as
defined in ssec-join-req-sending (REQ20).
In particular, the group member sends a CoAP POST request to the
endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group
Manager.
The Group Manager MUST return a 5.03 (Service Unavailable)
response in case the OSCORE group identified by GROUPNAME 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 of I-D.ietf-ace-key-groupcomm.
The value of the 'error' field MUST be set to 7 ("Group currently
not active").
The N_S challenge used to build the proof-of-possession input is
computed as per point (1) in sssec-challenge-value (REQ21).
The Group Manager verifies the PoP challenge included in
'client_cred_verify' in the same way taken when processing a
Joining Request for the OSCORE group in question, as defined in
ssec-join-req-processing (REQ20).
The Group Manager MUST return a 5.03 (Service Unavailable)
response in case the OSCORE group identified by GROUPNAME 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 of I-D.ietf-ace-key-groupcomm.
The value of the 'error' field MUST be set to 9 ("Group currently
not active").
The N_S signature challenge is computed as per point (1) in sssec-
challenge-value (REQ20).
If the request is successfully processed, the Group Manager stores
the association between i) the new public key of the group member;
and ii) the Group Identifier (Gid), i.e. the OSCORE ID Context,
associated to the OSCORE group together with the OSCORE Sender ID
assigned to the group member in the group.  The Group Manager MUST
keep this association updated over time.
If the request is successfully processed, the Group Manager stores
the association between i) the new public key of the group member;
and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context,
associated to the OSCORE group together with the OSCORE Sender ID
assigned to the group member in the group.  The Group Manager MUST
keep this association updated over time.
A group member or a signature verifier may need to retrieve the
public key of the Group Manager.  To this end, the group member or
signature verifier sends a Group Manager Public Key Request message
to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/gm-pub-key at the Group Manager defined in ssec-
resource-gm-pub-key of this document, where GROUPNAME is the name of
the OSCORE group.
The payload of the 2.05 (Content) Group Manager Public Key Response
is a CBOR map, which MUST contain the following parameters defined in
ssec-iana-ace-groupcomm-parameters-registry.
The 'kdc_nonce' parameter, specifying a nonce generated by the
Group Manager.  This parameter is encoded like the 'kdc_nonce'
parameter in the Joining Response (see ssec-join-resp).
The 'kdc_cred' parameter, specifying the Group Manager's public
key.  This parameter is encoded like the 'kdc_cred' parameter in
the Joining Response (see ssec-join-resp).
The 'kdc_cred_verify' parameter, specifying a proof-of-possession
(PoP) evidence computed by the Group Manager.  This parameter is
encoded like the 'kdc_cred_verify' parameter in the Joining
Response (see ssec-join-resp).
The PoP evidence is computed over the nonce specified in the
'kdc_nonce' parameter and taken as PoP input, by means of the same
method used when preparing the Joining Response (see ssec-join-
resp).  In particular, if the group is a pairwise-only group, the
Group Manager computes IKM by using its own Diffie-Hellman private
key as well as the Diffie-Hellman public key of the requesting
client.
A group member verifies the PoP evidence by means of the same
method used when processing the Joining Response (see ssec-join-
resp).  In particular, if the group is a pairwise-only group, the
group member computes IKM by using its own Diffie-Hellman private
key as well as the Diffie-Hellman public key of the Group Manager.
A signature verifier verifies the PoP evidence as a signature, by
using the public key of the Group Manager, as well as the
signature algorithm used in the OSCORE group and possible
corresponding parameters.  Note that a signature verifier would
not receive a successful response from the Group Manager, in case
GROUPNAME denotes a pairwise-only group.
In case of successful verification of the PoP evidence, the group
member or signature verifier MUST store the obtained Group Manager's
public key, possibly replacing the currently stored one.
fig-gm-pub-key-req-resp gives an overview of the exchange described
above, while fig-gm-pub-key-req-resp-ex shows an example.
A signature verifier may need to retrieve data required to verify
signatures of messages protected with the group mode and sent to a
group (see Sections 3.1 and 8.5 of I-D.ietf-core-oscore-groupcomm).
To this end, the signature verifier sends a Signature Verification
Data Request message to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/verif-data at the Group Manager defined in ssec-
resource-verif-data of this document, where GROUPNAME is the name of
the OSCORE group.
The payload of the 2.05 (Content) Signature Verification Data
Response is a CBOR map, which has the format used for the Joining
Response message in ssec-join-resp, with the following differences.
From the Joining Response message, only the parameters 'gkty',
'key', 'num', 'exp' and 'ace-groupcomm-profile' are present.  In
particular, the 'key' parameter includes only the following data.
The parameters 'hkdf', 'contextId', 'pub_key_enc',
'sign_enc_alg', 'sign_alg', 'sign_params'.  These parameters
MUST be present.
The parameters 'alg' and 'ecdh_alg'.  These parameter MUST NOT
be present if the group is a signature-only group.  Otherwise,
they MUST be present.
The parameter 'group_enc_key' is also included, with CBOR label
defined in ssec-iana-ace-groupcomm-parameters-registry.  This
parameter specifies the Group Encryption Key of the OSCORE Group,
encoded as a CBOR byte string.  The Group Manager derives the
Group Encryption Key from the group keying material, as per
Section 2.1.6 of I-D.ietf-core-oscore-groupcomm.  This parameter
MUST be present.
In order to verify signatures in the group (see Section 8.5 of I-
D.ietf-core-oscore-groupcomm), the signature verifier relies on: the
data retrieved from the 2.05 (Content) Signature Verification Data
Response; the public keys of the group members signing the messages
to verify, that can be retrieved as defined in sec-pub-keys; and the
public key of the Group Manager, which can be retrieved as defined in
sec-gm-pub-key.
fig-verif-data-req-resp gives an overview of the exchange described
above, while fig-verif-data-req-resp-ex shows an example.
A group member may request the current status of the the OSCORE
group, i.e. active or inactive.  To this end, the group member sends
a Group Status Request to the Group Manager.
In particular, the group member sends a CoAP GET request to the
endpoint /ace-group/GROUPNAME/active at the Group Manager defined in
ssec-resource-active of this specification, where GROUPNAME is the
name of the OSCORE group.  The success Group Version Response is
formatted as defined in ssec-resource-active of this specification.
A group member may request the current status of the the OSCORE
group, i.e., active or inactive.  To this end, the group member sends
a Group Status Request to the Group Manager.
In particular, the group member sends a CoAP GET request to the
endpoint /ace-group/GROUPNAME/active at the Group Manager defined in
ssec-resource-active of this document, where GROUPNAME is the name of
the OSCORE group.
The payload of the 2.05 (Content) Group Status Response includes the
CBOR simple value True if the group is currently active, or the CBOR
simple value False otherwise.  The group is considered active if it
is set to allow new members to join, and if communication within the
group is fine to happen.
fig-key-status-req-resp gives an overview of the exchange described
above.
fig-key-status-req-resp gives an overview of the exchange described
above, while fig-key-status-req-resp-ex shows an example.
Furthermore, since it is not a group member, the node does not
take part to a possible group rekeying.  Thus, following a group
rekeying and the consequent change of Gid in a group, the node
would retain the old Gid value and cannot correctly associate
intercepted messages to the right group, especially if acting as
signature verifier in several groups.  This in turn prevents the
efficient verification of counter signatures, and especially the
retrieval of required, new public keys from the Group Manager.
Furthermore, since it is not a group member, the node does not
take part to a possible group rekeying.  Thus, following a group
rekeying and the consequent change of Gid in a group, the node
would retain the old Gid value and cannot correctly associate
intercepted messages to the right group, especially if acting as
signature verifier in several groups.  This in turn prevents the
efficient verification of signatures, and especially the retrieval
of required, new public keys from the Group Manager.
fig-group-names-req-resp gives an overview of the exchanges described
above.
fig-group-names-req-resp gives an overview of the exchanges described
above, while fig-group-names-req-resp-ex shows an example.
Other than after a spontaneous request to the Group Manager as
described in sec-leave-req, a node may be forcibly removed from the
OSCORE group, e.g. due to expired or revoked authorization.
Other than after a spontaneous request to the Group Manager as
described in sec-leave-req, a node may be forcibly removed from the
OSCORE group, e.g., due to expired or revoked authorization.
In either case, the Group Manager "forgets" the Birth Gid currently
associated to the leaving node in the OSCORE group.  This was stored
following the Joining Response sent to that node, after its latest
(re-)joining of the OSCORE group (see ssec-join-resp).
The Group Manager frees the OSCORE Sender ID value of the leaving
node.  However, this value MUST NOT become available for possible
upcoming joining nodes in the same group.
The Group Manager cancels the association between, on one hand,
the public key of the leaving node and, on the other hand, the
Group Identifier (Gid) associated to the OSCORE group together
with the freed OSCORE Sender ID value.  The Group Manager deletes
the public key of the leaving node, if that public key has no
remaining association with any pair (Gid, Sender ID).
If the application requires forward security, the Group Manager MUST
generate updated security parameters and group keying material, and
provide it to the remaining group members (see sec-group-rekeying-
process).  As a consequence, the leaving node is not able to acquire
the new security parameters and group keying material distributed
after its leaving.
In order to rekey the OSCORE group, the Group Manager distributes a
new Group Identifier (Gid), i.e. a new OSCORE ID Context; a new
OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for
that group.  When doing so, the Group Manager MUST increment the
version number of the group keying material, before starting its
distribution.
Consistently with Section 2.3 of I-D.ietf-core-oscore-groupcomm, the
Group Manager MUST assign a Gid that has never been assigned before
to the OSCORE group.
Furthermore, the Group Manager MUST preserve the same unchanged
Sender IDs for all group members.  This avoids affecting the
retrieval of public keys from the Group Manager as well as the
verification of group messages.
The Group Manager MUST support at least the following group rekeying
scheme.  Future application profiles may define alternative message
formats and distribution schemes.
Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile'
and 'exp' are present.
The 'ms' parameter of the 'key' parameter specifies the new OSCORE
Master Secret value.
The 'contextId' parameter of the 'key' parameter specifies the new
Gid used as OSCORE ID Context value.
The Group Manager separately sends a group rekeying message to each
group member to be rekeyed.
It is RECOMMENDED that the Group Manager gets confirmation of
successful distribution from the group members, and admits a maximum
number of individual retransmissions to non-confirming group members.
This approach requires group members to act (also) as servers, in
order to correctly handle unsolicited group rekeying messages from
the Group Manager.  In particular, if a group member and the Group
Manager use OSCORE RFC8613 to secure their pairwise communications,
the group member MUST create a Replay Window in its own Recipient
Context upon establishing the OSCORE Security Context with the Group
Manager, e.g. by means of the OSCORE profile of ACE I-D.ietf-ace-
oscore-profile.
Group members and the Group Manager SHOULD additionally support
alternative rekeying approaches that do not require group members to
act (also) as servers.  A number of such approaches are defined in
Section 4.4 of I-D.ietf-ace-key-groupcomm.  In particular, a group
member may subscribe for updates to the group-membership resource of
the group, at the endpoint /ace-group/GROUPNAME/ of the Group
Manager.  This can rely on CoAP Observe RFC7641 or on a full-fledged
Pub-Sub model I-D.ietf-core-coap-pubsub with the Group Manager acting
as Broker.
The Group Manager frees the OSCORE Sender ID value of the leaving
node.  This value MUST NOT become available for possible upcoming
joining nodes in the same group, until the group has been rekeyed
and assigned a new Group Identifier (Gid).
The Group Manager MUST add the relinquished Sender ID of the
leaving node to the most recent set of stale Sender IDs, in the
collection associated to the group (see sssec-stale-sender-ids).
The Group Manager cancels the association between, on one hand,
the public key of the leaving node and, on the other hand, the Gid
associated to the OSCORE group together with the freed Sender ID
value.  The Group Manager deletes the public key of the leaving
node, if that public key has no remaining association with any
pair (Gid, Sender ID).
Then, the Group Manager MUST generate updated security parameters and
group keying material, and provide it to the remaining group members
(see sec-group-rekeying-process).  As a consequence, the leaving node
is not able to acquire the new security parameters and group keying
material distributed after its leaving.
In order to rekey the OSCORE group, the Group Manager distributes a
new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new
OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for
that group.  When doing so, the Group Manager MUST increment the
version number of the group keying material, before starting its
distribution.
The Group Manager can reassign a Gid to the same group over that
group's lifetime, e.g., once the whole space of Gid values has
been used for the group in question.
Before rekeying the group, the Group Manager MUST check if the new
Gid to be distributed coincides with the Birth Gid of any of the
current group members (see ssec-join-resp).  If any of such "elder
members" is found in the group, the Group Manager MUST evict them
from the group.  That is, the Group Manager MUST terminate their
membership and MUST rekey the group in such a way that the new
keying material is not provided to those evicted elder members.
This also includes adding their relinquished Sender IDs to the
most recent set of stale Sender IDs, in the collection associated
to the group (see sssec-stale-sender-ids), before rekeying the
group.
Until a further following group rekeying, the Group Manager MUST
store the list of those latest-evicted elder members.  If any of
those nodes re-joins the group before a further following group
rekeying occurs, the Group Manager MUST NOT rekey the group upon
their re-joining.  When one of those nodes re-joins the group, the
Group Manager can rely, e.g., on the ongoing secure communication
association to recognize the node as included in the stored list.
Across the rekeying execution, the Group Manager MUST preserve the
same unchanged OSCORE Sender IDs for all group members intended to
remain in the group.  This avoids affecting the retrieval of public
keys from the Group Manager and the verification of group messages.
The Group Manager MUST support at least the group rekeying scheme
defined in sending-rekeying-msg.  Future application profiles may
define alternative message formats and group rekeying schemes, which
MUST comply with the functional steps defined in Section 3.2 of I-
D.ietf-core-oscore-groupcomm.
It is RECOMMENDED that the Group Manager gets confirmation of
successful distribution from the group members, and admits a maximum
number of individual retransmissions to non-confirming group members.
Once completed the group rekeying process, the Group Manager creates
a new empty set X' of stale Sender IDs associated to the version of
the newly distributed group keying material.  Then, the Group Manager
MUST add the set X' to the collection of stale Sender IDs associated
to the group (see sssec-stale-sender-ids).
If the Gid is formatted as described in Appendix C of I-D.ietf-core-
oscore-groupcomm, the Group Prefix can be used as a hint to determine
the right Group Manager, as long as no collisions among Group
Prefixes are experienced.  Otherwise, a group member needs to contact
the Group Manager of each group, e.g. by first requesting only the
version of the current group keying material (see sec-version) and
then possibly requesting the current keying material (see ssec-
updated-key-only).
If the Gid is formatted as described in Appendix C of I-D.ietf-core-
oscore-groupcomm, the Group Prefix can be used as a hint to determine
the right Group Manager, as long as no collisions among Group
Prefixes are experienced.  Otherwise, a group member needs to contact
the Group Manager of each group, e.g., by first requesting only the
version of the current group keying material (see sec-version) and
then possibly requesting the current keying material (see ssec-
updated-key-only).
Furthermore, some of these group members can be in multiple groups,
all of which associated to the same Group Manager.  In this case,
these group members may also not have sufficient information to
determine which exact group they should refer to, when contacting the
right Group Manager.  Hence, they need to contact a Group Manager
multiple times, i.e. separately for each group they belong to and
associated to that Group Manager.
The Group Manager SHOULD use the same default values defined in
Section 3.2 of RFC8613 for both the HKDF algorithm and the AEAD
algorithm used in the group.
The Group Manager SHOULD use the following default values for the
algorithm, algorithm parameters and key parameters used to
countersign messages in the group, consistently with the "COSE
Algorithms" Registry COSE.Algorithms, the "COSE Key Types" Registry
COSE.Key.Types and the "COSE Elliptic Curves" Registry
COSE.Elliptic.Curves.
For the algorithm 'cs_alg' used to countersign messages in the
group, the signature algorithm EdDSA RFC8032.
The array , indicating the elliptic
curve Ed25519 RFC8032, in case EdDSA is assumed or specified
for 'cs_alg'.
The array , in case PS256, PS384 or PS512 RFC8017
is specified for 'cs_alg'.
The array [OKP, Ed25519] as pair (key type, elliptic curve), in
case EdDSA is assumed or specified for 'cs_alg' and Ed25519 is
assumed or specified within the second array of 'cs_params'.
The array [OKP, Ed448] as pair (key type, elliptic curve), in
case EdDSA is assumed or specified for 'cs_alg' and the
elliptic curve Ed448 RFC8032 is specified within the second
array of 'cs_params'.
The array [EC2, P-256] as pair (key type, elliptic curve), in
case ES256 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-256 is assumed or specified within the second array of
'cs_params'.
The array [EC2, P-384] as pair (key type, elliptic curve), in
case ES384 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-384 is specified within the second array of
'cs_params'.
The array [EC2, P-521] as pair (key type, elliptic curve), in
case ES512 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-521 is specified within the second array of
'cs_params'.
The array [RSA] indicating RSA as key type, in case PS256,
PS384 or PS512 RFC8017 is specified for 'cs_alg'.
For the 'cs_key_enc' encoding of the public keys of the group
members, COSE_Key from the "CWT Confirmation Methods" Registry
CWT.Confirmation.Methods.
If the group supports the pairwise mode of Group OSCORE, the Group
Manager SHOULD use the following default values for the algorithm,
algorithm parameters and key parameters used to compute static-static
Diffie-Hellman shared secrets, consistently with the "COSE
Algorithms" Registry COSE.Algorithms, the "COSE Key Types" Registry
COSE.Key.Types and the "COSE Elliptic Curves" Registry
COSE.Elliptic.Curves.
For the algorithm 'ecdh_alg' used to compute static-static Diffie-
Hellman shared secrets, the ECDH algorithm ECDH-SS + HKDF-256
specified in Section 6.3.1 of I-D.ietf-cose-rfc8152bis-algs.
The array , indicating the elliptic curve
X25519 RFC8032, in case EdDSA is assumed or specified for
'cs_alg'.
The array [OKP, X25519] as pair (key type, elliptic curve), in
case EdDSA is assumed or specified for 'cs_alg' and X25519 is
assumed or specified within the second array of 'ecdh_params'.
The array [OKP, X448] as pair (key type, elliptic curve), in
case EdDSA is assumed or specified for 'cs_alg' and the
elliptic curve X448 RFC8032 is specified within the second
array of 'ecdh_params'.
The array [EC2, P-256] as pair (key type, elliptic curve), in
case ES256 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-256 is assumed or specified within the second array of
'ecdh_params'.
The array [EC2, P-384] as pair (key type, elliptic curve), in
case ES384 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-384 is specified within the second array of
'ecdh_params'.
The array [EC2, P-521] as pair (key type, elliptic curve), in
case ES512 RFC6979 is specified for 'cs_alg' and the elliptic
curve P-521 is specified within the second array of
'ecdh_params'.
Furthermore, some of these group members can be in multiple groups,
all of which associated to the same Group Manager.  In this case,
these group members may also not have sufficient information to
determine which exact group they should refer to, when contacting the
right Group Manager.  Hence, they need to contact a Group Manager
multiple times, i.e., separately for each group they belong to and
associated to that Group Manager.
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 Manager MUST support at least the group rekeying scheme
defined in this section.
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.
From the Joining Response, only the parameters 'gkty', 'key',
'num', 'exp', and 'ace-groupcomm-profile' are present.  In
particular, the 'key' parameter includes only the following data.
The 'ms' parameter, specifying the new OSCORE Master Secret
value.
The 'contextId' parameter, specifying the new Gid to use as
OSCORE ID Context value.
Optionally, the 'salt' value, specifying the new OSCORE Master
Salt value.
The parameter 'stale_node_ids' MUST also be included, with CBOR
label defined in ssec-iana-ace-groupcomm-parameters-registry.
This parameter is encoded as a CBOR array, where each element is
encoded as a CBOR byte string.  The CBOR array has to be intended
as a set, i.e., the order of its elements is irrelevant.  The
parameter is populated as follows.
The Group Manager creates an empty CBOR array ARRAY.
The Group Manager considers the collection of stale Sender IDs
associated to the group (see sssec-stale-sender-ids), and takes
the most recent set X, i.e., the set associated to the current
version of the group keying material about to be relinquished.
The parameter 'stale_node_ids' takes ARRAY as value.
The Group Manager separately sends a group rekeying message formatted
as defined above to each group member to be rekeyed.
This distribution approach requires group members to act (also) as
servers, in order to correctly handle unsolicited group rekeying
messages from the Group Manager.  In particular, if a group member
and the Group Manager use OSCORE RFC8613 to secure their pairwise
communications, the group member MUST create a Replay Window in its
own Recipient Context upon establishing the OSCORE Security Context
with the Group Manager, e.g., by means of the OSCORE profile of ACE
I-D.ietf-ace-oscore-profile.
Group members and the Group Manager SHOULD additionally support
alternative distribution approaches that do not require group members
to act (also) as servers.  A number of such approaches are defined in
Section 4.4 of I-D.ietf-ace-key-groupcomm.  In particular, a group
member may subscribe for updates to the group-membership resource of
the group, at the endpoint /ace-group/GROUPNAME/ of the Group
Manager.  This can rely on CoAP Observe RFC7641 or on a full-fledged
Pub-Sub model I-D.ietf-core-coap-pubsub with the Group Manager acting
as Broker.
Once received the new group keying material, a group member proceeds
as follows.
As per Section 3.2 of I-D.ietf-core-oscore-groupcomm, the group
member MUST delete all its Recipient Contexts whose corresponding
Recipient ID is included in the set of specified stale Sender IDs.
If the group rekeying scheme defined in sending-rekeying-msg is used,
this information is 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.
The group member has not missed any group rekeying.  That is, the
old keying material owned by the group member has version number
V, while the received new keying material has version number V' =
(V + 1).  In such a case, the group member simply installs the new
keying material and derives the corresponding new Security
Context.
The group member has missed one or more group rekeying instances.
That is, the old keying material owned by the group member has
version number V, while the received new keying material has
version number V' > (V + 1).  In such a case, the group member
MUST proceed as defined in missed-rekeying.
The group member has received keying material not newer than the
stored one.  That is, the stored keying material owned by the
group member has version number V, while the received keying
material has version number V' < (V + 1).  In such a case, the
group member MUST ignore the received rekeying messages and MUST
NOT install the received keying material.
A group member can realize to have missed one or more rekeying
instances in one of the ways discussed below.  In the following, V
denotes the version number of the old keying material stored by the
group member, while V' denotes the version number of the latest,
possibly just distributed, keying material.
a.  The group member has participated to a rekeying process that has
distributed new keying material with version number V' > (V + 1), as
discussed in receiving-rekeying-msg.
b.  The group member has obtained the latest keying material from the
Group Manager, as a response to a Key Distribution Request (see ssec-
updated-key-only) or to a Joining Request when re-joining the group
(see ssec-join-req-sending).  In particular, V is different than V'
specified by the 'num' parameter in the response.
c.  The group member has obtained the public keys of other group
members, through a Public Key Request-Response exchange with the
Group Manager (see sec-pub-keys).  In particular, V is different than
V' specified by the 'num' parameter in the response.
d.  The group member has performed a Version Request-Response
exchange with the Group Manager (see sec-version).  In particular, V
is different than V' specified by the 'num' parameter in the
response.
In either case, the group member MUST delete the stored keying
material with version number V.
In case case (a) or case (b) applies, the group member MUST perform
the following actions.
The group member MUST NOT install the latest keying material yet.
In case (c) or (d) applies, the group member SHOULD perform the
following actions.
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).
In case (c) or (d) applies, the group member can alternatively
perform the following actions.
The group member re-joins the group (see ssec-join-req-sending).
When doing so, the group member MUST re-join with the same roles
it currently has in the group, and MUST request the Group Manager
for the public keys of all the current group members.  That is,
the 'get_pub_keys' parameter of the Joining Request MUST be
present and MUST be set to the CBOR simple value Null.
When receiving the Joining Response (see ssec-join-resp-processing
and ssec-join-resp-processing), the group member retrieves the
public keys specified in the 'pub_keys' parameter.  Then, the
group member MUST delete each of its stored Recipient Contexts
that does not include any of the public keys received from the
Group Manager.
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 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.
In particular, the node sends a CoAP FETCH request to the endpoint
/ace-group/GROUPNAME/stale-sids at the Group Manager defined in ssec-
resource-stale-sids of this document, where GROUPNAME is the name of
the OSCORE group.
The payload of the Stale Sender IDs Request MUST include a CBOR
unsigned integer.  This encodes the version number V of the most
recent group keying material owned and installed by the requesting
client.
The handler MUST respond with a 4.00 (Bad Request) response, if the
request is not formatted correctly.  Also, the handler MUST respond
with a 4.00 (Bad Request) response, if the specified version number V
is greater or equal than the version number V' associated to the
latest keying material in the group, i.e., if V >= V'.
Otherwise, the handler responds with a 2.05 (Content) Stale Sender
IDs Response.  The payload of the response is formatted as defined
below, where SKEW = (V' - V).
The Group Manager considers ITEMS as the current number of sets
stored in the collection of stale Sender IDs associated to the
group (see sssec-stale-sender-ids).
If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a
payload.
Otherwise, the payload of the Stale Sender IDs Response MUST
include a CBOR array, where each element is encoded as a CBOR byte
string.  The CBOR array has to be intended as a set, i.e., the
order of its elements is irrelevant.  The Group Manager populates
the CBOR array as follows.
The Group Manager creates an empty CBOR array ARRAY and an
empty set X.
The Group Manager considers the SKEW most recent sets stored in
the collection of stale Sender IDs associated to the group.
Note that the most recent set is the one associate to the
latest version of the group keying material.
The Group Manager copies all the Sender IDs from the selected
sets into X.  When doing so, the Group Manager MUST discard
duplicates.  That is, the same Sender ID MUST NOT be present
more than once in the final content of X.
Finally, ARRAY is specified as payload of the Stale Sender IDs
Response.  Note that ARRAY might result in the empty CBOR
array.
fig-stale-ids-req-resp gives an overview of the exchange described
above, while fig-stale-ids-req-resp-ex shows an example.
This section always applies, as related to common configuration
parameters.
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 format 'pub_key_enc' used to encode the public keys in the
group, the Group Manager SHOULD use a CBOR Web Token (CWT)RFC8392
or an unprotected CWT Claim Set I-D.ietf-rats-uccs.
For the maximum number 'max_stale_sets' of stored sets of stale
Sender IDs, the Group Manager SHOULD store at most N = 3 sets of
stale Sender IDs in the collection associated to the group (see
sssec-stale-sender-ids).
This section applies if the group uses (also) the group mode of Group
OSCORE.
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.
The Group Manager SHOULD use the following default values for the
Signature Algorithm 'sign_alg' and related parameters 'sign_params',
consistently with the "COSE Algorithms" Registry COSE.Algorithms, the
"COSE Key Types" Registry COSE.Key.Types and the "COSE Elliptic
Curves" Registry COSE.Elliptic.Curves.
For the Signature Algorithm 'sign_alg' used to sign messages
protected with the group mode, the signature algorithm EdDSA
RFC8032.
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 Ed25519 RFC8032.
The array , in case PS256, PS384 or PS512 RFC8017
is specified for 'sign_alg'.  In particular, this indicates to
use the COSE key type RSA.
This section applies if the group uses (also) the pairwise mode of
Group OSCORE.
For the AEAD Algorithm 'alg' used to encrypt messages protected with
the pairwise mode, the Group Manager SHOULD use the same default
value defined in Section 3.2 of RFC8613, i.e., AES-CCM-16-64-128
(COSE algorithm encoding: 10).
For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related
parameters 'ecdh_params', the Group Manager SHOULD use the following
default values, consistently with the "COSE Algorithms" Registry
COSE.Algorithms, the "COSE Key Types" Registry COSE.Key.Types and the
"COSE Elliptic Curves" Registry COSE.Elliptic.Curves.
For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to
compute static-static Diffie-Hellman shared secrets, the ECDH
algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of I-
D.ietf-cose-rfc8152bis-algs.
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.
Before sending the Joining Response, the Group Manager MUST verify
that the joining node actually owns the associated private key.  To
this end, the Group Manager can rely on the proof-of-possession
challenge-response defined in sec-joining-node-to-GM.  Alternatively,
the joining node can use its own public key as asymmetric proof-of-
possession key to establish a secure channel with the Group Manager,
e.g. as in Section 3.2.2 of I-D.ietf-ace-dtls-authorize.  However,
this requires such proof-of-possession key to be compatible with the
encoding as well as with the countersignature algorithm and possible
associated parameters used in the OSCORE group.
Before sending the Joining Response, the Group Manager MUST verify
that the joining node actually owns the associated private key.  To
this end, the Group Manager can rely on the proof-of-possession
challenge-response defined in sec-joining-node-to-GM.  Alternatively,
the joining node can use its own public key as asymmetric proof-of-
possession key to establish a secure channel with the Group Manager,
e.g., as in Section 3.2.2 of I-D.ietf-ace-dtls-authorize.  However,
this requires such proof-of-possession key to be compatible with the
encoding, as well as with the signature algorithm, and possible
associated parameters used in the OSCORE group.
A node may have joined multiple OSCORE groups under different non-
synchronized Group Managers.  Therefore, it can happen that those
OSCORE groups have the same Group Identifier (Gid).  It follows that,
upon receiving a Group OSCORE message addressed to one of those
groups, the node would have multiple Security Contexts matching with
the Gid in the incoming message.  It is up to the application to
decide how to handle such collisions of Group Identifiers, e.g. by
trying to process the incoming message using one Security Context at
the time until the right one is found.
With reference to the Joining Request message in ssec-join-req-
sending, the proof-of-possession signature included in
'client_cred_verify' is computed over the challenge N_C | N_S,
where | denotes concatenation.
For the N_C challenge share, 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.
A node may have joined multiple OSCORE groups under different non-
synchronized Group Managers.  Therefore, it can happen that those
OSCORE groups have the same Group Identifier (Gid).  It follows that,
upon receiving a Group OSCORE message addressed to one of those
groups, the node would have multiple Security Contexts matching with
the Gid in the incoming message.  It is up to the application to
decide how to handle such collisions of Group Identifiers, e.g., by
trying to process the incoming message using one Security Context at
the time until the right one is found.
With reference to the Joining Request message in ssec-join-req-
sending, the proof-of-possession (PoP) evidence included in
'client_cred_verify' is computed over an input including also N_C |
N_S, where | denotes concatenation.
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.
If the Access Token is not explicitly posted to the /authz-info
endpoint of the Group Manager, then N_S is computed as a 32-byte
long challenge share.  For an example, see point (2) of sssec-
challenge-value.
If the Access Token is not explicitly posted to the /authz-info
endpoint of the Group Manager, then N_S is computed as a 32-byte
long challenge.  For an example, see point (2) of sssec-challenge-
value.
Section 7 of I-D.ietf-ace-oscore-profile as well Appendix B.2 of
RFC8613 recommend the use of 8-byte random values as well.  Unlike
in those cases, the values of N_C and N_S considered in this
specification are not used for as sensitive operations as the
derivation of a Security Context, and thus do not have possible
implications in the security of AEAD ciphers.
As long as the Group Manager preserves the same N_S value currently
associated to an Access Token, i.e. the latest value provided to a
Client in a 'kdcchallenge' parameter, the Client is able to
successfully reuse the same signature challenge for multiple Joining
Requests to that Group Manager.
In particular, the Client can reuse the same N_C value for every
Joining Request to the Group Manager, and combine it with the same
unchanged N_S value.  This results in reusing the same signature
challenge for producing the signature to include in the
'client_cred_verify' parameter of the Joining Requests.
Unless the Group Manager maintains a list of N_C values already used
by that Client since the latest update to the N_S value associated to
the Access Token, the Group Manager can be forced to falsely believe
that the Client possesses its own private key at that point in time,
upon verifying the signature in the 'client_cred_verify' parameter.
Note to RFC Editor: Please replace all occurrences of "[[This
specification]]" with the RFC number of this specification and delete
this paragraph.
Section 7 of I-D.ietf-ace-oscore-profile as well Section B.2 of
RFC8613 recommend the use of 8-byte random values as well.  Unlike
in those cases, the values of N_C and N_S considered in this
document are not used for as sensitive operations as the
derivation of a Security Context, and thus do not have possible
implications in the security of AEAD ciphers.
As long as the Group Manager preserves the same N_S value currently
associated to an Access Token, i.e., the latest value provided to a
Client in a 'kdcchallenge' parameter, the Client is able to
successfully reuse the same proof-of-possession (PoP) input for
multiple Joining Requests to that Group Manager.
In particular, the Client can reuse the same N_C value for every
Joining Request to the Group Manager, and combine it with the same
unchanged N_S value.  This results in reusing the same PoP input for
producing the PoP evidence to include in the 'client_cred_verify'
parameter of the Joining Requests.
Unless the Group Manager maintains a list of N_C values already used
by that Client since the latest update to the N_S value associated to
the Access Token, the Group Manager can be forced to falsely believe
that the Client possesses its own private key at that point in time,
upon verifying the PoP evidence in the 'client_cred_verify'
parameter.
Note to RFC Editor: Please replace all occurrences of "[[This
document]]" with the RFC number of this specification and delete this
paragraph.
The following registrations are done for the OAuth Parameters
Registry following the procedure specified in Section 11.2 of
RFC6749.
The following registrations are done for the OAuth Parameters CBOR
Mappings Registry following the procedure specified in Section 8.10
of I-D.ietf-ace-oauth-authz.
Profile: "coap_group_oscore_app", defined in ssec-iana-groupcomm-
profile-registry of this specification.
Description: A Group_OSCORE_Input_Material object encoded as
described in ssec-join-resp of this specification.
Profile: "coap_group_oscore_app", defined in ssec-iana-groupcomm-
profile-registry of this document.
Description: A Group_OSCORE_Input_Material object encoded as
described in ssec-join-resp of this document.
This specification registers the 'application/aif-groupcomm-
oscore+cbor' media type for the AIF specific data model AIF-OSCORE-
GROUPCOMM defined in sec-format-scope of .
This registration follows the procedures specified in RFC6838.
This document registers the 'application/aif-groupcomm-oscore+cbor'
media type for the AIF specific data model AIF-OSCORE-GROUPCOMM
defined in sec-format-scope of .  This registration
follows the procedures specified in RFC6838.
Security considerations: See sec-security-considerations of [[This
specification]].
Security considerations: See sec-security-considerations of [[This
document]].
This specification establishes the IANA "Group OSCORE Roles"
Registry.  The Registry has been created to use the "Expert Review"
registration procedure RFC8126.  Expert review guidelines are
provided in ssec-iana-expert-review.
This document establishes the IANA "Group OSCORE Roles" Registry.
The Registry has been created to use the "Expert Review" registration
procedure RFC8126.  Expert review guidelines are provided in ssec-
iana-expert-review.
The Reference column for all of these entries will be [[This
specification]].
The Reference column for all of these entries will be [[This
document]].
IANA is asked to register the following entry in the "ACE Scope
Semantics" registry defined in Section 10.13 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry in the "ACE Groupcomm
Errors" registry defined in Section 10.13 of I-D.ietf-ace-key-
groupcomm.
Description: Signatures not used in the group.
Description: Operation permitted only to signature verifiers.