Re: [Ace] Fwd: review of palombini-ace-key-groupcomm

[Francesca Palombini <[e-mail]>]

Hi Peter,

Thanks a lot for this detailed review! We have uploaded a new version that includes (most of) your comments:https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02

Detailed replies and some questions inline (see FP in red below).

Thanks,
Francesca

From: Ace <[e-mail]<mailto:[e-mail]>> on behalf of Peter van der Stok <[e-mail]<mailto:[e-mail]>>
Organization: vanderstok consultancy
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 31 July 2018 at 10:52
To: Ace Wg <[e-mail]<mailto:[e-mail]>>
Subject: [Ace] Fwd: review of palombini-ace-key-groupcomm

Hi key-groupcomm authors,

To start the review I have looked at the dependencies between the different involved drafts and came up with the figure below.

[cid:[e-mail]]
The arrows indicate that a draft references another draft. The dots reference arrow means Informative reference. According to me, this means that the work on CORE can proceed independently of the work in ACE. The oscoap-join and key-groupcomm can proceed together to their conclusion without other dependencies. That guarantees that we can develop the group communication drafts in ACE without unwanted dependencies on pubsub. The pubsub-profile depends on core-pusub and key-groupcomm, which does not bother me too much.


FP: That is absolutely correct, the group communication drafts do not depend on the pubsub work, and can be move forward without dependencies.

Keeping this in mind, I have reviewed the key-groupcomm draft.

BTW, it might be helpful to include a similar overview in the oscoap-join draft.

________________________________________________________________

Abstract
OLD:This document defines a message format for distributing keying
material in group communication scenarios (such as based on multicast
or publisher-subscriber model) using the ACE framework.

NEW:This document defines a message format for distributing keying
material to groups to protect the communication between group members using the ACE framework.


FP: we started with your input and reformulated to:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.

Introduction
OLD: Profiles that use group communication can build on this document to specify exactly which of the message parameters defined in this documents are used, and what are their values.

NEW: Profiles that use group communication can build on this document to specify a selection of the message parameters defined in this document and their values.


FP: we included this with the smallest difference:
   Profiles that use group communication can build on this document to
   specify the selection of the message parameters defined in this
   document to use and their values.


At the end of section 1: .... [RFC8152], like Authorization Server (AS) and Resource Server (RS).
FP: Ok, added.


[cid:[e-mail]]
Figure 1 is not referenced in the text. I suggest a slightly different figure where dispatcher and KDC are endpoints of the RS, and for multicast the communication is directly between Client and group members without passing through the RS.


