See detailed comments in marked up PDF at https://1drv.ms/b/s!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? Clarify. 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 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?