Skip to main content

Telechat Review of draft-ietf-ace-key-groupcomm-17

Request Review of draft-ietf-ace-key-groupcomm
Requested revision No specific revision (document currently at 18)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2023-11-23
Requested 2023-10-30
Requested by Éric Vyncke
Authors Francesca Palombini , Marco Tiloca
I-D last updated 2023-11-23
Completed reviews Artart Last Call review of -17 by Henry S. Thompson (diff)
Tsvart Last Call review of -17 by Vidhi Goel (diff)
Genart Last Call review of -17 by Thomas Fossati (diff)
Iotdir Telechat review of -17 by Dave Thaler (diff)
Assignment Reviewer Dave Thaler
State Completed
Request Telechat review on draft-ietf-ace-key-groupcomm by Internet of Things Directorate Assigned
Posted at
Reviewed revision 17 (document currently at 18)
Result Almost ready
Completed 2023-11-23
See detailed comments in marked up PDF at!Aqj-Bj9PNivcn95dv6L8FUsmfqCzfA?e=eFgWDp

A summary of the non-trivial comments follows...

Security issues:
Section 3.3:
> The KDC MUST store the 'kdcchallenge' value associated with the
> Client at least until it receives a Join Request from it 

It seems to be that this can be used in a DOS attack, where a Client
sends a bunch of token requests without join requests.  

Or even NON-attacks that just happen where a Client crashes after
the token request and so never sends a join request...
when can the KDC clean up state?  This seems like a critical
thing to discuss.  Seems like you need the KDC to have a way to
clean up stale state.

For the intentional DoS attack, section 10.2 only mentions:
> The KDC needs to have a mechanism in place to detect DoS attacks from
> nodes repeatedly performing actions that might trigger a group
> rekeying.

I’d recommend covering state-based DOS attacks as well such as
mentioned above, with the same mitigation possible as already
mentioned in 10.2.

IoT Issues:
Section 4.3.1:
> Group members MUST NOT use
> the keying material after the time indicated in this field

So this introduces a requirement that all Clients MUST have a clock
and a clock synchronization (to UTC) mechanism?
This seems burdensome for constrained nodes, so should be called out explicitly.

Remote attestation (as specified in the RATS WG) on the other hand,
allows alternative mechanisms that use nonces or handle distributors,
to accommodate constrained nodes that either have no clock or no
ability to synchronize it with UTC.  In contrast, draft-ietf-ace-key-groupcomm
does not seem amenable to such constrained nodes and as such I think it
should be accompanied by an applicability statement (e.g., in the
introduction or abstract) that says that this document is ONLT applicable
to nodes with a clock that is synchronized to UTC, rather than implying
it is usable by “constrained nodes” in general as the draft -17 abstract
currently implies.

Section 6.2:
>  This yields an overall lower number of rekeying messages, thus
>  potentially reducing the overall time required to rekey the group.
>  On the other hand, it requires the KDC to provide and use additional
>  administrative keying material to protect the rekeying messages, and
>  to additionally sign them to ensure source authentication (see
>  Section 6.2.1).  Typically, this pays off in large-scale groups,
>  where the introduced performance overhead is less than the one
>  experienced by rekeying the group in a point-to-point fashion (see
>  Section 6.1).

Question: It may be less at the KDC, but would it be more overhead
at the Clients which may be constrained nodes on battery power?

Internationalization issues:
Section 1.1:
>  *  GROUPNAME: the invariant once established text string used in
>     URIs.  GROUPNAME uniquely maps to the group name of a group,
>     although they do not necessarily coincide.

Is this meant for human display, or *only* as part of a URI?
If meant for human display, then how do you communicate what language it is in?
Same question about NODENAME.

Section 4.1.2:
> *  'error_description', with value a CBOR text string specifying a
>     human-readable diagnostic description of the error occurred at the
>     KDC, written in English.  The diagnostic text is intended for
>     software engineers as well as for device and network operators, in
>     order to aid debugging and provide context for possible
>     intervention.

The "written in English" arguably violates IETF internationalization guidance.
The "intended for software engineers" part is probably fine but not the
"for device a network operators" part.

One should not assume that device and network operators read English.
Any text meant for human operator display should be localizable and have a
language tag indicating what language the string is in.

Section 4.2.1:
> *  'gname', whose value is encoded as a CBOR array, containing zero
>     or more group names.  The elements of this array are encoded as
>     text strings.

In what language? (and if not required to be in English, then they
cannot be guaranteed to be displayed correctly unless a language tag
is also provided)

URI issues:
Section 4.1:
> Note that the root url-path "ace-group" used hereafter is a default
> name

Why not use “.well-known/ace-group” and register it as a well-known path?

Clarity issues:
Section 3.1 says including ‘scope’ in an Authorization Request is a MAY.
Section 3.2 on the Authorization Response then says:
> Additionally, when included, the following parameter MUST have the
> corresponding values:
>  *  'scope' has the same format and encoding of 'scope' in the
>     Authorization Request, defined in Section 3.1.  If this parameter
>     is not present, the granted scope is equal to the one requested in
>     Section 3.1.

So what is the granted scope when scope was absent in the Authorization Request?

Furthermore, it then goes on to say:

>  The proof-of-possession access token (in 'access_token' above) MUST
>  contain the following parameters:
>  *  a scope claim (see for example 'scope' registered in Section 8.14
>     of [RFC9200] for CWT).
>     This claim specifies the same access control information as in the
>     'scope' parameter of the Authorization Response, if the parameter
>     is present in the message, or as in the 'scope' parameter of the
>     Authorization Request otherwise.

Again, the Authorization Request section allows it to be absent.
Is section 3.1 wrong, or is this text wrong?

Section 4.3.1:
> If, regardless the reason, the KDC replies with a 4.00 (Bad Request)
> error response, this response MAY have Content-Format set to
> application/ace-groupcomm+cbor and have a CBOR map as payload.

Does this mean Content-Format normally has some other value,
since this is only a MAY? I.e., it’s not obvious to me what the
alternative is to this MAY.

> *  If the application requires backward security or if the used
>    application profile prescribes so, the KDC MUST generate new group
>    keying material and securely distribute it to the current group
>    members (see Section 6).

How does the KDC know whether this is the case?
Clarify or provide a “(see <reference> for more details)” if explained elsewhere.

Section 4.6.1:
> In addition to what is defined in Section 4.1.2, the handler verifies
> that the Client is a current member of the group. 

To confirm: Since this statement does not appear in the preceding sections,
does that mean those requests do not require the Client to be a member of the group?