Hello Thomas, 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], with the corresponding Editor's Copy available at [EDITOR-COPY]. 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/95 [EDITOR-COPY] https://ace-wg.github.io/ace-key-groupcomm-oscore/opsdir-review/draft-ietf-ace-key-groupcomm-oscore.html ________________________________ From: Thomas Graf via Datatracker <[email protected]> Sent: Sunday, September 28, 2025 9:21 AM 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 Opsdir 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: Thomas Graf Review result: Not Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational and manageability aspects of the IETF drafts. This documents defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework which depends on the following specifications: - RFC 7252 for Constrained Application Protocol specification - RFC 8613 for Object Security for Constrained RESTful Environments - RFC 9052 and 9053 for CBOR Object Signing and Encryption - RFC 9200 for Authentication and Authorization - RFC 9254 for Key Provisioning for Group Communication - draft-ietf-core-oscore-groupcomm for Group Object Security I have been studying these documents, its relationships in order to understand how operational and manageability aspects are addressed to understand how draft-ietf-ace-key-groupcomm-oscore as application profile for authentication and authorization fit in and failed to do so because none of the above mentioned documents describe the operational and manageability aspect as described in https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-opsarea-rfc5706bis%23section-3&data=05%7C02%7Cmarco.tiloca%40ri.se%7C793946eec49d41b7b59808ddfe5faff7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638946409129663192%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WOFjV0ekCJrDYw%2FjmOp8K2rP7KYXZMRYD0lMcpFAITY%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-opsarea-rfc5706bis#section-3>. To my current understanding, none of these documents describe or refer to configuration models or how the defined protocols and mechanisms can be monitored. ==>MT Thanks for your comment! Also as part of addressing later, related comments in this review, we have updated the present document by adding a dedicated "Operational Considerations" section, as per Section 3.1 of draft-opsarea-rfc5706bis (and Section 3.1 of the latest draft-ietf-opsawg-rfc5706bis), Like recommended in Section 3.3 of draft-opsarea-rfc5706bis (and in Section 3.3 of the latest draft-ietf-opsawg-rfc5706bis), we have placed the new "Operational Considerations" section immediately before the "Security Considerations" section. Some side points regarding other related documents: * When addressing the GENART review archived at https://mailarchive.ietf.org/arch/msg/ace/Q_jhrS8xpFTMEm2PXvBCh3QRoBs/ , we extended Section 1 "Introduction", by replacing the original final paragraph with a longer explanation that should better put in relation with one another the present document and the documents that it builds on. After that text, we have also included a diagram that shows the relationships between the present document and related documents. 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 OPSDIR review. * Specifically regarding the "configuration" of the Group Manager, a possible method to accomplish that and to administer the Group Manager in an interoperable way is specified in draft-ietf-ace-oscore-gm-admin. The Group Manager specified in the present document can make use of that method but does not require it or build on it (hence, it is not mentioned upfront). While that method does not have to be the one to be used, it is already mentioned in the present document as a possible way to administer the Group Manager (see, e.g., the second from last paragraph of Section 3, the last paragraph of Section 8.2.1, and the first paragraph of Section 14). In the present document, the newly added "Operational Considerations" section explicitly mentions the method specified in draft-ietf-ace-oscore-gm-admin, in the context of administration of the Group Manager and its OSCORE groups. <== Here my feedback to the document: In section 1.1 terminology, the term "Monitor" is being defined and referred to "silent server" in draft-ietf-core-oscore-groupcomm. Why is a different term being used? Both document fails to describe the role and intend of that function. For instance in "Signature verifier" it states "intended to verify the signature of messages exchanged". ==>MT Section 1.1 "Terminology" defines the following four terms: * "requester" * "responder" * "monitor" * "signature verifier" These are all roles **with respect to the Group OSCORE protocol**, i.e., not with respect to an application or operational task. In the Group OSCORE protocol, a node with the role "signature verifier" has indeed the intent of (i.e., is deployed as intended for) verifying the signature of messages protected with the group mode, while not being a member of the group. A node with any of the roles "requester", "responder", or "monitor" does not have a specific intent implied by its role(s). As defined in Section 1.1, the roles reflect the behavior that a node has as a group member with respect to using the Group OSCORE protocol, i.e.: * A requester sends request messages protected with Group OSCORE. * A responder receives request messages protected with Group OSCORE and may reply back with responses protected with Group OSCORE. * A monitor is a responder that never sends responses protected with Group OSCORE. Again, this "monitor" role does not have a specific, implied intent. In particular, it does not have an implied relation with a potential application role that an entity can take as a "network probe", in order to assess operations in the network. That sort of role is orthogonal to the Group OSCORE protocol and the distribution of keying material for Group OSCORE using ACE. Hence, the characterization of that role is out of the scope for the documents specifying Group OSCORE and its key provisioning. Regarding the specific word "monitor", it was chosen to deliberately avoid any role name using the word "server". In the context of the ACE framework and its use in the present document, it is clearer and appropriate to use the word "server" only for the Authorization Server issuing access tokens and a Resource Server consuming access tokens (here the Group Manager). Any other node that obtains an access token and uploads it to the Group Manager is referred to as Client (i.e., ACE Client). Consequently, unless otherwise specified and absolutely needed (e.g., see "CoAP server" in Section 12), we use the words "client" and "server" as per their intended meaning in ACE. The role "monitor" avoids confusion with the ACE terminology and does reflect the Group OSCORE behavior of a group member with that role. Therefore, we think that the word "monitor" serves us well here, and there is no ambiguity in its one-to-one analogy with the term "silent server" used in draft-ietf-core-oscore-groupcomm, as highlighted in Section 1.1 of the present document. <== In section 2 it describes "A network node can join an OSCORE group by interacting with the responsible Group Manager. Once registered in the group". My understanding is based from reading RFC 9594 that the intent is to support multiple application profiles where draft-ietf-ace-key-groupcomm-oscore describes one. ==>MT >From the point of view of RFC 9594, the intent is to provide a common >blueprint that can be used to specify multiple application profiles for >distributing keying material for group communication using the ACE framework. >At the moment, one application profile is defined in the present document and >another one is defined in draft-ietf-ace-coap-pubsub-profile. >From the point of view of a KDC, it is possible that the same KDC supports >multiple application profiles of RFC 9594. However, each security group at the >KDC works in accordance with a single, pertinent application profile. <== The documents misses to describe under normal operation: - How can network operation verify which network nodes joined an OSCORE group successfully and which application profile has been used? - How can network operation determine that there were unsuccessful attempts in the past and from which network nodes at which time. - How does "Monitor" resp. "silent server" contribute to a troubleshooting process? ==>MT **Regarding the first two points** The new "Operational Considerations" section covers those points. In practice, the Group Manager can log any interactions occurred with its resources, especially the interactions that have resulted in a successful or failed joining of a group. Like also explained when addressing a previous comment, each security group GROUPNAME at the Group Manager works in accordance with a single, pertinent application profile. That is, the group-membership resource at /ace-group/GROUPNAME where Join Request messages are sent also relates to the application profile used in the group GROUPNAME. (Also note that the application profile used in the group GROUPNAME is further indicated by the parameter 'ace_groupcomm_profile' within the Join Response message, which the Group Manager sends as a reply to a Join Request message that targeted the resource /ace-group/GROUPNAME and that resulted in a successful joining of the group.) Relevant log entries can be made accessible to authorized third parties and network operators (e.g., through direct retrieval from the Group Manager or automatic notifications sent by the Group Manager), although the specific means to achieve that are out of the scope of the present document. **Regarding the third and last point** For a group member, having the role "monitor" is not meant to be related to contributing to a troubleshooting process. Like also explained when addressing a previous comment, this "monitor" role does not have a specific, implied intent. In particular, it does not have an implied relation with a potential application role that an entity can take as a "network probe", in order to assess operations in the network, e.g., in order to perform a troubleshooting process. <== Throughout the document error codes such as https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-oscore-18%23section-6.2&data=05%7C02%7Cmarco.tiloca%40ri.se%7C793946eec49d41b7b59808ddfe5faff7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638946409129694850%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KemarWndcxl6sPNFzyhBMhBA7YoDdiRUsf5Exr5c8lU%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-18#section-6.2> - The Group Manager MUST reply with a 5.03 (Service Unavailable) error response in the following cases - The Group Manager MUST reply with a 4.00 (Bad Request) error response in the following cases: - the Group Manager MAY reply with a 4.00 (Bad Request) error response in case all the following conditions hold: are used but no references are given where those error codes are being defined. To my understanding they relate to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7252%23section-5.9&data=05%7C02%7Cmarco.tiloca%40ri.se%7C793946eec49d41b7b59808ddfe5faff7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638946409129710364%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Zx5mXhGkOnzVCm27YmphJlr8uv5GSxBdooctizzVfII%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc7252#section-5.9> and a description in section 2, "Protocol Overview", describing that Response Code Definitions from https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7252%23section-5.9&data=05%7C02%7Cmarco.tiloca%40ri.se%7C793946eec49d41b7b59808ddfe5faff7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638946409129724674%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=k37zh2elQzMOcNxLL2EyzMUSKhs25FTTQ%2BcW1cvyrpY%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc7252#section-5.9> are used, is required to understand error code meaning and relationship to the CoAP protocol. ==>MT Although the present document uses CoAP error response codes that are all defined in Section 5.9 of RFC 7252, there are also response codes that are defined in other RFCs and are ultimately listed in the IANA registry "CoAP Response Codes", within the "Constrained RESTful Environments (CoRE) Parameters" registry group (see https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#response-codes ). Indeed, it is required to understand the meaning of CoAP response codes (i.e., both success response codes and error response codes), in the interest of effectively using CoAP altogether. Aligned with RFCs developed in the ACE WG that use CoAP (including RFC 9200 and RFC 9594), we do not think that it is required or helpful to explicitly describe in the present document that the response code definitions from Section 5.9 of RFC 7252 are used. The present document leverages the semantics of error response codes just like RFC 9594, which does not provide such pointers either. Error response codes are such a core element of CoAP that it has to be considered as part of the basic understanding of the protocol. That is, error response codes take part in the fundamental building of a CoAP error response message. Since it is clear upfront that CoAP is used and Section 1.1 says that familiarity is expected with the terms and concepts from RFC 7252, we believe that an implementer will not be surprised, confused, or lost when reading that, e.g., a CoAP error response with response code 5.03 has to be composed. (Similar considerations apply to the REST methods that can be used in a CoAP request, most of which are defined in Section 5.8 of RFC 7252, and a few more are defined in RFC 8132. Those methods are such a core element of CoAP that it has to be considered as part of the basic understanding of the protocol.) <== What is unclear to me is how besides a CoAP client an operator would have visibility in the individual errors, are they logged?, or how an operator could obtain a statistical view on the errors occurring. For an statistical example, the CoAP Management Interface, https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-comi-20%23section-6&data=05%7C02%7Cmarco.tiloca%40ri.se%7C793946eec49d41b7b59808ddfe5faff7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638946409129738231%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DKsND620%2FUKiUKyK0GLMNQofunIf4sibrmiazyLCeX0%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-20#section-6> describes the error handling and how they are represented statistically in a data model. To my current understanding, this is missing in context of the Authentication and Authorization for Constrained Environments (ACE) framework. ==>MT Like also explained when addressing a previous comment, the new "Operational Considerations" section covers this point too. In practice, the Group Manager can log any interactions occurred with its resources, including the interactions that have resulted in an error. Relevant log entries can be made accessible to authorized third parties and network operators (e.g., through direct retrieval from the Group Manager or automatic notifications sent by the Group Manager), although the specific means to achieve that are out of the scope of the present document. Other points that are out of scope of the present document are the specific semantics and data models that are used to represent and process the logged information (including for producing statistical views at the Group Manager or at third parties). Such means have not been defined in the context of ACE, and they can be defined by applications and future specifications, possibly in such a way that their applicability is general, i.e., it is not limited to this and other uses of ACE. <== Best wishes Thomas Graf
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
