Re: [Ace] draft-ietf-ace-key-groupcomm-13

[Cigdem Sengul <[e-mail]>]

Hello Marco,

Apologies for getting back to you late, I was/am snowed under at work.
But I've also read through the previous interim discussion as well.
In general, I think  everything is much clearer now.
Some more comments inline, mostly OKing your suggestions (and removing some
previous ones where we are in agreement, and there is no feedback sought).
Kind regards,
--Cigdem


On Wed, Sep 1, 2021 at 9:27 PM Marco Tiloca <[e-mail]> wrote:

> Hi Cigdem,
>
> Thank you very much for your review! Please, find my replies inline marked
> as "==>MT".
>
> Best,
> /Marco
>
> On 2021-08-25 23:52, Cigdem Sengul wrote:
>
>
> Hello,
> Here is also my review, as promised. I agree with Göran's comments and
> tried not to repeat them (but I realise I have the same concern about the
> presentation of Section 4 - more details below).
> *General comments:*
> The draft is quite thorough in providing details about how a node, as a
> participant of group communication, can get authorisation, join/get
> information about and leave the group, how a node can be removed, and how
> the key information is provided to protect the group communication. In the
> pub-sub draft, we take advantage of all these resources to secure pub-sub
> communication.
> In addition to some questions I have about resources (in my detailed
> comments), most of my comments are focused on improving the readability of
> the draft. As Göran also mentioned, after defining the available resources,
> it would be good to explain the flows and then give details of endpoints
> and examples. This way, it would be possible to understand first the
> primitives available for securing group communication, then have more
> detail important for the implementation.
>
>
> ==>MT
> I believe that the proposal to address this point in the review from Göran
> [1][1reply] can help here too. I re-include it below for convenience.
>
> 1) Merging the points from the bullet list of Section 4.0 into the
> corresponding resource description of Section 4.1, while still preserving
> the forward pointers. This can make it easier to map between actions from a
> client point of view with resources at the KDC, even though no details have
> been introduced yet.
>
> 2) Separately moving each Section 4.2-4.10 right after the corresponding
> handler section, now numbered 4.1.x.y. After that, a better structuring can
> also be achieved, so that:
>
> - Section 4.1 is renamed "Overview of the Interface at the KDC".
> - The following sections lose one numbering level, e.g. current 4.1.1
> "ace-group" becomes 4.2 "ace-group".
> - Each Section 4.x can be about a KDC resource. This in turn includes
> 4.x.y with a handler description for resource x, followed by 4.x.y.z with
> the example for handler y or resource x (taken from current Sections
> 4.2-4.10).
>
> That is:
>
> 4. Keying Material Provisioning and Group Membership Management
>
> 4.1 Overview of the Interface at the KDC
>
> 4.2 ace-group
> 4.2.1 FETCH handler
> 4.2.1.1 Example <Content from current Section 4.2>
>
> 4.3 ace-group/GROUPNAME
> 4.3.1 POST handler
> 4.3.1.1 Example <Content from current Section 4.3>
> 4.3.2 GET handler
> 4.3.1.1 Example <currently missing>
>
> ...
>
>
> How does it look?
>
>
> [1] https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>
> [1reply]
> https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>
> <==
>

[CS: I think this would make things a lot more clear, yes.]

>
> Also,  reading the draft, it was first not clear how the rekeying was
> supported, whether it was a push/poll based solution, i.e., whether the KDC
> pushes new keys or the group participants query for the new key
> information.  Both options are supported, but it would be nice to have one
> clear section on this with a recommendation (Sections 4.4 and 4.5 look like
> the main sections for this, but there are several instances throughout the
> text rekeying is mentioned.)
>
>
> ==>MT
> I think most of the useful content is in the bullet list in Section 4.4.
> Instead, Section 4.5 is about renewing "individual keying material" (e.g.
> an OSCORE Sender ID), and is not related to the group rekeying.
>
> Here's a possible way forward. We can introduce a new section specific on
> group rekeying, with the alternatives from Section 4.4. Then, this section
> can be pointed by (at least) Sections 4.5, 5 and 9.1.
>
> As to what can be recommended, I started to think of something like the
> following:
>
> - The KDC should make /ace-group/GROUPNAME observable, hence supporting a
> distribution approach based on notifications.
>
> - If the joining node does not plan to observe /ace-group/GROUPNAME , the
> joining node MUST specify 'control_uri' in the joining request.
>
> - The KDC must support at least one push-based approach, minimally a
> point-to-point one. More efficient alternatives, e.g. based on multicast,
> remain possible.
>
> - If the Group Manager rekeys the group members point-to-point, the Group
> Manager sends the rekeying message to a certain group member either as a
> notification (if the group member is registered as an observer of
> /ace-group/GROUPNAME) or as a request to the resource of the group member
> at 'control_uri' (if the group member is not registered as an observer).
>
>    If neither of the two is possible (which means the group member is not
> complying with the above), the group member would miss a rekeying. Later
> on, after having failed to successfully exchange secure messages with other
> peers in the group, the group member will have to align itself in a pull
> fashion, by sending a GET request to ace-group/GROUPNAME or
> ace-group/GROUPNAME/nodes/NODENAME.
>
>
> What do you think?
> <==
>
[CS: I think combined with what you shared after the previous interim
meeting, it's getting a lot more clear how rekeying is supported, and
signaled to the group participants.]

>
> Finally, I've read the draft linearly and revised my comments if something
> I questioned was answered later; however, I've kept the comment to show
> where someone can be puzzled, and a forward pointer to the correct section
> may be appropriate. My comments are within [CS: ]. I hope you find them
> useful.
>
>
> ==>MT
> Thanks! Please, see also my replies in line.
> <==
>
>
> *Detailed comments:*
>
>
> ACE Working Group                                           F. Palombini
> Internet-Draft                                               Ericsson AB
> Intended status: Standards Track                               M. Tiloca
> Expires: 13 January 2022                                         RISE AB
>                                                             12 July 2021
>
>
>            Key Provisioning for Group Communication using ACE
>                     draft-ietf-ace-key-groupcomm-13
>
>
> [SNIP]
>
>
> 1.1.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
>
>    Readers are expected to be familiar with the terms and concepts
>    described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru
>    ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS)
>    and Resource Server (RS).
>
>    This document uses names or identifiers for groups and nodes.  Their
>    different meanings are summarized here:
>
>    *  "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.
>
> [CS: This has confused me earlier with the distinction of security and
> application
> group not being clear at the time. Would it be possible to emphasise this
> is a Security Group
> Name?]
>
>
> ==>MT
> Even better, we can add an earlier definition of "Group", clarifying that
> it is a security group. Something like:
>
> "Group: a set of nodes that share group keying material and security
> parameters used to protect their communications. That is, the term refers
> to a "security group". This is not to be confused with an "application
> group", which has relevance at the application level and whose members
> share a common pool of resources or content."
>
> It shouldn't be necessary to explicitly point to the definition of
> "application group" and "security group" given in
> draft-ietf-core-groupcomm-bis.
> <==
>
[CS: Excellent]


