[Ace] draft-ietf-ace-key-groupcomm-oscore-18 ietf last call Genart review

[Russ Housley via Datatracker <[e-mail]>]

Document: draft-ietf-ace-key-groupcomm-oscore
Title: Key Management for Group Object Security for Constrained RESTful
Environments (Group OSCORE) Using Authentication and Authorization for
Constrained Environments (ACE) Reviewer: Russ Housley Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-ace-key-groupcomm-oscore-18
Reviewer: Russ Housley
Review Date: 2025-09-16
IETF LC End Date: 2025-09-25
IESG Telechat date: Not scheduled for a telechat

Summary: Not Ready

Major Concerns:

This document builds upon so many other documents.  To me, more is
needed than the last paragraph in Section 1.  It would help to add
something to the Introduction that explains how they all fit together.
A diagram would be extremely helpful, but I am not sure that is possible.

Minor Concerns:

Section 1.1: It would have been useful to me to include the Gid and
Birth Gid concepts from [I-D.ietf-core-oscore-groupcomm].

Section 2 says:

   All communications between the involved entities (Client, Group
   Manager, Authorization Server) MUST be secured.

I expected this to say how they are secured.  This MUST statement does
not tell an implementer what to do.  The details come in the next
paragraph.  I suggest replacing this MUST statement with an introduction
to the following paragraph.  I would make them one paragraph as well.

Section 3 describes the computation of the R value.  I think the reader
would more quickly understand the algorithm if it was described as a
bitmask carried in a CBOR unsigned integer.

In Section 6.3, the text about the HKDF parameter is confusing.  Is the
hash function named, or is the HMAC algorithm named?  The default is
neither one of these choices (HKDF SHA-256), which adds to the confusion.
The example in Figure 4 shows "HMAC with SHA-256", which seems like the
intent is to name the HMAC algorithm.

Section 6.3 says:

   This parameter MUST be present if and only if the node does not join
   the OSCORE group exclusively with the role of monitor, ...

Please reword.  This is a very complex way of saying that the parameter
MUST be present if the node has at least one role other than monitor.

Section 9.1.1 says that "The 'exp' parameter SHOULD be present."  Please
provide the consequences if the 'exp' parameter is not present.

Section 9.1.2 says that "The 'exp' parameter SHOULD be present."  Please
provide the consequences if the 'exp' parameter is not present.

In Section 14.1, the text about the HKDF parameter is confusing.  Based
on the example in Figure 4, which shows "HMAC with SHA-256", the HMAC
algorithm should be discussed as the default.

In Section 16.1, the formatting does not make it clear that two OAuth
parameters are being registered.  Please make two sets of bullets.

In Section 16.3, the formatting does not make it clear that five ACE
Groupcomm parameters are being registered.  Please make five sets of
bullets.

In Section 16.6, the group_SenderId entry does not include a registry,
but the other entries in this section do so.

In Section 16.6, the formatting does not make it clear that six ACE
OSCORE Security Context parameters are being registered.  Please make
six sets of bullets.

In Section 16.8, the formatting does not make it clear that two AIF
Media-Type sub-parameters are being registered.  Please make two sets
of bullets.

In Section 16.9, the formatting does not make it clear that two
CoAP Content-Formats are being registered.  Please make two sets of
bullets.

In Section 16.9, the formatting does not make it clear that three
ACE Groupcomm Errors are being registered.  Please make three sets of
bullets.

Nits:

Section 4: I suggest rewording:

  OLD:
      The joining node is currently a group member acting not
      exclusively as monitor, and it is re-joining the group not
      exclusively as monitor.
  NEW:
      The joining node is currently a group member with at least
      one role other than monitor, and it is re-joining the group
      with at least one role other than monitor.

Section 5.3: s/an 8-byte long random nonce/an 8-byte random nonce/

Section 5.3: s/Consistently with Section/To align with Section/ (twice)

Section 5.3.2: s/to join or interact with/to join or monitor/ (twice)

Section 6.1: s/an 8-byte long random nonce/an 8-byte random nonce/

Section 6.1: s/that could have happened/proof-of-possession could occur/

Section 6.1: s/In either case, the N_S/The N_S/

Section 6.1: s/HKDF Algorithm HKDF SHA-256/HKDF Algorithm with SHA-256/

Section 6.2: s/In such a case /In such a case, /

Section 6.2: s/stored value (if any)/stored value, if any/

Section 8.6: s/newly defined earlier in Section 8/defined in Section 8/

Section 9.5.2: s/an 8-byte long random nonce/an 8-byte random nonce/

Section 9.10: s/Furthermore, since it/Since the signature verifier node/

Section 10: s/not exclusively the role of/at least one role other than/

Section 15.2: s/an 8-byte long random nonce/an 8-byte random nonce/

Section 15.2: s/take 8-byte long values/take 8-byte random values/

Note:

I did not review the Appendices.