Draft: draft-ietf-ace-key-groupcomm

Commentary:  's review , as agreed at IETF108 . 
 Add a handler to the root for requesting gids and getting group names and URIs back ( we probably need to register a new parameter to send those URIs in the same map ) . Add group identifier terminology as identifier of group keying material . 
 not happy with Retrieval of New Individual Keying Material Jim suggests : 3 - Retrieval of keying material 4 - Requesting a change of keying material  : I would be against renaming section 4.4 so because it seems to imply a group rekey , while that is not what this exchange is . I think we still need something in the title with “ individual ” , as opposed to “ group keying ” . [ JLS ] But section 4.4 could be about a group rekeying . It is going to be profile based how this is responded to . A profile for which identifiers are fixed is going to re - key the entire group . One for which they are fluid can just change the identifier . 
 “ Beside possible expiration , the client may need to communicate to the KDC its need for part of the keying material to be renewed . “ Remove part of and put in text about why this is needed ( i.e. AEAD integrity / confidentially limits ) to motivate things better . 
 it 's already in sec cons ,  . 
 remove individual 
 OLD The handler only accepts a request from the node identified by " NODENAME " via the secure session , where NODENAME is used in Uri-  , and that is part of the " GROUPNAME " group : the handler verifies that the group name " GROUPNAME " is a subset of the ' scope ' stored in the access token associated to this client , and that this client is identified by " NODENAME " . If verification fails , the KDC MUST respond with a 4.01 ( Unauthorized ) error message . NEW The handler verifies that the group name of the /ace - group / GROUPNAME path is a subset of the ' scope ' stored in the access token associated to this client , identified by " NODENAME " . If verification fails , the KDC MUST respond with a 4.01 ( Unauthorized ) error message . 
 add following explanation : The KDC extract the granted 
 repeat encoding and remove ref to framework 
 high level 
 and use " invariant once established " instead 
 Remove that the root uris can be different for every profile . They all use the same and what specific application profile is used is per group ( and that info is saved in each group ) . 
 does it mean that we need to register a well - known URI for this document though ? ( only for this one and not for additional application profiles ) 
 One of two things need to happen . 1 ) register a will - known URI or 2 ) document how this would be found if a server decides to use a different URI . This is the rt and directory thing that the ace framework is doing . 
 i think being consistent with what the framework does is probably the right choice . 
 OLD The Client can retrieve a new individual key , or new input material to derive it . This is described in Section 4.4 . NEW The Client can retrieve new keying material for itself . This is described in Section 4.4 
 s / applications / application profiles 
 s / different key / different signing key 
 OLD : After successful verification , the Client is authorized to receive the group keying material from the KDC and join the group . In particular , the KDC replies to the Client with a 2.01 ( Created ) response , using Content - Format " application / ace+cbor " defined in Section 8.14 of [ I - D.ietf - ace - oauth - authz ] . NEW : After successful verification , the Client is authorized to receive the group keying material from the KDC and join the group . The KDC replies to the Client with a 2.01 ( Created ) response , using Content - Format " application / ace+cbor " defined in Section 8.14 of [ I - D.ietf - ace - oauth - authz ] . 
 OLD : Optionally , the Client might want to request information concerning the public keys in the group , as well as concerning the algorithm and related parameters for computing signatures in the group . In such a case , the joining node MAY ask for that information to the KDC in this same request . To this end , it sends the CoAP POST request to the /authz - info endpoint using the Content - Format " application/ ace+cbor " . NEW : Optionally , the Client might want to request encoding information about the public keys in the group , used for source authentication , as well as any other group parameters . The joining node MAY ask for this information from the KDC in the same message as it uses to POST the token to the RS . 
 that if it ’s not present in the response the granted scope is the same as the requested one . 
 even if those 2 are different 
 instead of any - this simplifies the processing of getting the group name in the rd 
 Add an example of scope that uses AIF port the example from the OSCORE application profile ( the one in section 3 of ) . 
 OLD : The Content - Format used in the message is the one indicated by the used transport profile of ACE . For example , ... NEW : The Content - Format used in the message depends on the used transport profile of ACE . For example , ... 
 OLD : “ Possible ways to provide a secure communication association are DTLS [ RFC6347 ] and OSCORE [ RFC8613 ] . ” NEW : “ Possible ways to provide a secure communication association are described in the DTLS transport profile [ I - D.ietf - ace - dtls - authorize ] and OSCORE transport profile [ I - D.ietf - ace - oscore - profile ] of ACE . ”
