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

[Paul Wouters <[e-mail]>]

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 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