>
> 2.  Overview
>
>    The full procedure can be separated in two phases: the first one
>    follows the ACE framework, between Client, AS and KDC; the second one
>    is the key distribution between Client and KDC.  After the two phases
>    are completed, the Client is able to participate in the group
>    communication, via a Dispatcher entity.
>
>
>        +------------+                  +-----------+
>        |     AS     |                  |    KDC    |
>        |            |        .-------->|           |
>        +------------+       /          +-----------+
>              ^             /
>              |            /
>              v           /                           +-----------+
>        +------------+   /      +------------+        |+-----------+
>        |   Client   |<-'       | Dispatcher |        ||+-----------+
>        |            |<-------->|            |<------->||   Group   |
>        +------------+          +------------+         +|  members  |
>                                                        +-----------+
>
>                   Figure 1: Key Distribution Participants
>
>    The following participants (see Figure 1) take part in the
>    authorization and key distribution.
>
>    *  Client (C): node that wants to join the group communication.  It
>       can request write and/or read rights.
>
>    *  Authorization Server (AS): same as AS in the ACE Framework; it
>       enforces access policies, and knows if a node is allowed to join a
>       given group with write and/or read rights.
>
>    *  Key Distribution Center (KDC): maintains the keying material to
>       protect group communications, and provides it to Clients
>       authorized to join a given group.  During the first part of the
>       exchange (Section 3), it takes the role of the RS in the ACE
>       Framework.  During the second part (Section 4), which is not based
>       on the ACE Framework, it distributes the keying material.  In
>       addition, it provides the latest keying material to group members
>       when requested or, if required by the application, when membership
>       changes.
>
> [CS: It is not clear to me whether the KDC is programmed to rekey when
> membership
> changes or that needs to be invoked as a request from one of the group
> communication
> participants (which may have, say, a coordinator role). (Again, this is
> clarified later,
> but each time I saw it, it triggered the same question.)]
>
>
> ==>MT
> This will be clarified in a dedicated section about group rekeying (see
> the comments at the beginning of this reply).
>
> In short, a rekeying is started only by the KDC, due to different possible
> reasons, and can be done through different distribution approaches. There
> is no such thing like a "request for rekeying the group".
> <==
>
[CS: +1]

>
>
>
>
> Palombini & Tiloca       Expires 13 January 2022                [Page 5]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    *  Dispatcher: entity through which the Clients communicate with the
>       group and which distributes messages to the group members.
>       Examples of dispatchers are: the Broker node in a pub-sub setting;
>       a relayer node for group communication that delivers group
>       messages as multiple unicast messages to all group members; an
>       implicit entity as in a multicast communication setting, where
>       messages are transmitted to a multicast IP address and delivered
>       on the transport channel.
>
> [CS:Is a Dispatcher always needed? Clients initiating unicast messages to
> other
> group members directly p2p?]
>
>
> ==>MT
> That's a good point. We can clarify that the Dispatcher enforces the
> distribution of a message intended to multiple recipients. A
> single-recipient message (even though intended to another member of the
> security/application group) can be reached by alternative, more direct
> means.
> <==
>
[CS: +1]

