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

From: Marco Tiloca <[email-masked]>
Date: Wed, 1 Sep 2021 22:27:04 +0200

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/

<==

> 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?
<==

> 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
>
> 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
> [SNIP]
>
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
>    2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
>    3.  Authorization to Join a Group . . . . . . . . . . . . . . . .   8
>      3.1.  Authorization Request . . . . . . . . . . . . . . . . . .   8
>      3.2.  Authorization Response  . . . . . . . . . . . . . . . . .  10
>      3.3.  Token Post  . . . . . . . . . . . . . . . . . . . . . . .  12
>    4.  Keying Material Provisioning and Group Membership
>            Management  . . . . . . . . . . . . . . . . . . . . . . .  15
>      4.1.  Interface at the KDC  . . . . . . . . . . . . . . . . . .  17
>      4.2.  Retrieval of Group Names and URIs . . . . . . . . . . . .  39
>      4.3.  Joining Exchange  . . . . . . . . . . . . . . . . . . . .  40
>      4.4.  Retrieval of Updated Keying Material  . . . . . . . . . .  42
>      4.5.  Requesting a Change of Keying Material  . . . . . . . . .  44
>      4.6.  Retrieval of Public Keys and Roles for Group Members  . .  45
>      4.7.  Update of Public Key  . . . . . . . . . . . . . . . . . .  47
>      4.8.  Retrieval of Group Policies . . . . . . . . . . . . . . .  48
>      4.9.  Retrieval of Keying Material Version  . . . . . . . . . .  49
>      4.10. Group Leaving Request . . . . . . . . . . . . . . . . . .  50
>    5.  Removal of a Node from the Group  . . . . . . . . . . . . . .  50
>    6.  Extended Scope Format . . . . . . . . . . . . . . . . . . . .  52
>    7.  ACE Groupcomm Parameters  . . . . . . . . . . . . . . . . . .  54
>    8.  ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . .  55
>    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  56
>      9.1.  Update of Keying Material . . . . . . . . . . . . . . . .  57
>      9.2.  Block-Wise Considerations . . . . . . . . . . . . . . . .  58
>    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  58
>      10.1.  Media Type Registrations . . . . . . . . . . . . . . . .  58
>      10.2.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  59
>      10.3.  OAuth Parameters Registry  . . . . . . . . . . . . . . .  60
>      10.4.  OAuth Parameters CBOR Mappings Registry  . . . . . . . .  60
>      10.5.  ACE Groupcomm Parameters Registry  . . . . . . . . . . .  61
>      10.6.  ACE Groupcomm Key Registry . . . . . . . . . . . . . . .  61
>      10.7.  ACE Groupcomm Profile Registry . . . . . . . . . . . . .  62
>      10.8.  ACE Groupcomm Policy Registry  . . . . . . . . . . . . .  63
>      10.9.  Sequence Number Synchronization Method Registry  . . . .  63
>      10.10. Interface Description (if=) Link Target Attribute Values
>              Registry  . . . . . . . . . . . . . . . . . . . . . . .  64
>      10.11. CBOR Tags Registry . . . . . . . . . . . . . . . . . . .  64
>      10.12. ACE Scope Semantics  . . . . . . . . . . . . . . . . . .  65
>
>
>
> Palombini & Tiloca       Expires 13 January 2022        [Page 2]
> 
> Internet-Draft  Key Provisioning for Group Communication   July 2021
>
>
>      10.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . .  65
>      10.14. Expert Review Instructions . . . . . . . . . . . . . . .  66
>    11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  66
>      11.1.  Normative References . . . . . . . . . . . . . . . . . .  66
>      11.2.  Informative References . . . . . . . . . . . . . . . . .  69
>    Appendix A.  Requirements on Application Profiles . . . . . . . .  70
>    Appendix B.  Extensibility for Future COSE Algorithms . . . . . .  73
>      B.1.  Format of 'sign_info_entry' . . . . . . . . . . . . . . .  74
>    Appendix C.  Document Updates . . . . . . . . . . . . . . . . . .  74
>      C.1.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  74
>      C.2.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  75
>      C.3.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  75
>      C.4.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  76
>      C.5.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  76
>    Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  77
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  77
>
> 1.  Introduction
>
>    This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
>    define the message exchanges used to request, distribute and renew
>    the keying material in a group communication scenario, e.g., based on
>    multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing
>    [I-D.ietf-core-coap-pubsub].
>
>
> [CS: Nit: publish-subscribe messaging instead of publishing-subscribing?]

==>MT
Ok.
<==

>
>
> The ACE framework is based on CBOR
>    [RFC8949], so CBOR is the format used in this specification.
>    However, using JSON [RFC8259] instead of CBOR is possible, using the
>    conversion method specified in Sections 6.1 and 6.2 of [RFC8949].
>
>    Profiles that use group communication can build on this document, by
>    defining a number of details such as the exact group communication
>    protocol and security protocols used.  The specific list of details a
>    profile needs to define is shown in Appendix A.
>
>    If the application requires backward and forward security, new keying
>    material is generated and distributed to the group upon membership
>    changes.
>
> [CS: Whose responsibility is this? While I acknowledge that options 
> available become clear in the end, it would be good to define the 
> different operating models, e.g., push/pull based]

==>MT
Right, we'll explicitly mention the KDC here and point forward for more 
details on distribution approaches.
<==

>
>  A key management scheme performs the actual distribution of
>    the new keying material to the group.  In particular, the key
>    management scheme rekeys the current group members when a new node
>    joins the group, and the remaining group members when a node leaves
>    the group.  Rekeying mechanisms can be based on [RFC2093], [RFC2094]
>    and [RFC2627].
>
> Palombini & Tiloca       Expires 13 January 2022        [Page 3]
> 
> Internet-Draft  Key Provisioning for Group Communication   July 2021
>
>
> 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.
<==

