Thanks a lot for your review! Please find in line below our detailed replies to your comments.
A Github PR where we have addressed your comments is available at [PR].
Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -18 of the document.
Thanks,
/Marco
[PR] https://github.com/ace-wg/ace-key-groupcomm/pull/160
On 2023-10-31 17:44, Henry Thompson via
Datatracker wrote:
Reviewer: Henry Thompson Review result: Ready with Issues Document: Key Provisioning for Group Communication using ACE [1] Intended RFC status: Proposed Standard Review type: artart - Last Call review Reviewer: Henry S. Thompson Review Date: 2023-10-@@ Result: Ready with Issues *Summary* Caveat: I'm not familiar with the group comms family of RFCs or the applications they support, so this review is from an outsider's perspective. As such, I am not able to comment on the adequacy of section 4. This is where the details of the Client and KDC interactions are spelled out, and it needs a potential user of this spec. to judge whether they provide the necessary functionality.
==>MT
We have collaborated with current users of this specification (for example draft-ietf-ace-key-groupcomm-oscore and draft-ietf-ace-pubsub-profile), so we think that we have provided necessary functionalities there.
<==
*Substantive points*
Section 2. I'm seeing an inconsistency in the way the Dispatcher is
discussed. When introduced in the bullet points the last bullet says
"If it consists of an explicit entity such as a pub-sub Broker or a
message relayer, the Dispatcher is comparable to an _untrusted_
on-path intermediary, and as such it is _able to read_ the messages
sent by Clients in the group." [emphasis added]
But at the end of section 2 we find
"5. The joining node can communicate _securely_ with the other group
members, using the keying material provided in step 3."
[emphasis added]
If the Dispatcher is untrusted, how can communication be secure?
There is no discussion of the Dispatcher in the Security section.
==>MT
The Dispatcher is untrusted, and as such it does not have the group keying material required to decrypt and tamper with the messages that it dispatches.
To clarify, we have extended the definition of "Dispatched" in Section 2 as follows, per the commit at: https://github.com/ace-wg/ace-key-groupcomm/commit/cf96f68fd10fe5a51423df07a88656c085d1b659
OLD
> Dispatcher: entity through which the Clients communicate with the group, when sending a message intended to multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. A single-recipient message intended to only one group member may be delivered by alternative means, with no assistance from the Dispatcher.
NEW (emphasis mine)
> Dispatcher: entity through which the Clients communicate with the group when sending a message intended to multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. **The Dispatcher does not have access to the group keying material**. A single-recipient message intended to only one group member may be delivered by alternative means, with no assistance from the Dispatcher.
<==
Section 5: I don't see how authority to institute forced deletion is established. Indeed the means for forced deletion don't appear to be defined at all. Section 4.8 (and 4.8.3) explicitly requires that only the Client can send a Delete request, and only for themselves.
==>MT
A node can only trigger its own eviction from the group, by sending a DELETE request to its dedicated resource /ace-group/GROUPNAME/nodes/NODENAME (i.e., "leave the group"). Then it is up to the KDC to rekey to whole group, in such a way that the leaving node does not have access to further communications in the group.
In addition to that:
* No group member is allowed to trigger the eviction of other group members.
* The KDC has full authority, at any time, to evict current group members, with the consequent deletion of the corresponding member-specific resource at /ace-group/GROUPNAME/nodes/NODENAME. Possible reasons and follow-up actions taken by the KDC are discussed in Section 5 "Removal of a Group Member".
* The KDC is expected to determine that a group member has to be evicted either through its own means, or based on information that it obtains from a trusted source (e.g., an Intrusion Detection System, or an issuer of authentication credentials). Additional mechanics, protocols, and interfaces at the KDC that can support this are out of the scope of this document.
<==
*Minor points* Section 1. I note that one of the two referenced examples of candidate application profiles, "A publish-subscribe architecture for the Constrained Application Protocol (CoAP)" [2], has expired. I'm not sure how much it matters to have reasonably mature examples, but without _some_ good reasons to suppose that there's a community out there waiting to implement this framework, its future does seem a bit shaky... There is of course a chicken-and-egg problem here which may explain the lack of progress.
==>MT
draft-ietf-core-coap-pubsub-12 indeed expired. However, a new version -13 was submitted before the cut-off for IETF 118. The work on that document is progressing.
We believe that there is interest for implementing this framework (not only for pubsub, but also for other applications). This has been discussed within the Working Group.
<==
Section 2. This is the first point where the actual connection between ACE and this document is made clear, that is, that the KDC is the Resource Server _per ACE_. Simply adding ", per ACE," to "Resource Server" in para 2 of Section 1 would fix this for me.
==>MT
To clarify, we have extended the second paragraph of Section 1 as follows, by mentioning "ACE" for both the Clients and Resource Server.
OLD
> Candidate group members acting as Clients and authorized to join a group can interact with the Key Distribution Center (KDC) acting as Resource Server and responsible for that group, in order to obtain the necessary keying material and parameters to communicate with other group members.
NEW (emphasis mine)
> Candidate group members acting as **ACE** Clients and authorized to join a group can interact with the Key Distribution Center (KDC) acting as **ACE** Resource Server and responsible for that group, in order to obtain the necessary keying material and parameters to communicate with other group members.
<==
Section 6: It might be helpful to include ASCII-art diagrams of the different communication pathways described for accomplishing rekeying.
==>MT
In Sections 6.1 and 6.2.0, we have added an example each, consisting of an ASCII-art diagram and accompanying text, per the commit at: https://github.com/ace-wg/ace-key-groupcomm/commit/12463deac7c6359340fe3f5263936a2615892a3e
<==
Sections 3.1 & 7: The example scopes include Verifier and Monitor roles. Although there is a parenthetical reference to the [Vv]erifier role in Section 3.3.1, no other mention of Monitor is given, and in general the role of roles is not explained anywhere. There is a "Request inconsistent with the current roles" error code defined in section 9, but no tabulation of roles allowed/required for particular requests, which one might expect. Nor are any REQ or OPT obligations provided to cover this. If all this is something defined in one of the many referenced specs, and so familiar to likely readers, that's OK, otherwise perhaps something should be added.
==>MT
Right, the roles are defined in the application profiles of this specification. Those that you mention are only examples.
Appendix A.1 of the present document defines two requirements on profiles that cover this point:
* REQ1 expects application profiles to fully define the format of scope, including the possible roles in the group.
* REQ11 covers the requirement for the set of roles, their meanings, and aspects such as their pertinence with messages sent to the KDC.
<==
Sections 11.6--11.16: _Seven_ new IANA registries! At a quick count, that's a 50% increase in the number of related (CBOR + COAP) registries. Is there a plan for populating the expert reviewer slots this entails?
==>MT
We are sure that our wonderful AD will find people willing to serve as Designated Experts :)
On a serious note, we believe that the registries are needed and that we are not overextending IANA by creating them.
<==
*Nits* Section 1 / Appendix A: The use of REQ[n] and OPT[n] in conjunction with REQUIRED and MAY is not explained, nor are they linked to the relevant text in Appendix A. There is an oblique reference to this practice in para. 4 of Section 1, which could stand to be expanded to explain your conventions.
==>MT
In Section 1, we have extended the text of the fourth paragraph as follows.
OLD
> In order to ensure consistency and aid the development of such application profiles, this document defines a number of related compliance requirements (see Appendix A).
NEW (emphasis mine)
> In order to ensure consistency and aid the development of such application profiles, **Appendix A of** this document defines a number of related compliance requirements. **In particular, Appendix A.1 compiles the requirements that application profiles are REQUIRED to fulfill; these are referred to by an identifier that starts with "REQ". Instead, Appendix A.2 compiles the requirements that application profiles MAY fulfill; these are referred to by an identifier that starts with "OPT".**
<==
Passim: Please do a thorough spell-check. The following were found in the first 4 sections: recommeded -> recommended memebrs -> members specificaton -> specification acces -> access trasferring -> transferring
==>MT
Right, these will be fixed in the next version -18.
<==
ht
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
