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

[Göran Selander <[e-mail]>]

Hi,

Here is a review of ace-key-groupcomm-13.


General
===

This draft provides a link between the ACE-OAuth authorization framework (including its transport profiles) and specifications of communication security in groups of constrained devices, e.g. the coap-groupcomm work currently developed in CORE. The document is intended to support different group communication schemes, but the details of those are defined in separate “application profiles” such as draft-ietf-ace-key-groupcomm-oscore (for Group OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This draft instead defines a common interface to a KDC acting as RS in the ACE-OAuth architecture, how to use this interface to perform various key management operations, and requirements for such application profiles.

As such, this draft is thus an “intermediary” specification, and its usefulness will be determined by the application profiles which I've glanced at but are not part of this review. 

While this approach seems reasonable from a structure point of view, I have a question about abstracting the underlying communication in comment 1 below. 

The content of the draft is quite elaborate and with detailed examples which is good but also leads to my comment number 2.

Now for the main comments:

1. How does this scale to large groups? 

Depending on application it may not be necessary to update keys during join of new members, and depending on the dynamics of the members rekeying may not be a major issue. But if it is a large group and all group members need to be updated at joining or leaving then this may require a lot of communication for which the underlying group communication may be helpful. 

For example, in case of a new member joining then a new group key or the new node's public key may be distributed using broadcast/multicast and protected with some existing group key. 

In case of rekeying a group key after a node has been evicted, a similar method could be used if it was possible to apply some key hierarchy scheme like e.g. LKH, i.e. distributing new keys corresponding to a path from the evicted node to the root in a key hierarchy.

Two sub-questions: 

a. Is it possible to extend the interface to make use of the underlying group communication?

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

These features are not necessarily in scope of this draft, but it would be good to understand if a specification of these features would be able to use the interface defined here, or if some generalization is required in which case that change may be considered already now.


2. How would a "minimal" profile look like?

The target setting for ACE in general and this draft in particular is constrained devices and networks. Some parts of the draft give example of thinking about lightweight aspects, but other parts are not at all minimalistic and includes a large number of features, however in many cases optional. 

It would be interesting to have a “minimal” example, where care has been taken in trying to define a group setting such that the resulting messages are as few and as small as possible (for a certain security level). The same comment applies to code size and state machine: There are a number of options and “nice to have” features, which if all implemented could have a measurable impact on the footprint.  

The use of the word "minimal" is not intended in an absolute sense but to target as little as possible and still provide authorized group key functionality. Perhaps such an exercise makes more sense in an application profile, such as draft-ace-key-groupcomm-oscore. But this draft may be provide a partial answer by indicating what handlers to include (sec. 4), what groupcomm parameters (sec. 7), what error ids (sec 8), etc.

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


 
More detailed comments
===


I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST Token” for the different message exchanges, respectively, quite confusing. For a long time I thought the latter referred to the former. It is true that the access token is carried with the method POST in the second exchange, but I think that is irrelevant and would suggest to instead use some other consistent terminology. For example, use  “POST /token” and “POST /authz-info” to refer to the exchanges, respectively. Alternatively, call the latter “Token provisioning” or something similar without reference to the actual method by which the token is provisioned.

This applies in particular to:

Figure 2 
“Token Post”

Figure 3 
“POST Token”

“3.3. Token Post”

3.3.1.
“an OPTIONAL parameter of the Token Post
   response message “

3.3.2
“Token Post response”

etc.


4.1

Section 4.1 specifies the handlers, 20 pages. This is followed by how the handlers are used 4.2 - 4.10, roughly one page per subsection. When reading I ended up having two copies of the draft side by side looking at the handler and its corresponding use. I'm not sure this is a problem, but reading the handlers is more motivating after having read about how they are used. There is a summary in the bullet list in 4.0 but this is merely a forward reference and didn't make me do the mapping from handler to action in my head. Maybe just move content such that 4.2-4.10 comes before 4.1 (and then you can remove the bullet list in 4.0).


"It is REQUIRED of the application profiles of this specification to
   define what operations (e.g., CoAP methods) are allowed on each
   resource"

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



9.

The security consideration speaks about different key update strategies. I was looking for considerations when to not rekey in case of new member joining a group. I would imagine in e.g. a building automation setting where a new actuator device is added into a group it may not always be necessary to renew the group key of existing actuators. This is in particular assuming by the nature of security for actuations there are already means in place to determine freshness etc. preventing misuse of an old group key.




Nits
===


3.1

s/Toid/“Toid”
s/Tperm/“Tperm”


3.2

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

- remove the “}”



3.3.  Token Post

- - -

   “The CBOR map MAY additionally include the following
   parameter, which, if included, MUST have the corresponding values:

   *  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
      value Null to require information about the signature algorithm,
      signature algorithm parameters, signature key parameters and on
      the exact encoding of public keys used in the group.”


This seems to unnecessary duplicate information coming just after:


“3.3.1.  'sign_info' Parameter

   The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
   response message defined in Section 5.10.1. of
   [I-D.ietf-ace-oauth-authz].  This parameter contains information and
   parameters about the signature algorithm and the public keys to be
   used between the Client and the RS.  Its exact content is application
   specific.

- - - 

   When used in the request, the 'sign_info' encodes the CBOR simple
   value Null, to require information and parameters on the signature
   algorithm and on the public keys used.

   The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
   in the request is given below.

      sign_info_req = nil”


3.3.1

I got the impression from the text above that ‘sign_info’ is the name of the parameter, but it turns out that the actual parameter is either called “sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’ encoding the CBOR simple value Null, which seems like a straightforward assignment, there is actually no ‘sign_info’ parameter. This is a minor, still slightly confusing.


3.3.1

"This format is consistent with every signature algorithm currently
   considered in [I-D.ietf-cose-rfc8152bis-algs], "


s/considered/defined



3.3.2

"(see the 'client_cred_verify' parameter in
   Section 4)"

Refer instead to 4.1.2.1




4.1.3.1

“in case both the 'role_filter' array and the 'id_filter'
   array are not empty”


s/not empty/non-empty


4.1.3.1

 "Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
   and 'id_filter' MUST NOT be both empty."

replace with

   "Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter'
   and 'id_filter' MUST NOT both be empty."





4.4
A  missing comma at the end of the following line:  

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



Göran




On 2021-07-12, 18:16, "Ace on behalf of [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:


    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.

            Title           : Key Provisioning for Group Communication using ACE
            Authors         : Francesca Palombini
                              Marco Tiloca
    	Filename        : draft-ietf-ace-key-groupcomm-13.txt
    	Pages           : 78
    	Date            : 2021-07-12

    Abstract:
       This document defines message formats and procedures for requesting
       and distributing group keying material using the ACE framework, to
       protect communications between group members.

    Discussion Venues

       This note is to be removed before publishing as an RFC.

       Source for this draft and an issue tracker can be found at
       https://protect2.fireeye.com/v1/url?k=08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5&q=1&e=fd87b927-3fdc-4d5a-ab71-6248ac68bf5d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm.


    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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ace