>
>    *  "GROUPNAME" is the invariant once established text string used in
>       URIs.  GROUPNAME maps to the group name of a group, although it is
>       not necessarily the same.
>
>    *  "Group identifier" is the identifier of the group keying material.
>       Opposite to group name and GROUPNAME, this identifier changes over
>       time, when the keying material is updated.
>
>    *  "Node name" is the invariant once established identifier of the
>       node.  It is used in the communication between AS, RS and Client
>       to identify a member of the group.
>
>    *  "NODENAME" is the invariant once established text string used in
>       URIs.  NODENAME is used to identify a node in a group.
>
>    This document additionally uses the following terminology:
>
>    *  Transport profile, to indicate a profile of ACE as per
>       Section 5.8.4.3 of [I-D.ietf-ace-oauth-authz].  A transport
>       profile specifies the communication protocol and communication
>       security protocol between an ACE Client and Resource Server, as
>       well as proof-of-possession methods, if it supports proof-of-
>       possession access tokens, etc.  Tranport profiles of ACE include,
>       for instance, [I-D.ietf-ace-oscore-profile],
>       [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile].
>
> [CS: Tranport -> Transport]

==>MT
Will fix.
<==

>
>
>
> Palombini & Tiloca       Expires 13 January 2022            [Page 4]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    *  Application profile, that defines how applications enforce and use
>       supporting security services they require.  These services may
>       include, for instance, provisioning, revocation and distribution
>       of keying material.  An application profile may define specific
>       procedures and message formats.
>
> 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".
<==

>
>
>
> 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.
<==

>
>
>    This document specifies a mechanism for:
>
>    *  Authorizing a new node to join the group (Section 3), and
>       providing it with the group keying material to communicate with
>       the other group members (Section 4).
>
>    *  Allowing a group member to retrieve group keying material
>       (Section 4.4 and Section 4.5).
>
>    *  Allowing a group member to retrieve public keys of other group
>       members (Section 4.6) and to provide an updated public key
>       (Section 4.7).
>
>    *  Allowing a group member to leave the group (Section 5).
>
>    *  Evicting a group member from the group (Section 5).
>
>    *  Renewing and re-distributing the group keying material (rekeying)
>       upon a membership change in the group (Section 4.10 and
>       Section 5).
>
>    Figure 2 provides a high level overview of the message flow for a
>    node joining a group communication setting, which can be expanded as
>    follows.
>
>    1.  The joining node requests an Access Token from the AS, in order
>        to access a specific group-membership resource on the KDC and
>        hence join the associated group.  This exchange between Client
>        and AS MUST be secured, as specified by the transport profile of
>        ACE used between Client and KDC.  The joining node will start or
>        continue using a secure communication association with the KDC,
>        according to the response from the AS.
>
>    2.  The joining node transfers authentication and authorization
>        information to the KDC, by posting the obtained Access Token to
>        the /authz-info endpoint at the KDC.  This exchange, and all
>        further communications between the Client and the KDC, MUST occur
>        over the secure channel established as a result of the transport
>        profile of ACE used between Client and KDC. After that, a
>
>
>
> Palombini & Tiloca       Expires 13 January 2022            [Page 6]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>        joining node MUST have a secure communication association
>        established with the KDC, before starting to join a group under
>        that KDC.  Possible ways to provide a secure communication
>        association are described in the DTLS transport profile
>        [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile
>        [I-D.ietf-ace-oscore-profile] of ACE.
>
>    3.  The joining node starts the joining process to become a member of
>        the group, by accessing the related group-membership resource at
>        the KDC.  At the end of the joining process, the joining node has
>        received from the KDC the parameters and keying material to
>        securely communicate with the other members of the group, and the
>        KDC has stored the association between the authorization
>        information from the access token and the secure session with the
>        joining node.
>
> [CS: Maybe also clarify here that this potentially triggers re-keying 
> as shown in the figure?]

==>MT
Sure.
<==

>
>    4.  The joining node and the KDC maintain the secure association, to
>        support possible future communications.  These especially include
>        key management operations, such as retrieval of updated keying
>        material or participation to a group rekeying process.
>
>    5.  The joining node can communicate securely with the other group
>        members, using the keying material provided in step 3.
>
>                C                           AS  KDC          Group
>                |                           |    |           Member
>              / |                           |    |               |
>              | |   Authorization Request   |    |               |
>     Defined  | |-------------------------->|    |                 |
>     in the   | |                           |    |               |
>       ACE    | |   Authorization Response  |    |               |
>    framework | |<--------------------------|    |                 |
>              | |                                |               |
>              \ |---------- Token Post --------->|                 |
>                |                                |               |
>                |------- Joining Request ------->|                 |
>                |                                |               |
>                |<------ Joining Response -------|-- Group Rekeying -->|
>                |                                |               |
>                | Dispatcher       |
>                | |            |
>                |<===== Secure group communication =======|===========>|
>                | |            |
>
>                Figure 2: Message Flow Upon New Node's Joining
>
>
> Palombini & Tiloca       Expires 13 January 2022            [Page 7]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
> 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 ..."
<==

>
>       This value is a CBOR byte string, wrapping a CBOR array of one or
>       more entries.
>
>
>
> 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.
<==

>
>       -  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.
<==

>
>       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 ..."
<==

>
>    *  'audience', with an identifier of a KDC.
>
>    As defined in [I-D.ietf-ace-oauth-authz], other additional parameters
>    can be included if necessary.
>
> Palombini & Tiloca       Expires 13 January 2022            [Page 9]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    gname = tstr
>
>    permissions = uint . bits roles
>
>    roles = &(
>       Requester: 1,
>       Responder: 2,
>       Monitor: 3,
>       Verifier: 4
>    )
>
>    scope_entry = AIF_Generic<gname, permissions>
>
>    scope = << [ + scope_entry ] >>
>
>        Figure 4: Example CDLL definition of scope, using the default
>                       Authorization Information Format
>
>    gname = tstr
>
>    role = tstr
>
>    scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
>
>    scope = << [ + scope_entry ] >>
>
>       Figure 5: CDLL definition of scope, using as example group name
>                       encoded as tstr and role as tstr
>
> 3.2.  Authorization Response
>
> [SNIP]
>
>
> 3.3.  Token Post
>
>    The Client sends a CoAP POST request including the access token to
>    the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
>
>    This request differs from the one defined in
>    [I-D.ietf-ace-oauth-authz], because it allows to transport additional
>    encoding information about the public keys in the group, used for
>    source authentication, as well as any other group parameters.
>
> [CS: Transport or request additional information?]

==>MT
Right, it's mixed up :-)

The request includes additional parameters that allow to request for 
additional information to be transported in the response. Will be fixed.
<==

>
>    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.
<==

>
>    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.
<==

>
>    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).
<==