>
>
> 3.  Authorization to Join a Group
>
>   [SNIP]
>
> 3.1.  Authorization Request
>
>    The Authorization Request sent from the Client to the AS is defined
>    in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
>    following parameters, which, if included, MUST have the corresponding
>    values:
>
>    *  'scope', containing the identifier of the specific groups, or
>       topics in the case of pub-sub, that the Client wishes to access,
>       and optionally the roles that the Client wishes to take.
>
> [CS: I think we have to include that a pub-sub model may also group nodes
> based on something other than topics, even though we've written the pub-sub
> profile based on topic(or topic filter)-based group identifiers. Maybe
> this is
> better given just as an example?]
>
>
> ==>MT
> How about simply the following?
>
> "'scope', containing the identifier of the specific groups, e.g. of topics
> in the case of pub-sub, that ..."
> <==
>
[CS: Yes, that's great.]

>
>
>
> Palombini & Tiloca       Expires 13 January 2022                [Page 8]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>       By default, each entry is encoded as specified by
>       [I-D.ietf-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 Figure 4.
>
>       Otherwise, each scope entry can be defined as a CBOR array, which
>       contains:
>
> [CS: Two options. One recommended? (Though I see that this is better
> clarified
> below when explaining extended scope format and how KDC may support
> multiple...
> Maybe a forward reference?)]
>
>
> ==>MT
> I would recommend the option using AIF as more compact, but it really
> depends on how important/necessary it is for the application to have roles
> expressed in a compact way. I can see that the pub-sub profile uses text
> strings for those.
>
> Maybe it's just fine to do something like the following:
>
> - Expand the paragraph above to mention that the default option based on
> AIF allows for more compact scopes (since roles are expressed in a more
> compact way), and thus is preferable for application profiles that aim to
> achieve compact scopes, especially if they define multiple possible roles
> and their coexistence for a same node.
>
> - Point to Section 6 as to the extended format for semantics
> disambiguation. Note that this extension applies to a scope encoded as a
> byte string (although beyond the scopes defined in this document and its
> profiles), which is the case for both the alternatives in Figure 4 and
> Figure 5, since the actual 'scope' claim is encoded as a byte string in
> either case. This is also evident from the examples in Figure 28 and Figure
> 29, respectively.
> <==
>
[CS: I think what you suggest would read fine.]


>
>
>       -  As first element, the identifier of the specific group or
>          topic, encoded as a tstr.
>
>       -  Optionally, as second element, the role (or CBOR array of
>          roles) that the Client wishes to take in the group.  This
>          element is optional since roles may have been pre-assigned to
>          the Client, as associated to its verifiable identity
>          credentials.  Alternatively, the application may have defined a
>          single, well-known role for the target resource(s) and
>          audience(s).
>
> [CS: What happens if a Client uses the option to select a role but
> mismatches what
> is pre-assigned. I expect it's overwritten with what's pre-programmed at
> the AS?
> Is there an error message for the mismatch? e.g., "Request inconsistent
> with the current roles"]
>
>
> ==>MT
> I think you mean that: a role A was configured as legitimate for the
> Client on the AS; the Client asks for a token that grants role B.
>
> In this case, the Client is simply not supposed to be authorized to take
> role B. I would expect the AS to return an error response with code
> "invalid_scope", i.e. "The requested scope is invalid, unknown, malformed,
> or exceeds the scope granted by the resource owner" (see Section 5.2 of RFC
> 6749).
>
> Overall, this does not deviate from what defined in the ACE framework, in
> its Sections 5.8.1-5.8.3. The Section 3.1 of this document with the text
> quoted above is pointing to Section 5.8.1 of the ACE framework.
> <==
> [CS: Actually my comment was more for the text: " Optionally, as second
> element, the role (or CBOR array of roles) that the Client wishes to take
> in the group." as if the client can wish for a role even if it is
> pre-assigned, and thought the return of an error in this case should be
> explained in the text.]
>
>
>       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).
>
>       An example of CDDL definition [RFC8610] of scope using the format
>       above, with group name and role identifiers encoded as text
>       strings is given in Figure 5.
>
> [CS: is->are]
>
>
> ==>MT
> Isn't the subject "example" ? It can be anyway rephrased as "Figure 5
> provides an example of ..."
> <==
>
[CS: Ah, yes. I took it as "group name and role identifiers". Thanks for
rephrasing.]

>
>
> 3.3.  Token Post
>
>                     [Snip]
>
>    The joining node MAY ask for this information from the KDC in the
>    same message it uses to POST the token to the RS.  In such a case,
>    the message MUST have Content-Format set to application/ace+cbor
>    defined in Section 8.16 of [I-D.ietf-ace-oauth-authz].  The message
>    payload MUST be formatted as a CBOR map, which MUST include the
>    access token.  The CBOR map MAY additionally include the following
>    parameter, which, if included, MUST have the corresponding values:
>
>    *  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
>       value Null to require information about the signature algorithm,
>       signature algorithm parameters, signature key parameters and on
>       the exact encoding of public keys used in the group.
>
>    Alternatively, the joining node may retrieve this information by
>    other means.
> [CS: Reference to them?]
>
>
> ==>MT
> I can add a commented informative reference to
> draft-tiloca-core-oscore-discovery.
>
> That document is practically focused on the Group OSCORE case covered by
> ace-key-groupcomm-oscore (where it is in fact referred to), but the overall
> idea has general applicability to the discovering of security groups where
> different protocols are used. All in all, it's about discovering the links
> to join a security group, along with attributes describing how the group
> works.
>
> Beside that, "other means" can include pre-configuration or other early
> discovery/learning processes that a group member would go through before
> joining. I'm not sure what good, general references about that can be added.
> <==
> [CS: OK thanks, otherwise "other means" is too vague, and does not give
> any hints to what may be acceptable.]
>
>
>    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".
>
>    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 3.3.2, 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 Section 4).  Note that the payload
>    format of the response deviates from the one defined in the ACE
>    framework (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]), which
>    has no payload.
>
>    The KDC MUST store the 'kdcchallenge' value associated to the Client
>    at least until it receives a join request from it (see Section 4.3),
>    to be able to verify that the Client possesses its own private key.
>
> [CS: OK, just to clarify? the kdcchallenge is generated and returned in
> the Authorisation
> response, and the client uses it to prove ownership of public key on join
> request.
> It may be useful to specify more clearly when the challenge parameter is
> used.
> (This is clarified much later; I feel explaining the possible flows using
> the resources
> beforehand would be better, as I comment later as well.]
>
>
> ==>MT
> 'kdcchallenge' is included in the response to the Token posting (the
> Authorization Response is part of the earlier exchange with the AS).
>
> The paragraph above can explicitly mention the later Joining Request, and
> that N_S is used as part of a PoP input to compute the PoP evidence.
> <==
>
[CS: +1]

>
>
>    The same challenge MAY be reused several times by the Client, to
>    generate a new proof of possession, e.g., in case of update of the
>
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 12]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    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 Section 4.3.
>
>    If 'sign_info' is included in the request, the KDC MAY include the
>    'sign_info' parameter defined in Section 3.3.1, with the same
>    encoding.  Note that the field 'id' takes the value of the group name
>    for which the 'sign_info_entry' applies to.
>
> [CS: This MAY mean that even if the client has sign_info, the KDC
> may not return this information? What's the reason for this?]
>
>
> ==>MT
> A possible reason is that the group indicated in the token does not use
> signatures to ensure source authentication. The client doesn't know that
> and just uses 'sign_info' as usual in its request. In that case, the KDC
> has nothing to say about 'sign_info'. Also, it is up to the application
> profile and its associated secure group communication protocol to have
> already defined alternative means to achieve source authentication in the
> group. This will be clarified better.
>
> A case in point is in ace-key-groupcomm-oscore , when a group uses only
> the pairwise mode of Group OSCORE. In that "extreme" but possible case,
> communication among group members occurs only one-to-one, and source
> communication is achieved by pairwise symmetric encryption keys. These are
> in turn derived from the group key material and the asymmetric keys of the
> two peers in question. Hence, there is no set of information to convey with
> 'sign_info', while other specific parameters defined in
> ace-key-groupcomm-oscore transport information required to perform those
> operations (e.g. algorithms and parameters).
> <==
>
[CS: With this explanation, it's more clear]

>
> [Snip]
>
>
> 3.3.1.  'sign_info' Parameter
>
> [CS: It is confusing to read about sign_info in two places (in
> the previous section and this section). Maybe defer
> all sign_info -related information to this section?]
>
>
> ==>MT
> I've seen it as a common practice to have a parameter defined in a
> dedicated section, here Section 3.3.1, so that its definition abstracting
> from any particular use can be referred by possible other documents or by
> IANA registrations. The intent here is to define a new parameter first of
> all for OAuth and ACE (see the later registrations in Sections 10.3 and
> 10.4).
>
> The previous Section 3.3.0 defines the specific use of 'sign_info' in this
> document, consistent with the general definition.
>
> Does it make sense?
> <==
>
[CS: OK]

>
>
> [SNIP]
>
>
> 3.3.2.  'kdcchallenge' Parameter
> [CS: The same comment as above, either explained here or above...
> Otherwise
> repetitious]
>
>
> ==>MT
> See the comment above about 'sign_info'.
> <==
>
[CS: OK. ]

>
> [SNIP]
>
> 4.  Keying Material Provisioning and Group Membership Management
>
> [SNIP]
>
>
> 4.1.  Interface at the KDC
>
>    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 (REQ7), 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 (Section 10.10) and can be used to describe
>    this interface.
>
>    *  /ace-group: this resource is invariant once established and
>       indicates that this specification is used.  If other applications
>       run on a KDC implementing this specification and use this same
>       resource, these applications will collide, and a mechanism will be
>       needed to differentiate the endpoints.  This resource supports the
>       FETCH method.
>
>    *  /ace-group/GROUPNAME: one sub-resource to /ace-group is
>       implemented for each group the KDC manages.
>
>       If the value of the GROUPNAME URI path and the group name in the
>       access token scope ('gname' in Section 3.2) do not match, the KDC
>       MUST implement a mechanism to map the GROUPNAME value in the URI
>       to the group name, in order to retrieve the right group (REQ1).
>
> [CS: While I understand the purpose of the statement above, it reads
> confusing.
> What if the mismatch is an error? E.g., the wrong token is provided
> for the call, and it should be not authorised, no?]
>
>
> ==>MT
> Well, if the token was found valid and stored, the KDC grants access to
> /ace-group/GROUPNAME , where GROUPNAME is the result of the (possibly
> identity-)mapping from gname.
>
> At the same time, the Client has to target the correct URI
> /ace-group/GROUPNAME . This does not require the Client to be aware of the
> exact gname -> GROUPNAME mapping performed by the KDC, but just to know the
> right URI (which is up to a separate discovering/learning task).
>
> If the mismatch is an actual mistake, meaning the Client uses a wrong URI
> for the group gname, the KDC will reply with an error response as per the
> ACE framework, in this case returning a 4.03 (Forbidden), see Section
> 5.10.2 of the ACE framework document.
>
> Do you think it is worth to include these clarifications?
> <==
>
[CS: OK, but it was not clear to me why KDC would want to keep an
alternative naming. I think without understanding that, it felt awkward to
read that KDC MUST implement the mapping.]

>
>
>       Each resource contains the symmetric group keying material for
>       that group.  These resources support the GET and POST methods.
>
>    *  /ace-group/GROUPNAME/pub-key: this resource is invariant once
>       established and contains the public keys of all group members.
>       This resource supports the GET and FETCH methods.
>
> [CS: All group members do not need to have public keys, e.g., For pub-sub,
> its only publishers]
>
>
> ==>MT
> Right, this is also related to another comment in the review from Göran.
> Some particular group members, e.g. depending on their role, may have no
> use of some resources. This means they will not send requests to those
> resources.
>
> On the other hand, the KDC provides such resources and an interface to
> access them for the group members for which it makes sense. It's probably
> up to an application profile to clarify that the interaction to a
> particular resource is not expected/relevant by particular group members.
> <==
>
[CS: OK]

>
>
>    *  /ace-group/GROUPNAME/policies: this resource is invariant once
>       established and contains the group policies.  This resource
>       supports the GET method.
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 17]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    *  /ace-group/GROUPNAME/num: this resource is invariant once
>       established and contains the version number for the symmetric
>       group keying material.  This sub-resource supports the GET method.
>
>    *  /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
>       group/GROUPNAME is implemented for each node in the group the KDC
>       manages.  These resources are identified by the node name (in this
>       example, the node name has value NODENAME).  Each resource
>       contains the group and individual keying material for that node.
>       These resources support the GET, PUT and DELETE methods.
>
>    *  /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to
>       /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node
>       in the group the KDC manages.  These resources are identified by
>       the node name (in this example, the node name has value NODENAME).
>       Each resource contains the individual public keying material for
>       that node.  These resources support the POST method.
> [CS: It also supports FETCH and GET, as detailed later?]
>
>
> ==>MT
> No, this resource supports only POST requests, for the node with name
> NODENAME to provide a new public key of its own.
>
> The resource related to public keys as supporting both GET and FETCH
> requests is rather /ace-group/GROUPNAME/pub-key . This is not individually
> associated to a group member, and it is accessible by any group member to
> retrieve the public keys now used in the group.
> <==
>
[CS: OK, makes sense - i missed the Uri difference]

>
>
>    It is REQUIRED of the application profiles of this specification to
>    define what operations (e.g., CoAP methods) are allowed on each
>    resource, for each role defined in Section 3.1 according to REQ2
>    (REQ8).
>
> [CS: Just to clarify again, this spec supports the above detailed
> operations,
> and it is REQUIRED that the profile, which uses this profile, further
> constrains the operations
> and who is allowed to access. And the access may not be based on only
> role, e.g.
> NODENAME may be able to PUT under nodes/NODENAME?]
>
>
> ==>MT
> The idea was that in every application profile the KDC supports all these
> operations. At the same time, I can imagine that an application profile
> really not needing some functionalities may just declare some of the KDC
> resources not relevant and not have them altogether. Also, the KDC of an
> application profile may add new resources to provide additional
> functionalities.
>
> Taking the perspective of a group member:
>
> - It is already intended that a node with name NODENAME can access only
> node-based sub-resources exactly under nodes/NODENAME. That is, it cannot
> access node-based sub-resources of another node. This is ensured by the
> consistency checks in the handlers of those resources (see, for instance,
> Section 4.1.6.1).
>
> - The quoted sentence and REQ8 require application profiles to further
> define/limit the access to the KDC resources, based on the role that a node
> trying to access that resource has in the group. In
> ace-key-groupcomm-oscore , this requirement is fulfilled in its Section 5.5
> by means of Figure 2.
> <==
>
[CS: OK]

>
>    [SNIP]
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 19]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    *  'scope', with value the specific resource at the KDC that the
>       Client is authorized to access, i.e., group or topic name, and
>       role(s).  This value is a CBOR byte string wrapping one scope
>       entry, as defined in Section 3.1.
>
>    *  'get_pub_keys', if the Client wishes to receive the public keys of
>       the other nodes in the group from the KDC.  This parameter may be
>       present if the KDC stores the public keys of the nodes in the
>       group and distributes them to the Client; it is useless to have
>       here if the set of public keys of the members of the group is
>       known in another way, e.g., it was provided by the AS.  Note that
>       including this parameter may result in a large message size for
>       the following response, which can be inconvenient for resource-
>       constrained devices.
>
>       The parameter's value is either the CBOR simple value Null, or a
>       non-empty CBOR array containing the following three elements.
>
>       -  The first element, namely 'inclusion_flag', encodes the CBOR
>          simple value True.
>
> [CS: Maybe explained what this flag signifies, as I see it's true by
> default for this handler, and may not be for other handlers (It's explained
> much later)]
>
>
> ==>MT
> Sure, will do. For example, some explanation can be moved up from the
> later paragraph "Also note that the array of node identifiers ..."
> <==
>
[CS: +1]

