Re: [Last-Call] Artart last call review of draft-ietf-ace-key-groupcomm-17

[Marco Tiloca <[e-mail]>]

Hello Henry,

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

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se