Draft: draft-ietf-ace-key-groupcomm

Commentary:  's review : In Section 4.1.2.1 - I believe that the minimal content for a join request is an empty map . I believe that the minimal content for a join response is an empty map . The first makes sense as authorization comes from else where and so can the public key if it is needed . I am not so sure that an empty response makes a great deal of sense for a response but it may be what you intended . 
 This was an editorial bug , of course the response always MUST contain group keying material . 
 said : 
 Actually , you do not need to be a member of the group ( i.e. having done the join process ) to get the public keys , so there is no need to define such a role . As long as you get access to the pub - key resource ( by getting authorized by the AS ) , you can request those . Will add some considerations about that in pub - key section . 
 But this is something that I might want to control in order to restrict who can determine who is in the group . This would be determinable by looking at the public key . 
 Had agreement that it 's fine at the interim ( OSCORE profile does define the role for monitor ) . 
 So , the additional detail should cover : A mechanism like  B.2 of OSCORE are useful in case of lost of context and reboot , so that the recipient can be on the safe side . If the group is rekeying , the time window between the end of the rekeying and a next loss of context is safe to go . A group rekeying puts the recipients on the safe side . Is that it ? 
 I hope this is a good enough clarification .. 
 said : The answer is not necessarily , but nothing stops the KDC to do a key rollover if it wants . I think this should be already clear , do we need any specific clarifications ? 
 Not fixed . 
 better now ? The point is that 1st paragraph said : " this request is only accepted if you are deleting your own resource ( " NODENAME " ) " and par 3 said " this request is only accepted if the node is authorized for this group ( " GROUPNAME " ) " . So it was 2 different things . Now I merged them , as they probably fit much better together in par 3 ... 
 said : 
 said : 
 In retrospect , I think that allowing it to be a floating point is a general CWT error . It was copied directly from CBOR but it means that all of the servers / clients now potentially need to have support for a floating point library to evaluate this field . Making it only an integer means that is not an issue . This has been raised as a RATS issue 
 That makes sense . I 'll change it to only int . Maybe it can be " fixed " in the Ace framework ( ) as well ? By keeping the value integer or floating but adding a sentence saying that a constrained implementation might only use ints ( which might be useful if the token use only int ) ? 
 Related to ' controlpath ' , asked : 
 No by the server - it is the client providing this to the server . 
 Ah ok , you mean if the KDC does not support mechanism using that ? Then it will just ignore that parameter I suppose ... I will add a note about that . 
 as Interface Description ( if= ) Link Target Attribute Values Registry expert , does this registration for the Key Distribution Center interface look ok to you ? ( before I close the issue ) 
 wrote : In Section 3.3 - As an input to your " make it an array " decisions , remember that the order of scope elements that the client gave to the AS are not necessarily the same order as are in the token . I think you might just need to collapse all three arrays into a single value in the map . 
 I am not sure what " collapse all three arrays in a single value in the map " means ... But yes we need to deal with this :  proposes the following : I think this makes more sense : We are not allowing more than one pub key encoding anyway per group . I 'll implement this , but please comment if you do n't agree . 
 Yes that was the type of thing I was thinking of . 
 I have the feeling this might be leftovers , I do n't see a reason now why the AS could not return the same access token ( if it 's still valid ) ... Whatever issues there could be about re - use of keying material MUST be dealt with by the application profile used ( which OSCORE profile does with nonces , for example ) 
 the AS MAY reply with 
 wrote : This was leftover text that never got fixed . We will explicitly state what  ( and what MAY ) be included in the token . 
 I believe that one needs to look at the following cases : No public key with the right parameters has been associated with the token - in this case both the key and proof are required One public key with the right parameters has been associated with the token - in this case the following would seem to be fine a ) neither are present , b ) just the key is present ( proof already has been done ) , c ) both are present public keys with the right parameters have been associated with the token - In this case the following would seem to be fine a ) just the key is present ( proof has already been done ) or b ) both are present Such a change would seem to maximize the number of times that the public key can be omitted and an even greater number of times the proof can be omitted . In the event that the proof is needed , the error would return a new server nonce to be used in the re - sent join message . 
 EDIT : this response is in preparation for Ace interim 15 - 04 - 2020 My main question is : what does this consideration applies to ? It could apply to the joining process and to POST to pub - key ( where the node post a new public key to the KDC ) . These are quite perpendicular though ( 1 -joining , 2 -pub - key , 3 -not supported ) , so I am not sure what this adds … This could be covering the join – leave – rejoin with the same token process , that is not very well covered right now , is that something we need to expand on ? What we do say is that key and proof of possession are required during join process if KDC collects and distribute keys , and the client is a sender . So one key will always be associated with the token . 1 is a quite convoluted way to say : “ always at joining ” ( which we already say … ) or is this supposed to cover another case ? Are we talking about after joining , posting a new pub key to the KDC ? Then both are needed . Unless the key is the same … in which case it is useless to repost the same to pub - key . The KDC only keeps one public key per node ( see pub - key handler ) , this is not supported . In what case would the client want to associate more than one key ? Is this something we want ? I think right now we already cover the case where the key and proof MUST be sent in each section . What are we missing ? 
 If I have a token that allows access to multiple groups , once I have done the POP on the signing key for that token , that POP can be propagated forward to any other group join which uses the same token . I might end up with multiple keys for the single token with different keys . This POP could potentially be propagated forward as tokens are updated .