> [SNIP]
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 20]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>    [SNIP]
>
>
>
>    *  'control_uri', with value a full URI, encoded as a CBOR text
>       string.  If 'control_uri' 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 Section 4.4), or to inform the Client of its
>       removal from the group Section 5.
>
> [CS: So the above are KDC initiated? I think it needs to be clarified what
> mechanisms are expected to be initiated by KDC. If this uri is not
> present,
> how does the KDC rekey?]
>
>
> ==>MT
> See the proposal in one of the comments at the beginning of the review.
> Some key points are restated here:
>
> - Yes, the rekeying is initiated by the KDC (due to possibly different
> reasons) and it's not something that can be requested. There will be a new
> dedicated section on the possible approaches for the actual distribution.
>
> - An alternative to sending requests to the member's resource at
> 'control_uri' is to rely on observe notifications. A group member not
> wishing to observe must provide 'control_uri' in the Joining Request.
> <==
>
[CS: OK - this is fine as proposed to be described.]

>
> [SNIP]
>
>    If an eligible public key for the Client is neither present in the
>    'client_cred' field nor already stored, it is RECOMMENDED that the
>    handler stops the processing and responds with a 4.00 (Bad Request)
>    error message.  Applications profiles MAY define alternatives (OPT6).
>
>    If all the verifications above succeed, the handler performs the
>    following actions.
>
>    *  The handler adds the Client to the list of current members of the
>       group.
>
>    *  The handler assigns a name identifier NODENAME to the Client, and
>       creates a sub-resource to /ace-group/GROUPNAME/ at the KDC (e.g.,
>       "/ace-group/GROUPNAME/nodes/NODENAME").
>
>    *  The handler associates the node identifier NODENAME to the access
>       token and the secure session for the Client.
>
>    *  If the KDC manages the group members' public keys:
>
>       -  The handler associates the retrieved Client's public key to the
>          node identifier NODENAME and to the access token.
>
> [CS: shouldn't this be better  - (nodename, groupname, accesstoken, public
> key),
> or my assumption is invalid, one public key per client, not per group?]
>
>
> ==>MT
> Yes, you're right, and as you say, a public key is indeed possibly used by
> the same client in multiple groups, as per the previous comment. So, the
> same access token that possibly grants access to multiple groups might end
> up being associated to the different involved public keys of the node.
>
> The missing link to groupname will be made explicit. That was the intent,
> though perhaps carried out too concisely in the immediately following
> paragraph here below, where the public key used by the client in the group
> is added to the overall set of public keys in the group.
> <==
>
[CS: OK]