FP: We have now referenced the figure in the text. We have not modified the pictures, since we are not sure the change simplifies it. Reading the proposed figure, it seems like KDC and Dispatcher are logical entities in the same physical entity (the RS), which is not correct.
Key Distribution Center (KDC): Maintains the keying material to protect group communications, and provides keys to clients authorized to join the group. It corresponds to an endpoint of the RS in the ACE Framework.
FP: We have now rephrased based on your and Jims inputs:
o  Key Distribution Center (KDC): maintains the keying material to
      protect group communications, and provides it to Clients
      authorized to join the group.  During the first part of the
      exchange (Section 3<https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02#section-3>), it takes the role of the RS in the ACE
      Framework.
Also, it is worth noting that in this document we use the term “endpoint” as defined in ACE (equivalent to “resource” in CoAP), which is different from the “endpoint” term in CoRE/CoAP.

Dispatcher: this is the entity the Client wants to securely
communicate with and is responsible for distribution of group
messages. Example dispatchers are the Broker in a pub-sub setting or the generator of unicast messages to all group members for group communication.
Alternatively, Group communication is done by transmitting to a multicast IP address, and entrusting message delivery to the transport channels between Client and Group members.


FP: We don’t think “generator” is the best word, the true generator would still be the group member, so we replaced that with relayer. Including the comments from Jim, this gives:
   o  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.


What is the difference between "adding node to group" and "distribution of keying material". I find the phrase difficult to understand.


FP: Assuming this was about the title of section 4, we rephrased that to “Authorization to Join a Group”.

Figure 2 : I suggest to add Group Member (GM) as communication entity.
FP: Good idea, it is now included.


At the end of section 2, I suggest some text on group identifier and role identifier, such that these terms can be used independent of the application profiles specified in other documents.


FP: I am not sure why do you think these terms (which appear first in section 3.1) are not independent of the application profiles specified in other documents. Could you please expand on that?

Section 3.

Remove: "where the RDC takes the role of RS".
FP: Ok, done.

Suggest to add the message exchange before section 3.1

POST --- Authorization Request (application/CBOR) ---->
<-- Authorization Response (???? ) -----


FP: We have now added message exchanges as suggested, although for lack of space we only include name of the message, CoAP Code or Method and the uri if applicable.

It would be nice if here the use of DTLS (or not) and the content format is specified: application/cbor or application/Cose+cbor
FP: that would really be profile specific, so we have not specified it here.


section 3.1
scope: with as values the group identifier and optionally the role ....
FP: added optionally.


"The encoding of the group identifier and the role(s) is application specific."
FP: thanks, rephrased to match your suggestion:
      The encoding of the group or topic identifier and of the role
      identifiers is application specific.


cnf: Optionally, the public key or the certificate of the client
FP: Right, thanks


Question: is this a certificate identifier, or the public key extracted from the certificate, or a hash?????
FP: This is defined in other documents of ACE, see draft-ietf-ace-cwt-proof-of-possession-03 sections 3.2 and 3.4


section 3.2:
0 access token containing all the parameters defined below; This is very confusing. I understood that access token parameter is at same level as cnf, rs_cnf, and exp. And here you write that they are contained in access token. If that is true, I suggest to make the other three parameter sub-bullets of access-token bullet.
FP: We have tried to improve this the following way: The access_token bullet only says that it contains the access token. After the bullet list (and all the parameters are listed), we specify:
   The access token MUST contain all the parameters defined above
   (including the same 'scope' as in this message, if present, or the
   'scope' of the Authorization Request otherwise), and additionally
   other optional parameters the profile requires.


For topic and role see section 3.1
FP: Ok, same fix applied.

section 3.3:
same request response figure as suggested in section 3 before section 3.1
FP: This is part of the figure 3, in section 3.

"a different endpoint" is very vague. Please explain.
FP: Rephrased to: “the Client MAY use a different endpoint than /authz-info”
Again, this derives from the use of “endpoint” as ACE defines it.

section 4:

/The same types of messages can also be/the same set of messages is/


FP: Partly included. We keep the “can also be”, since we leave it to the application to decide to use or not use these mechanisms. We want to allow for flexibility.

just before section 4.1 same figure and information as requested in section 3 before section 3.1
FP: Done now in section 4, see figure 4.


section 4.1
"....request to the endpoint in the KDC associated..." Not clear what is meant:
- one endpoint for all groups?
- one endpoint per group?
- one endpoint per subset of groups?


FP: We meant one endpoint (or resource) pre group, which the Client knows via the Scope (it is “associated” to it). We do not say that the endpoint has the same value as the group identifier, it might be something derived from it. We have now tried to clarify by rephrasing:  This
   corresponds to a CoAP POST request to the endpoint in the KDC
   associated to the group to join.  The endpoint in the KDC is
   associated to the 'scope' value of the Authorization Request/
   Response.

scope: remove topic; what resource is referred to?


FP: rephrased to:
   o  'scope', with value the specific resource that the Client is
      authorized to access (i.e. group or topic identifier) and role(s),
      encoded as in Section 3.1<https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02#section-3.1>.


get_pub_keys: Instead of empty CBOR array, an empty payload is also possible?
FP: Probably payload is wrong. If you meant empty byte string, yes that was also possible, but we tried to be consistent with the format of get_pub_keys used afterward.


client_cred: same question on certificate as for section 3.1
FP: see previous answer


below figure 3
/additionally/Optionally/
FP: Ok, done.


The parameters group_policies and mgt_key_material are not specified in pubsub-profile draft. Do you ever use them?
FP: We do use them in the joining draft. They are relevant for the pubsub draft, but I haven’t gotten them in yet.


Section 5.2
"NOte that .... leaving node" It is not clear if the client has left the group in this case, and what that means. The actions look quite contradictory to me.
FP: We have now rephrased:
   Note that, after having left the group, a node may wish to join it
   again.  Then, as long as the node is still authorized to join the
   group, i.e. it has a still valid access token, it can re-request to
   join the group directly to the KDC without needing to retrieve a new
   access token from the AS.  This means that the KDC needs to keep
   track of nodes with valid access tokens, before deleting all
   information about the leaving node.



section 6
/not able to participate to/not able to receive or decrypt/
FP: Ok, done

section 6.1
scope: same remarks about topic and group identifier.
FP: Same question as above


"In some cases ... same KDC". Suggest to remove. In a fast changing environment, this may lead to many error messages if not wrong behavior; Imagine group GA is the only group. C is member of GA. GA is removed and GB is entered as the only group. C wants to leave/join GA, and accesses GB.
FP: Thanks for this input, this makes sense. We have now removed this text and made the “scope” parameter mandatory.


Section 7
Again suggest to add figure with request before section 7.1


FP: Ok, added in section 7 (figure 6)

scope: same comment on group identifier and topic.
FP: same question


_____________________________________________________

Hope this helps,
FP: It helps a lot, thanks! :)


greetings,

Peter


--
Peter van der Stok
vanderstok consultancy
mailto: [e-mail]<mailto:[e-mail]>,[e-mail]<mailto:[e-mail]>
www: www.vanderstok.org<http://www.vanderstok.org>
tel NL: [phone]     F: [phone]