Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-18
Yes
Paul Wouters
No Objection
Jim Guichard
John Scudder
(Andrew Alston)
(Robert Wilton)
Abstain
Recuse
Note: This ballot was opened for revision 17 and is now closed.
Paul Wouters
Yes
Erik Kline
No Objection
Comment
(2023-11-24 for -17)
Sent
# Internet AD comments for draft-ietf-ace-key-groupcomm-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S6 * What is the real meaning behind: The KDC can perform a group rekeying before the current group keying material expires, unless it is acceptable or there are reasons to temporarily pause secure communications in the group, following the expiration of the current keying material. Specifically: when is it acceptable to "pause secure communications"?
Jim Guichard
No Objection
John Scudder
No Objection
Roman Danyliw
No Objection
Comment
(2023-11-17 for -17)
Sent
** Section 1.1. Per the definition of “Group name” and GROUPNAME. The latter is defined as a “text string used in a URIs”. The former has no definition beyond saying it is an identifier. Is it not a text string? ** Section 1.1. * Individual keying material: information exclusively pertaining to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be a member identifier that is unique within the group. -- unlike group and node identifier, member identifier is not defined -- how is a member identifier an example of “keying material”? Is it an identifier for a key? ** Section 2. Per the comment “Defined in the ACE framework” in Figure 2, which framework is this text referencing? This document? RFC9200? ** Section 3.1. Editorial * 'scope', specifying the name of the groups that the Client requests to access, Should this be “name_s_ of the groups ...”? Otherwise, it reads as if there is a single name for a collection of groups. ** Section 3.1 * 'audience', with an identifier of the KDC. The definition of audience from Section 5.8.1 of RFC9200 points to RFC8693 (OAuth’s definition of audience). It says: ==[ snip ]== The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the resource parameter but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both the client and the authorization server understand. ==[ snip ]== Does the application profile have to specify the semantics of this audience value (just like the scope parameter)? ** Section 5. 2. The node has been found compromised or is suspected so. What triggers this behavior in #2? How does the KDC know about compromise? Can Clients tell it that? Can a Client evict another Client? ** Section 6.2.1. Reading this text as normative guidance seemed odd since the parent section 6.2 stated that the specifics of one-to-many is effectively out of scope and this document only provides high level guidance. ** Section 10. Security considerations are inherited from the ACE framework [RFC9200], and from the specific transport profile of ACE used between the Clients and the KDC, e.g., [RFC9202] and [RFC9203]. And from application profiles too which specify the details of the keys and tokens? ** Section 10 Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. ... Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, or after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods. The first sentence seems to be encouraging rekeying but subsequent text points out that this might not be reasonable. Should the initial “SHOULD” text be harmonized with this other more nuanced guidance? ** Typos -- Section 1. Typo. s/recommeded/recommended/ -- Section 2. Typo. s/membrs/members/ -- Section 3.1. Typo. s/ specificaton/specification/ -- Section 3.3.1. Typo. s/acces/access/ -- Section 4. Typo. s/trasferring/transferring/
Warren Kumari
No Objection
Comment
(2023-11-29 for -17)
Sent
Thank you for writing this document - I found it both useful, and an easy read. I do have a nit / readability suggestion: "New keying material is generated and distributed to the group upon membership changes (rekeying), if the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining) and forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving)." I found this wording confusing - I think that it is the comma after "upon membership changes (rekeying)". This initially sounds like "new keys are generated on every membership change. If the application requires backward security then [something else / something additional". I *think* that just dropping the comma fixes it... You also have a typo: "It is REQUIRED of application profiles of this specificaton to" - specification.
Zaheduzzaman Sarker
No Objection
Comment
(2023-11-28 for -17)
Sent
Thanks for working on this document. Thanks Vidhi Goel for the TSVART review. However, I have noticed this review didn't get any responses from the authors or wg. Please respond. I have hard time understanding the example used for individual keying material. what is this "member identifier" ? where is this defined?
Éric Vyncke
Abstain
Comment
(2023-11-30 for -17)
Sent
I am balloting ABSTAIN as I had no time to review it on my own, but I am trusting the IoT-directorate "almost ready" review by Dave Thaler: https://datatracker.ietf.org/doc/review-ietf-ace-key-groupcomm-17-iotdir-telechat-thaler-2023-11-23/ Dave's review has identified issues in the security and IoT domains that I could not verify (lack of time) but it would help a lot if the authors replied to Dave's review.
Francesca Palombini
Recuse
Comment
(2023-10-23 for -17)
Not sent
It is mine
Andrew Alston Former IESG member
No Objection
No Objection
(for -17)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2023-11-28 for -17)
Sent
Thanks to Vidhi Goel for the TSVART review. (2) "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." Is this accurate? Why does the Dispatcher need the group key to relay messages? (3.3) s/since it allows to ask/since it allows the client to ask
Robert Wilton Former IESG member
No Objection
No Objection
(for -17)
Not sent