>
>
>
>
> [SNIP]
>
>
>    *  'group_policies', with value a CBOR map, whose entries specify how
>       the group handles specific management aspects.  These include, for
>       instance, approaches to achieve synchronization of sequence
>       numbers among group members.  The elements of this field are
>       registered in the "ACE Groupcomm Policy" Registry.  This
>       specification defines the three elements "Sequence Number
>       Synchronization Method", "Key Update Check Interval" and
>       "Expiration Delta", which are summarized in Figure 9.  Application
>       profiles that build on this document MUST specify the exact
>       content format and default value of included map entries (REQ17).
>
> [CS: So these MUST be specified, but I am still unclear whether Key updates
> are push/poll based, e.g., there are places where it reads like it is KDC
> initiated.
> So, key update check interval is 0, for example, if it's always
> push-based?]
>
>
> ==>MT
> The inclusion of this parameter is optional in the Joining Response, but
> profiles must specify details about its single information elements, for
> the case when the parameter is included.
>
> On the group rekeying in general, please see earlier replies to comments
> in this review.
>
> About "Key Update Check Interval", that's related to a poll-based action
> for group members to perform, but it does not trigger a rekeying. By
> polling the KDC at most every  Key Update Check Interval seconds, a group
> member can regularly check whether it has the current group key material or
> it has rather missed an earlier group rekeying.
>
> Note that the actual check is not necessarily a GET to
> /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME , or at least
> not right away. Instead, it can be a GET to /ace-group/num , followed by
> querying one of the resources above only in case the response specifies a
> key material version different than the version of the key material owned
> by the group member.
> <==
> [CS: OK - I think this will be a lot more clear with the new explanations
> on rekeying.]
>
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 27]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>   +--------------+-------+----------|---------------------|------------+
>   |      Name    | CBOR  |   CBOR   |    Description      | Reference  |
>   |              | label |   type   |                     |            |
>   |--------------+-------+----------|---------------------|------------|
>   | Sequence     | TBD1  | tstr/int | Method for a re-    | [[this     |
>   | Number       |       |          | cipient node to     | document]] |
>   | Synchroniza- |       |          | synchronize with    |            |
>   | tion Method  |       |          | sequence numbers    |            |
>   |              |       |          | of a sender node.   |            |
>   |              |       |          | Its value is taken  |            |
>   |              |       |          | from the 'Value'    |            |
>   |              |       |          | column of the       |            |
>   |              |       |          | Sequence Number     |            |
>   |              |       |          | Synchronization     |            |
>   |              |       |          | Method registry     |            |
>   |              |       |          |                     |            |
>   | Key Update   | TBD2  |   int    | Polling interval    | [[this     |
>   | Check        |       |          | in seconds, to      | document]] |
>   | Interval     |       |          | check for new       |            |
>   |              |       |          | keying material at  |            |
>   |              |       |          | the KDC             |            |
>   |              |       |          |                     |            |
>   | Expiration   | TBD3  |   uint   | Number of seconds   | [[this     |
>   | Delta        |       |          | from 'exp' until    | document]] |
>   |              |       |          | the specified UTC   |            |
>   |              |       |          | date/time after     |            |
>   |              |       |          | which group members |            |
>   |              |       |          | MUST stop using the |            |
>   |              |       |          | keying material to  |            |
>   |              |       |          | verify incoming     |            |
>   |              |       |          | messages.           |            |
>   +--------------+-------+----------|---------------------|------------+
>
>                      Figure 9: ACE Groupcomm Policies
>
>    *  'mgt_key_material', encoded as a CBOR byte string and containing
>       the administrative keying material to participate in the group
>       rekeying performed by the KDC.  The application profile MUST
>       define if this field is used, and if used then MUST specify the
>       exact format and content which depend on the specific rekeying
>       scheme used in the group.  If the usage of 'mgt_key_material' is
>       indicated and its format defined for a specific key management
>       scheme, that format must explicitly indicate the key management
>       scheme itself.  If a new rekeying scheme is defined to be used for
>       an existing 'mgt_key_material' in an existing profile, then that
>       profile will have to be updated accordingly, especially with
>       respect to the usage of 'mgt_key_material' related format and
>       content (REQ22).
>
> [CS: so, there is an implicit admin group, which can receive this
> information.
> I assume this is pre-assigned, or is it in the token scope?]
>
>
> ==>MT
> This kind of admin group would work according to the specifically used
> group key management scheme. Below I reuse some responses to two related
> points from Göran's review [1][1reply]:
>
> * For example, if a hierarchy-based scheme is used, the parameter
> specifies the administrative keys in the key tree from the leaf node
> associated to the group member all the way up along the path from that leaf
> node to the root (which is the administrative group key).
>
> * When joining the group, a node also needs to know the exactly used group
> rekeying scheme. The easiest way I see to signal it is defining one more
> integer-valued ACE Groupcomm Policy (see Figure 9 in Section 4.1.2.1) to be
> specified in the optional 'group_policies' parameter of the Joining
> Response.
>
>    Its value would indicate the exact rekeying scheme (and we would need a
> new IANA registry). If the KDC does not say anything about that, the
> joining node assumes that a group rekeying is performed point-to-point,
> thus relying on the pairwise communication channel it has with the KDC.
>
>
> [1] https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>
> [1reply]
> https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>
>
> Furthermore, the token scope does not need to cover this. The "admin
> group" associated to the administrative key material is exclusively tight
> to the main security group to be rekeyed by using such key material. Also,
> the KDC as such is the entity authorized and capable to rekey the main
> security group, while there is no additional authorization needed to allow
> group members to participate in a rekeying instance.
> <==
> [CS: This sounds all fine.]
>
>
>
> 4.1.3.1.  FETCH Handler
>
>    The FETCH handler receives identifiers of group members for the group
>    identified by GROUPNAME and returns the public keys of such group
>    members.
>
>    The handler expects a request with payload formatted as a CBOR map,
>    that MUST contain the following fields:
>
>    *  'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with
>       the following modification:
>
>       -  The element 'inclusion_flag' encodes the CBOR simple value True
>          if the third element 'id_filter' specifies an empty CBOR array,
>          or if the Client wishes to receive the public keys of the nodes
>          having their node identifier specified in 'id_filter'.
>          Instead, this element encodes the CBOR simple value False if
>          the Client wishes to receive the public keys of the nodes not
>          having the node identifiers specified in the third element
>          'id_filter'.
>
> [CS: so, to clarify, id_filter becomes an exclusion list if inclusion_flag
> is false?
> if it is true, and id_filter is not empty, it returns the pub_keys in the
> list, i.e.,
> inclusion list? (Reading further, this seems correct. It may be explained
> earlier when
> inclusion_flag is first introduced]
>
>
> ==>MT
> Yes, that's a correct summary. We will fully define the meaning of
> 'inclusion_flag' when introducing it in Section 4.1.2.1.
> <==
>
[CS: +1]

>
>
>       -  The array 'role_filter' may be empty, if the Client does not
>          wish to filter the requested public keys based on the roles of
>          the group members.
>
>       -  The array 'id_filter' contains zero or more node identifiers of
>          group members, for the group identified by GROUPNAME.  The
>          Client indicates that it wishes to receive the public keys of
>          the nodes having or not having these node identifiers, in case
>          the 'inclusion_flag' parameter encodes the CBOR simple value
>          True or False, respectively.  The array may be empty, if the
>          Client does not wish to filter the requested public keys based
>          on the node identifiers of the group members.
>
>    Note that, in case both the 'role_filter' array and the 'id_filter'
>    array are not empty:
>
>    *  If the 'inclusion_flag' encodes the CBOR simple value True, the
>       handler returns the public keys of group members whose roles match
>       with 'role_filter' and/or having their node identifier specified
>       in 'id_filter'.
>
>    *  If the 'inclusion_flag' encodes the CBOR simple value False, the
>       handler returns the public keys of group members whose roles match
>       with 'role_filter' and, at the same time, not having their node
>       identifier specified in 'id_filter'.
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 30]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
>    and 'id_filter' MUST NOT be both empty.
>
> [CS: Why? Can't I ask to get all the public keys of nodes in this group,
> which has a public key? (I see that this is a GET request, on reading
> further,
> a forward pointer here?)]
>
>
> ==>MT
> Yes, we'll include a forward pointer to the GET handler for retrieving all
> public keys.
> <==
>
[CS: Thanks]

>
>
>   [SNIP]
>
>    The handler MAY enforce one of the following policies, in order to
>    handle possible node identifiers that are included in the 'id_filter'
>    element of the 'get_pub_keys' parameter of the request but are not
>    associated to any current group member.  Such a policy MUST be
>    specified by the application profile (REQ16).
>
>    *  The KDC silently ignores those node identifiers.
>
>    *  The KDC retains public keys of group members for a given amount of
>       time after their leaving, before discarding them.  As long as such
>       public keys are retained, the KDC provides them to a requesting
>       Client.
>
> [CS: I think this is a wider policy e.g., how long does the KDC retain
> any information about the historical group members?]
>
>
> ==>MT
> If I understand correctly, you'd like a policy of this kind to explicitly
> define also how the retention time is determined, possibly on a per-node
> basis. Correct?
> <==
>
[CS: Yes, I suggest that KDC says what that "given amount of time" is - it
could be uniform across group members, or per-node basis.]