>
>    Note that the CBOR map specified as payload of the 2.01 (Created)
>    response may include further parameters, e.g. according to the
>    signalled transport profile of ACE.  Application profiles MAY define
>    the additional parameters to use within this exchange (OPT2).
>
>    Application profiles of this specification MAY define alternative
>    specific negotiations of parameter values for the signature algorithm
>    and signature keys, if 'sign_info' is not used (OPT1).
>
> 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?
<==

>
> [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'.
<==

> [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?
<==

>
>       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.
<==

>
>    *  /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.
<==

>
>    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.
<==

>
>    The details for the handlers of each resource are given in the
>    following sections.  These endpoints are used to perform the
>    operations introduced in Section 4.
>
> 4.1.1.  ace-group
>
>    This resource implements a FETCH handler.
>
> 4.1.1.1.  FETCH Handler
>
>    [SNIP]
>
> 4.1.2.  ace-group/GROUPNAME
>
>    This resource implements GET and POST handlers.
>
> 4.1.2.1.  POST Handler
>
>    The POST handler adds the public key of the client to the list of the
>    group members' public keys and returns the symmetric group keying
>    material for the group identified by GROUPNAME.  Note that the group
>    joining exchange is done by the client via this operation, as
>    described in Section 4.3.
>
>    The handler expects a request with payload formatted as a CBOR map,
>    which MAY contain the following fields, which, if included, MUST have
>    the corresponding values:
>
>
> 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 ..."
<==

>
>       -  The second element, namely 'role_filter', is a non-empty CBOR
>          array.  Each element of the array contains one role or a
>          combination of roles for the group identified by GROUPNAME.
>          The Client indicates that it wishes to receive the public keys
>          of all group members having any of the single roles, or at
>          least all of the roles indicated in any combination of roles.
>          For example, the array ["role1", "role2+role3"] indicates that
>          the Client wishes to receive the public keys of all group
>          members that have at least "role1" or at least both "role2" and
>          "role3".
>
>       -  The third element, namely 'id_filter', is an empty CBOR array.
>
>       If the Client wishes to receive all public keys of all group
>       members, it encodes the 'get_pub_key' parameter as the CBOR simple
>       value Null.
>
>       The CDDL definition [RFC8610] of 'get_pub_keys' is given in
>       Figure 6, using as example encoding: node identifier encoded as a
>       CBOR byte string; role identifier encoded as a CBOR text string,
>       and combination of roles encoded as a CBOR array of roles.
>
>       Note that the array of roles 'role_filter' is non-empty for this
>       handler, but this is not necessarily the case for other handlers
>       using this parameter: if this array is empty, it means that the
>       client is not filtering public keys based on roles.
>
>
> Palombini & Tiloca       Expires 13 January 2022           [Page 20]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>       Also note that the array of node identifiers 'id_filter' is empty
>       for this handler, because the joining node is not expected or
>       capable to express a filter based on node identifiers at this
>       point in time.  Consistently, the 'inclusion_flag' element is set
>       to the CBOR simple value True.  However, the 'id_filter' array is
>       not necessarily empty for the value of 'get_pub_keys' received by
>       the handler of FETCH to ace-group/GROUPNAME/pub-key (see
>       Section 4.1.3.1).
>
>       Finally, the 'get_pub_keys' parameter MUST NOT have the arrays
>       'role_filter' and 'id_filter' as both empty, i.e., in CBOR
>       diagnostic notation: [ bool, [ ], [ ] ].  Thus, if this parameter
>       is received as formatted in that way, it has to be considered
>       malformed.
>
> [CS: I understand that other handlers may use this parameter, but maybe
> it's better to focus its value for this handler; otherwise it becomes 
> tedious
> to parse the information].

==>MT
Ok, we'll not mention other handlers here.
<==

>
>    [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.
<==

>
> If the KDC does not implement
>
>
> Palombini & Tiloca       Expires 13 January 2022           [Page 22]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>       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.
>
> [SNIP]
>
>    If no public key is included in the 'client_cred' field, the handler
>    checks if one public key is already associated to the received access
>    token (see Section 4.3 for an example) and to the group identified by
>    GROUPNAME.
>
> [CS: I assume the client can use different public keys for different 
> groups,
> and KDC supports this]

==>MT
Yes, indeed. It will be mentioned explicitly.
<==

>
>    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.
<==

>
>       -  The handler adds the retrieved Client's public key to the
>          stored list of public keys stored for the group identified by
>          GROUPNAME.  If such list already includes a public key for the
>          Client, but a different public key is specified in the
>          'client_cred' field, then the handler MUST replace the old
>          public key in the list with the one specified in the
>          'client_cred' field.
>
>    *  The handler returns a 2.01 (Created) response, containing the
>       symmetric group keying material, the group policies and the public
>       keys of the current members of the group, if the KDC manages those
>       and the Client requested them.
>
> [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.
<==

>
>
> 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.
<==

>
> [SNIP]
>
>
> 4.1.3.  ace-group/GROUPNAME/pub-key
>
>    [SNIP]
>
>
> 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.
<==

>
>       -  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.
<==

>
>   [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?
<==

>
> [SNIP]
>
>
> 4.1.4.  ace-group/GROUPNAME/policies
>
> [SNIP]
>
>
> 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.
<==

>
> [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.
<==

>
>    [SNIP]
>
>
>
> 4.1.7.  ace-group/GROUPNAME/nodes/NODENAME/pub-key
>
>    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.
>
> 4.1.7.1.  POST Handler
>
>    The POST handler is used to replace the stored public key of this
>    client (identified by NODENAME) with the one specified in the request
>    at the KDC, for the group identified by GROUPNAME.
>
>    [SNIP]
>
> 4.2.  Retrieval of Group Names and URIs
>
>    In case the joining node only knows the group identifier of the group
>    it wishes to join or about which it wishes to get update information
>    from the KDC, the node can contact the KDC to request the
>    corresponding group name and joining resource URI. The node can
>    request several group identifiers at once.  It does so by sending a
>    CoAP FETCH request to the /ace-group endpoint at the KDC formatted as
>    defined in Section 4.1.1.1.
>
>    [SNIP]
>
>
>
> 4.3.  Joining Exchange
>
> [CS: I feel this needs to come earlier in the draft]

==>MT
Yes, please see the reply to the comment at the beginning of this 
review, about section restructuring.
<==

>
>    Figure 12 gives an overview of the Joining exchange between Client
>    and KDC, when the Client first joins a group, while Figure 13 shows
>    an example.
>
>       Client         KDC
>          |          |
>          |----- Joining Request: POST /ace-group/GROUPNAME ------>|
>          |          |
>          |<--------- Joining Response: 2.01 (Created) ----------- |
>          | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |
>
>         Figure 12: Message Flow of First Exchange for Group Joining
>
>  Request:
>
>  Header: POST (Code=0.02)
>  Uri-Host: "kdc.example.com 
> <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkdc.example.com%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937771776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=z0af%2BoalIqiYx0nhnyxut6tDezmR35%2Fcy2vk1e79WXQ%3D&reserved=0>"
>  Uri-Path: "ace-group"
>  Uri-Path: "g1"
>  Content-Format: "application/ace-groupcomm+cbor"
>  Payload (in CBOR diagnostic notation,
>           with PUB_KEY and POP_EVIDENCE being CBOR byte strings):
>    { "scope": << [ "group1", ["sender", "receiver"] ] >> ,
>      "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
>      "cnonce": h'6df49c495409a9b5', "client_cred_verify": POP_EVIDENCE }
>
>  Response:
>
>  Header: Created (Code=2.01)
>  Content-Format: "application/ace-groupcomm+cbor"
>  Location-Path: "kdc.example.com 
> <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkdc.example.com%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C6b6d12f0f3004d621cb408d96812c85f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637655253937781729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mg5pkrpGIhS77CIVDA0pQ4ERm5mAUCM2i5zA6tmLtQE%3D&reserved=0>"
>  Location-Path: "g1"
>  Location-Path: "nodes"
>  Location-Path: "c101"
>  Payload (in CBOR diagnostic notation,
>           with KEY being a CBOR byte strings):
>    { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200,
>      "pub_keys": [ PUB_KEY1, PUB_KEY2 ],
>      "peer_roles": ["sender", ["sender", "receiver"]],
>      "peer_identifiers": [ ID1, ID2 ] }
>
>          Figure 13: Example of First Exchange for Group Joining
>
>
>
>
>
> Palombini & Tiloca       Expires 13 January 2022           [Page 40]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    [SNIP]
>
> 4.4.  Retrieval of Updated Keying Material
>
>    When any of the following happens, a node MUST stop using the owned
>    group keying material to protect outgoing messages, and SHOULD stop
>    using it to decrypt and verify incoming messages.
>
>    *  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 receiving a notification of revoked/renewed keying material
>       from the KDC, possibly as part of an update of the keying material
>       (rekeying) triggered by the KDC.
>
>    *  Upon receiving messages from other group members without being
>       able to retrieve the keying material to correctly decrypt them.
>       This may be due to rekeying messages previously sent by the KDC,
>       that the Client was not able to receive or decrypt.
>
>    In either case, if it wants to continue participating in the group
>    communication, the node has to request the latest keying material
>    from the KDC.  To this end, the Client sends a CoAP GET request to
>    the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC,
>    formatted as specified in Section 4.1.6.2.
>
> [CS: I feel the information in this section need to come before after the
> resources are introduced, but before
> the operation and parameter details are presented for each group.
> The message examples would be better appreciated right after all
> the parameters etc of the operation is introduced.]

==>MT
As above, the section restructuring proposed in the reply to the comment 
at the beginning of this review should also address this point.
<==

>
>    [SNIP]
>
>
>    Alternatively, the re-distribution of keying material can be
>    initiated by the KDC, which e.g.,:
>
>    *  Can make the ace-group/GROUPNAME resource Observable [RFC7641],
>       and send notifications to observer Clients when the keying
>       material is updated.
>
> [CS: Some of my questions earlier is answered here. I feel this should
> be said earlier]

==>MT
Yes, see comments above.
<==

>
>     [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".

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?
<==

>
>    Note that these methods of KDC-initiated key distribution have
>    different security properties and require different security
>    associations.
>
> 4.5.  Requesting a Change of Keying Material
>
>    [SNIP]
>
>
>
> 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.
<==

>
>  [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.
<==

>
>
>     [SNIP]
>
>
>
> 7.  ACE Groupcomm Parameters
>
> [CS: Handy table]

==>MT
Agree :-)
<==

>
>    This specification defines a number of fields used during the second
>    part of the message exchange, after the ACE Token POST exchange.  The
>    table below summarizes them, and specifies the CBOR key to use
>    instead of the full descriptive name.
>
>    Note that the media type application/ace-groupcomm+cbor MUST be used
>    when these fields are transported.
>
>  +=======================+======+================+==================+
>    | Name                  | CBOR | CBOR Type      | Reference        |
>    |                       | Key  |                |              |
>  +=======================+======+================+==================+
>    | error                 | TBD  | int            | Section 4        |
>  +-----------------------+------+----------------+------------------+
>    | error_description     | TBD  | text string    | Section 4        |
>  +-----------------------+------+----------------+------------------+
>    | scope                 | TBD  | byte string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | get_pub_keys          | TBD  | array / simple | Section 4.1.2.1, |
>    |                       |      | value null     | Section 4.1.3.1  |
>  +-----------------------+------+----------------+------------------+
>    | client_cred           | TBD  | byte string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | cnonce                | TBD  | byte string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | client_cred_verify    | TBD  | byte string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>
>
>
> Palombini & Tiloca       Expires 13 January 2022           [Page 54]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
>    | pub_keys_repos        | TBD  | text string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | control_uri           | TBD  | text string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | gkty                  | TBD  | integer / text | Section 4.1.2.1  |
>    |                       |      | string         |              |
>  +-----------------------+------+----------------+------------------+
>    | key                   | TBD  | see "ACE       | Section 4.1.2.1  |
>    |                       |      | Groupcomm Key" |              |
>    |                       |      | Registry       |              |
>  +-----------------------+------+----------------+------------------+
>    | num                   | TBD  | int            | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | ace-groupcomm-profile | TBD  | int            | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | exp                   | TBD  | int            | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | pub_keys              | TBD  | array          | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | peer_roles            | TBD  | array          | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | peer_identifiers      | TBD  | array          | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | group_policies        | TBD  | map            | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | mgt_key_material      | TBD  | byte string    | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | sign_info             | TBD  | array          | Section 4.1.2.1  |
>  +-----------------------+------+----------------+------------------+
>    | gid                   | TBD  | array          | Section 4.1.1.1  |
>  +-----------------------+------+----------------+------------------+
>    | gname                 | TBD  | array of text  | Section 4.1.1.1  |
>    |                       |      | strings        |              |
>  +-----------------------+------+----------------+------------------+
>    | guri                  | TBD  | array of text  | Section 4.1.1.1  |
>    |                       |      | strings        |              |
>  +-----------------------+------+----------------+------------------+
>    | kdcchallenge          | TBD  | byte string    | Section 4.1.7.1  |
>  +-----------------------+------+----------------+------------------+
>
>                                  Table 1
>
>    [SNIP]
>
>
>
> 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.
<==

>
>   [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.
<==

>
>
> [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.
<==

>
>    As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future
>    algorithms can be registered in the "COSE Algorithms" Registry
>    [COSE.Algorithms] as specifying none or multiple COSE capabilities.
>
>    To enable the seamless use of such future registered algorithms, this
>    section defines a general, agile format for each 'sign_info_entry' of
>    the 'sign_info' parameter in the Token Post response, see
>    Section 3.3.1.
>
>    If any of the currently registered COSE algorithms is considered,
>    using this general format yields the same structure of
>    'sign_info_entry' defined in this document, thus ensuring retro-
>    compatibility.
>
>
>
>
> Palombini & Tiloca       Expires 13 January 2022           [Page 73]
> 
> Internet-Draft  Key Provisioning for Group Communication       July 2021
>
>
> B.1.  Format of 'sign_info_entry'
>
>    The format of each 'sign_info_entry' (see Section 3.3.1) is
>    generalized as follows.  Given N the number of elements of the
>    'sign_parameters' array, i.e., the number of COSE capabilities of the
>    signature algorithm, then:
>
>    *  'sign_key_parameters' is replaced by N elements 'sign_capab_i',
>       each of which is a CBOR array.
>
>    *  The i-th array following 'sign_parameters', i.e., 'sign_capab_i'
>       (i = 0, ..., N-1), is the array of COSE capabilities for the
>       algorithm capability specified in 'sign_parameters'[i].
>
>       sign_info_entry =
>       [
>         id : gname / [ + gname ],
>         sign_alg : int / tstr,
>         sign_parameters : [ alg_capab_1 : any,
>                             alg_capab_2 : any,
>                             ...,
>                             alg_capab_N : any],
>         sign_capab_1 : [ any ],
>         sign_capab_2 : [ any ],
>         ...,
>         sign_capab_N : [ any ],
>         pub_key_enc = int / nil
>       ]
>
>       gname = tstr
>
>               Figure 30: 'sign_info_entry' with general format
>
> [SNIP]
>
> On Tue, Aug 24, 2021 at 5:52 PM Göran Selander 
> <goran.selander=[email-masked] 
> <mailto:[email-masked]>> 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 [email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> 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
>     [email-masked] <mailto:[email-masked]>
>     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
>     [email-masked] <mailto:[email-masked]>
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Göran Selander <[email-masked]>
Date: Tue, 14 Sep 2021 08:57:38 +0000

Hi Marco,

Please find responses inline.

On 2021-08-31, 18:10, "Marco Tiloca" <marco.tiloca=[email-masked]> wrote:
  
    > 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.

    ==>MT
    Definitely the new group key material to use before completing the 
    joining of the new member.

    As to the public key of the new group member (if there is one at all, 
    depending on the member's roles), it's actually good to admit its 
    provisioning _together_ with the group key material. It would spare 
    other group members to perform dedicated retrieval traffic with the KDC 
    just for that later on. This can be added to the last paragraph of 
    Section 4.3.

[GS: OK.]

    As to using "some existing group key", yes, this requires a separate set 
    of administrative key material, possibly organized into a hierarchy 
    whose root is the administrative group key (see also later comments). 
    That's the key material used to protect rekeying messages at the 
    application layer, and in principle unrelated to the secure 
    communication protocol used in the group.

[GS: Sure, I could have been more accurate and written "a key derived from some existing shared key". This can be done in different ways but since this draft is about rekeying for group communication in resource constrained settings, shouldn't the use of the existing secure group communication be defined here or in an application profile?]

    >
    > 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.

    ==>MT
    Yes. This is explicitly mentioned in Section 4.4, in the second bullet 
    point after Figure 15.

    As above, this requires a separate set of administrative key material, 
    possibly organized into a hierarchy whose root is the administrative 
    group key (see also later comments). Also as above, that's the key 
    material used to protect rekeying messages at the application layer, and 
    in principle unrelated to the secure communication protocol used in the 
    group.
    <==

[GS: Thanks, I missed that. It seems inevitable for good scalability that at least the application profiles define this. More below.]

    >
    > Two sub-questions:
    >
    > a. Is it possible to extend the interface to make use of the underlying group communication?

    ==>MT
    It should already be able to accommodate it. In particular:

    * In Section 4.4, the second bullet point after Figure 15 already 
    mentions this possibility. An application profile or a separate 
    specification that builds on and extends it would have to define the 
    exact rekeying scheme to use and its message formats.

    * At the end of Section 4.1.2.1, it is defined that the Joining Response 
    can include an optional parameter 'mgt_key_material'. In case of 
    rekeying schemes more advanced than a basic point-to-point approach 
    using pairwise security associations, this parameter provides a group 
    member with the administrative key material _it_ needs to have to 
    participate in a group rekeying.

        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 shared by 
    all the group members).

    * In Section 4.4, the third bullet point after Figure 15 refers to a 
    local "control" resource at a group member, where the KDC can send 
    requests such as rekeying messages. The group member can provide the KDC 
    with the URI of such a local resource when joining the group, in the 
    'control_uri' parameter of the Joining Request.

        This is more generally intended as a resource where the KDC can 
    reach the group member with a request, and is potentially usable for 
    several administrative operations, including a group rekeying. In the 
    previous, second bullet point, it can be explicitly mentioned that this 
    resource can also be the target of a group rekeying request sent over 
    multicast.

        Note that 'control_uri' may indicate an administrative "root path", 
    that the group member determines as relevant for that security group. I 
    would imagine requests for different administrative tasks to target 
    different sub-resources identified by well-known path segments under 
    that path.

[GS: Right, so there are components defined which can be used for this purpose.]

    There are still two missing things, though.

    * A group member would need to know the multicast address where the KDC 
    sends group rekeying messages. This might also be provided as an 
    additional parameter in the Joining Response.

        Several versions ago, we proposed to include this in draft, but the 
    idea was dismissed to keep things simple. Should we revisit this and add 
    an optional parameter of this kind in the Joining Response?

[GS: If needed for simple configuration, then I'd say "yes", see below.]

        Note that this goes hand-in-hand with _requiring_ a joining node to 
    provide also the URI of a local control resource, in the 'control_uri' 
    parameter of the Joining Request. Hence, it becomes (even more) 
    important for the joining node to know as much as possible about how the 
    group works (e.g. by means of early discovery), before attempting to 
    join it by sending the Joining Request.

[GS: Thanks for elaborate response. Maybe what I'm missing is a simple example of how to apply the different components of  this draft for using a key hierarchy scheme (again, could go into a profile). On the latter topic of what information needs to be provided before joining, some configuration data can be assumed to be pre-configured. To re-iterate: I'm not looking for a "complete" scheme which takes into account all information flows in all possible key distribution schemes, but making sure that there is a simple deployment which scales to very large groups.]

    >
    > b. Is it possible to apply this interface with a key hierarchy scheme?

    ==>MT
    Yes, it is totally up to the application profile and what it defines. 
    The answer above should already give more practical details on what we 
    have and what seems to be still missing.
    <==

    >
    > 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.

    ==>MT
    Agree. The draft key-groupcomm-oscore is defining in detail a simple, 
    point-to-point approach. Based on a comment above, it can be extended so 
    that, in case of rekeying upon joining of a new member, the rekeying 
    messages include also the public key and Sender ID of the new node (if 
    this is not a Monitor).

    More generally, a multicast-based approach (e.g. relying on key 
    hierarchy) should be totally possible to separately define and use, once 
    some general aspects mentioned in the comments above are finalized here 
    in key-groupcomm to be inheritable in an application profile.
    <==

[GS: OK! Any thoughts on where to put such an example?]

    > 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.

    ==>MT
    I try to reply separately on each of the affected aspects mentioned above.

    * The handlers as such (Section 4) run at the KDC, which is not intended 
    to be constrained. So, we defined the KDC as expected to offer the full 
    interface specified in Section 4.1. I can imagine an application profile 
    that really does not need a particular subset of handlers to declare 
    them as not to be implemented, possibly under certain conditions.

    Thinking of a group member, I can imagine as important to have minimally 
    implemented the logic for:

    FETCH on ace-group/
    - To retrieve the group name and joining URI from the specified group 
    identifier.

    POST/GET on ace-group/GROUPNAME/
    - To join the group (POST) and retrieve the current group key material 
    as group member (GET).

    GET/FETCH on ace-group/GROUPNAME/pub-key
    - To retrieve the public keys of all the other group members (GET) or 
    only of some by filtering (FETCH). Admittedly, the latter might be 
    sacrificed, but it allows to reduce the number of transferred public 
    keys a lot.

    GET on ace-group/GROUPNAME/num
    - To retrieve only the current version of the group key material.

    DELETE on ace-group/GROUPNAME/nodes/NODENAME
    - To leave the group.

    Instead, the following logic might be omitted in the implementation of a 
    minimal group member:

    GET on ace-group/GROUPNAME/active
    - To check the status of the group

    GET on ace-group/GROUPNAME/policies
    - To retrieve the group policies. Thus, they would be obtainable only 
    when joining the group with a POST on ace-group/GROUPNAME/ (see above).

    GET/PUT on ace-group/GROUPNAME/nodes/NODENAME
    - GET is for obtaining the current group key material plus the 
    "individual node key material" (e.g., the Sender ID in the Group OSCORE 
    case). The former can be obtained with a GET on ace-group/GROUPNAME/ 
    (see above). The latter would not be possible to re-obtain as group 
    member, thus expecting the group member to just remember that 
    information, whose possible change happens in a synchronized way with 
    the KDC anyway (see right below).
    - PUT is requesting new "individual node key material" (which can result 
    in the KDC providing new one, or rekeying the group, or both things 
    together). This can also be sacrificed, so that a group member needing a 
    new individual node key material would re-join the group with a POST on 
    ace-group/GROUPNAME/ (see above).

    POST on ace-group/GROUPNAME/nodes/NODENAME/pub-key
    - To upload a new public key of its own. This can be sacrificed, 
    assuming that a group member does not change its public key during its 
    membership.

[GS: This type of discussion makes sense to me and I think it should be somewhere in the draft. The specification of exactly what of these to support is not part of this draft, but could go into an application profile, or some "compliance" document used for a particular deployment.]

    * About the Error IDs (Section 8), error responses will be sent anyway 
    in case of errors at the KDC.

        The group members can of course not understand those error IDs. 
    Also, based on the third from last paragraph in Section 4.0, the 
    accompanying textual 'error_description' is already optional.

        Maybe it can help to:

        - Remove the parameter 'error_description' altogether; or, even more 
    aggressively,

        - Make it just optional for the KDC to use these extended error 
    responses with content format application/ace-groupcomm+cbor and payload 
    the CBOR map with 'error' and 'error_description'.

        Thoughts?

[GS: I think the focus should be on what actions follow from the error message, either autonomous or by humans. Detailed error codes can make sense for these settings when there are different autonomous actions that can follow from the errors. In case the errors anyway needs to be resolved by a human, a human readable diagnostic message could be an alternative. Having said this, it is not clear to me what can be predicted about deployment of a particular profile of this draft. One question to ask is if the error semantics should be left more to the profiles or does the current error codes have value for intended profiles?]

    * About the ACE Groupcomm Parameters summarized in Section 7), most of 
    them are required or practically required. Some of them can be 
    conditionally not supported, e.g. by particular group members. Trying to 
    have a first classification below:

    Must be supported:
    - 'scope', 'gkty', 'key', 'num' and 'exp', as related to the group in 
    question and the retrieval of its key material.
    - 'gid', 'gname' and 'guri', as required for FETCH to /ace-group .
    - 'pub_keys' and 'peer_identifiers', since public keys are sooner or 
    later going to be retrieved, accompanied by the node identifiers of the 
    corresponding nodes.

    Practically must be supported:
    - 'get_pub'keys' is practically necessary, except for the inconvenient 
    and undesirable behavior where: i) a group member does not ask for the 
    other group members' public keys upon joining; and ii) later on, the 
    group member only retrieves the public keys of all group members with a 
    GET to ace-group/GROUPNAME/pub-key  (i.e., never by using FETCH).

    Conditionally not supported
    - 'client_cred', 'cnonce' and 'client_cred_verify' are not needed to be 
    supported by a node if this does not have a public key of its own that 
    it uses in the group.
    - 'kdcchallenge' is not needed to be supported by a node if this does 
    not have a public key of its own that it uses in the group, or if it 
    does not post the Token to /authz-info at the KDC. The PoP input share 
    N_S of the KDC has thus to be determined differently and it's up to the 
    profiles to define how (see REQ21).
    - 'pub_keys_repos' is not needed to be supported by a node if this does 
    not have a public key of its own that it uses in the group, or if it 
    does not store the public key in a repo to point to with this parameter.
    - 'group_policies' might be sent by the KDC anyway. It may not be 
    supported by a node if it is already aware of all group policies. These 
    may include a particular group rekeying scheme (see comment above). In 
    other words, it may not be supported by a node that never joins a group 
    without knowing its group policies in advance.
    - 'peer_roles' goes hand-in-hand with 'pub_keys' and 'peer_identifiers'. 
    Generally, it should be fine that it is not needed to be supported by a 
    node if this does not have to care of the exact role of the node 
    associated to a retrieved public key.
    - 'control_uri', is already optional to include in the Joining Request. 
    However, its support is preferable to enable even point-to-point group 
    rekeying initiated by the KDC. On the other other hand, it would rather 
    become necessary to support, if the group uses an advanced key 
    management scheme. In such a case, a node willing to join such a group 
    has to support this parameter, in order to indicate the URI of a local 
    resource to the KDC.
    - 'mgt_key_material' would be sent by the KDC anyway, if the group uses 
    an advanced key management schemes. In such a case, a node willing to 
    join such a group has to support this parameter. In other words, it may 
    not be supported by a node that never joins a group which uses an 
    advanced group key management scheme.

    May generally be not supported:
    - 'error' and 'error_description', see comment above.
    - 'ace_groupcomm_profile', as already defined optional in Section 4.1.2.1.

    Would this kind of reasoned classification help?

[GS: Yes, I think some reasoning or classification would be instructive.]

    <==

    >
    > (This comment actually applies also to the transport profiles, which this draft does not need to take responsibility for.)

    ==>MT
    Right, to be kept in mind for the profiles too, considering the 
    additional profile-specific parameter that they can add.
    <==

    >
    >
    >   
    > 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.
    >

    ==>MT
    Right, I can replace this occurrences of "Token Post" with "Token 
    Uploading".

[GS: Good. (Perhaps consider also other synonyms to "uploading" ...)]

    The use of "POST /token" and "POST /authz-info" is limited to Figures 2 
    and 3, where it should be appropriate.
    <==

    >
    >
    > 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).

    ==>MT
    The issue is that each example in Sections 4.2-4.10 also refers to the 
    corresponding handler description, which defines also the payload format 
    for that operation. In particular, all the ACE Groupcomm parameters are 
    introduced in Section 4.1. An example shown before that risks to not say 
    that much.

    I think that a middle ground can be the following, and it should also be 
    aligned with and address similar comments that Cigdem gave in her review 
    [1].

    2) Separately moving each current 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:

    That is:

    4.2 ace-group
    4.2.1 FETCH handler

    4.3 ace-group/GROUPNAME
    4.3.1 POST handler

    ...

    How does it sound?

    [1] https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0/

    <==

[GS: Sounds good!]

    > It speaks of operations on each resource, but it does not say which resources are mandatory to implement. Where is that written?

    ==>MT
    Building on a comment above, the KDC is supposed to implement all these 
    resources (and possibly add more if needed and defined by a specific 
    application profile).

    As discussed above, a minimal group member may however not need to 
    implement the logic to use some of those resources.

    This requirement was more intended to require application profiles to 
    produce something like Figure 2 of ace-key-groupcomm-oscore , see its 
    Section 5.5 "Admitted Methods".
    <==

[GS: OK]

    >
    >
    >
    > 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.

    ==>MT
    We can add something along these lines, especially on when it might be 
    acceptable to not ensure backward security (or anyway not rigorously 
    upon every single new joining). Ultimately, it is up to the specific 
    application to decide and define policies for the KDC to enforce.

    Besides the freshness aspects you mention, this is more about accepting 
    that the newly joined node would have access to communications in the 
    group prior its joining, if it has recorded such exchanged messages.
    <==

[GS: OK]

    >     The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
    >     [I-D.ietf-ace-oauth-authz].  This parameter contains information and
    >     used between the Client and the RS.  Its exact content is application
    >     specific.
    >
    > - - -
    >
    >     The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as

    ==>MT
    Ok, we can remove the redundancy and also be more explicit, pointing to 
    the exact format 'sign_info_req' or 'sign_info_resp' used in the message 
    in question.
    <==

    >
    >
    > 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.

    ==>MT
    Yes, there is only one actual parameter, 'sign_info', and we want a 
    single CBOR abbreviation registered for it to use in the payload map.

    Using the different _req and _resp versions in Section 3.3.1 is just a 
    way to make a hard distinction between the request and response case. It 
    might help to improve the CDDL definition, i.e.:

    sign_info = sign_info_req / sign_info_resp

    sign_info_req  = nil                    ; used in a request
    sign_info_resp = [ + sign_info_entry ]  ; used in a response

    ...

[GS: Yes, that reads better to me]

Göran

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 15 Sep 2021 19:47:59 +0200

Hi Göran,

Thanks for the follow-up!

As to the questions and open points from your latest mail, below I 
summarize the outcome from the 2021-09-14 ACE interim meeting. For 
convenience, they are aggregated into 3 macro-points.

1) Available operations to support.

- The KDC is assumed to support everything defined here. Application 
profiles can rule out specific unneeded operations, or add more.
- For the group members, we will clarify what is expected to be 
minimally supported and why that's the case or not. There will be a new 
requirement for application profiles to define if certain operations 
must be supported or can remain optional for group members.

2) Enhanced error responses. We'll clarify that:

- The diagnostic text is optional and intended for deployments that 
involve human intervention. Otherwise it can certainly be skipped. The 
KDC is supposed to log error events anyway.
- These messages mimic the same approach used by the main error 
responses of the ACE framework.
- The integer Error IDs are a cheap hint for a device, to tell it better 
than what a too generic CoAP error response code can tell.
- Error IDs defined here are all available for application profiles, 
which can define and register more of their own, as they find them useful.

3) Group rekeying based on one-to-many messages, e.g., over multicast.

We will enable this, by adding the missing building blocks. These include:

- New related parameters especially in the Joining Response, e.g., 
signaling of the used rekeying scheme and the multicast IP address to use.
- Provisioning of the KDC's public key, whose general parts can be 
imported from key-groupcomm-oscore where this has been defined already. 
This comes from the need to sign one-to-many rekeying messages to ensure 
they are sent by the KDC.

Also, it should be possible to provide a high-level example in the 
new-to-be section dedicated to group rekeying, when discussing efficient 
approaches. Key Graph can be taken as a concrete rekeying scheme to make 
such example not too abstract.

Building on that example, application profiles can probably refine 
details, while still remaining high-level. For instance, the generic 
"node identifier" of key-groupcomm becomes the more specific "Sender ID" 
in key-groupcomm-oscore , if that information has to be conveyed in a 
rekeying message.

Something way more detailed, up to a precise message/data format to send 
on the wire, is very much dependent on the exact rekeying scheme used in 
the group, and is also likely affected by the exact application profile. 
I believe that that level of detail would require separate, dedicated 
specifications, that define a binding between a rekeying scheme on one 
hand, and with key-groupcomm together with one or more of its 
application profiles on the other hand.

Best,
/Marco

On 2021-09-14 10:57, Göran Selander wrote:
>      [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fgv_uRo2Y45jqOLJghVSbAARWky0%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C060e402a92954dbe7a9608d9775dbeb5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637672066803513332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pI%2FXmRkFgV6dR4PbqKzxdfJLb%2BzuXn8uV%2Binhb2fd8U%3D&amp;reserved=0
>
>      <==
>
> [GS: Sounds good!]
>
>      >
>      >

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System