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

[Yoav Nir 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: Yoav Nir Review result: Has Issues

This is a very complex document, which relies on several other documents (RFCs
9594, 9200, 9203, 9202), all of whom are mentioned in the first paragraph of
the Security Considerations section, plus draft-ietf-core-oscore-groupcomm,
which is not. Much of the security considerations are inherited from those
other documents.

Section 15.1 goes over some security properties and points to sections in the
CORE document that describe them. And here it becomes unclear. The first bullet
point is about rekeying, and it points to section 12.2 of the CORE document
that is about rekeying. It mentions that the group manager is responsible for
rekeying, and that it should rekey if a member leaves the group in the
interests of forward secrecy, and according to policy maybe also when a node
joins the group for backward security. OK. Are these the only reasons to rekey?
Are there regular rekeys? Don't know. The text is silent.  The second bullet
point says that the GM is the repository for credentials. But that is stated
explicitly in section 12 of the CORE document, so why is it a security
consideration in this companion document?

The penultimate paragraph of section 15.1 says that "the Group Manager MUST
verify that the joining node actually owns the associated private key" and to
do that, if should follow the procedure in section 6. I find it strange that
section 6 has the technical details, but not the reason behind them - to verify
that the node actually owns the private key. Yes, section 6 uses the term
"PoP". Still strange.

The last paragraph of section 15.1 is about dealing with duplicate Gids from
different GMs. It advises to try the different security contexts one after the
other until the right one is found, but does not specify how it knows that the
right one has been found. Presumably, the AEAD decryption validates?

Section 15.2 has a bunch of recommendations about the size of the nonces. It
uses a lot of RFC2119 language and seems to repeat a lot of things form section
5 on generating nonces.

Section 15.3 looks fine, except that I'm not convinced (and neither are
dictionaries) that "reusage" is a word.