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

Commentary: To be aligned with changes to draft - ietf - core - oscore - groupcomm : 1 ) A Sender ID can not be recycled under the same Group ID value ; 2 ) If a node re - joins and is recognized as a current group member , it must still get a new  ID .
The terms and concepts described in CBOR I-D.ietf-cbor-7049bis and
COSE I-D.ietf-cose-rfc8152bis-algs.
The terms and concepts decribed in CoAP RFC7252 and group
communication for CoAP I-D.ietf-core-groupcomm-bis.  Unless
otherwise indicated, the term "endpoint" is used here following
its OAuth definition, aimed at denoting resources such as /token
and /introspect at the AS, and /authz-info at the RS.  This
document does not use the CoAP definition of "endpoint", which is
"An entity participating in the CoAP protocol".
The terms and concepts described in CBOR RFC8949 and COSE I-
D.ietf-cose-rfc8152bis-algs.
The terms and concepts described in CoAP RFC7252 and group
communication for CoAP I-D.ietf-core-groupcomm-bis.  Unless
otherwise indicated, the term "endpoint" is used here following
its OAuth definition, aimed at denoting resources such as /token
and /introspect at the AS, and /authz-info at the RS.  This
document does not use the CoAP definition of "endpoint", which is
"An entity participating in the CoAP protocol".
The set of requested roles is expressed as a single CBOR
unsigned integer, computed as defined in sec-format-scope
(REQ2) from the numerical abbreviations defined in fig-role-
values for each requested role (OPT7).
The set of requested roles is expressed as a single CBOR
unsigned integer, computed as defined in sec-format-scope
(REQ2) from the numerical abbreviations defined in fig-role-
values for each requested role (OPT8).
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.
Furthermore, ssec-admitted-methods provides a summary of the CoAP
methods admitted to access different resources at the Group Manager,
for nodes with different roles in the group or as non members
(REQ7aa).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in iana-rt (REQ7a), 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.
Furthermore, ssec-admitted-methods provides a summary of the CoAP
methods admitted to access different resources at the Group Manager,
for nodes with different roles in the group or as non members (REQ8).
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.
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 (REQ7aa).  If either verification fails, the Group
Manager MUST respond with a 4.01 (Unauthorized) error message.
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 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.
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").
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 (OPT2a).
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).
The 'ecdh_info' parameter is an OPTIONAL parameter of the Token Post
response message defined in Section 5.1.2. of I-D.ietf-ace-oauth-
authz.
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.
If this parameter is present and its value is non-null, each
element of the first inner CBOR array is encoded as a CBOR
unsigned integer, with the same value of a permission set
("Tperm") indicating that role or combination of roles in a scope
entry, as defined in sec-format-scope.
If this parameter is present and its value is non-null, each
element of the inner CBOR array 'role_filter' is encoded as a CBOR
unsigned integer, with the same value of a permission set
("Tperm") indicating that role or combination of roles in a scope
entry, as defined in sec-format-scope.
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 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 selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node.
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.  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 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 '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 (REQ9).
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).
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.
a.  The Group Manager rekeys the OSCORE group.  That is, the Group
Manager generates new group keying material for that group (see
sec-group-rekeying-process), and replies to the group member with
a group rekeying message as defined in sec-group-rekeying-process,
providing the new group keying material.  Then, the Group Manager
rekeys the rest of the OSCORE group, as discussed in sec-group-
rekeying-process.
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
(OPT8).
b.  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 '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.
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, with
the following additions.
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").
Otherwise, the Group Manager performs one of the following actions.
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 rekeys the OSCORE group.  That is, the Group
Manager generates new group keying material for that group (see
sec-group-rekeying-process), and replies to the group member
with a group rekeying message as defined in sec-group-rekeying-
process, providing the new group keying material.  Then, the
Group Manager rekeys the rest of the OSCORE group, as discussed
in sec-group-rekeying-process.
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.
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.
The Group Manager MUST return a 5.03 (Service Unavailable)
response in case there are currently no 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").
Each element (if any) of the first inner CBOR array is formatted
as in the first inner CBOR array of the 'get_pub_keys' parameter
of the Joining Request when the parameter value is non-null (see
ssec-join-req-sending).
Each element (if any) of the second inner CBOR array is a CBOR
byte string (REQ9), which encodes the Sender ID of the group
member for which the associated public key is requested.
Each element (if any) of the inner CBOR array 'role_filter' is
formatted as in the inner CBOR array 'role_filter' of the
'get_pub_keys' parameter of the Joining Request when the parameter
value is non-null (see ssec-join-req-sending).
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 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 (1) in sssec-
challenge-value (REQ17).
Upon receiving the Public Key Update 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 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 (Bad request) 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 N_S signature challenge is computed as per point (1) in sssec-
challenge-value (REQ20).
In either case, the node only knows the current Gid of the group, as
learnt from received or intercepted messages exchanged in the group.
As detailed below, the node can contact the Group Manager, and
request the group name and URI to the group-membership resource
corresponding to that Gid. Then, it can use that information to
either join the group as a candidate group member, get the latest
keying material as a current group member, or retrieve public keys
used in the group as a signature verifier.  To this end, the node
sends a Group Name and URI Retrieval Request, as per Section 4.2 of
I-D.ietf-ace-key-groupcomm.
In either case, the node only knows the current Gid of the group, as
learned from received or intercepted messages exchanged in the group.
As detailed below, the node can contact the Group Manager, and
request the group name and URI to the group-membership resource
corresponding to that Gid. Then, it can use that information to
either join the group as a candidate group member, get the latest
keying material as a current group member, or retrieve public keys
used in the group as a signature verifier.  To this end, the node
sends a Group Name and URI Retrieval Request, as per Section 4.2 of
I-D.ietf-ace-key-groupcomm.
In particular, the node sends a CoAP FETCH request to the endpoint
/ace-group at the Group Manager formatted as defined in
Section 4.1.1.1 of I-D.ietf-ace-key-groupcomm.  Each element of the
CBOR array 'gid' is a CBOR byte string (REQ7b), which encodes the Gid
of the group for which the group name and the URI to the group-
membership resource are requested.
In particular, the node sends a CoAP FETCH request to the endpoint
/ace-group at the Group Manager formatted as defined in
Section 4.1.1.1 of I-D.ietf-ace-key-groupcomm.  Each element of the
CBOR array 'gid' is a CBOR byte string (REQ9), which encodes the Gid
of the group for which the group name and the URI to the group-
membership resource are requested.
Upon receiving the Group Name and URI Retrieval Request, the Group
Manager processes it as per Section 4.1.1.1 of I-D.ietf-ace-key-
groupcomm.  The success Group Name and URI Retrieval Response is
formatted as defined in Section 4.1.1.1 of I-D.ietf-ace-key-
groupcomm.  In particular, each element of the CBOR array 'gid' is a
CBOR byte string (REQ7b), which encodes the Gid of the group for
which the group name and the URI to the group-membership resource are
provided.
Upon receiving the Group Name and URI Retrieval Request, the Group
Manager processes it as per Section 4.1.1.1 of I-D.ietf-ace-key-
groupcomm.  The success Group Name and URI Retrieval Response is
formatted as defined in Section 4.1.1.1 of I-D.ietf-ace-key-
groupcomm.  In particular, each element of the CBOR array 'gid' is a
CBOR byte string (REQ9), which encodes the Gid of the group for which
the group name and the URI to the group-membership resource are
provided.
If, upon joining the group (see ssec-join-req-sending), the leaving
node specified a URI in the 'control_path' parameter defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm, the Group Manager MUST
inform the leaving node of its eviction, by sending a DELETE request
targeting the URI specified in the 'control_path' parameter (OPT9).
If any of the two conditions below holds, the Group Manager MUST
inform the leaving node of its eviction as follows.  If both
conditions hold, the Group Manager MUST inform the leaving node only
once, using either of the corresponding methods.
If, upon joining the group (see ssec-join-req-sending), the
leaving node specified a URI in the 'control_uri' parameter
defined in Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm, the
Group Manager sends a DELETE request targeting the URI specified
in the 'control_uri' parameter (OPT10).
If the leaving node has been observing the associated resource at
ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an
unsolicited 4.04 (Not Found) response to the leaving node, as
specified in 4.1.6.2 of I-D.ietf-ace-key-groupcomm.
The 'contextId' parameter of the 'key' parameter specifies the new
Group ID used as OSCORE ID Context value.
The 'contextId' parameter of the 'key' parameter specifies the new
Gid used as OSCORE ID Context value.
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 (OPT9), if provided by
the intended recipient upon joining the group (see ssec-join-req-
sending).
Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member
used during the joining process.  In particular, each rekeying
message can target the 'control_uri' URI path defined in
Section 4.1.2.1 of I-D.ietf-ace-key-groupcomm (OPT10), if provided by
the intended recipient upon joining the group (see ssec-join-req-
sending).
The array , in case PS256, PS384 or PS512 RFC8017 is
specified for 'cs_alg'.
The array , in case PS256, PS384 or PS512 RFC8017
is specified for 'cs_alg'.
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.
Synchronization of sequence numbers (see Section 6.2 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.
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 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 countersignature algorithm and possible
associated parameters used in the OSCORE group.
IANA is asked to register the following entry to the "ACE Groupcomm
Parameters" Registry defined in Section 8.5 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry to the "ACE Groupcomm
Parameters" Registry defined in Section 10.5 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry to the "ACE Groupcomm
Key" Registry defined in Section 8.6 of I-D.ietf-ace-key-groupcomm.
IANA is asked to register the following entry to the "ACE Groupcomm
Key" Registry defined in Section 10.6 of I-D.ietf-ace-key-groupcomm.
IANA is asked to register the following entry to the "ACE Groupcomm
Profile" Registry defined in Section 8.7 of I-D.ietf-ace-key-
groupcomm.
IANA is asked to register the following entry to the "ACE Groupcomm
Profile" Registry defined in Section 10.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 8.9 of I-
D.ietf-ace-key-groupcomm.
Description: No action is taken.
Description: The first received request sets the baseline
reference point, and is discarded with no delivery to the
application.
Description: Challenge response using the Echo Option for CoAP
from I-D.ietf-core-echo-request-tag.
This specification establishes the IANA "Group OSCORE Roles"
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in ssec-iana-expert-review.
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.
IANA is asked to register the following entry in the "ACE Scope
Semantics" registry defined in Section 10.12 of I-D.ietf-ace-key-
groupcomm.
Description: Access to OSCORE groups through the ACE Group
Manager.
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.
Description: Group currently not active.