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.
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.
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.
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.
At the end of section 1: .... [RFC8152], like Authorization Server (AS)
and Resource Server (RS).
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.
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.
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.
What is the difference between "adding node to group" and "distribution
of keying material". I find the phrase difficult to understand.
Figure 2 : I suggest to add Group Member (GM) as communication entity.
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.
Section 3.
Remove: "where the RDC takes the role of RS".
Suggest to add the message exchange before section 3.1
POST --- Authorization Request (application/CBOR) ---->
<-- Authorization Response (???? ) -----
It would be nice if here the use of DTLS (or not) and the content format
is specified: application/cbor or application/Cose+cbor
section 3.1
scope: with as values the group identifier and optionally the role ....
"The encoding of the group identifier and the role(s) is application
specific."
cnf: Optionally, the public key or the certificate of the client
Question: is this a certificate identifier, or the public key extracted
from the certificate, or a hash?????
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.
For topic and role see section 3.1
section 3.3:
same request response figure as suggested in section 3 before section
3.1
"a different endpoint" is very vague. Please explain.
section 4:
/The same types of messages can also be/the same set of messages is/
just before section 4.1 same figure and information as requested in
section 3 before section 3.1
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?
scope: remove topic; what resource is referred to?
get_pub_keys: Instead of empty CBOR array, an empty payload is also
possible?
client_cred: same question on certificate as for section 3.1
below figure 3
/additionally/Optionally/
The parameters group_policies and mgt_key_material are not specified in
pubsub-profile draft. Do you ever use them?
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.
section 6
/not able to participate to/not able to receive or decrypt/
section 6.1
scope: same remarks about topic and group identifier.
"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.
Section 7
Again suggest to add figure with request before section 7.1
scope: same comment on group identifier and topic.
_____________________________________________________
Hope this helps,
greetings,
Peter
--
Peter van der Stok
vanderstok consultancy
mailto: [email protected], [email protected]
www: www.vanderstok.org [1]
tel NL: +31(0)492474673 F: +33(0)966015248
Links:
------
[1] http://www.vanderstok.org
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
