Hello Yoav, Thanks a lot for your review and apologies for the long time taken to reply. Please find in line below our detailed replies to your comments.
A GitHub PR where we have addressed your comments is available at [PR]. Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -19 of the document. Thanks, /Marco [PR] https://github.com/ace-wg/ace-key-groupcomm-oscore/pull/94 ________________________________ From: Yoav Nir via Datatracker <[email protected]> Sent: Wednesday, September 24, 2025 11:15 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: draft-ietf-ace-key-groupcomm-oscore-18 ietf last call Secdir review 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. ==>MT We have received a similar comment on the relationships between this document and related documents, in the GENART review archived at https://mailarchive.ietf.org/arch/msg/ace/Q_jhrS8xpFTMEm2PXvBCh3QRoBs/ When addressing that comment, we extended Section 1 "Introduction", by replacing the original final paragraph with a longer explanation that should better put the documents in relation with one another. After that text, we have also included a diagram that shows the relationships between this document and related documents. The old text and new text in Section 1 are shown below. The new text together with the diagram is also available at the updated Editor's copy that addresses the GENART review, see https://ace-wg.github.io/ace-key-groupcomm-oscore/genart-review/draft-ietf-ace-key-groupcomm-oscore.html#section-1 In order to minimize conflicts when merging Pull Requests on GitHub, we have not made the same updates also in the PR addressing this SECDIR review. OLD > This document is an application profile of [RFC9594], which itself builds on > the Authentication and Authorization for Constrained Environments (ACE) > framework [RFC9200]. Message exchanges among the participants as well as > message formats and processing follow what is specified in [RFC9594], and > enable the provisioning and renewing of keying material in group > communication scenarios, where Group OSCORE is used to protect CoAP group > communication. NEW > Building on the Authentication and Authorization for Constrained Environments > (ACE) framework [RFC9200], the document [RFC9594] defines how to request, > distribute, and renew keying material and configuration parameters to protect > message exchanges in a group communication environment. That is, candidate > group members that act as ACE Clients and are authorized to join a group can > interact with a Key Distribution Center (KDC) that acts as ACE Resource > Server and is responsible for the group. The KDC provides the necessary > keying material and parameters to communicate with other group members. > > While [RFC9594] defines the operations and interface available at the KDC, as > well as general message formats for the interactions between Clients and the > KDC, it delegates details on the communication and security approaches used > in a group to separate application profiles. These are specialized instances > of [RFC9594] that target a particular group communication approach and define > how communications in the group are protected, as well as the specific keying > material and configuration parameters provided to group members. > > This document specifies an application profile of [RFC9594]. Message > exchanges among the participants as well as message formats and processing > follow what is specified in [RFC9594], and enable the provisioning and > renewing of keying material in group communication scenarios, where Group > OSCORE is used to protect CoAP group communication. In particular, network > nodes that wish to join an OSCORE group act as ACE Clients, while the Group > Manager responsible for managing the OSCORE group is the KDC acting as ACE > Resource Server. > > This application profile leverages protocol-specific transport profiles of > ACE (e.g., [RFC9202][RFC9203]), in order to achieve communication security, > server authentication, and proof of possession for a key owned by the Client > and bound to an OAuth 2.0 access token. <== 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? ==>MT As to the group rekeying, building on the requirements from draft-ietf-core-oscore-groupcomm, the normative behavior of this ACE-based Group Manager is not defined in Section 15.1 of the present document, but rather in Section 7 of the present document. That is, Section 7 specifies that the Group Manager MUST rekey the group: * When one or more nodes leave the group. * When a node joins the group, if the application requires backward security. * When extending the secure group operation, if the expiration time for the group keying material approaches or has passed. In its last paragraph, Section 7 also says: > The Group Manager MAY rekey the group for other reasons, e.g., according to > an application-specific rekeying period or scheduling. So, indeed, regular/scheduled rekeying instances are pertinent and can occur according to application-specific policies. For completeness and clarity, we have updated the text in Section 15.1 as below: OLD > The Group Manager performs a rekeying when one or more members leave the > group, thus preserving forward security and ensuring that the security > properties of Group OSCORE are fulfilled. According to the specific > application requirements, the Group Manager can also rekey the group upon a > new node's joining, in case backward security has also to be preserved. NEW (emphasis mine) > **As defined in Section 7**, the Group Manager performs a rekeying when one > or more members leave the group, thus preserving forward security and > ensuring that the security properties of Group OSCORE are fulfilled. > According to the specific application requirements, the Group Manager can > also rekey the group upon a new node's joining, in case backward security has > also to be preserved. **The Group Manager can also rekey the group for > further reasons, e.g., according to an application-specific rekeying period > or scheduling.** Regarding the second bullet point in Section 15.1, quoting some text for context: > This profile leverages the following management aspects related to OSCORE > groups and discussed in the sections of [I-D.ietf-core-oscore-groupcomm] > referred below. > ... > * Provisioning and retrieval of authentication credentials (see Section 12 of > [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as repository of > authentication credentials of group members, and provides them upon request. As mentioned in the paragraph "This profile leverages ..." that opens the section, this text is mainly intended to position the ACE-based Group Manager defined in this document with respect to expectations set by the Group OSCORE protocol in draft-ietf-core-oscore-groupcomm. With particular reference to the Group Manager acting as repository for the public authentication credentials of the group members, that's indeed already defined in draft-ietf-core-oscore-groupcomm from the perspective of the Group OSCORE protocol, irrespective of the specific realization of Group Manager. However, the present document is first of all an application profile of RFC 9594, which defines a general Key Distribution Center (KDC) entity. In that definition, it is optional for the KDC to act as a repository of authentication credentials of group members. Therefore, it feels appropriate to explicitly highlight that this particular instance of KDC acts as a repository of authentication credentials, which is of course aligned with related operations defined in previous sections of the present 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. ==>MT Beyond Section 6 referred to in Section 15.1, this comment actually applies to multiple sections in the document, where a node or the Group Manager computes a PoP evidence to prove the possession of its own private key. In those sections, we have updated the text as below. OLD (Section 6.1) > ... that the joining node intends to use in the group. NEW (Section 6.1) > ... that the joining node intends to use in the group. That is, the joining > node might have already proven the possession of its own private key to the > Group Manager. OLD (Section 6.1) > If the conditions above do not hold or the joining node prefers to compute a > non-empty PoP evidence, then the joining node proceeds as follows. NEW (Section 6.1) > If the conditions above do not hold or the joining node prefers to compute a > non-empty PoP evidence, then the joining node proceeds as follows to prove > the possession of its own private key. OLD (Section 6.3) > ..., specifying the proof-of-possession (PoP) evidence computed by the Group > Manager. NEW (Section 6.3) > ..., specifying the proof-of-possession (PoP) evidence computed by the Group > Manager to prove the possession of its own private key. OLD (Section 8.1.1) > ... together with a proof-of-possession (PoP) evidence. NEW (Section 8.1.1) > ... together with a proof-of-possession (PoP) evidence as a proof that the > Group Manager possesses its own private key. OLD (Section 9.4) > The group member computes the proof-of-possession (PoP) evidence ... NEW (Section 9.4) > To prove the possession of its own private key, the group member computes the > proof-of-possession (PoP) evidence ... OLD (Section 9.5.1) > ... evidence included in 'kdc_cred_verify' (REQ21). NEW (Section 9.5.1) > ... evidence included in 'kdc_cred_verify' (REQ21) that the Group Manager > uses to prove the possession of its own private key. OLD (Section 9.5.2) > ... The 'kdc_cred_verify' field specifies the PoP evidence computed by the > Group Manager over the following PoP input: ... NEW (Section 9.5.2) > ... The 'kdc_cred_verify' field specifies the PoP evidence computed by the > Group Manager to prove the possession of its own private key. The Group > Manager computes the PoP evidence over the following PoP input: ... <== 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? ==>MT Yes, although it can be phrased in a more general way. We have updated the text as below. OLD > It is up to the application to decide how to handle such collisions of Group > Identifiers, e.g., by trying to process the incoming message using one > Security Context at the time until the right one is found. NEW (emphasis mine) > It is up to the application to decide how to handle such collisions of Group > Identifiers, e.g., by trying to process the incoming message using one > Security Context at the time until the right one is found **(i.e., the > incoming message is successfully decrypted and verified)**. <== 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. ==>MT We believe that it is worth having the recommendation on size and randomness of nonces also in the related security considerations, which also helps follow the discussion in the final bullet list of Section 15.2. On the same topic, the same approach was actually taken in other documents, e.g., see RFC 9203 in its Sections 4.1 (first paragraph) and 4.2 (second paragraph), and then its later Section 7 (fifth paragraph). Note that, when addressing follow-up comments from the AD review, we updated the text in the Editor's copy on GitHub about the size and randomness of nonces, now mentioned as two distinct aspects. For example, the first sentence of the second paragraph now reads: > As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is > RECOMMENDED to be a random value. <== Section 15.3 looks fine, except that I'm not convinced (and neither are dictionaries) that "reusage" is a word. ==>MT Thanks! We have replaced "reusage" with "reuse" in: * Section 6.1.1 (last paragraph) * Section 15.3 (title) * Appendix D.13 (third from last bullet point) <==
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
