Hi Paul, Thank you for your review, we will start working on it.
When addressing your comments, we will also process a few more recent points tracked as Github issues [0]. In particular:
- Issues 148, 150, and 151 are about editorial fixes/improvements.- Issues 147 is about clarifications, while issue 149 is about fixes in the IANA considerations.
- Issue 146 is about relaxing the now-mandatory inclusion of one parameter in a message.
This issue 146 was first brought up to the WG at the ACE interim meeting on 2022-09-12, further elaborated on its Github entry, and then confirmed at the ACE interim meeting on 2022-12-19.
Best, /Marco [0] https://github.com/ace-wg/ace-key-groupcomm/issues On 2023-09-01 02:26, Paul Wouters wrote:
You don't often get email from paul.wout...@aiven.io. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>Hi, Thanks for this document and my apologies for the long wait time.I think this document is mostly ready to go. I have a few questions and some comments on what I think are changes needed for the IANA Considerations section.1) Race conditions with group rekey Section 2: When a group rekeys so an new member joining won't be able to read old messages, how are race conditions prevented? eg one node wants to send a message, but processes a group rekey, then sends the message it had. Then the new member join is complete and that message can be read by the new member. Section 6: The KDC MUST increment the version number NUM of the current keying material, before distributing the newly generated keying material with version number NUM+1 to the group. So when the KDC increments the version, and starts distributing the new keying material, any client requesting "num" will believe it is behind and request a new copy? Wouldn't this cause duplicate rekeys? I see this is partially addressed in the Security Considerations, but I feel handling these race conditions is part of the actual protocol, not merely a security consideration? 2) IV/counter re-use Section 4: Symmetric keys are shared between group members. How is it prevented that same IVs/counters are used by different members of the group? (there is some talk about Base IV and Partial IV, but that didn't seem to answer my question 3) IANA port registration?optionally together with a port number (which defaults to 5683 if omitted)Is this port going to be registered with IANA ? 4) PoP evidence with own nonce Section 4.5.1: The PoP evidence is computed over the nonce specified in the 'kdc_nonce' parameter and taken as PoP input, by means of the same method used when preparing the Join ResponseWhat is the point of the nonce here? Since the nonce comes from the same party that uses the nonce, it doesn't "prove" anything, eg it could be a replay of a previously observed/triggered nonce. Can you explain what the purpose of the nonce is?Similar in Section 4.9.1.1 where the Client updates its Authentication credential,and uses its own nonce to prove possesion of the private key. COMMENTS: Section 1: If the application requires backward and forward security What is "backward security" ? I assume a new member not seeing old msgs. Maybe explain that? Section 2: The full procedure can be separated The full procedure being "add member to group" ? The overview for "Dispatcher" does not make it clear whether it can read the content to be dispatched from the client, or not. Section 4: As most important operation after trasferring the access token to the KDC, the Client can perform a Join Request-Response exchange with the KDC, by specifying the group it requests to join Should "group" be "group(s)" ? to join the specified group Should "group" be "group(s)" ? /ace-group/GROUPNAME/creds : this resource is invariant once established, and contains the authentication credentials of all the members of the group with name GROUPNAME. How is this "invariant" when it changes depending on group members? Am I misunderstanding the term "invariant" ? Section 4.1 The KDC can provide a list of group names that exist. Can this access be restricted to a partial list depending on the client? Section 4.3.1 Group members MUST stop using the keying material to protect outgoing messages and retrieve new keying material at the time indicated in this field. Don't you mean "retrieve new keying material before this time" and "start using the new key material after this time"? Related in 4.8.1.1 it says: In either case, if it wants to continue participating in the group communication, the node has to request the latest keying material from the KDC. and: if the Client wants to be sure that it has the latest group keying material. If that is the case, the Client will receive from the KDC the same group keying material it already has in memory.Seems to suggest key material is not available before expiry time. That is, there is always a downtime of a few RTTs when the keying material expired, as clients cannot prefetch new keying material ahead of time ? I think it wouldbe a lot more robust if clients could prefetch the new key slightly beforethe expiry time. Then adjust for group membership changes to ensure a rekey is done if the leaving member could (or has) obtained the num+1 keying material?Section 4.8.2: Not providing the Client with newly generated, individual keying material, but rather rekeying the whole groupDoesn't this open up a denial of service possibility with a malicious client? The Security Considerations do warn about this and that requests for rekeyscan be ignored by the KDC, so this is okay. What is "individual keying material" ? Is based on the security association the client <-> KDC have based on the transport protocol? Section 5: A Client identified by NODENAME may be removed from a group identified by GROUPNAME where it is a member, due to the following reasons.I don't think the following list is a complete set of possible reasons. I wouldrephrase this along the lines of "for example, for the following reasons". Section 6: In case the KDC deletes the group, this also allows the KDC to send an unsolicited 4.04 (Not Found) response What does "this" refer to? Making the resource Observable ? Section 6.2.1: COUNT, as a 1-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeying instance, and is incremented after each use of the encryption key. This limits the key to only be used for 256 messages. Is that enough for large groups of thousands of devices? Or are groups to be expected to be smaller? Or should those groups anticipate this and switch to one-to-many rekey methods? Wouldn't 2 bytes create a much larger safety margin at a very little cost? Section 10.2: The KDC should renew the group keying material upon a group membership change. Since the minimum number of group members is one, the KDC should provide also a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC should provide new group keying material also to a Client that remains the only member in the group after the leaving of other group members. Why are these "should"s not normative, eg SHOULDs ? Section 10.2.1 This (finally) addresses my race condition questions.... In any case, the recipient should actively ask the KDC for the latest group keying material according to an application-defined policy, for instance after a given number of unsuccessfully decrypted incoming messages.Seeing that the KDC presumably is hard at work distributing new keying material, would nodes sending more requests to the KDC not just make things worse? Maybe it should also mention that it MUST first verify the signature of the node sending the encrypted payload before deciding it might need to ask for the updated group key material to prevent spoofed messages trying to trigger all clients to send requests to the KDC to overload it ? (I can also see that this is a very obviousthing to do anyway, so perhaps this advise is meaningless) Section 11:The IANA section mentions the IESG as Change Controller, but it is prefered to useIETF instead. (IANA will bug you about this later if not changed)Under which collection/grouping should the a "ACE Groupcomm" registries appear ? Under https://www.iana.org/assignments/ace/ace.xhtml <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Face%2Face.xhtml&data=05%7C01%7Cmarco.tiloca%40ri.se%7C90f845f51ae441a280f808dbaa821350%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638291247875827690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Vh6usMKEgwgUsG%2FxjgtT493TD7%2Fh3o9jI6ZKH0%2B2b6k%3D&reserved=0> or under a sub-registry ace-groupcomm ?Either way, it should be clarified to IANA. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well. Possibly rephrase as:Values in this registry are covered by different registration policies as indicatedSection 11.10 describes this as well, but it does indicate how/when different policies apply.(likely based on the Value field?)Section 11.11 doesn't list the maximum/minimum values (or limiting size of the value)Section 11.13:The IANA Registries established in this document are defined as expert review.It's a bit contentious whether a registry can be Standards Track PLUS Expert Review. Toavoid issues around this, I would remove this entire sentence. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way.I think for all non-private use entries, this is "expected", so I would remove the partstarting at "if they are expected ....". When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.That feels a little odd to me. Not sure this makes much sense, since even FSFC needs a specification. Private use is well, private use. So which registration cases wouldthere be that can leave out a specification? NITS: ** Downref: Normative reference to an Informational RFC: RFC 7967 ** Downref: Normative reference to an Informational RFC: RFC 9053 These downrefs are okay. == Outdated reference: A later version (-19) exists of draft-ietf-core-oscore-groupcomm-14 == Outdated reference: draft-ietf-cose-countersign has been published as RFC 9338 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-countersign'== Outdated reference: draft-ietf-ace-mqtt-tls-profile has been publishedas RFC 9431 == Outdated reference: A later version (-12) exists of draft-ietf-core-coap-pubsub-10 == Outdated reference: A later version (-09) exists of draft-ietf-core-groupcomm-bis-07 == Outdated reference: A later version (-06) exists of draft-ietf-cose-cbor-encoded-cert-04 == Outdated reference: A later version (-13) exists of draft-tiloca-core-oscore-discovery-11These need updating (because of my long time to do my AD review. Again my apologies)typoes/grammer: for those that aim to -> for those that aim for trasferring -> transferingconsistently with the roles it has in the group -> consistent with the roles it has in the group.the handler reply with a -> the handler replies with a Due to different reasons - > [remove entirely] ameliorate -> [pick a different more common term for this] This sentence does not parse: As long as both sides get the new group keying material, updating group the keying material in the middle of a transfer will not cause any issue. retro-compatibility -> backwards compatibility ? Paul
-- 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
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
