Hello Paul, We have just submitted version -14 to address your AD review. Please find in line below our replies to your comments.
This version also addresses the following points: * Aligned with increasingly common expectations and with the recommendations in draft-opsarea-rfc5706bis, we have added a new section "Operational Considerations", right before the section "Security Considerations". * The parameter 'gp_enc_alg' from draft-ietf-ace-key-groupcomm-oscore is now called with that name in this document too, thus resolving a long-time pending Editor's note. * Two CoAP error response codes have been fixed, to use more appropriate ones (code 4.05 in Section 6; code 4.00 in Section 6.8). * Minor fixes in the examples of message payloads (registered and placeholder codepoints) and in the example algorithm of Appendix A. * Minor clarifications and editorial fixes, largely building on applicable feedback from the IETF Last Call of draft-ietf-ace-key-groupcomm-oscore. Best, /Marco ________________________________ From: Paul Wouters <[email protected]> Sent: Wednesday, October 1, 2025 4:47 AM To: Ace Wg <[email protected]> Subject: [Ace] AD review of draft-ietf-ace-oscore-gm-admin-13 AD review of draft-ietf-ace-oscore-gm-admin-13 Thanks for this document. All in all it is very clear. I do have some questions and comments/nits: TLS version this can rely on DTLS [RFC9147] as per [RFC9202] Does this mean it requires DTLS 1.3, or is DTLS 1.2 allowed? Should this be made more explicit? ==>MT The DTLS profile of ACE specified in RFC 9202 does cover both DTLS 1.2 and DTLS 1.3. However, the text of the quoted paragraph talks more specifically of the secure communication protocol used between two involved entities, pointing to DTLS as an example and without normative recommendations. In other words, the focus of that sentence is about the possible use of the DTLS protocol, rather than the DTLS profile of ACE. Since there was no specific need to mention exactly DTLS 1.2, we followed the (good?) practice of omitting RFC 6347, as obsoleted by RFC 9147. To be aligned with what the DTLS profile of ACE offers, we have extended the quoted sentence in Section 1.1 to also use the informative reference to RFC 6347, i.e.: NEW > ... this can rely on DTLS [RFC6347][RFC9147] as per [RFC9202] ... Note that, later on in Section 4, two sentences mentioning DTLS only refer to RFC 9147, per the same rationale used when writing the quoted original text from Section 1.1. <== Default values and their use While the defaults use RECOMMENDED, things like Section 6.6 state the value from defaults MUST be used. It is a little unclear to me what this means when the RECOMMENDED value was not used. Should it use the different value or the RECOMMENDED to comply to the MUST ? ==>MT Quoting text from Section 6.6 for context: > For each other parameter not specified in the POST request, the Group Manager > MUST use default values as specified in Section 5.2. Agreed that the original text is misleading. The intent is that the Group Manager refers to the default values in Section 5.2, where it is said that such default values SHOULD be used. As also stated in Section 5.2, the Group Manager might have reasons to deviate from the recommended default values and thus MAY choose different values to use as default ones. Here in Section 6.6, the text should be revised to use the same wording of Section 6.3 about the same topic. That is, Section 6.3 says: > For each parameter not specified in the request, the Group Manager refers to > the default values specified in Section 5.2. With that in mind and aiming for additional editorial consistency, we have rephrased the text in both Sections 6.3 and 6.6 to use exactly the same wording: OLD (Section 6.3) > For each parameter not specified in the request, the Group Manager refers to > the default values specified in Section 5.2. OLD (Section 6.6) > For each other parameter not specified in the POST request, the Group Manager > MUST use default values as specified in Section 5.2. NEW (Sections 6.3 and 6.6) > For each parameter not specified in the POST request, the Group Manager > refers to default values as specified in Section 5.2. For additional clarity, we have also rephrased related text in other sections when referring to recommended default values, to point exactly to Section 5.2.1 and Section 5.2.2 where those recommended values are defined. That is: OLD (Section 6.3) > ... and the Group Manager used default values different from the ones > recommended in Section 5.2, ... NEW (Section 6.3) > ... and the Group Manager used default values different from the ones > recommended in Section 5.2.1 and Section 5.2.2, ... OLD (Section 6.3) > ... or the corresponding default value recommended in Section 5.2.1 otherwise. NEW (Section 6.3) > ... or the corresponding default value recommended in Section 5.2.1 or > Section 5.2.2 otherwise. OLD (Section 6.6) > ... and the Group Manager used default values different from the ones > recommended in Section 5.2, ... NEW (Section 6.6) > ... and the Group Manager used default values different from the ones > recommended in Section 5.2.1 and Section 5.2.2, ... OLD (Section 6.6) > ... or the corresponding default value recommended in Section 5.2.1 otherwise. NEW (Section 6.6) > ... or the corresponding default value recommended in Section 5.2.1 or > Section 5.2.2 otherwise. <== Fix reference on draft-amsuess-core-cachable-oscore det_hash_alg refers to draft-amsuess-core-cachable-oscore but this should be draft-ietf-core-cacheable-oscore. ==>MT Fixed. We have also fixed the reference draft-ietf-ace-revoked-token-notification, which is now RFC 9770. <== default values This section defines the default values that the Group Manager uses for the configuration and status parameters. But the next sentence says these are the RECOMMENDED values. So perhaps it should say that here too? ==>MT Aligned with the update made to address a previous comment about Section 6.6, we have rephrased the text here in Section 5.2 as below. OLD > This section defines the default values that the Group Manager uses for the > configuration and status parameters. > > The Group Manager MAY choose different default values instead of those > recommended in this section. A possible reason is ... NEW (emphasis mine) > This section defines the default values that the Group Manager **refers to** > for the configuration and status parameters. **In particular, Section 5.2.1 > and Section 5.2.2 define the default values that are RECOMMENDED to use for > the configuration and status parameters, respectively.** > > **Exceptionally, the** Group Manager MAY choose different default values > instead of those recommended in **Section 5.2.1 and Section 5.2.2**. A > possible reason is ... <== Section 6.6.1 Why is this listed here? Isn't this regular operation unrelated to this document? ==>MT It is good to have this content here for completeness and to build a clear relationship with the other interface specified in draft-ietf-ace-key-groupcomm-oscore. At the same time, it is true that the text in Section 6.6.1 of the present document does not define new behavior, and therefore it should avoid normative language. We have rephrased the first paragraph as below: OLD > After having overwritten a group configuration, if the value of the status > parameter 'active' is changed from true (0xf5) to false (0xf4), the Group > Manager MUST stop admitting new members in the OSCORE group. In particular, > until the status parameter 'active' is changed back to true (0xf5), the Group > Manager MUST respond to a Join Request with a 5.03 (Service Unavailable) > response, as defined in Section 6.2 of [I-D.ietf-ace-key-groupcomm-oscore]. NEW (emphasis mine) > After having overwritten a group configuration, if the value of the status > parameter 'active' is changed from true (0xf5) to false (0xf4) **and thus the > group becomes inactive**, the Group Manager **stops** admitting new members > in the OSCORE group. In particular, until the status parameter 'active' is > changed back to true (0xf5) **and thus the group becomes active again**, the > Group Manager **replies** to a Join Request with a 5.03 (Service Unavailable) > response, as defined in Section 6.2 of [I-D.ietf-ace-key-groupcomm-oscore]. (Through the document, we have consistently replaced "respond" with "reply") <== Section 6.6.2 6.6.2 also repeats this text: If the value of the status parameter 'active' is changed from true (0xf5) to false (0xf4): The Group Manager MUST stop accepting requests for new individual keying material from current group members Should this not read that the group members MUST stop sending requests ? If not, why is this text repeated from 6.6.1? Note that it does say so in the second bullet point: * Every group member, upon learning that the OSCORE group has been deactivated (i.e., 'active' has value false (0xf4)), SHOULD stop communicating in the group. then: Every group member, upon learning that the OSCORE group has been reactivated (i.e., 'active' has value true (0xf5) again), can resume communicating in the group. Am I correct in that group members "learn" this via the pairwise connection with the GNM by requesting a LIST command filtered by Active state? ==>MT Note that Section 6.6.1 refers to nodes that are not group members, hence its considerations are limited to stopping those nodes from joining an inactive group. Instead, Section 6.6.2 is about group members, hence its considerations cover the broader set of operations that those nodes can normally perform with the Group Manager and with one another. If the status parameter 'active' is changed from true (0xf5) to false (0xf4) and thus the group becomes inactive, it's not simply that group members "MUST stop sending requests". They have to stop communicating with one another, and they have to stop sending to the Group Manager the two types of request that are specifically mentioned in the text. However, they can send other types of requests to the Group Manager as per the interface defined in draft-ietf-ace-key-groupcomm-oscore, e.g., in order to learn when the group becomes active again or to leave the group. Specifically regarding a group member that learns about the group becoming active again: * The group member does rely on the pairwise secure communication association that it has with the Group Manager. * The group member does **not** rely on any operation for the interface defined in the present document (which is intended for Administrators). The operation to learn about the current status of the group with name GROUPNAME is defined in Section 9.9 of draft-ietf-ace-key-groupcomm-oscore , i.e., a GET request to the resource /ace-group/GROUPNAME/active at the Group Manager. Just to clarify: an Administrator can effectively retrieve the current status of a group with name GROUPNAME by retrieving the 'active' status parameter from the group configuration. The Administrator does that by sending a GET or a FETCH request to the /manage/GROUPNAME resource at the Group Manager (see Sections 6.4 and 6.5 of the present document). With the above in mind and in the same spirit of the update that addresses the previous comment about Section 6.6.1, we have also rephrased the text in Section 6.6.2 as below. OLD > * If the value of the status parameter 'active' is changed from true (0xf5) > to false (0xf4): > > - The Group Manager MUST stop accepting requests for new individual keying > material from current group members (see Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' is > changed back to true (0xf5). Until then, the Group Manager MUST respond to a > Key Renewal Request with a 5.03 (Service Unavailable) response, as defined in > Section 9.2 of [I-D.ietf-ace-key-groupcomm-oscore]. > > - The Group Manager MUST stop accepting updated authentication credentials > uploaded by current group members (see Section 9.4 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' is > changed back to true (0xf5). Until then, the Group Manager MUST respond to an > Authentication Credential Update Request with a 5.03 (Service Unavailable) > response, as defined in Section 9.4 of [I-D.ietf-ace-key-groupcomm-oscore]. > > * Every group member, upon learning that the OSCORE group has been > deactivated (i.e., 'active' has value false (0xf4)), SHOULD stop > communicating in the group. > > Every group member, upon learning that the OSCORE group has been > reactivated (i.e., 'active' has value true (0xf5) again), can resume > communicating in the group. NEW (emphasis mine) > * If the value of the status parameter 'active' is changed from true (0xf5) > to false (0xf4) **and thus the group becomes inactive**: > > - The Group Manager **stops** accepting requests for new individual keying > material from current group members (see Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' is > changed back to true (0xf5) **and thus the group becomes active again**. > Until then, the Group Manager **replies** to a Key Renewal Request with a > 5.03 (Service Unavailable) response, as defined in Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]. > > - The Group Manager **stops** accepting updated authentication credentials > uploaded by current group members (see Section 9.4 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' is > changed back to true (0xf5) **and thus the group becomes active again**. > Until then, the Group Manager **replies** to an Authentication Credential > Update Request with a 5.03 (Service Unavailable) response, as defined in > Section 9.4 of [I-D.ietf-ace-key-groupcomm-oscore]. > > * Every group member, upon learning that the OSCORE group has been > deactivated (i.e., 'active' has value false (0xf4)), **stops sending messages > to other group members and stops processing messages from other group > members, until the group becomes active again. In the meantime, the group > member can still interact with the Group Manager, e.g., in order to check > whether the group has become active again**. > > Every group member, upon learning that the OSCORE group has been > reactivated (i.e., 'active' has value true (0xf5) again), can resume **taking > part in communications with other group members (i.e., sending messages and > processing incoming messages)**. > > **A group member can learn about the current group status of a group with > group name GROUPNAME by accessing the /ace-group/GROUPNAME/active resource at > the Group Manager, as specified in Section 9.9 of > [I-D.ietf-ace-key-groupcomm-oscore]. Optionally, the group member may > subscribe for updates to such a resource, e.g., by using CoAP Observe > [RFC7641].** The wording above is aligned with how a previous comment was addressed in draft-ietf-ace-key-groupcomm-oscore, to not erroneously suggest that a group member has to stop communicating also with the Group Manager. (Through the document, we have consistently replaced "respond" with "reply") <== Section 6.8 Otherwise, the Group Manager continues processing the request, I am not sure where this "Otherwise" comes from. Eg if "otherwise" is the "else" part, what was the "if" part? What part of the processing was done before this statement was reached? ==>MT When re-reading the document before processing this review, indeed we noticed that the quoted paragraph and the immediately following one did not read well. Besides the "Otherwise" issue raised in this comment, the error handling described by the two paragraphs was not presented in a clean and linear way. Consequently, we have rephrased the fourth and fifth paragraphs of Section 6.8 as below: OLD > Otherwise, the Group Manager continues processing the request, which MUST > fail it the OSCORE group is active. That is, the DELETE request MUST yield > the deletion of the OSCORE group only if the corresponding status parameter > 'active' has current value false (0xf4). The Administrator can ensure that, > by first performing an update of the group-configuration resource associated > with the OSCORE group (see Section 6.6 and Section 6.7), and setting the > corresponding status parameter 'active' to false (0xf4). > > If, upon receiving the DELETE request, the current value of the status > parameter 'active' is true (0xf5), the Group Manager MUST respond with a 4.09 > (Conflict) response. The response MUST have Content-Format set to > application/concise-problem-details+cbor [RFC9290] and is formatted as > defined in Section 4.1.2 of [RFC9594]. Within the Custom Problem Detail entry > 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 10 > ("Group currently active"). NEW > If the OSCORE group is active, i.e., the current value of the status > parameter 'active' is true (0xf5), then the request MUST fail and the Group > Manager MUST reply with a 4.00 (Bad Request) response. The response MUST have > Content-Format set to "application/concise-problem-details+cbor" [RFC9290] > and is formatted as defined in Section 4.1.2 of [RFC9594]. Within the Custom > Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field > MUST be set to 10 ("Group currently active"). > > That is, the request yields the deletion of the OSCORE group only if the > OSCORE group is inactive, i.e., the corresponding status parameter 'active' > has current value false (0xf4). The Administrator can ensure that, by first > performing an update of the group-configuration resource associated with the > OSCORE group (see Section 6.6 and Section 6.7) and setting the corresponding > status parameter 'active' to false (0xf4). Note that this update includes also a fix to the error response code, i.e., from 4.09 (Conflict) to the most appropriate 4.00 (Bad Request). Also note that a similar spurious "Otherwise" was present at the beginning of the fourth paragraph of Section 6.4, i.e., "Otherwise, after a successful processing of the GET request, ...". We have fixed that by simply starting the sentence as "After a successful processing of the GET request, ..." <== I wonder if [I-D.amsuess-core-cachable-oscore] should be normative? ==>MT Like discussed and agreed on the mailing list [0], we have kept the reference informative. As also proposed, we have improved the three instances of a related sentence, in Sections 5.1.1 and 6.6.2: OLD > ... as defined in [I-D.amsuess-core-cachable-oscore] NEW > ... (see [I-D.ietf-core-cacheable-oscore]) [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ <== [I-D.tiloca-core-oscore-discovery] is definitly normative. ==>MT Like discussed and agreed on the mailing list [0], we have kept the reference informative. As also proposed, we have updated two sentences as below. * In Section 6.3, rephrased as below: OLD > The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory [RFC9176], as defined in Section 2 of [I-D.tiloca-core-oscore-discovery]. NEW (emphasis mine) > The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory [RFC9176], **e.g., by using the approach described in** [I-D.tiloca-core-oscore-discovery]. * In Section 6.6, removed the reference altogether, i.e.: OLD > If the link to the group-membership resource was registered in the Resource Directory [RFC9176], the Group Manager is responsible to refresh the registration, as defined in Section 3 of [I-D.tiloca-core-oscore-discovery]. NEW > If the link to the group-membership resource was registered in the Resource Directory [RFC9176], the Group Manager is responsible to refresh the registration. [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ <== RFC9176 is probably normative too ==>MT Like discussed and agreed on the mailing list [0], we have changed the reference to be normative. [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ <== NITS: The Constrained Application Protocol (CoAP) [RFC7252] can also be used for group communication [I-D.ietf-core-groupcomm-bis], where messages are exchanged between members of a group I would remove "also" and the comma before "where. ==>MT Fixed like suggested. <== as well as how it should be configured and later on updated or deleted, e.g., based on the current application state or pre-installed policies I had to read this a few times.. how abour "and later on how it should be updated or deleted" ==>MT We agree that the original text can be simplified. At the same time, the suggested new text as-is risks to miss the specific point about configuration upon creation. Building on the suggestion, we have rephrased as below: OLD > In some deployments, the application running on the Group Manager may know > when a new OSCORE group has to be created, as well as how it should be > configured and later on updated or deleted, e.g., based on the current > application state or pre-installed policies. NEW (emphasis mine) > In some deployments, the application running on the Group Manager may know > when a new OSCORE group has to be created, **how the group should be > configured upon creation, and later on how the group should be updated or > deleted, e.g., based on the current application state or pre-installed > policies**. <== and is poorly flexible and is not very flexible. ==>MT Fixed like suggested. <==
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