>
>
> 4.1.5.  ace-group/GROUPNAME/num
>
>    This resource implements a GET handler.
>
> 4.1.5.1.  GET Handler
>
>    The handler expects a GET request.
>
>  [SNIP]
> [CS: In general, in the SNIPPED text above, there is much repetition
> across different sections, in terms of format expected, group membership
> access control etc. Could that be said only once to apply to all
> resources, or
> all operations within a resource?]
>
>
> ==>MT
> Hopefully so :-)
>
> I'll try to identify a clear "boilerplate" with actions common to all
> handlers to include once and for all.
> <==
>
[CS: That would be great]

>
>
> [SNIP]
>
> 4.1.6.  ace-group/GROUPNAME/nodes/NODENAME
>
>    This resource implements GET, PUT and DELETE handlers.
>
> 4.1.6.1.  PUT Handler
> 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.  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 (OPT8).
>
> [CS: I am a bit puzzled that something that potentially is rekeying
> the whole group is done under NODENAME resource.
> On the other hand, POSTing the GROUPNAME adds a node to the group rather
> than rekeying
> the group. I would expect POSTing to ace-group/GROUPNAME/nodes would add
> a node instead.
> ]
>
>
> ==>MT
> This may require more explicit clarifications in the draft.
>
> This particular PUT request is sent by the group member with name
> NODENAME, say node X, to ask for new individual keying material, as
> abstractly put in this draft. A concrete example is in
> ace-key-groucomm-oscore , where the group member asks for a new OSCORE
> Sender ID.
>
> Following this PUT request, the KDC can decide to go for one of the
> following options. What influences the KDC decision is really
> application/context specific, and an application profile may give more
> details as appropriate.
>
> * Only assigning new individual keying material to the group member X,
> including it in the response to the PUT request.
>
> * Rekeying the whole group. For the sake of efficiency, the KDC can
> provide the new group key material to the group member X in the response to
> the PUT request.
>
> * Doing both things above, i.e. first providing the group member X with
> new individual keying material in the response to the PUT request, and then
> also perform a full group rekeying.
>
>
> So, yes, this PUT request can potentially trigger a whole group rekeying
> as a side effect, depending on what the KDC decides exactly to do. However,
> it is not what the group member X is asking for, which is not its
> prerogative as mentioned in previous comments.
>
> On the final part of the comment:
>
> * POSTing to ace-group/GROUPNAME does add a node to the group but does not
> necessarily result in rekeying the group. That depends on the key
> management policies adopted by the KDC for that group. A group rekeying
> would especially happen if the application requires to enforce backward
> security.
>
> * Early design discussions resulted in ace-group/GROUPNAME/nodes as just
> the "root" resource (with no handlers) for the node-based sub-resources
> ace-group/GROUPNAME/nodes/NODENAME, each of which is added only once when
> the corresponding node is added as group member.
> <==
>
[CS: OK, yes putting clarifications in the draft would be helpful on these
choices.]

>
>
>     [SNIP]
>
>    *  Can act as a publisher in a pub-sub scenario, and update the
>       keying material by publishing on a specific topic on a broker,
>       which all the members of the group are subscribed to.
>
> [CS: This is not a good scenario for pub-sub, as the broker should not
> know the
> keys. The whole idea of the pub-sub profile is the protect the content
> of the messages from the broker. That means these keying materials should
> be
> encrypted, and hence, then, the distribution of that keying material ...
> becomes a recursive problem.]
>
>
> ==>MT
> Before dismissing this option, let's think a bit more about it --- This
> can possibly become a separate thread.
>
> This way of rekeying the main security group is not referring exactly to
> the pub-sub profile of ACE to do that. It is referring only to a pub-sub
> scenario where, for the sake of rekeying the main security group, the KDC
> is a publisher and all the group members are subscribers of a "rekeying
> topic".
>

