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

Commentary: See discussion at :
Mailing list commentary: Hi ! , I think now I understand your idea and it makes sense to me . Some comments in line below . Best , /Marco = = > MT Step ( 1 ) is intended to allow access to the group - membership resource at the Group Manager ( GM ) , to get the keying material for communicating in the group . Practically , the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining . MT As above , the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining . But I agree that we should inform the other group members of that role , i.e. " allowed to send requests " and/or " allowed to send responses " . MT This can be one more parameter in the Joining Response or in the Public Key Response , when request public keys of group members are included . Together with the array of public keys , we can have a same - ordered array of roles echoing the roles from the scope of the Access Token above . Each element of the array can possibly be an array of roles . How does it sound ? MT Right , if it 's " requester"-only . MT What I understand from 's proposal is essentially enabling at each group member a list of valid request signers and valid response signers . MT Just to complement , this is all fine for this level of " filtering " , i.e. " this group member can send requests / responses or not " . We have a separate draft at [ 1 ] , defining a new Group OSCORE profile of ACE , to enforce access control within the group , i.e. to access group members ' resources after having joined , i.e. as a group member towards another group member . That is , that profile considers a granularity of exact REST methods and resources , i.e. as fine - grained as ACE can be . Also , it enables having together ACE - based access control and Group OSCORE , which is so far not possible with other profiles . The current version -01 in the datatracker defines a " full mode " where both OSCORE and Group OSCORE are considered as security protocols between and RS . We plan to submit soon an updated version , focusing more on a lighter , intended - to - be main mode , that focuses on using only Group OSCORE as security protocol between and RS . [ 1 ] < = = Best , /Marco
GROUPNAME and NODENAME are used to indicate the variant parts of
the resource endpoint, i.e. "gid" and "node" URI path in I-D.ietf-
ace-key-groupcomm.
If the application requires backward and forward security, the Group
Manager MUST generate new security parameters and group keying
material, and distribute them to the group (rekeying) upon membership
changes.
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.
Parameters and group keying material include a new Group Identifier
(Gid) for the group and a new Master Secret for the OSCORE Common
Security Context of that group (see Section 2 of I-D.ietf-core-
oscore-groupcomm).  Once completed a group rekeying, the GM MUST
increment the version number of the group keying material.
The keying material distributed through a group rekeying MUST include
a new Group Identifier (Gid) for the group and a new value for the
Master Secret parameter of the OSCORE Common Security Context of that
group (see Section 2 of I-D.ietf-core-oscore-groupcomm).  Also, it
MAY include a new value for the Master Salt parameter of the 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 name of the OSCORE group to join under the Group Manager
is encoded as a CBOR text string.
The role in the OSCORE group to join is encoded as a text string.
Accepted values of roles are: "requester", "responder", and
"monitor".  Possible combinations are: ["requester" ,
"responder"]; ["requester" , "monitor"].
The group name of the OSCORE group to join under the Group
Manager is encoded as a CBOR text string (REQ1).
Accepted values for role identifiers in the OSCORE group to
join are: "requester", "responder", and "monitor" (REQ2).
Possible combinations are: ["requester" , "responder"];
["requester" , "monitor"].  Each role identifier MUST be
encoded as a CBOR integer (REQ2), by using for abbreviation the
values specified in fig-role-cbor-values (OPT7).
The AS MUST include the 'exp' 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 'scope' parameter, when the value included
in the Access Token differs from the one specified by the joining
node in the request.  In such a case, the second element of
'scope' MUST be present and includes the role or CBOR array of
roles that the joining node is actually authorized to take in the
OSCORE group, encoded as specified in ssec-auth-req 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 'scope' parameter, when the value included
in the Access Token differs from the one specified by the joining
node in the request.  In such a case, the second element of each
scope entry MUST be present, and includes the role or CBOR array
of roles that the joining node is actually authorized to take in
the OSCORE group for that scope entry, encoded as specified in
ssec-auth-req of this document.
The handler expects a GET request.
The handler verifies that the group identifier of the /group-
manager/GROUPNAME/active path is a subset of the 'scope' stored in
the Access Token associated to the requesting client.  If
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 expected.
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.tiloca-
ace-oscore-gm-admin.
The 'rsnonce' parameter contains a dedicated 8-byte nonce N_S
generated by the Group Manager.  The joining node may use this
nonce in order to prove the possession of its own private key,
upon joining the group (see ssec-join-req-sending).
'sign_parameters' takes values from the "Counter Signature
Parameters" Registry (see Section 9.1 of I-D.ietf-core-oscore-
groupcomm).  Its structure depends on the value of 'sign_alg'.
If no parameters of the counter signature algorithm are
specified, 'sign_parameters' MUST be encoding the CBOR simple
value Null.
'sign_key_parameters' takes values from the "Counter Signature
Key Parameters" Registry (see Section 9.2 of I-D.ietf-core-
oscore-groupcomm).  Its structure depends on the value of
'sign_alg'.  If no parameters of the key used with the counter
signature algorithm are specified, 'sign_key_parameters' MUST
be encoding the CBOR simple value Null.
'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation
Key' column of the "CWT Confirmation Method" Registry defined
in I-D.ietf-ace-cwt-proof-of-possession, so indicating that
public keys in the OSCORE group are encoded as COSE Keys
RFC8152.  Future specifications may define additional values
for this parameter.
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.
The 'rsnonce' parameter contains a dedicated nonce N_S generated
by the Group Manager.  For the N_S value, it is RECOMMENDED to use
a 8-byte long random nonce.  The joining node may use this nonce
in order to prove the possession of its own private key, upon
joining the group (see ssec-join-req-sending).
TODO: have 'sign_info' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
'sign_parameters' takes values from the "Counter Signature
Parameters" Registry (see Section 11.1 of I-D.ietf-core-oscore-
groupcomm).  Its structure depends on the value of 'sign_alg'.
If no parameters of the counter signature algorithm are
specified, 'sign_parameters' MUST be encoding the CBOR simple
value Null.
'sign_key_parameters' takes values from the "Counter Signature
Key Parameters" Registry (see Section 11.2 of I-D.ietf-core-
oscore-groupcomm).  Its structure depends on the value of
'sign_alg'.  If no parameters of the key used with the counter
signature algorithm are specified, 'sign_key_parameters' MUST
be encoding the CBOR simple value Null.
TODO: have 'pub_key_enc' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
If 'pub_key_enc' is present in the response, it takes value 1
("COSE_Key") from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in I-D.ietf-ace-cwt-proof-
of-possession, so indicating that public keys in the OSCORE group
are encoded as COSE Keys RFC8152.  Future specifications may
define additional values for this parameter.
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.
'cnonce' contains a dedicated 8-byte nonce N_C generated by the
joining node.
'cnonce' contains a dedicated nonce N_C generated by the joining
node.  For the N_C value, it is RECOMMENDED to use a 8-byte long
random nonce.
If the Token posting has relied on the DTLS profile of ACE I-
D.ietf-ace-dtls-authorize and the joining node included 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"
defined in Section 7 of I-D.ietf-ace-mqtt-tls-profile.
If the Token posting has relied on the DTLS profile of ACE I-
D.ietf-ace-dtls-authorize and the joining node included 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.
A 4.00 Bad Request response from the Group Manager to the joining
node MUST have content format application/ace-group+cbor.  The
response payload is a CBOR map which MUST contain the 'sign_info'
as well as the 'pub_key_enc' parameters.
A 4.00 Bad Request response from the Group Manager to the joining
node MUST have content format application/ace-group+cbor.  The
response payload is a CBOR map which MUST contain the 'sign_info'
and 'pub_key_enc' parameters.  The CBOR map SHOULD additionally
contain the 'rsnonce' parameter, specifying a new dedicated 8-byte
nonce generated by the Group Manager (see ssec-token-post).
The 'client_cred' parameter, including a public key compatible
with the encoding, countersignature algorithm and possible
associated parameters indicated by the Group Manager.
The 'client_cred_verify' parameter, including 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.
The 'cnonce' parameter MUST include a new dedicated nonce N_C
generated by the joining node.
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 'rsnonce'
parameter, the joining node MUST use its content as new N_S
challenge to compute the signature.
The 'rpl' parameter, if present, specifies the OSCORE Replay
Window Size and Type value.
The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm.
This parameter is a CBOR map whose content depends on the
counter signature algorithm, as specified in Section 2 and
Section 9.1 of I-D.ietf-core-oscore-groupcomm.
The 'cs_key_params' parameter MAY be present and specifies the
additional parameters for the key used with the counter
signature algorithm.  This parameter is a CBOR map whose
content depends on the counter signature algorithm, as
specified in Section 2 and Section 9.2 of I-D.ietf-core-oscore-
groupcomm.
The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm.
This parameter is a CBOR map whose content depends on the
counter signature algorithm, as specified in Section 2 and
Section 11.1 of I-D.ietf-core-oscore-groupcomm.
The 'cs_key_params' parameter MAY be present and specifies the
additional parameters for the key used with the counter
signature algorithm.  This parameter is a CBOR map whose
content depends on the counter signature algorithm, as
specified in Section 2 and Section 11.2 of I-D.ietf-core-
oscore-groupcomm.
The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (TBD), which is defined in ssec-iana-
groupcomm-profile-registry of this specification.
The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (TBD1), which is defined in ssec-iana-
groupcomm-profile-registry of this specification.
Finally, the joining node uses the information received in the
Joining Response to set up the OSCORE Security Context, as described
in Section 2 of I-D.ietf-core-oscore-groupcomm.  From then on, the
joining node can exchange group messages secured with Group OSCORE as
described in I-D.ietf-core-oscore-groupcomm.
Finally, the joining node uses the information received in the
Joining Response to set up the 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 group.
The joining node MUST NOT process an incoming request message, if
signed by a group member whose public key is not associated to the
role "Requester".
The joining node MUST NOT process an incoming response message, if
signed by a group member whose public key is not associated to the
role "Responder".
Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures (see Sections 2 and
3 of I-D.ietf-core-oscore-groupcomm).  Therefore, group members must
be able to retrieve each other's public key from a trusted key
repository, in order to verify source authenticity of incoming group
messages.
Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures (see Sections 2 and
4 of I-D.ietf-core-oscore-groupcomm).  Therefore, group members must
be able to retrieve each other's public key from a trusted key
repository, in order to verify source authenticity of incoming group
messages.
The Group Manager processes the Key Distribution Request according to
Section 4.1.2.2 of I-D.ietf-ace-key-groupcomm.  The Key Distribution
Response is formatted as defined in Section 4.1.2.2 of I-D.ietf-ace-
key-groupcomm.
The Group Manager processes the Key Distribution Request according to
Section 4.1.2.2 of I-D.ietf-ace-key-groupcomm.  The Key Distribution
Response is formatted as defined in Section 4.1.2.2 of I-D.ietf-ace-
key-groupcomm.  In particular, the 'key' parameter is formatted as
defined in ssec-join-resp of this specification, with the difference
that it does not include the 'clientId' parameter.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME/NODENAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to
Section 4.1.6.2 of I-D.ietf-ace-key-groupcomm.  The Key Distribution
Response is formatted as defined in Section 4.1.6.2 of I-D.ietf-ace-
key-groupcomm.  Note that the current Sender ID of the group member
is not specified as a separate parameter, but rather included as
'clientId' in the 'key' parameter.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME/nodes/NODENAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to
Section 4.1.6.2 of I-D.ietf-ace-key-groupcomm.  The Key Distribution
Response is formatted as defined in Section 4.1.6.2 of I-D.ietf-ace-
key-groupcomm.
In particular, the 'key' parameter is formatted as defined in ssec-
join-resp of this specification, with the difference that if the
requesting group member is configured exclusively as monitor, no
'clientId' is specified within the 'key' parameter.  Note that, in
any other case, the current Sender ID of the group member is not
specified as a separate parameter, but rather specified as 'clientId'
within the 'key' parameter.
As discussed in Section 2.2 of I-D.ietf-core-oscore-groupcomm, a
group member may at some point experience a wrap-around of its own
Sender Sequence Number in the group.
When this happens, the group member MUST send a Key Renewal Request
message to the Group Manager, as per Section 4.4 of I-D.ietf-ace-key-
groupcomm.  In particular, it sends a CoAP PUT request to the
endpoint /group-oscore/GROUPNAME/NODENAME at the Group Manager.
Upon receiving the Key Renewal Request, the Group Manager processes
it as defined in Section 4.1.6.2 of I-D.ietf-ace-key-groupcomm, and
performs one of the following actions.
The Group Manager replies to the group member with a 4.06 (Not
Acceptable) error response, and rekeys the whole OSCORE group as
discussed in sec-group-rekeying-process.
The Group Manager generates a new Sender ID for that group member
and replies with a Key Renewal Response, formatted as defined in
Section 4.1.6.2 of I-D.ietf-ace-key-groupcomm.  In particular, the
CBOR Map in the response payload includes a single parameter
'clientId' 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.
As discussed in Section 2.5 of I-D.ietf-core-oscore-groupcomm, a
group member may at some point experience a wrap-around of its own
Sender Sequence Number in the group.
When this happens, the group member MUST send a Key Renewal Request
message to the Group Manager, as per Section 4.4 of I-D.ietf-ace-key-
groupcomm.  In particular, it sends a CoAP PUT request to the
endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the Group Manager.
Upon receiving the Key Renewal Request, the Group Manager processes
it as defined in Section 4.1.6.1 of I-D.ietf-ace-key-groupcomm, and
performs one of the following actions.
b.  Or the Group Manager generates 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 'clientId' 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.
A group member may request the current policies used in the OSCORE
group.  To this end, the group member sends a Policies Request, as
per Section 4.6 of I-D.ietf-ace-key-groupcomm.  In particular, it
sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/
policies at the Group Manager, where GROUPNAME is the name of the
OSCORE group.
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.6 of I-D.ietf-ace-key-
groupcomm.  In particular, it sends a CoAP POST request to the
endpoint /group-oscore/GROUPNAME/nodes/NODENAME/pub-key at the Group
Manager.
Upon receiving the Group Leaving Request, the Group Manager processes
it as per Section 4.1.7.1 of I-D.ietf-ace-key-groupcomm, with the
following additions.
The N_S signature challenge is computed as per point (3) in sssec-
challenge-value (REQ17).
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 may request the current policies used in the OSCORE
group.  To this end, the group member sends a Policies Request, as
per Section 4.7 of I-D.ietf-ace-key-groupcomm.  In particular, it
sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/
policies at the Group Manager, where GROUPNAME is the name of the
OSCORE group.
A group member may request the current version of the keying material
used in the OSCORE group.  To this end, the group member sends a
Version Request, as per Section 4.7 of I-D.ietf-ace-key-groupcomm.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the
name of the OSCORE group.
A group member may request the current version of the keying material
used in the OSCORE group.  To this end, the group member sends a
Version Request, as per Section 4.8 of I-D.ietf-ace-key-groupcomm.
In particular, it sends a CoAP GET request to the endpoint /group-
oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the
name of the OSCORE group.
A group member may request to leave the OSCORE group.  To this end,
the group member sends a Group Leaving Request, as per Section 4.8 of
I-D.ietf-ace-key-groupcomm.  In particular, it sends a CoAP DELETE
request to the endpoint /group-oscore/GROUPNAME/NODENAME at the Group
Manager.
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 /group-oscore/GROUPNAME/active at the Group Manager defined
in sec-interface-GM of this specification, where GROUPNAME is the
name of the OSCORE group.  The success Group Version Response is
formatted as defined in sec-interface-GM of this specification.
Upon learning from a 2.05 (Content) response that the group is
currently inactive, the group member SHOULD stop taking part in
communications within the group, until it becomes active again.
Upon learning from a 2.05 (Content) response that the group has
become active again, the group member can resume taking part in
communications within the group.
fig-key-status-req-resp gives an overview of the exchange described
above.
A group member may request to leave the OSCORE group.  To this end,
the group member sends a Group Leaving Request, as per Section 4.9 of
I-D.ietf-ace-key-groupcomm.  In particular, it sends a CoAP DELETE
request to the endpoint /group-oscore/GROUPNAME/nodes/NODENAME at the
Group Manager.
In order to rekey the OSCORE group, the Group Manager distributes a
new Group Identifier (Gid), i.e. a new OSCORE ID Context, and a new
OSCORE Master Secret for that group.  When doing so, the Group
Manager MUST increment the version number of the group keying
material.  Also, 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 message countersignatures.
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.
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 message countersignatures.
The Group Manager separately sends a group rekeying message to each
group member to be rekeyed.  Each rekeying message MUST be secured
with the pairwise secure communication channel between the Group
Manager and the group member used during the joining process.
The Group Manager separately sends a group rekeying message to each
group member to be rekeyed.
Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member
used during the joining process.  In particular, each rekeying
message can target the 'control_path' URI path defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm, if provided by the
intended recipient upon joining the group (see ssec-join-req-
sending).
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.
In case the rekeying terminates and some group members have not
received the new keying material, they will not be able to correctly
process following secured messages exchanged in the group.  These
group members will eventually contact the Group Manager, in order to
retrieve the current keying material and its version.
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.3 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 /group-oscore/GROUPNAME/NODENAME 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 method described in this document leverages the following
management aspects related to OSCORE groups and discussed in the
sections of I-D.ietf-core-oscore-groupcomm referred below.
Management of group keying material (see Section 2.1 of I-D.ietf-
core-oscore-groupcomm).  The Group Manager is responsible for the
renewal and re-distribution of the keying material in the groups
of its competence (rekeying).  According to the specific
application requirements, this can include rekeying the group upon
changes in its membership.  In particular, renewing the group
keying material is required upon a new node's joining or a current
node's leaving, in case backward security and forward security
have to be preserved, respectively.
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.3 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 /group-oscore/GROUPNAME/nodes/NODENAME 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.
Security considerations for this profile are inherited from I-D.ietf-
ace-key-groupcomm, the ACE framework for Authentication and
Authorization I-D.ietf-ace-oauth-authz, and the specific transport
profile of ACE signalled by the AS, such as I-D.ietf-ace-dtls-
authorize and I-D.ietf-ace-oscore-profile.
The following security considerations also apply for this profile.
This profile leverages the following management aspects related to
OSCORE groups and discussed in the sections of I-D.ietf-core-oscore-
groupcomm referred below.
Management of group keying material (see Section 2.4 of I-D.ietf-
core-oscore-groupcomm).  The Group Manager is responsible for the
renewal and re-distribution of the keying material in the groups
of its competence (rekeying).  According to the specific
application requirements, this can include rekeying the group upon
changes in its membership.  In particular, renewing the group
keying material is required upon a new node's joining or a current
node's leaving, in case backward security and forward security
have to be preserved, respectively.
Synchronization of sequence numbers (see Section 5.1 of I-D.ietf-
core-oscore-groupcomm).  This concerns how a responder node that
has just joined an OSCORE group can synchronize with the sequence
number of requesters in the same group.
Synchronization of sequence numbers (see Section 6.1 of I-D.ietf-
core-oscore-groupcomm).  This concerns how a responder node that
has just joined an OSCORE group can synchronize with the sequence
number of requesters in the same group.
Further security considerations are inherited from I-D.ietf-ace-key-
groupcomm, the ACE framework for Authentication and Authorization I-
D.ietf-ace-oauth-authz, and the specific transport profile of ACE
signalled by the AS, such as I-D.ietf-ace-dtls-authorize and I-
D.ietf-ace-oscore-profile.
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 value, 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.
As defined in sssec-challenge-value, the way the N_S value is
computed depends on the particular interaction 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, or if the joining node re-joins
without re-posting the same still valid Access Token, then N_S is
computed as a 32-byte long nonce (see points (2) and (3) of sssec-
challenge-value).
If the Access Token has been explicitly posted to the /authz-info
endpoint of the Group Manager, N_S takes the value conveyed in the
'rsnonce' parameter of the 2.01 response to the Token Post (see
ssec-token-post).  Similarly, if a Joining Request is not
successfully processed by the Group Manager, the returned error
response should also include the 'rsnonce' parameter specifying a
new nonce N_S (see ssec-join-req-processing).  In either case, it
is RECOMMENDED to use a 8-byte long random nonce as value for N_S.
If we consider both N_C and N_S to be 8-byte long nonces, the
following considerations hold.
If both N_C and N_S are random nonces, the average collision for
each nonce will happen after 2^32 messages, as per the birthday
paradox and as also discussed in Section 7 of I-D.ietf-ace-oscore-
profile.  This amounts to considerably more token provisionings
than the expected new joinings of OSCORE groups under a same Group
Manager.
If N_C and N_S are not generated randomly, e.g. by using a
counter, the joining node and the Group Manager need to guarantee
that reboot and loss of state on either node does not provoke re-
use.  If that is not guaranteed, a joining node may repeatedly
post a valid Access Token to the /authz-info endpoint of the Group
Manager, until it gets back an exact, re-used value N_S* to use as
nonce.  Then, the joining node can send a Joining Request,
conveying a reused N_C* nonce in 'cnonce' and an old stored
signature in 'client_cred_verify', computed over N_C* | N_S*. By
verifying the signature, the Group Manager would falsely believe
that the joining node possesses its own private key at that point
in time.
Since N_C is always conveyed in a secured Joining Request, it is
practically infeasible for an on-path attacker to replay Joining
Requests from a joining node to the Group Manager, in order to
cause that joining node to use an arbitrary nonce N_S.
Section 7 of I-D.ietf-ace-oscore-profile as well Appendix B.2 of
RFC8613 recommend the use of 8-byte random nonces as well.  Unlike
in those cases, the nonces N_C and N_S considered in this
specification are not used for as sensitive operations as the
derivation of a Security Context, with possible implications in
the security of AEAD ciphers.
IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 8.4 of I-D.ietf-ace-key-groupcomm.
IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 9.6 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 9.5 of I-D.ietf-ace-key-groupcomm.
IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" Registry defined in Section 9.2 of I-
D.ietf-ace-oscore-profile.
IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" Registry defined in Section 9.4 of I-
D.ietf-ace-oscore-profile.
IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 8.5 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 8.7 of I-
D.ietf-ace-key-groupcomm.
IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 9.8 of I-
D.ietf-ace-key-groupcomm.
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.1).
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.2).
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.3).
IANA is asked to register the following entry in the "ACE Groupcomm
Parameters" Registry defined in Section 8.3 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry in the "ACE Groupcomm
Parameters" Registry defined in Section 9.4 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry in the "TLS Exporter
Label" Registry defined in Section 6 of RFC5705 and updated in
Section 12 of RFC8447.