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

Commentary: AP7 : Specify that when using the OSCORE profile between group member and GM , the joining nodes need to have both client and server roles . This means configuring their keying material accordingly . In particular , the group member ’s recipient context need to contain a replay window ) . 
 AP6 : In Section 6 , third bullet point , clarify about ensuring that any signature algorithm parameters that might exist are going to be checked and enforced . 
 AP5 : In Section 6 , proof - of - possession of the client ’s private key , e.g. by signing a nonce returned by the GM in the response to the  post . 
 AP4 : In Section 6 , clarify in the third bullet on asymmetric PoP. 
 AP10 : Section 4.3 - GM refuses the join request with 4.xx if the client_cred passed in was not in the correct format . 
 AP3 : In Section 4.4.1 , about ' key_info ' , change " its format " to " its exact content " . 
 AP2 : In Section 4.1 , extend the format of ‘ key_info ’ 
 AP9 : add sec cons that this is up to the application to decide what to do with collisions of Gid 
 AP8 : Switch to Requester , Responder , Monitor 
 AP1 : In the abstract , change “ where communications are based ” to “ where the group communication is based ” .
This document describes a method to request and provision keying
material in group communication scenarios where communications are
based on CoAP and secured with Object Security for Constrained
RESTful Environments (OSCORE).  The proposed method delegates the
authentication and authorization of new client nodes that join an
OSCORE group through a Group Manager server.  This approach builds on
the ACE framework for Authentication and Authorization, and leverages
protocol-specific profiles of ACE to achieve communication security,
proof-of-possession and server authentication.
This document describes a method to request and provision keying
material in group communication scenarios where the group
communication is based on CoAP and secured with Object Security for
Constrained RESTful Environments (OSCORE).  The proposed method
delegates the authentication and authorization of new client nodes
that join an OSCORE group through a Group Manager server.  This
approach builds on the ACE framework for Authentication and
Authorization, and leverages protocol-specific transport profiles of
ACE to achieve communication security, proof-of-possession and server
authentication.
As described in I-D.ietf-core-oscore-groupcomm, OSCORE may be used to
protect CoAP group communication over IP multicast RFC7390.  This
relies on a Group Manager, which is responsible for managing an
OSCORE group, where members exchange CoAP messages secured with
OSCORE.  The Group Manager can be responsible for multiple groups,
coordinates the join process of new group members, and is entrusted
with the distribution and renewal of group keying material.
As described in I-D.ietf-core-oscore-groupcomm, OSCORE may be used to
protect CoAP group communication over IP multicast I-D.dijk-core-
groupcomm-bis.  This relies on a Group Manager, which is responsible
for managing an OSCORE group, where members exchange CoAP messages
secured with OSCORE.  The Group Manager can be responsible for
multiple groups, coordinates the join process of new group members,
and is entrusted with the distribution and renewal of group keying
material.
In order to achieve communication security, proof-of-possession and
server authentication, the client and the Group Manager leverage
protocol-specific profiles of ACE.  These include also possible
forthcoming profiles that comply with the requirements in Appendix C
of I-D.ietf-ace-oauth-authz.
In order to achieve communication security, proof-of-possession and
server authentication, the client and the Group Manager leverage
protocol-specific transport profiles of ACE.  These include also
possible forthcoming transport profiles that comply with the
requirements in Appendix C of I-D.ietf-ace-oauth-authz.
Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol described in RFC7390.  Note that, 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".
Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol described in I-D.dijk-core-groupcomm-
bis.  Note that, 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".
Joining node: a network node intending to join an OSCORE group,
where communication is based on CoAP RFC7390 and secured with
OSCORE as described in I-D.ietf-core-oscore-groupcomm.
Joining node: a network node intending to join an OSCORE group,
where communication is based on CoAP I-D.dijk-core-groupcomm-bis
and secured with OSCORE as described in I-D.ietf-core-oscore-
groupcomm.
Join resource: a resource hosted by the Group Manager, associated
to an OSCORE group under that Group Manager.  A join resource is
identifiable with the Group Identifier (Gid) of the respective
group.  A joining node accesses a join resource to start the join
process and become a member of that group.
Join resource: a resource hosted by the Group Manager, associated
to an OSCORE group under that Group Manager.  A join resource is
identifiable with the Group Identifier (Gid) of the respective
group.  A joining node accesses a join resource to start the join
process and become a member of that group.  The URI of a join
resource is fixed.
Listener: member of an OSCORE group that receives request messages
from other members of the group.  A listener may reply back, by
sending a response message to the requester which has sent the
request message.
Pure listener: member of a group that is configured as listener
and never replies back to requesters after receiving request
messages.  This corresponds to the term "silent server" used in I-
D.ietf-core-oscore-groupcomm.
Responder: member of an OSCORE group that receives request
messages from other members of the group.  A responder may reply
back, by sending a response message to the requester which has
sent the request message.
Monitor: member of a group that is configured as responder and
never replies back to requesters after receiving request messages.
This corresponds to the term "silent server" used in I-D.ietf-
core-oscore-groupcomm.
Group communication for CoAP over IP multicast has been enabled in
RFC7390 and can be secured with Object Security for Constrained
RESTful Environments (OSCORE) I-D.ietf-core-object-security as
described in I-D.ietf-core-oscore-groupcomm.  A network node joins an
OSCORE group by interacting with the responsible Group Manager.  Once
registered in the group, the new node can securely exchange messages
with other group members.
Group communication for CoAP over IP multicast has been enabled in I-
D.dijk-core-groupcomm-bis and can be secured with Object Security for
Constrained RESTful Environments (OSCORE) I-D.ietf-core-object-
security as described in I-D.ietf-core-oscore-groupcomm.  A network
node joins an OSCORE group by interacting with the responsible Group
Manager.  Once registered in the group, the new node can securely
exchange messages with other group members.
In particular, communications between the joining node and the Group
Manager leverage protocol-specific profiles of ACE to achieve
communication security, proof-of-possession and server
authentication.  To this end, the AS must signal the specific profile
to use, consistently with requirements and assumptions defined in the
ACE framework I-D.ietf-ace-oauth-authz.
In particular, communications between the joining node and the Group
Manager leverage protocol-specific transport profiles of ACE to
achieve communication security, proof-of-possession and server
authentication.  To this end, the AS must signal the specific
transport profile to use, consistently with requirements and
assumptions defined in the ACE framework I-D.ietf-ace-oauth-authz.
With reference to the AS, communications between the joining node and
the AS (/token endpoint) as well as between the Group Manager and the
AS (/introspect endpoint) can be secured by different means, for
instance using DTLS RFC6347 or OSCORE I-D.ietf-core-object-security.
Further details on how the AS secures communications (with the
joining node and the Group Manager) depend on the specifically used
profile of ACE, and are out of the scope of this specification.
With reference to the AS, communications between the joining node and
the AS (/token endpoint) as well as between the Group Manager and the
AS (/introspect endpoint) can be secured by different means, for
instance using DTLS RFC6347 or OSCORE I-D.ietf-core-object-security.
Further details on how the AS secures communications (with the
joining node and the Group Manager) depend on the specifically used
transport profile of ACE, and are out of the scope of this
specification.
in the second element, the role(s) that the joining node
intends to have in the group it intends to join.  Possible
values are: "requester"; "listener"; and "pure listener".
Possible combinations are: ["requester" , "listener"];
["requester" , "pure listener"].
in the second element, the role (encoded as a text string) or
CBOR array of roles that the joining node intends to have in
the group it intends to join.  Accepted values of roles are:
"requester", "responder", and "monitor".  Possible combinations
are: ["requester" , "responder"]; ["requester" , "monitor"].
The AS must include the 'scope' parameter in the response 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(s) that the joining
node is actually authorized to take in the group, encoded as
specified in ssec-auth-req of this document.
Also, the 'profile' parameter indicates the specific profile of ACE
to use for securing communications between the joining node and the
Group Manager (see Section 5.6.4.3 of I-D.ietf-ace-oauth-authz).
The AS must include the 'scope' parameter in the response 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
group, encoded as specified in ssec-auth-req of this document.
Also, the 'profile' parameter indicates the specific transport
profile of ACE to use for securing communications between the joining
node and the Group Manager (see Section 5.6.4.3 of I-D.ietf-ace-
oauth-authz).
If the joining node is not aware of the countersignature algorithm
and related parameters used in the OSCORE group, it may want to get
that information from the Group Manager.  In such a case, the CoAP
POST request uses the Content-Format "application/ace+cbor" defined
in Section 8.14 of I-D.ietf-ace-oauth-authz, and includes also the
parameter 'key info' defined in key-info and registered in iana-
kinfo, encoding the CBOR simple value Null.  Alternatively, the
joining node may retrieve that information by other means, e.g. by
using the approach described in I-D.tiloca-core-oscore-discovery.
If the Access Token is valid, the Group Manager responds to the POST
request with a 2.01 (Created) response, according to what is
specified in the signalled profile of ACE.
The first element is an integer or a text string, indicating the
counter signature algorithm used in the OSCORE group.  This
parameter takes values from Tables 5 and 6 of RFC8152.
The second element indicates the parameters of the counter
signature algorithm.  Its structure depends on the value of the
first element, and is defined in the Counter Signature Parameters
Registry (see Section 9.1 of I-D.ietf-core-oscore-groupcomm).
This parameter MUST be omitted if there are no parameters for that
algorithm value.
The CDDL notation of the 'key info' parameter is given below.
Finally, the joining node establishes a secure channel with the Group
Manager, according to what is specified in the Access Token response
and the signalled profile of ACE.
The 'key info' parameter is an OPTIONAL parameter of the AS Request
Creation Hints message defined in Section 5.1.2. of I-D.ietf-ace-
oauth-authz.  This parameter contains information about the key to be
used in the security association between the Client and the RS.  Its
format is application specific.
At this point in time, the joining node might not have all the
necessary information concerning the public keys in the OSCORE group,
as well as concerning the algorithm and related parameters for
computing countersignatures in the OSCORE group.  In such a case, the
joining node MAY use the 'sign_info' and 'pub_key_enc' parameters
defined in Section 3.3 of I-D.ietf-ace-key-groupcomm to ask for such
information.
Alternatively, the joining node may retrieve this information by
other means, e.g. by using the approach described in I-D.tiloca-core-
oscore-discovery.
If the Access Token is valid, the Group Manager responds to the POST
request with a 2.01 (Created) response, according to what is
specified in the signalled transport profile of ACE.  The Group
Manager MUST use the Content-Format "application/ace+cbor" defined in
Section 8.14 of I-D.ietf-ace-oauth-authz.
The payload of the 2.01 (Created) response is a CBOR map, which MUST
include the 'cnonce' parameter defined in section 5.1.2 of I-D.ietf-
ace-oauth-authz, and MAY include the 'sign_info' parameter as well as
the 'pub_key_enc' parameter.
The 'cnonce' parameter includes a nonce N 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).
'sign_alg', i.e. the first element of the 'sign_info' parameter,
takes value from Tables 5 and 6 of RFC8152.
'sign_parameters', i.e. the second element of the 'sign_info'
parameter, 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', i.e. the third element of the 'sign_info'
parameter, 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 from fig-pub-key-enc-values, as a public
key encoding in the "ACE Public Key Encoding" Registry (see
Section 11.2 of I-D.ietf-ace-key-groupcomm).
Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g. according to the
signalled transport profile of ACE.
Finally, the joining node establishes a secure channel with the Group
Manager, according to what is specified in the Access Token response
and the signalled transport profile of ACE.
The 'client_cred' parameter, if present, includes the public key
of the joining node.  In case the joining node knows the
countersignature algorithm and possible associated parameters used
in the OSCORE group, the included public key MUST be in a
consistent format.  This parameter MAY be omitted if: i) the
joining node is asking to access the group exclusively as pure
listener; or ii) the Group Manager already acquired this
information, for instance during a previous join process.  In any
other case, this parameter MUST be present.
The Group Manager processes the request according to I-D.ietf-ace-
oauth-authz and Section 4.2 of I-D.ietf-ace-key-groupcomm.  If this
yields a positive outcome, the Group Manager performs the following
check.  In case the Join Request included the 'client_cred'
parameter, the Group Manager checks that the public key of the
joining node is consistent with the counter signature algorithm and
possible associated parameters used in the OSCORE group.
If the public key of the joining node does not have an accepted
format, the Group Manager MUST reply to the joining node with a 2.01
(Created) response.  The payload of this response is a CBOR map,
which includes a 'key info' parameter formatted as in the Token POST
response in ssec-token-post.  Upon receiving this response, the
joining node SHOULD send a new Join Request to the Group Manager,
with the 'client_cred' parameter including its own public key in a
format consistent with the countersignature algorithm and possible
associated parameters indicated by the Group Manager.
Otherwise, the Group Manager updates the group membership by
registering the joining node as a new member of the OSCORE group.
The 'type' parameter is set to 1 ("key distribution").
The 'client_cred' parameter, if present, includes the public key
of the joining node.  In case the joining node knows the encoding
of public keys in the OSCORE group, as well as the
countersignature algorithm and possible associated parameters used
in the OSCORE group, the included public key MUST be in a
consistent format.  This parameter MAY be omitted if: i) the
joining node is asking to access the group exclusively as monitor;
or ii) the Group Manager already acquired this information, for
instance during a past join process.  In any other case, this
parameter MUST be present.
Furthermore, the CBOR map specified as payload of the Join Request
MAY also include the following additional parameter, which MUST be
present if the 'client_cred' parameter is present.
The 'client_cred_verify' parameter, which is encoded as a CBOR
byte string and contains a signature computed by the joining node,
in order to prove possession of its own private key.  The
signature is computed over the nonce N received in the 2.01
(Created) response to the Token POST (see ssec-token-post).  In
particular, the joining node MUST use the COSE_CounterSignature0
object RFC8152, with the Sig_structure containing the nonce N as
payload; and an empty external_aad.  The joining node computes the
signature by using the same private key and countersignature
algorithm it intends to use for signing messages in the OSCORE
group.
The Group Manager processes the Join Request according to I-D.ietf-
ace-oauth-authz and Section 4.2 of I-D.ietf-ace-key-groupcomm.  Also,
the Group Manager MUST return a 4.00 (Bad Request) response in case
the Join Request includes the 'client_cred' parameter but does not
include the 'client_cred_verify' parameter.
If the request processing yields a positive outcome, the Group
Manager performs the further following checks.
In case the Join Request includes the 'client_cred' parameter, the
Group Manager checks that the public key of the joining node has
an accepted format.  That is, the public key has to be encoded as
expected in the OSCORE group, and has to be consistent with the
counter signature algorithm and possible associated parameters
used in the OSCORE group.  The join process fails if the public
key of the joining node does not have an accepted format.
In case the Join Request does not include the 'client_cred'
parameter, the Group Manager checks whether it is storing a public
key for the joining node, which is consistent with the encoding,
counter signature algorithm and possible associated parameters
used in the OSCORE group.  The join process fails if the Group
Manager either: i) does not store a public key with an accepted
format for the joining node; or ii) stores multiple public keys
with an accepted format for the joining node.
In case the Join Request includes the 'client_cred_verify'
parameter, the Group Manager verifies the signature contained in
the parameter.  To this end, it considers: i) as signed value, the
nonce N previously provided in the 2.01 (Created) response to the
Token POST (see ssec-token-post); ii) the countersignature
algorithm used in the OSCORE group; and iii) the public key of the
joining node, either retrieved from the 'client_cred' parameter,
or as stored from a past join process.  The join process fails if
the Group Manager does not successfully verify the signature.
If the join process has failed, the Group Manager MUST reply to the
joining node with a 4.00 (Bad Request) response.  The payload of this
response is a CBOR map, which includes a 'sign_info' parameter and a
'pub_key_enc' parameter, formatted as in the Token POST response in
ssec-token-post.
The 'client_cred' parameter, including a public key in a format
consistent 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, 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.
Otherwise, in case of success, the Group Manager updates the group
membership by registering the joining node as a new member of the
OSCORE group.
The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of I-
D.ietf-core-oscore-groupcomm.  This parameter includes a
Group_OSCORE_Security_Context object, which is defined in this
specification and extends the OSCORE_Security_Context 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 'cs_alg' and 'cs_params' defined in ssec-iana-security-
context-parameter-registry of this specification.  More
specifically, the 'key' parameter is composed as follows.
The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of I-
D.ietf-core-oscore-groupcomm.  This parameter has as value a
Group_OSCORE_Security_Context object, which is defined in this
specification and extends the OSCORE_Security_Context 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 'cs_alg', 'cs_params', 'cs_key_params' and 'cs_key_enc'
defined in ssec-iana-security-context-parameter-registry of this
specification.  More specifically, the 'key' parameter is composed
as follows.
The 'clientId' parameter, if present, has as value the OSCORE
Sender ID assigned to the joining node by the Group Manager.
This parameter is not present if the node joins the group
exclusively as pure listener, according to what specified in
the Access Token (see ssec-auth-resp).  In any other case, this
parameter MUST be present.
The 'clientId' parameter, if present, has as value the OSCORE
Sender ID assigned to the joining node by the Group Manager.
This parameter is not present if the node joins the group
exclusively as monitor, according to what specified in the
Access Token (see ssec-auth-resp).  In any other case, this
parameter MUST be present.
The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm.
This parameter is encoded as specified in Section 2 of I-
D.ietf-core-oscore-groupcomm.
The 'profile' parameter MUST be present and has value
"coap_group_oscore", which is defined in ssec-iana-groupcomm-
profile-registry of this specification.
The 'pub_keys' parameter is present only if the 'get_pub_keys'
parameter was present in the join request.  If present, this
parameter includes the public keys of the group members that are
relevant to the joining node.  That is, it includes: i) the public
keys of the non-pure listeners currently in the group, in case the
joining node is configured (also) as requester; and ii) the public
keys of the requesters currently in the group, in case the joining
node is configured (also) as listener or pure listener.
The 'group_policies' parameter SHOULD be present and includes a
list of parameters indicating particular policies enforced in the
group.  For instance, it can indicate the method to achieve
synchronization of sequence numbers among group members (see
Appendix E 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 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_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 taken from fig-pub-
key-enc-values, as a public key encoding in the "ACE Public Key
Encoding" Registry (see Section 11.2 of I-D.ietf-ace-key-
groupcomm).  If this parameter is not present, COSE_Key (1)
MUST be assumed as default value.
The '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 'pub_keys' parameter is present only if the 'get_pub_keys'
parameter was present in the Join Request.  If present, this
parameter includes the public keys of the group members that are
relevant to the joining node.  That is, it includes: i) the public
keys of the responders currently in the group, in case the joining
node is configured (also) as requester; and ii) the public keys of
the requesters currently in the group, in case the joining node is
configured (also) as responder or monitor.
The 'group_policies' parameter SHOULD be present and includes a
list of parameters indicating particular policies enforced in the
group.  For instance, its field "Sequence Number Synchronization
Method" can indicate the method to achieve synchronization of
sequence numbers among group members (see Appendix E of I-D.ietf-
core-oscore-groupcomm), as indicated by the corresponding value
from the "Sequence Number Synchronization Method" Registry defined
in Section 11.8 of I-D.ietf-ace-key-groupcomm.
When the OSCORE Security Context expires, as specified by the 'exp'
parameter of the join response, the node considers it invalid and to
be renewed.  Then, the node retrieves updated security parameters and
keying material, by exchanging shortened Join Request and Join
Response messages with the Group Manager, according to the approach
defined in Section 6 of I-D.ietf-ace-key-groupcomm.  Finally, the
node uses the updated security parameters and keying material to set
up the new OSCORE Security Context as described in Section 2 of I-
D.ietf-core-oscore-groupcomm.
When the OSCORE Security Context expires, as specified by the 'exp'
parameter of the Join Response, the node considers it invalid and to
be renewed.  Then, the node retrieves updated security parameters and
keying material, by exchanging with the Group Manager a shortened
Join Request sent to the same Join Resource with the 'type' parameter
set to 3 ("update key") and a shortened Join Response message,
according to the approach defined in Section 6 of I-D.ietf-ace-key-
groupcomm.  Finally, the node uses the updated security parameters
and keying material to set up the new OSCORE Security Context as
described in Section 2 of I-D.ietf-core-oscore-groupcomm.
The 'clientId' parameter of the 'key' parameter specifies the new
Sender ID of the node.
Same considerations in Section 5 of I-D.ietf-ace-key-groupcomm apply
here as well, considering the Group Manager acting as KDC.  In
particular, a node requests to leave the OSCORE group as described in
Section 5.2 of I-D.ietf-ace-key-groupcomm.
Same considerations in Section 5 of I-D.ietf-ace-key-groupcomm apply
here as well, considering the Group Manager acting as KDC.  In
particular, a node requests to leave the OSCORE group as described in
Section 5.2 of I-D.ietf-ace-key-groupcomm, i.e. by sending to the
Group Manager a request to the same Join Resource with the 'type'
parameter set to 2 ("leave").
In particular, four cases can occur when a new node joins a group.
The joining node is going to join the group exclusively as pure
listener.  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 upon joining the group.
The Group Manager already acquired the public key of the joining
node during a previous join process.  In this case, the joining
node may not provide again its own public key to the Group
Manager, in order to limit the size of the join request.
The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication channel.  In
this case, the Group Manager stores the proof-of-possession key
conveyed in the Access Token as the public key of the joining
node.
Furthermore, as described in ssec-join-req, the joining node may have
explicitly requested the Group Manager to retrieve the public keys of
the current group members, i.e. through the 'get_pub_keys' parameter
in the join request.  In this case, the Group Manager includes also
such public keys in the 'pub_keys' parameter of the join response
(see ssec-join-resp).
Later on as a group member, the node may need to retrieve the public
keys of other group members.  The node can do that by exchanging
shortened Join Request and Join Response messages with the Group
Manager, according to the approach defined in Section 7 of I-D.ietf-
ace-key-groupcomm.
In order to rekey the OSCORE group, the Group Manager distributes a
new Group ID of the group and a new OSCORE Master Secret for that
group.  To this end, 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 'kty', 'key', 'profile' and 'exp' are present.
In particular, one of the following four cases can occur when a new
node joins an OSCORE group.
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.
The Group Manager already acquired the public key of the joining
node during a past join process.  In this case, the joining node
MAY not provide again its own public key to the Group Manager, in
order to limit the size of the Join Request.  The joining node
MUST provide its own public key again if it has provided the Group
Manager with multiple public keys during past join processes,
intended for different OSCORE groups.  If the joining node
provides its own public key, the Group Manager performs
consistency checks as in ssec-join-resp and, in case of success,
considers it as the public key associated to the joining node in
the OSCORE group.
The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication channel.  Then,
two cases can occur.
The proof-of-possession key is consistent with the encoding as
well as with the counter signature algorithm and possible
associated parameters used in the OSCORE group.  Then, the
Group Manager considers the proof-of-possession key as the
public key associated to the joining node in the OSCORE group.
If the joining node is aware that the proof-of-possession key
is also valid for the OSCORE group, it MAY not provide it again
as its own public key to the Group Manager.  The joining node
MUST provide its own public key again if it has provided the
Group Manager with multiple public keys during past join
processes, intended for different OSCORE groups.  If the
joining node provides its own public key in the 'client_cred'
parameter of the Join Request (see ssec-join-req), the Group
Manager performs consistency checks as in ssec-join-resp 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 consistent 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 consistent public key to the
Group Manager in the 'client_cred' parameter of the Join
Request (see ssec-join-req).  Then, the Group Manager performs
consistency checks on this latest provided public key as in
ssec-join-resp and, in case of success, considers it as the
public key associated to the joining node in the OSCORE group.
Furthermore, as described in ssec-join-req, the joining node may have
explicitly requested the Group Manager to retrieve the public keys of
the current group members, i.e. by including the 'get_pub_keys'
parameter in the Join Request.  In this case, the Group Manager
includes also such public keys in the 'pub_keys' parameter of the
Join Response (see ssec-join-resp).
Later on as a group member, the node may need to retrieve the public
keys of other group members.  The node can do that by exchanging with
the Group Manager a shortened Join Request sent to the same Join
Resource with the 'type' parameter set to 5 ("pub keys") and a
shortened Join Response, according to the approach defined in
Section 7 of I-D.ietf-ace-key-groupcomm.
In order to rekey the OSCORE group, the Group Manager distributes a
new Group ID of the group and a new OSCORE Master Secret for that
group.  When doing so, the Group Manager MAY take a best effort to
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 MUST support at least the following group rekeying
scheme.  Future application profiles may define alternative message
formats and distribution schemes.
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 I-D.ietf-core-object-security 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.
A group member queries the Group Manager for updated group keying
material, by sending a dedicated request to the same Join Resource
targeted when joining the group.  Like for the case discussed in
ssec-join-resp where the OSCORE Security Context expires, the
group member exchanges with the Group Manager a shortened Join
Request sent to the same Join Resource with the 'type' parameter
set to 3 ("update key") and a shortened Join Response message,
according to the approach defined in Section 6 of I-D.ietf-ace-
key-groupcomm.
A group member subscribes for updates to the join resource and its
associated group keying material on 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.
Either case, the Group Manager provides the (updated) group keying
material as specified above in this section.
Synchronization of sequence numbers (see Section 5 of I-D.ietf-
core-oscore-groupcomm).  This concerns how a listener node that
has just joined an OSCORE group can synchronize with the sequence
number of requesters in the same group.
Before sending the join response, the Group Manager should verify
that the joining node actually owns the associated private key, for
instance by performing a proof-of-possession challenge-response,
whose details are out of the scope of this specification.
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 profile of ACE signalled by
the AS, such as I-D.ietf-ace-dtls-authorize and I-D.ietf-ace-oscore-
profile.
Synchronization of sequence numbers (see Section 5 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 Join 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 consistent with the
encoding as well as with the countersignature 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.
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.
IANA is asked to register the following entry in the "ACE
Authorization Server Request Creation Hints" Registry defined in
Section 8.1 of I-D.ietf-ace-oauth-authz.
IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 9.1 of I-D.ietf-ace-key-groupcomm.
Profile: "coap_group_oscore", defined in ssec-iana-groupcomm-
profile-registry of this specification.
IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 11.5 of I-D.ietf-ace-key-groupcomm.
Profile: "coap_group_oscore_app", defined in ssec-iana-groupcomm-
profile-registry of this specification.
IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 9.2 of I-D.ietf-ace-key-
groupcomm.
Description: Profile to provision keying material for
participating in group communication protected with Group OSCORE
as per I-D.ietf-core-oscore-groupcomm.
IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 11.6 of I-D.ietf-ace-key-
groupcomm.
Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE
as per I-D.ietf-core-oscore-groupcomm.
IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 11.8 of I-
D.ietf-ace-key-groupcomm.
Description: No action is taken.
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.1).
Description: The first received request sets the baseline
reference point, and is discarded with no delivery to the
application.
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.2).
Description: Challenge response using the Echo Option for CoAP
from I-D.ietf-core-echo-request-tag.
Reference: I-D.ietf-core-oscore-groupcomm (Appendix E.3).