"Group name" is the invariant once established identifier of the
group.  It is used in the communication between AS, RS and Client
to identify the group.
"GROUPNAME" is the invariant once established text string used in
URIs.  GROUPNAME maps to the group name of a group, although it is
not necessarily the same.
"Group identifier" is the identifier of the group keying material.
Opposite to group name and GROUPNAME, this identifier changes over
time, when the keying material is updated.
"NODENAME" is the invariant once established text string used in
URIs.  NODENAME is used to identify a node in a group.
Application profile, that defines how applications enforce and use
supporting security services they require.  These services may
include, for instance, provisioning, revocation and
(re-)distribution of keying material.  An application profile may
define specific procedures and message formats.
Application profile, that defines how applications enforce and use
supporting security services they require.  These services may
include, for instance, provisioning, revocation and distribution
of keying material.  An application profile may define specific
procedures and message formats.
The joining node transfers authentication and authorization
information to the KDC, by posting the obtained Access Token to
the /authz-info endpoint at the KDC.  This exchange, and all
further communications between the Client and the KDC, MUST occur
over the secure channel established as a result of the transport
profile of ACE used between Client and KDC.  After that, a joining
node MUST have a secure communication association established with
the KDC, before starting to join a group under that KDC.  Possible
ways to provide a secure communication association are DTLS
RFC6347 and OSCORE RFC8613.
The joining node transfers authentication and authorization
information to the KDC, by posting the obtained Access Token to
the /authz-info endpoint at the KDC.  This exchange, and all
further communications between the Client and the KDC, MUST occur
over the secure channel established as a result of the transport
profile of ACE used between Client and KDC.  After that, a joining
node MUST have a secure communication association established with
the KDC, before starting to join a group under that KDC.  Possible
ways to provide a secure communication association are described
in the DTLS transport profile I-D.ietf-ace-dtls-authorize and
OSCORE transport profile I-D.ietf-ace-oscore-profile of ACE.
Communications between the Client and the AS MUST be secured, as
defined by the transport profile of ACE used.  The Content-Format
used in the message is the one indicated by the used transport
profile of ACE.  For example, this can be application/ace+cbor for
the first two messages and application/cwt for the third message,
which are defined in the ACE framework.  The transport profile of ACE
also defines a number of details such as the communication and
security protocols used with the KDC (see Appendix C of I-D.ietf-ace-
oauth-authz).
Communications between the Client and the AS MUST be secured, as
defined by the transport profile of ACE used.  The Content-Format
used in the message depends on the used transport profile of ACE.
For example, this can be application/ace+cbor for the first two
messages and application/cwt for the third message, which are defined
in the ACE framework.  The transport profile of ACE also defines a
number of details such as the communication and security protocols
used with the KDC (see Appendix C of I-D.ietf-ace-oauth-authz).
By default, each entry is encoded as specified by I-D.bormann-
core-ace-aif.  It is up to the application profiles to define and
register Toid and Tperm to fit the use case.  The object
identifier Toid corresponds to the group name, while the
permission set Tperm indicates the roles that the client wishes to
take in the group.
As first element, the identifier of the specific group or
topic.
By default, each entry is encoded as specified by I-D.bormann-
core-ace-aif.  The object identifier Toid corresponds to the group
name and MUST be encoded as a tstr.  The permission set Tperm
indicates the roles that the client wishes to take in the group.
It is up to the application profiles to define Tperm (REQ2) and
register Toid and Tperm to fit the use case.  An example of scope
using the AIF format is given in cddl-ex-0.
As first element, the identifier of the specific group or
topic, encoded as a tstr.
In each entry, the encoding of the group or topic identifier (REQ1
in req) and of the role identifiers (REQ2) is application
specific, and part of the requirements for the application
profile.
In particular, the application profile may specify CBOR values to
use for abbreviating role identifiers (OPT7).
In each entry, the encoding of the role identifiers is application
specific, and part of the requirements for the application profile
(REQ2).  In particular, the application profile may specify CBOR
values to use for abbreviating role identifiers (OPT7).
'scope' containing the scope the AS grants access to.  This
parameter has the same format and encoding of 'scope' in the
Authorization Request, defined in ssec-authorization-request.
'scope' containing the scope the AS grants access to.  This
parameter has the same format and encoding of 'scope' in the
Authorization Request, defined in ssec-authorization-request.  If
this parameter is not present the granted scope is equal to the
one requested in ssec-authorization-request}.
Optionally, the Client might want to request information concerning
the public keys in the group, as well as concerning the algorithm and
related parameters for computing signatures in the group.  In such a
case, the joining node MAY ask for that information to the KDC in
this same request.  To this end, it sends the CoAP POST request to
the /authz-info endpoint using the Content-Format "application/
ace+cbor".
Optionally, the Client might want to request encoding information
about the public keys in the group, used for source authentication,
as well as any other group parameters.  The joining node MAY ask for
this information from the KDC in the same message it uses to POST the
token to the RS.
After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group.  In
particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of I-D.ietf-ace-oauth-authz.
After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group.
The KDC replies to the Client with a 2.01 (Created) response, using
Content-Format "application/ace+cbor" defined in Section 8.14 of I-
D.ietf-ace-oauth-authz.
The KDC MUST store the 'kdcchallenge' value associated to the Client
at least until it receives a join request from it (see ssec-key-
distribution-exchange), to be able to verify the proof of possession.
The same challenge MAY be reused several times by the Client, to
generate new proof of possessions, e.g. in case of update of the
public key, or to join a different group with a different key, so it
is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' after
the first join is processed as well.  If the KDC has already
discarded the 'kdcchallenge', that will trigger an error response
with a newly generated 'kdcchallenge' that the client can use to
restart the join process, as specified in ssec-key-distribution-
exchange.
The KDC MUST store the 'kdcchallenge' value associated to the Client
at least until it receives a join request from it (see ssec-key-
distribution-exchange), to be able to verify the proof of possession.
The same challenge MAY be reused several times by the Client, to
generate new proof of possessions, e.g. in case of update of the
public key, or to join a different group with a different signing
key, so it is RECOMMENDED that the KDC keeps storing the
'kdcchallenge' after the first join is processed as well.  If the KDC
has already discarded the 'kdcchallenge', that will trigger an error
response with a newly generated 'kdcchallenge' that the client can
use to restart the join process, as specified in ssec-key-
distribution-exchange.
Applications of this specification MAY define alternative specific
negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' is not used (OPT2).
Application profiles of this specification MAY define alternative
specific negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' is not used (OPT2).
The CDDL notation RFC8610 of the 'sign_info' parameter formatted as
in the response is given below, with gname formatted as a bstr (note
that gname can be encoded differently, see REQ1).
The CDDL notation RFC8610 of the 'sign_info' parameter formatted as
in the response is given below.
The Client can retrieve a new individual key, or new input
material to derive it.  This is described in new-keys.
The Client can retrieve new keying material for itself.  This is
described in new-keys.
The KDC is configured with the following resources.  Note that the
root url-path "ace-group" given here are default names:
implementations are not required to use these names, and can define
their own instead.  The Interface Description (if=) Link Target
Attribute value ace.group is registered (if-ace-group) and can be
used to describe this interface.
The KDC is configured with the following resources.  Note that the
root url-path "ace-group" given here are default names:
implementations are not required to use these names, and can define
their own instead.  Each application profile of this specification
MUST register a Resource Type for the root url-path (REQ7a), and that
Resource Type can be used to discover the correct url to access at
the KDC.  This Resource Type can also be used at the GROUPNAME sub-
resource, to indicate different application profiles for different
groups.  The Interface Description (if=) Link Target Attribute value
ace.group is registered (if-ace-group) and can be used to describe
this interface.
No handlers are implemented for this resource.
This resource implements a FETCH handler.
The FETCH handler receives group identifiers and returns the
corresponding group names and GROUPNAME URIs.
'gid', whose value is encoded as a CBOR array, containing one or
more group identifiers.  The exact encoding of group identifier
MUST be specified by the application profile (REQ7b).  The Client
indicates that it wishes to receive the group names and GROUPNAMEs
of all groups having these identifiers.
The handler identifies the groups that are secured by the keying
material identified by those group identifiers.
'gid', whose value is encoded as a CBOR array, containing zero or
more group identifiers.  The handler indicates that those are the
identifiers it is sending group names and GROUPNAMEs for.  This
CBOR array is a subset of the 'gid' array in the FETCH request.
'gname', whose value is encoded as a CBOR array, containing zero
or more group names.  The elements of this array are encoded as
text strings.  Each element of index i of this CBOR array
corresponds to the element of group identifier i in the 'gid'
array.
'guri', whose value is encoded as a CBOR array, containing zero or
more URIs, each indicating a GROUPNAME resource.  The elements of
this array are encoded as text strings.  Each element of index i
of this CBOR array corresponds to the element of group identifier
i in the 'gid' array.
If the KDC does not find any group associated with the specified
group identifiers, the handler returns a response with payload
formatted as a CBOR byte string of zero length.
'cnonce', with the same encoding as defined for the "cnonce"
parameter of Ace, in Section 5.1.2 of I-D.ietf-ace-oauth-authz,
and including a dedicated nonce N_C generated by the Client.  This
parameter MUST be present if the 'client_cred' parameter is
present.
'cnonce', encoded as a CBOR byte string, and including a dedicated
nonce N_C generated by the Client.  This parameter MUST be present
if the 'client_cred' parameter is present.
The handler extracts the granted scope from the access token, and
checks the requested one against the token one.  If this join message
does not include a 'scope' field, the KDC is expected to understand
which group and role the Client is requesting (e.g. there is only one
the Client has been granted).  If the KDC can not recognize which
scope the Client is requesting, it MUST respond with a 4.00 (Bad
Request) error message.
that such public key has an acceptable format for the group
identified by "GROUPNAME", i.e. it is encoded as expected and is
compatible with the signature algorithm and possible associated
parameters.  If that cannot be verified, it is RECOMMENDED that
the handler stops the process and responds with a 4.00 (Bad
Request) error message.  Applications profiles MAY define
alternatives (OPT5).
that the signature contained in "client_cred_verify" passes
verification.  If that cannot be verified, the handler MUST
respond with a 4.00 (Bad Request) error message, and if the token
was posted (see REQ17) including the 'kdcchallenge' associated to
this Client (see token-post) if it can be retrieved, or otherwise
newly generated, in a CBOR map in the payload.  This error
response MUST also have Content-Format "application/ace+cbor".
that such public key has an acceptable format for the group
identified by "GROUPNAME", i.e. it is encoded as expected and is
compatible with the signature algorithm and possible associated
parameters.
that the signature contained in "client_cred_verify" passes
verification.
If that cannot be verified, it is RECOMMENDED that the handler stops
the process and responds with a 4.00 (Bad Request) error message.
Applications profiles MAY define alternatives (OPT5).
The PUT handler is used to get the KDC to produce and return
individual keying material to protect outgoing messages for the node
(identified by "NODENAME") for the group identified by "GROUPNAME".
The PUT handler is used to get the KDC to produce and return
individual keying material to protect outgoing messages for the node
(identified by "NODENAME") for the group identified by "GROUPNAME".
Application profiles MAY also use this handler to rekey the whole
group.  (OPT8) It is up to the application profiles to specify if
this handler supports renewal of individual keying material, renewal
of the group keying material or both.
If verification succeeds, the handler returns a 2.05 (Content)
message containing newly-generated individual keying material for the
Client, or information enabling the Client to derive it.  The payload
of the response is formatted as a CBOR map.  The specific format of
newly-generated individual keying material for group members, or of
the information to derive it, and corresponding CBOR label, MUST be
specified in the application profile (REQ15) and registered in iana-
reg.
If verification succeeds, the handler returns a 2.05 (Content)
message containing newly-generated keying material for the Client,
and/or, if the application profiles requires it (OPT8), starts the
comprete group rekeying.  The payload of the response is formatted as
a CBOR map.  The specific format of newly-generated individual keying
material for group members, or of the information to derive it, and
corresponding CBOR label, MUST be specified in the application
profile (REQ15) and registered in iana-reg.
The handler only accepts a request from the node identified by
"NODENAME" via the secure session, where NODENAME is used in Uri-
Path, and that is part of the "GROUPNAME" group: the handler verifies
that the group name "GROUPNAME" is a subset of the 'scope' stored in
the access token associated to this client, and that this client is
identified by "NODENAME".  If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.
The handler verifies that the group name of the /ace-group/GROUPNAME
path is a subset of the 'scope' stored in the access token associated
to this client, identified by "NODENAME".  If verification fails, the
KDC MUST respond with a 4.01 (Unauthorized) error message.
In case the joining node only knows the group identifier of the group
it wishes to join or about which it wishes to get update information
from the KDC, the node can contact the KDC to request the
corresponding group name and joining resource URI.  The node can
request several group identifiers at once.  It does so by sending a
CoAP FETCH request to the /ace-group endpoint at the KDC formatted as
defined in ace-group-fetch.
fig-ace-group-fetch gives an overview of the exchanges described
above.
To join the group, the Client sends a CoAP POST request to the /ace-
group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group
name of the group to join, formatted as specified in gid-post.  This
group name is the same as in the scope entry corresponding to that
group, specified in the 'scope' parameter of the Authorization
Request/Response, or it can be retrieved from it.  Note that, in case
of successful joining, the Client will receive the URI to retrieve
individual or group keying material and to leave the group in the
Location-Path option of the response.
To join the group, the Client sends a CoAP POST request to the /ace-
group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group
name of the group to join, formatted as specified in gid-post.  This
group name is the same as in the scope entry corresponding to that
group, specified in the 'scope' parameter of the Authorization
Request/Response, or it can be retrieved from it.  Note that, in case
of successful joining, the Client will receive the URI to retrieve
group keying material and to leave the group in the Location-Path
option of the response.
Congestion control mechanisms need to be implemented: see Section 4.7
of RFC7252 and, where Observe is used, Section 4.5.1 of RFC7641.
Beside possible expiration, the client may need to communicate to the
KDC its need for part of the keying material to be renewed.  For
example, if the Client uses an individual key to protect outgoing
traffic and has to renew it, the node may request a new one, or new
input material to derive it, without renewing the whole group keying
material.
Beside possible expiration, the client may need to communicate to the
KDC its need for the keying material to be renewed, e.g. due to
exhaustion of AEAD nonces, if AEAD is used for protecting group
communnication.  Depending on the application profile (OPT8), this
can result in renewal of idividual keying material, group keying
material, or both.  For example, if the Client uses an individual key
to protect outgoing traffic and has to renew it, the node may request
a new one, or new input material to derive it, without renewing the
whole group keying material.
Furthermore, policies can be set up so that, upon receiving a Key
Renewal Request, the KDC performs a complete group rekeying before or
after replying to the client (OPT8).
When receiving a Public Key Response, the requesting group member
stores (or updates) the public keys (in the 'pub_keys' parameter) and
roles (in the 'peer_roles' parameter) of the group members.