An example of CDDL definition of scope, with group identifier
encoded as byte string and role identifier as text string, is
given in cddl-ex.
The CDDL definition of scope, using as example group identifier
encoded as byte string and role identifier as text string, is
given in cddl-ex.
The access token MUST contain all the parameters defined above
(including the same 'scope' as in this message, if present, or the
'scope' of the Authorization Request otherwise), and additionally
other optional parameters that the transport profile of ACE requires.
When receiving an Authorization Request from a Client that was
previously authorized, and which still owns a valid non expired
access token, the AS replies with an Authorization Response with a
new access token.
a scope claim (see for example 'scope' registered in Section 8.13
of I-D.ietf-ace-oauth-authz for CWT).  This claim has the same
encoding as 'scope' parameter above.  Additionally, this claim has
the same value of the 'scope' parameter if the parameter is
present in the message, or it takes the value of 'scope' in the
Authorization Request otherwise.
The access token MAY additionally contain other claims that the
transport profile of ACE requires, or other optional parameters.
When receiving an Authorization Request from a Client that was
previously authorized, and for which the AS still owns a valid non
expired access token, the AS MAY reply with that token.  Note that it
is up to application profiles of ACE to make sure that re-posting the
same token does not cause re-use of keying material between nodes
(for example, that is done with the use of random nonces in I-D.ietf-
ace-oscore-profile).
'sign_info' defined in sign-info, encoding the CBOR simple value
Null, to require information and parameters on the signature
algorithm and on the public keys used in the group.
The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters
formatted as in the request is given below.
'sign_info' defined in sign-info.
The payload of the 2.01 response is a CBOR map, which MUST include
the parameter 'rsnonce' defined in Section rsnonce, specifying a
dedicated nonce N_S generated by the KDC.  The Client may use this
nonce for proving possession of its own private key (see the
'client_cred_verify' parameter in key-distr).  Note that the payload
format of the response deviates from the default as defined in the
ACE framework (see Section 5.8.1 of I-D.ietf-ace-oauth-authz).
Optionally, if they were included in the request, the KDC MAY include
the 'sign_info' parameter as well as the 'pub_key_enc' parameter
defined in sign-info and pub-key-enc of this specification,
respectively.
The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter with value Null.  If present, the
'sign_info' parameter of the 2.01 (Created) response is a CBOR array
formatted as follows.
TODO: have 'sign_info' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
The first element 'sign_alg' is an integer or a text string,
indicating the signature algorithm used in the group.  It is
REQUIRED of the application profiles to define specific values
that this parameter can take (REQ3), selected from the set of
signing algorithms of the COSE Algorithms registry defined in
RFC8152.
The second element 'sign_parameters' indicates the parameters of
the signature algorithm.  Its structure depends on the value of
'sign_alg'.  It is REQUIRED of the application profiles to define
specific values for this parameter (REQ4).  If no parameters of
the signature algorithm are specified, 'sign_parameters' MUST be
encoded as the CBOR simple value Null.
The third element 'sign_key_parameters' indicates the parameters
of the key used with the signature algorithm.  Its structure
depends on the value of 'sign_alg'.  It is REQUIRED of the
application profiles to define specific values for this parameter
(REQ5).  If no parameters of the key used with the signature
algorithm are specified, 'sign_key_parameters' MUST be encoded as
the CBOR simple value Null.
The 'pub_key_enc' parameter MUST be present if the POST request
included the 'pub_key_enc' parameter with value Null.  If present,
the 'pub_key_enc' parameter of the 2.01 (Created) response is either
a CBOR integer indicating the encoding of public keys used in the
group, or has value Null indicating that the KDC does not act as
repository of public keys for group members.
TODO: have 'pub_key_enc' as an array, if 'scope' in the Access Token
covers multiple groups/topics.
Its acceptable values are taken from the "CWT Confirmation Method"
Registry defined in I-D.ietf-ace-cwt-proof-of-possession.  It is
REQUIRED of the application profiles to define specific values to use
for this parameter (REQ6).
The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters
formatted as in the response is given below.
The payload of the 2.01 response is a CBOR map.  If the access token
contains a role that requires the Client to send its own public key
to the KDC when joining the group, the CBOR map MUST include the
parameter 'kdcchallenge' defined in Section kdcchallenge, specifying
a dedicated challenge N_S generated by the KDC.  The Client uses this
challenge to prove possession of its own private key (see the
'client_cred_verify' parameter in key-distr).  Note that the payload
format of the response deviates from the default as defined in the
ACE framework (see Section 5.8.1 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.
If either of 'sign_info' or 'pub_key_enc' were included in the
request, the KDC MAY include the 'sign_info' parameter defined in
sign-info, optionally including the 'pub_key_enc' parameter pub-key-
enc.
The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter and/or the pub_key_enc with value
Null.  The encoding of the 'sign_info' parameter in the response is
defined in pub-key-enc.  Note that the field 'id' takes the value of
the group identifier for which the 'sign_info' applies to, in this
specification.
When used in the request, the 'sign_info' encodes the CBOR simple
value Null, to require information and parameters on the signature
algorithm and on the public keys used.
The CDDL notation of the 'sign_info' parameter formatted as in the
request is given below.
The 'sign_info' parameter of the 2.01 (Created) response is a CBOR
array of one ore more elements.  The number of elements is lower or
at most equal to the number of groups the client has been authorized
to join.  Each element contains information about signing parameters
and keys for one or more group or topic and is formatted as follows.
The first element 'id' is an identifier of the group or an array
of identifiers for the groups for which this information applies.
The second element 'sign_alg' is an integer or a text string if
the POST request included the 'sing_info' parameter with value
Null, and indicates the signature algorithm used in the group
identified by 'gid'.  It is REQUIRED of the application profiles
to define specific values that this parameter can take (REQ3),
selected from the set of signing algorithms of the COSE Algorithms
registry defined in RFC8152.  If the POST request did not include
the 'sing_info' parameter, this element is encoded as the CBOR
simple value Null.
The third element 'sign_parameters' indicates the parameters of
the signature algorithm.  Its structure depends on the value of
'sign_alg'.  It is REQUIRED of the application profiles to define
specific values for this parameter (REQ4).  If no parameters of
the signature algorithm are specified, 'sign_parameters' MUST be
encoded as the CBOR simple value Null.  If the POST request did
not include the 'sing_info' parameter, this element is encoded as
the CBOR simple value Null.
The fourth element 'sign_key_parameters' indicates the parameters
of the key used with the signature algorithm.  Its structure
depends on the value of 'sign_alg'.  It is REQUIRED of the
application profiles to define specific values for this parameter
(REQ5).  If no parameters of the key used with the signature
algorithm are specified, 'sign_key_parameters' MUST be encoded as
the CBOR simple value Null.  If the POST request did not include
the 'sing_info' parameter, this element is encoded as the CBOR
simple value Null.
The fifth element 'pub_key_enc' parameter is optional and MUST
only be present if the POST request included the 'pub_key_enc'
parameter with value Null.  If present, it is either a CBOR
integer indicating the encoding of public keys used in the group
identified by 'gid', or has value Null indicating that the KDC
does not act as repository of public keys for group members.  Its
acceptable values are taken from the "CWT Confirmation Method"
Registry defined in I-D.ietf-ace-cwt-proof-of-possession.  It is
REQUIRED of the application profiles to define specific values to
use for this parameter (REQ6).
The CDDL notation of the 'sign_info' parameter formatted as in the
response is given below, with gid formatted as a bstr (note that gid
can be encoded differently, see REQ1).
In this specification and in application profiles building on it,
this parameter is used to ask and retrieve from the KDC information
about the encoding of public keys used in the group.
The 'rsnonce' 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 a nonce generated by the RS and
provided to the Client.  Its exact content is application specific.
In this specification and in application profiles building on it,
this parameter is used to provide a nonce that the Client may use to
prove possession of its own private key in the Joining Request ((see
the 'client_cred_verify' parameter in key-distr).
In this specification and in application profiles building on it,
this parameter is used to ask the KDC information about the encoding
of public keys used in the group.
The CDDL notation of the 'pub_key_enc' parameter formatted as in the
request is given below.
The 'kdcchallenge' 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 a challenge generated by
the KDC and provided to the Client.  The Client may use this
challenge to prove possession of its own private key in the Joining
Request ((see the 'client_cred_verify' parameter in key-distr).
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 inferface.
The details for the handlers of each resource are given in the
following sections.  These endpoints are used to perform the
operations introduced in key-distr.  Note that the url-path given
here are default names: implementations are not required to use these
names, and can define their own instead.
The details for the handlers of each resource are given in the
following sections.  These endpoints are used to perform the
operations introduced in key-distr.
'cnonce', as defined 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.
'client_cred_verify', encoded as a CBOR byte string.  This
parameter MUST be present if the 'client_cred' parameter is
present.  This parameter contains a signature computed by the
Client over N_S concatenated with N_C, where N_S is the nonce
received from the KDC in the 'rsnonce' parameter of the 2.01
(Created) response to the token POST request (see token-post),
while N_C is the nonce generated by the Client and specified in
the 'cnonce' parameter above.  If the token is not being posted
(e.g. if it is used directly to validate TLS instead), it is
REQUIRED of the specific profile to define how the nonce N_S is
generated (REQ17).  The Client computes the signature by using its
own private key, whose corresponding public key is either directly
specified in the 'client_cred' parameter or included in the
certificate specified in the 'client_cred' parameter.
'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.
scope is the byte string specified in the 'scope parameter
above'.
N_S is the challenge received from the KDC in the
'kdcchallenge' parameter of the 2.01 (Created) response to the
token POST request (see token-post).
N_C is the nonce generated by the Client and specified in the
'cnonce' parameter above.
If the token is not being posted (e.g. if it is used directly to
validate TLS instead), it is REQUIRED of the specific profile to
define how the challenge N_S is generated (REQ17).  The Client
computes the signature by using its own private key, whose
corresponding public key is either directly specified in the
'client_cred' parameter or included in the certificate specified in
the 'client_cred' parameter.
'control_path', with value the URI path of a resource at the
Client, encoded as a CBOR text string.  This resource is intended
to be accessible for the KDC to send request messages to the
Client, such as for individual provisioning of new keying material
when performing a group rekeying.  In particular, this resource is
intended for communications concerning exclusively the group or
topic specified in the 'scope' parameter.  Note that, in order to
support mechanisms of rekeying using this resource, the Client
needs to be able to act as a CoAP server.
'control_path', with value a full URI, encoded as a CBOR text
string.  If 'control_path' is supported by the Client, the Client
acts as a CoAP server and hosts a resource at this specific URI.
The KDC MAY use this URI to send CoAP requests to the Client
(acting as CoAP server in this exchange), for example for
individual provisioning of new keying material when performing a
group rekeying (see update-keys), or to inform the Client of its
removal from the group sec-node-removal.  If the KDC does not
implement mechanisms using this resource, it can just ignore this
parameter.  Other additional functionalities of this resource MAY
be defined in application profiles of this specifications (OPT9).
In particular, this resource is intended for communications
concerning exclusively the group or topic specified in the 'scope'
parameter.
If the request is not formatted correctly (e.g. unknown, not-expected
fields present, or expected fields with incorrect format), the
handler MUST respond with a 4.00 (Bad Request) error message.  The
response MAY contain a CBOR map in the payload with ace-
groupcomm+cbor format, e.g. it could send back "pub_key_enc" set to
Null if the Client sent its own public key and the KDC is not set to
store public keys of the group members.  Application profiles MAY
define optional or mandatory payload formats for specific error cases
(OPT6).
If the KDC stores the group members' public keys, the handler
verifies that one public key can be retrieved for the node, either
from the 'client_cred' field, or from the KDC previous knowledge of
it.  In particular, the KDC checks that such public key has an
accepted 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
alternatives (OPT5).
If the signature contained in "client_cred_verify" does not pass
verification, the handler MUST respond with a 4.00 (Bad Request)
error message.
If the request is not formatted correctly (e.g. unknown, not-expected
fields present, or expected fields with incorrect format), the
handler MUST respond with a 4.00 (Bad Request) error message.  The
response MAY contain a CBOR map in the payload with ace+cbor format,
e.g. it could send back "pub_key_enc" set to Null if the Client sent
its own public key and the KDC is not set to store public keys of the
group members.  Application profiles MAY define optional or mandatory
payload formats for specific error cases (OPT6).
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".
If one public key is already associated to the access token and to
that group, but the 'client_cred' is populated with a different
public key, the handler MUST delete the previous one and replace it
with this one, after verifying the points above.
If the token was posted but the KDC cannot retrieve the
'kdcchallenge' associated to this Client (see token-post), the KDC
MUST respond with a 4.00 Bad Request error response, including a
newly generated 'kdcchallenge' in a CBOR map in the payload.  This
error response MUST also have Content-Format "application/ace+cbor".
Adds the node to the list of current members of the group.
Assigns a name NODENAME to the node, and creates a sub-resource to
/ace-group/GROUPNAME/ at the KDC (e.g. "/ace-
group/GROUPNAME/nodes/NODENAME").
Associates the identifier "NODENAME" with the access token and the
secure session for that node.
Associates the node's public key with its access token and the
group identified by "GROUPNAME", if such association did not
already exist.
Returns a 2.01 (Created) message containing the symmetric group
keying material, the group policies and all the public keys of the
current members of the group, if the KDC manages those and the
Client requested them.
'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or
floating-point number.  This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds,
analogous to what specified for NumericDate in Section 2 of
RFC7519.
'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer.  This
field contains a numeric value representing the number of seconds
from 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds, analogous to what specified for NumericDate
in Section 2 of RFC7519.  Group members MUST stop using the keying
material to protect outgoing messages and retrieve new keying
material at the time indicated in this field.
'exp_delta', with value the time interval (starting at 'exp')
during which the keying material for the group communication can
still be used for verifying incoming messages, encoded as a CBOR
unsigned integer.  This field contains a numeric value
representing the number of seconds from 'exp' until the specified
UTC date/time after which group members MUST stop using the keying
material to verify incoming messages.
The payload MAY also include the parameters 'ace-groupcomm-profile',
'exp' and 'mgt_key_material' parameters specified in gid-post.
The payload MAY also include the parameters 'ace-groupcomm-profile',
'exp', 'exp_delta' and 'mgt_key_material' parameters specified in
gid-post.
'get_pub_keys', whose value is a non-empty CBOR array.  Each
element of the array is the identifier of a group member for the
group identified by "GROUPNAME".  The specific format of public
keys as well as identifiers of group members MUST be specified by
the application profile (OPT1, REQ9).
The first array contains zero or more roles (or combination of
roles) of group members for the group identified by
"GROUPNAME".
The second array contains zero or more identifiers of group
members for the group identified by "GROUPNAME".
The CDDL definition of 'get_pub_keys' is given in cddl-ex-getpubkeys
using as example encoding: node identifier encoded as byte string,
role identifier as text string, and combination of roles encoded as a
CBOR array of roles.  Note that the empty array is not valid for this
handler, but is valid for the value of "get_pub_keys" received by the
handler of POST to ace-group/GROUPNAME (see gid-post).
The specific format of public keys as well as identifiers, roles and
combination of roles of group members MUST be specified by the
application profile (OPT1, REQ2, REQ9).
If verification succeeds, the handler identifies the public keys of
the current group members for which the identifier matches with one
of those indicated in the request.  Then, the handler returns a 2.05
(Content) message response with payload formatted as a CBOR map,
containing only the 'pub_keys' and 'peer_roles' parameters from gid-
post.  In particular, 'pub_keys' encodes the list of public keys of
those group members including the respective member identifiers,
while 'peer_roles' encodes their respective role (or CBOR array of
roles) in the group.
If verification succeeds, the handler identifies the public keys of
the current group members for which either: - the role identifier
matches with one of those indicated in the request (including the
exact combination of roles requested), or - the identifier matches
with one of those indicated in the request.
Then, the handler returns a 2.05 (Content) message response with
payload formatted as a CBOR map, containing only the 'pub_keys' and
'peer_roles' parameters from gid-post.  In particular, 'pub_keys'
encodes the list of public keys of those group members including the
respective member identifiers, while 'peer_roles' encodes their
respective role (or CBOR array of roles) in the group.
The DELETE handler removes the node identified by "NODENAME" from the
group identified by "GROUPNAME".  If the node sending the request and
the node name used in the Uri-Path do not match, the handler responds
with a 4.01 (Unauthorized) error response.
The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MAY contain only the
'scope' field as specified in gid-post.
The handler verifies that the group identifier 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.
If the request contained a 'scope' field, the handler MUST extract
the roles for that client.  If the value is such that the KDC cannot
extract all the necessary information to understand and process it
correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00
(Bad Request) error message.
The DELETE handler removes the node identified by "NODENAME" from the
group identified by "GROUPNAME".
The handler expects a request with method DELETE (and empty payload).
The handler only accept a request from the node that matches the
"NODENAME" used in Uri-Path, and that is part of the "GROUPNAME"
group: the handler verifies that the group identifier "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.
This resource implements a POST handler.
This resource implements a POST handler, if the KDC stores the public
key of group members.  If the KDC does not store the public keys of
group members, the handler does not implement any method, and every
request returns a 4.05 Method Not Allowed error.
The handler expects a POST request with payload as specified in gid-
post, with the difference that it includes only the parameters
'client_cred', 'cnonce' and 'client_cred_verify'.  In particular, the
signature included in 'client_cred_verify' is expected to be computed
as defined in gid-post.  Since no nonce N_S is provided by the KDC,
it is REQUIRED of the specific profile to define how the nonce N_S is
generated (REQ17).  The specific format of public keys is specified
by the application profile (OPT1).
The handler expects a POST request with payload as specified in gid-
post, with the difference that it includes only the parameters
'client_cred', 'cnonce' and 'client_cred_verify'.  In particular, the
signature included in 'client_cred_verify' is expected to be computed
as defined in gid-post, with a newly generated N_C nonce and the
previously received N_S.  The specific format of public keys is
specified by the application profile (OPT1).
Otherwise, the handler verifies the signature contained in the
'client_cred_verify' field of the request, using the public key
specified in the 'client_cred' field.  If the signature does not pass
verification, the handler MUST respond with a 4.00 (Bad Request)
error message.
Otherwise, the handler verifies the signature contained in the
'client_cred_verify' field of the request, using the public key
specified in the 'client_cred' field.  If the signature does not pass
verification, the handler MUST respond with a 4.00 (Bad Request)
error message.  If the KDC cannot retrieve the 'kdcchallenge'
associated to this Client (see token-post), the KDC MUST respond with
a 4.00 Bad Request error respons, including a newly generated
'kdcchallenge' in a CBOR map in the payload the payload.  This error
response MUST also have Content-Format "application/ace+cbor".
If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members, upon a new node's joining the group.  To this
end, the KDC uses the message format of the Joining Response (see
gid-post).  Application profiles may define alternative ways of
retrieving the keying material, such as sending separate requests to
different resources at the KDC (gid-get, pubkey-get, policies-get).
After distributing the new group keying material, the KDC MUST
increment the version number of the keying material.
If the node is joining a group for the first time, and the KDC
maintains the public keys of the group members, the Client is
REQUIRED to send its own public key and proof of possession
("client_cred" and "client_cred_verify" in gid-post).  The request is
only accepted if both public key and proof of possession are
provided.  If a node re-joins a group with the same access token and
the same public key, it can omit to send the public key and the proof
of possession, or just omit the proof of possession, and the KDC will
be able to retrieve its public key associated to its token for that
group (if the key has been discarded, the KDC will reply with 4.00
Bad Request, as specified in gid-post).  If a node re-joins a group
but wants to update its own public key, it needs to send both public
key and proof of possession.
If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members, upon a new node's joining the group.  To this
end, the KDC uses the message format of the response defined in gid-
get.  Application profiles may define alternative ways of retrieving
the keying material, such as sending separate requests to different
resources at the KDC (gid-get, pubkey-get, policies-get).  After
distributing the new group keying material, the KDC MUST increment
the version number of the keying material.
Upon expiration of the keying material, according to what
indicated by the KDC with the 'exp' parameter in a Joining
Response, or to a pre-configured value.
Upon expiration of the keying material, according to what
indicated by the KDC with the 'exp' (and possibly the 'exp_delta')
parameter in a Joining Response, or to a pre-configured value.
If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members, upon a group member updating its own public
key.  To this end, the KDC uses the message format of the response
defined in gid-get.  Application profiles may define alternative ways
of retrieving the keying material, such as sending separate requests
to different resources at the KDC (gid-get, pubkey-get, policies-
get).  After distributing the new group keying material, the KDC MUST
increment the version number of the keying material.
Additionally, after updating its own public key, a group member MAY
send a number of the later requests including an identifier of the
updated public key, to signal nodes that they need to retrieve it.
How that is done depends on the group communication protocol used,
and therefore is application profile specific (OPT10).
the access token is still valid, upon its expiration.
The node's authorization to be a group member is not valid
anymore, either because the access token has expired, or it has
been revoked.  If the AS provides Token introspection (see
Section 5.7 of I-D.ietf-ace-oauth-authz), the KDC can optionally
use it and check whether the node is still authorized for that
group in that role.
In case of forced eviction, the KDC MAY explicitly inform the leaving
node, if the Client implements the 'control_path' resource specified
in gid-post.  To this end, the KDC can send a DEL request, targeting
the URI specified in the 'control_path' parameter of the Joining
Request.
In case of forced eviction, the KDC MAY explicitly inform the leaving
node, if the Client implements the 'control_path' resource specified
in gid-post.  To this end, the KDC MAY send a DEL request, targeting
the URI specified in the 'control_path' parameter of the Joining
Request.
When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of RFC8613.
When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of RFC8613.  In case the Client rebooted and lost the
security state used to protect previous communication with that
sender, such a mechanism is useful for the recipient to be on the
safe side.  If the group has renewed its group keying material, the
time window between the end of the rekeying process and the next loss
of security state is safe for recipients, as replayed older messages
protected with previous keying material will not be accepted.
That is, the KDC may not rekey the group at every membership change,
for instance if members' joining and leaving occur frequently and
performing a group rekeying takes too long.  Instead, the KDC may
rekey the group after a minum number of group members have joined or
left within a given time interval, or during predictable network
inactivity periods.
That is, the KDC may not rekey the group at every membership change,
for instance if members' joining and leaving occur frequently and
performing a group rekeying takes too long.  Instead, the KDC may
rekey the group after a minimum number of group members have joined
or left within a given time interval, or during predictable network
inactivity periods.
The KDC needs to have a mechanism in place to detect DoS attacks from
nodes constantly initiating rekeys (for example by updating their
public key), such as removing these nodes from the group.
In the second case, the sender protects a message using the new
keying material, but the recipient receives that request before
having received the new keying material.  Therefore, the recipient
would not be able to correctly process the request and hence discards
it.  If the recipient receives the new keying material shortly after
that and the sender endpoint uses CoAP retransmissions, the former
will still be able to receive and correctly process the message.  In
any case, the recipient should actively ask the KDC for an updated
keying material according to an application-defined policy, for
instance after a given number of unsuccessfully decrypted incoming
messages.
In the second case, the sender protects a message using the new
keying material, but the recipient receives that request before
having received the new keying material.  Therefore, the recipient
would not be able to correctly process the request and hence discards
it.  If the recipient receives the new keying material shortly after
that and the application at the sender endpoint performs
retransmissions, the former will still be able to receive and
correctly process the message.  In any case, the recipient should
actively ask the KDC for an updated keying material according to an
application-defined policy, for instance after a given number of
unsuccessfully decrypted incoming messages.
Description: The 'ace group' interface is used to provision keying
material and related informations and policies to members of a
group using the Ace framework.