Re: [Ace] AD review draft-ietf-ace-key-groupcomm-16

[Marco Tiloca <[e-mail]>]

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 [e-mail]. 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 Response
>
> What 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 
> would
> be a lot more robust if clients could prefetch the new key slightly before
> the 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 group
>
> Doesn't this open up a denial of service possibility with a malicious 
> client?
> The Security Considerations do warn about this and that requests for 
> rekeys
> can 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 would
> rephrase 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 obvious
> thing 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 use
> IETF 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 indicated
>
> Section 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. To
> avoid 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 part
> starting 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 would
> there 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 
> published
>      as 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-11
>
> These 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 -> transfering
>
> consistently 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: [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