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

From: Göran Selander <[email-masked]>
Date: Tue, 24 Aug 2021 16:52:22 +0000

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]" <[email-masked] on behalf of [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.

    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/

    There is also an htmlized version available at:
    https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    Ace mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ace

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 25 Aug 2021 22:52:54 +0100

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

*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

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

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]

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

   *  "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]

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

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

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

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

      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?)]

      -  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"]

      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]

   *  '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?]

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

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

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

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

[SNIP]

3.3.2.  'kdcchallenge' Parameter
[CS: The same comment as above, either explained here or above... Otherwise
repetitious]
[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?]

      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]

   *  /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?]

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

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

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

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

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]

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

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

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

[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]

      -  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?)]

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

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

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

   [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]

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

   [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]

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

   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"?]

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

    [SNIP]

7.  ACE Groupcomm Parameters

[CS: Handy table]

   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]

  [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]

[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]

   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]> wrote:

> 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.
>
> 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:
>
> 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.
>
>
> 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.
>
> 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 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
>
> 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
>
> On 2021-07-12, 18:16, "Ace on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 31 Aug 2021 18:09:38 +0200

Hi Göran,

Thanks a lot for your review! Please, see my comments inline marked as 
"==>MT".

Best,
/Marco

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

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

> 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 corresp…

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

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

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?

    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.

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

> 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 genera…

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

> 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 sens…

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

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

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

<==

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

> “an OPTIONAL parameter of the Token Post

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

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

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

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

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

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

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

<==

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

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

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

> s/Tperm/“Tperm”

==>MT
OK
<==

> If this parameter is not present, the granted scope is equal to the one requested in Section 3.1}.

==>MT
OK
<==

>     in the request is given below.

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

> 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 i…

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

...
<==

>     considered in [I-D.ietf-cose-rfc8152bis-algs], "

==>MT
Ok
<==

> "(see the 'client_cred_verify' parameter in

==>MT
Ok
<==

> “in case both the 'role_filter' array and the 'id_filter'

==>MT
Ok
<==

>     and 'id_filter' MUST NOT both be empty."

==>MT
Ok
<==

> "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY

==>MT
Ok
<==

>         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&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jG%2Fl8n4csOXfzoKTQSg9ajkCz21q7wjqAjt2GSFECyY%3D&amp;reserved=0.
>
>
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lDO4CzJ0LM%2F7hB3C8giMlJdNAUGkrJjqygkUCsZZUVM%3D&amp;reserved=0
>
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=X%2FkLzQBW4i9tol6MvK304fGENoTlZgRT7skgeg4KH%2FM%3D&amp;reserved=0
>
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Szj2SV16cyAp2YJYN149C22YRR1oaSBb%2Bvk1NYFidRU%3D&amp;reserved=0
>
>
>      https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Cg%2FMHmh0M9fwDouhpjAM%2FjKyXdk4nshAazRn5llh84M%3D&amp;reserved=0
>
>
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&amp;reserved=0
>
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&amp;reserved=0

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