[CS: OK, it want's clear to me what you meant by "a broker" in that
paragraph. I understood it as the Broker for pub-sub communication, which
the Clients engage in the first place. If the KDC is going to be a broker
(or a published as you explain below) use pub-sub communication to send out
keys, I don't have a problem with this. ]


>
> It is good that the broker does not see the exchanged messages. These
> would be protected by the KDC at the application level, using additional
> administrative key material shared between the KDC and the members of the
> main security group. Such key material can be provided in the
> 'mgt_key_material' parameter of a Joining Response, and depends on the
> exact group key management scheme used.
>
> Since the KDC is acting as publisher, you would need to involve also the
> KDC's public key. The best option is probably to provide it in the Joining
> Response, using the dedicated parameter 'kdc_cred' recently introduced in
> ace-key-groupcomm-oscore (see its Section 6.4), as required for other
> reasons in the Group OSCORE case.
>
>
> Actually, I believe the pub-sub profile of ACE may assist for this case
> too. The KDC has to obtain from the AS a token and upload it to the broker
> as a proof of authorization for publishing in the "rekeying topic" to rekey
> a particular security group. Again, the administrative key material to
> protect the rekeying messages is generated by the KDC itself, which
> provides it to the members of the main security group in the respective
> Joining Responses, when they join that security group.
>
> This is a just simple example with one single "rekeying topic" to deliver
> a rekeying message to all the group members of the main security group. If
> a rekeying message has to target only a subset of the group members, you
> would need a respective sub-topic. For instance, the key hierarchy used by
> the group rekeying scheme can be mapped to a hierarchy of rekeying topics,
> all used to rekey the main security group.
>
> Does it make sense?
> <==
>
[CS: Yes, this may work. But then the "administrative key" for rekeying
topic, isn't that rolled over? And then how is that "re-keyed"?]

>
>
> 5.  Removal of a Node from the Group
>
>    [SNIP]
>
>
>    Furthermore, in case of forced eviction, the KDC removes the public
>    key of the evicted node if the KDC keep tracks of that, and possibly
>    removes the evicted node from the list of observers of the resource
>    at ace-group/GROUPNAME (if observable).
>
> [CS: Why only "possibly"?]
>
>
> ==>MT
> It was intended to mean "in case the evicted node was an observer at all".
> We'll make it explicit; if the evicted node is an observer, it has to be
> removed from the list of observers.
> <==
>
[CS: OK]

>
>
>  [SNIP]
>
>
> 6.  Extended Scope Format
>
>    [SNIP]
>
>    The value of the 'scope' claim following the extended format is
>    composed as follows.  Given the original scope using a semantics SEM
>    and encoded as a CBOR byte string, the corresponding extended scope
>    is encoded as a tagged CBOR byte string, wrapping a CBOR sequence
>    [RFC8742] of two elements.  In particular:
>
>    *  The first element of the sequence is a CBOR integer, and
>       identifies the semantics SEM used for this scope.  The value of
>       this element has to be taken from the "Value" column of the "ACE
>       Scope Semantics" registry defined in Section 10.12 of this
>       specification.
>
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 52]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>       When defining a new semantics for a binary scope, it is up to the
>       applications and application profiles to define and register the
>       corresponding integer identifier (REQ24).
>
>    *  The second element of the sequence is the original scope using the
>       semantics SEM, encoded as a CBOR byte string.
>
>    Finally, the CBOR byte string wrapping the CBOR sequence is tagged,
>    and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format",
>    defined in Section 10.11 of this specification.
>
>    The resulting tagged CBOR byte string is used as value of the 'scope'
>    claim of the access token.
>
>    The usage of the extended scope format is not limited to application
>    profiles of this specification or to applications based on group
>    communication.  Rather, it is generally applicable to any application
>    and application profile where access control information in the
>    access token is expressed as a binary encoded scope.
>
> [CS: Then should it be defined here in this profile or somewhere else?]
>
>
> ==>MT
> This document is defining the general extensibility method, as agreed to
> have it exactly in this document. Other specifications that want to take
> advantage of the extended format have to define some specific details.
>
> For instance, Section 4.2 of ace-key-groupcomm-oscore defines a particular
> integer value to prepend to the CBOR sequence if the AS actually uses the
> extended scope format. This reflects the specific scope semantics defined
> in that application profile.
> <==
>
[CS: OK]

> 9.  Security Considerations
>
>   [SNIP]
>
>    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.  The KDC may rekey the
>    group after a minimum number of group members have joined or left
>    within a given time interval, or after maximum amount of time since
>    the last rekeying was completed, or yet during predictable network
>    inactivity periods.
>
>    However, this would result in the KDC not constantly preserving
>    backward and forward security.  Newly joining group members could be
>    able to access the keying material used before their joining, and
>    thus could access past group communications.  Also, until the KDC
>    performs a group rekeying, the newly leaving nodes would still be
>    able to access upcoming group communications that are protected with
>    the keying material that has not yet been updated.
>
> [CS: I think the minimum number of group members should be just 1 if we
> are talking about secure group communication]
>
>
> ==>MT
> Yes, it's still about joining a group with group key material to share
> with next nodes to come. It will be said explicit.
>
> In particular, if the key material is revoked upon nodes' leaving, it has
> to be also when the number of members goes from 1 to 0. Then new group key
> material has to be provided to the next new member joining the group.
> <==
> [CS: OK]
>
>
>   [SNIP]
> 9.1.  Update of Keying Material
>
>    A group member can receive a message shortly after the group has been
>    rekeyed, and new keying material has been distributed by the KDC.  In
>    the following two cases, this may result in misaligned keying
>    material between the group members.
>
>    In the first case, the sender protects a message using the old keying
>    material.  However, the recipient receives the message after having
>    received the new keying material, hence not being able to correctly
>    process it.  A possible way to ameliorate this issue is to preserve
>    the old, recent, keying material for a maximum amount of time defined
>    by the application.  By doing so, the recipient can still try to
>    process the received message using the old retained keying material.
>    Note that a former (compromised) group member can take advantage of
>
>
>
> Palombini & Tiloca       Expires 13 January 2022               [Page 57]
>
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    this by sending messages protected with the old retained keying
>    material.  Therefore, a conservative application policy should not
>    admit the storage of old keying material.
>
> [CS: Could it be an option to resend the message with the new keying
> material? if the
> rekeying happened within a window]
>
>
> ==>MT
> That's most likely what happens once the sender has also obtained the
> latest group key material (either by actually receiving the rekeying
> messages, of by asking for it to the KDC if it realizes it has missed a
> rekeying). It can be added here.
> <==
>
[CS: OK]

>
>
>
> [SNIP]
>
>
> 10.  IANA Considerations
>
>    This document has the following actions for IANA.
>
> 10.1.  Media Type Registrations
>
>    [SNIP]
>
>
>
>
> Appendix B.  Extensibility for Future COSE Algorithms
>
> [CS: Why not just use this format instead of reformatting sign_info_entry
> In section 3.3.1]
>
>
> ==>MT
> Simply for the sake of readability. Considering that today's COSE
> algorithms have only one capability (and always Key Type), for the time
> being it is sufficient for an implementer to just refer to the simpler
> format in Section 3.3.1.
>
> In other words, it was good to define the more general format as
> future-ready, but it's not strictly necessary to be aware of it when
> implementing a KDC today. Hence the preference to have it in Appendix B
> rather than burdening Section 3.3.1.
> <==
> [CS: OK]
>
> [THE END]
>
>


> On Tue, Aug 24, 2021 at 5:52 PM Göran Selander <goran.selander=
> [e-mail]> wrote:
>
>> Hi,
>>
>> Here is a review of ace-key-groupcomm-13.
>>
>>
>> General
>> ===
>>
>> This draft provides a link between the ACE-OAuth authorization framework
>> (including its transport profiles) and specifications of communication
>> security in groups of constrained devices, e.g. the coap-groupcomm work
>> currently developed in CORE. The document is intended to support different
>> group communication schemes, but the details of those are defined in
>> separate “application profiles” such as draft-ietf-ace-key-groupcomm-oscore
>> (for Group OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This
>> draft instead defines a common interface to a KDC acting as RS in the
>> ACE-OAuth architecture, how to use this interface to perform various key
>> management operations, and requirements for such application profiles.
>>
>> As such, this draft is thus an “intermediary” specification, and its
>> usefulness will be determined by the application profiles which I've
>> glanced at but are not part of this review.
>>
>> While this approach seems reasonable from a structure point of view, I
>> have a question about abstracting the underlying communication in comment 1
>> below.
>>
>> The content of the draft is quite elaborate and with detailed examples
>> which is good but also leads to my comment number 2.
>>
>> Now for the main comments:
>>
>> 1. How does this scale to large groups?
>>
>> Depending on application it may not be necessary to update keys during
>> join of new members, and depending on the dynamics of the members rekeying
>> may not be a major issue. But if it is a large group and all group members
>> need to be updated at joining or leaving then this may require a lot of
>> communication for which the underlying group communication may be helpful.
>>
>> For example, in case of a new member joining then a new group key or the
>> new node's public key may be distributed using broadcast/multicast and
>> protected with some existing group key.
>>
>> In case of rekeying a group key after a node has been evicted, a similar
>> method could be used if it was possible to apply some key hierarchy scheme
>> like e.g. LKH, i.e. distributing new keys corresponding to a path from the
>> evicted node to the root in a key hierarchy.
>>
>> Two sub-questions:
>>
>> a. Is it possible to extend the interface to make use of the underlying
>> group communication?
>>
>> b. Is it possible to apply this interface with a key hierarchy scheme?
>>
>> These features are not necessarily in scope of this draft, but it would
>> be good to understand if a specification of these features would be able to
>> use the interface defined here, or if some generalization is required in
>> which case that change may be considered already now.
>>
>>
>> 2. How would a "minimal" profile look like?
>>
>> The target setting for ACE in general and this draft in particular is
>> constrained devices and networks. Some parts of the draft give example of
>> thinking about lightweight aspects, but other parts are not at all
>> minimalistic and includes a large number of features, however in many cases
>> optional.
>>
>> It would be interesting to have a “minimal” example, where care has been
>> taken in trying to define a group setting such that the resulting messages
>> are as few and as small as possible (for a certain security level). The
>> same comment applies to code size and state machine: There are a number of
>> options and “nice to have” features, which if all implemented could have a
>> measurable impact on the footprint.
>>
>> The use of the word "minimal" is not intended in an absolute sense but to
>> target as little as possible and still provide authorized group key
>> functionality. Perhaps such an exercise makes more sense in an application
>> profile, such as draft-ace-key-groupcomm-oscore. But this draft may be
>> provide a partial answer by indicating what handlers to include (sec. 4),
>> what groupcomm parameters (sec. 7), what error ids (sec 8), etc.
>>
>> (This comment actually applies also to the transport profiles, which this
>> draft does not need to take responsibility for.)
>>
>>
>>
>> More detailed comments
>> ===
>>
>>
>> I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST
>> Token” for the different message exchanges, respectively, quite confusing.
>> For a long time I thought the latter referred to the former. It is true
>> that the access token is carried with the method POST in the second
>> exchange, but I think that is irrelevant and would suggest to instead use
>> some other consistent terminology. For example, use  “POST /token” and
>> “POST /authz-info” to refer to the exchanges, respectively. Alternatively,
>> call the latter “Token provisioning” or something similar without reference
>> to the actual method by which the token is provisioned.
>>
>> This applies in particular to:
>>
>> Figure 2
>> “Token Post”
>>
>> Figure 3
>> “POST Token”
>>
>> “3.3. Token Post”
>>
>> 3.3.1.
>> “an OPTIONAL parameter of the Token Post
>>    response message “
>>
>> 3.3.2
>> “Token Post response”
>>
>> etc.
>>
>>
>> 4.1
>>
>> Section 4.1 specifies the handlers, 20 pages. This is followed by how the
>> handlers are used 4.2 - 4.10, roughly one page per subsection. When reading
>> I ended up having two copies of the draft side by side looking at the
>> handler and its corresponding use. I'm not sure this is a problem, but
>> reading the handlers is more motivating after having read about how they
>> are used. There is a summary in the bullet list in 4.0 but this is merely a
>> forward reference and didn't make me do the mapping from handler to action
>> in my head. Maybe just move content such that 4.2-4.10 comes before 4.1
>> (and then you can remove the bullet list in 4.0).
>>
>>
>> "It is REQUIRED of the application profiles of this specification to
>>    define what operations (e.g., CoAP methods) are allowed on each
>>    resource"
>>
>> It speaks of operations on each resource, but it does not say which
>> resources are mandatory to implement. Where is that written?
>>
>>
>>
>> 9.
>>
>> The security consideration speaks about different key update strategies.
>> I was looking for considerations when to not rekey in case of new member
>> joining a group. I would imagine in e.g. a building automation setting
>> where a new actuator device is added into a group it may not always be
>> necessary to renew the group key of existing actuators. This is in
>> particular assuming by the nature of security for actuations there are
>> already means in place to determine freshness etc. preventing misuse of an
>> old group key.
>>
>>
>>
>>
>> Nits
>> ===
>>
>>
>> 3.1
>>
>> s/Toid/“Toid”
>> s/Tperm/“Tperm”
>>
>>
>> 3.2
>>
>> If this parameter is not present, the granted scope is equal to the one
>> requested in Section 3.1}.
>>
>> - remove the “}”
>>
>>
>>
>> 3.3.  Token Post
>>
>> - - -
>>
>>    “The CBOR map MAY additionally include the following
>>    parameter, which, if included, MUST have the corresponding values:
>>
>>    *  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
>>       value Null to require information about the signature algorithm,
>>       signature algorithm parameters, signature key parameters and on
>>       the exact encoding of public keys used in the group.”
>>
>>
>> This seems to unnecessary duplicate information coming just after:
>>
>>
>> “3.3.1.  'sign_info' Parameter
>>
>>    The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
>>    response message defined in Section 5.10.1. of
>>    [I-D.ietf-ace-oauth-authz].  This parameter contains information and
>>    parameters about the signature algorithm and the public keys to be
>>    used between the Client and the RS.  Its exact content is application
>>    specific.
>>
>> - - -
>>
>>    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 [RFC8610] of the 'sign_info' parameter formatted as
>>    in the request is given below.
>>
>>       sign_info_req = nil”
>>
>>
>> 3.3.1
>>
>> I got the impression from the text above that ‘sign_info’ is the name of
>> the parameter, but it turns out that the actual parameter is either called
>> “sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’
>> encoding the CBOR simple value Null, which seems like a straightforward
>> assignment, there is actually no ‘sign_info’ parameter. This is a minor,
>> still slightly confusing.
>>
>>
>> 3.3.1
>>
>> "This format is consistent with every signature algorithm currently
>>    considered in [I-D.ietf-cose-rfc8152bis-algs], "
>>
>>
>> s/considered/defined
>>
>>
>>
>> 3.3.2
>>
>> "(see the 'client_cred_verify' parameter in
>>    Section 4)"
>>
>> Refer instead to 4.1.2.1
>>
>>
>>
>>
>> 4.1.3.1
>>
>> “in case both the 'role_filter' array and the 'id_filter'
>>    array are not empty”
>>
>>
>> s/not empty/non-empty
>>
>>
>> 4.1.3.1
>>
>>  "Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
>>    and 'id_filter' MUST NOT be both empty."
>>
>> replace with
>>
>>    "Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter'
>>    and 'id_filter' MUST NOT both be empty."
>>
>>
>>
>>
>>
>> 4.4
>> A  missing comma at the end of the following line:
>>
>> "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
>>
>>
>>
>> Göran
>>
>>
>>
>>
>> On 2021-07-12, 18:16, "Ace on behalf of [e-mail]" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>
>>     A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>     This draft is a work item of the Authentication and Authorization for
>> Constrained Environments WG of the IETF.
>>
>>             Title           : Key Provisioning for Group Communication
>> using ACE
>>             Authors         : Francesca Palombini
>>                               Marco Tiloca
>>         Filename        : draft-ietf-ace-key-groupcomm-13.txt
>>         Pages           : 78
>>         Date            : 2021-07-12
>>
>>     Abstract:
>>        This document defines message formats and procedures for requesting
>>        and distributing group keying material using the ACE framework, to
>>        protect communications between group members.
>>
>>     Discussion Venues
>>
>>        This note is to be removed before publishing as an RFC.
>>
>>        Source for this draft and an issue tracker can be found at
>>
>> https://protect2.fireeye.com/v1/url?k=08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5&q=1&e=fd87b927-3fdc-4d5a-ab71-6248ac68bf5d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5%26q%3D1%26e%3Dfd87b927-3fdc-4d5a-ab71-6248ac68bf5d%26u%3Dhttps%253A%252F%252Fgithub.com%252Face-wg%252Face-key-groupcomm&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937781729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mvHeT5tjyppaBePYDOGel52skuI%2BMatR%2B0sxMahBkFs%3D&reserved=0>
>> .
>>
>>
>>     The IETF datatracker status page for this draft is:
>>     https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937791678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zfmgemL%2FYrrCz23oBWFSCBntxg3ZQkXQ1WwmH9sbNoI%3D&reserved=0>
>>
>>     There is also an htmlized version available at:
>>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937791678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HChwFO1piTC5OtQMrg4ueZMGu1qn4I8eyaqqwjygdtI%3D&reserved=0>
>>
>>     A diff from the previous version is available at:
>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937801642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a5kp1sozCnKNvR1lGyBZbIX9MoMh%2BeCKZsJ9u3T0Uw0%3D&reserved=0>
>>
>>
>>     Internet-Drafts are also available by anonymous FTP at:
>>     ftp://ftp.ietf.org/internet-drafts/
>> <https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937801642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4JHoOf6eGP25%2Bq6CGTAJ2mua7QhQfkyfyyRSSlg60ZM%3D&reserved=0>
>>
>>
>>     _______________________________________________
>>     Ace mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/ace
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937811593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hzRM6nnCGIkQjThU2V312U2JV5t6xmdvfVtCSw2rff0%3D&reserved=0>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937811593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hzRM6nnCGIkQjThU2V312U2JV5t6xmdvfVtCSw2rff0%3D&reserved=0>
>>
>
> _______________________________________________
> Ace mailing [e-mail]://www.ietf.org/mailman/listinfo/ace
>
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Division: Digital System
> Department: Computer Science
> Unit: Cybersecurity
>
> RISE Research Institutes of Swedenhttps://www.ri.se
>
> Phone: [phone]
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
>
>