Hello Russ, 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/93 ________________________________ From: Russ Housley via Datatracker <[email protected]> Sent: Tuesday, September 16, 2025 4:49 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 Genart 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: Russ Housley Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmarco.tiloca%40ri.se%7C748cdf9225464103d04308ddf53047e1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638936309913987363%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BTqOIK2QkB8cTopPPLXPbrLidyMXaeAHd0LmOV8mXbw%3D&reserved=0<https://wiki.ietf.org/en/group/gen/GenArtFAQ>>. Document: draft-ietf-ace-key-groupcomm-oscore-18 Reviewer: Russ Housley Review Date: 2025-09-16 IETF LC End Date: 2025-09-25 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready Major Concerns: This document builds upon so many other documents. To me, more is needed than the last paragraph in Section 1. It would help to add something to the Introduction that explains how they all fit together. A diagram would be extremely helpful, but I am not sure that is possible. ==>MT Thanks for this comment. The final paragraph of Section 1.0 is admittedly quite short for fairly introducing the related ACE documents. As below, we have replaced the old final paragraph with a longer explanation that should better put the related documents in relation with one another. 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. Consistent with this text, Section 1.0 now also includes a diagram that shows the relationships between this document and related documents, see https://ace-wg.github.io/ace-key-groupcomm-oscore/genart-review/draft-ietf-ace-key-groupcomm-oscore.html#section-1 <== Minor Concerns: Section 1.1: It would have been useful to me to include the Gid and Birth Gid concepts from [I-D.ietf-core-oscore-groupcomm]. ==>MT With minor editorial adjustments, we have reused the definitions from Section 1.1 of draft-ietf-core-oscore-groupcomm and added those in Section 1.1 of the present document, between the definitions of "Group Manager" and "Authentication credential": > - Group Identifier (Gid): identifier assigned to an OSCORE group, unique > within the set of groups of a given Group Manager. The Gid value changes > every time the OSCORE group is rekeyed. > > - Birth Gid: with respect to a group member, the Gid obtained by that group > member upon (re-)joining the OSCORE group. <== Section 2 says: All communications between the involved entities (Client, Group Manager, Authorization Server) MUST be secured. I expected this to say how they are secured. This MUST statement does not tell an implementer what to do. The details come in the next paragraph. I suggest replacing this MUST statement with an introduction to the following paragraph. I would make them one paragraph as well. ==>MT It's certainly good to merge the two paragraphs and be clearer upfront about what has to be done (i.e., using a transport profile of ACE for secure communication between the parties). With that in mind and some rephrasing, it's actually good to keep the MUST, in the same spirit of what RFC 9594 says in its Section 2: > This exchange between the Client and AS MUST be secured, as specified by the > transport profile of ACE used between the Client and KDC. > ... > The joining node transfers authentication and authorization information to > the KDC by transferring > ... > Once this exchange is completed, the joining node MUST have a secure > communication association established with the KDC before joining a group > under that KDC. > > This exchange and the following secure communications between the Client and > the KDC MUST occur in accordance with the transport profile of ACE used > between the Client and KDC, ... Building on the above, we have rephrased as follows: OLD > All communications between the involved entities (Client, Group Manager, > Authorization Server) MUST be secured. > > In particular, communications between the Client and the Group Manager > leverage protocol-specific transport profiles of ACE to achieve communication > security, proof of possession, and server authentication (REQ24). It is > expected that, in the commonly referred base-case of this document, the > transport profile to use is pre-configured and well-known to nodes > participating in constrained applications. NEW > All communications between the involved entities (Client, Group Manager, > Authorization Server) MUST occur and be secured in accordance with the > protocol-specific transport profile of ACE used. In particular, > communications between the Client and the Group Manager leverage transport > profiles of ACE to achieve communication security, proof of possession, and > server authentication (REQ24). It is expected that, in the commonly referred > base-case of this document, the transport profile to use is pre-configured > and well-known to nodes participating in constrained applications. <== Section 3 describes the computation of the R value. I think the reader would more quickly understand the algorithm if it was described as a bitmask carried in a CBOR unsigned integer. ==>MT Section 3 of RFC 9237 defining AIF uses the following phrasing when defining the data model for simple REST authorization: > The set of numbers is converted into a single number REST-method-set by > taking two to the power of each (decremented) method number and computing the > inclusive OR of the binary representations of all the power values. In this document, the final step of the algorithm computing R says: > The set of N numbers is converted into the single value R, by taking two to > the power of each numeric identifier X_1, X_2, ..., X_N, and then computing > the inclusive OR of the binary representations of all the power values. So we are intentionally using a parlance as close as possible to the one that RFC 9237 uses when defining the data model for simple REST authorization. Furthermore, the R value encoded by the CBOR unsigned integer Tperm is not really a bitmask. It is simply a set of flags indicating permissions. Conversely, the producer (consumer) of R can use an appropriate bitmask in order to set (check) the bits of interest in R as needed. Therefore, we prefer to keep the current text. <== In Section 6.3, the text about the HKDF parameter is confusing. Is the hash function named, or is the HMAC algorithm named? The default is neither one of these choices (HKDF SHA-256), which adds to the confusion. The example in Figure 4 shows "HMAC with SHA-256", which seems like the intent is to name the HMAC algorithm. ==>MT Quoting the text in question: > The 'hkdf' parameter, if present, specifies the HKDF Algorithm that is used > in the OSCORE group. The HKDF Algorithm is specified by the HMAC Algorithm > value. This parameter MAY be omitted, if the HKDF Algorithm used in the group > is HKDF SHA-256. Otherwise, this parameter MUST be present. Note that the text refers to "HKDF Algorithm" (e.g., HKDF SHA-256) and "HMAC Algorithm" (e.g., HMAC 256/256), but not to "hash function" (e.g., SHA-256). In Section 6.3, the parameter 'hkdf' is in turn specified within the parameter 'key'. The 'key' parameter has as value a Group_OSCORE_Input_Material object, which is defined in the present document and extends the OSCORE_Input_Material object encoded in CBOR as defined in Section 3.2.1 of RFC 9203. By using the OSCORE_Input_Material object, Section 3.2 of RFC 9203 says: > Additionally, the AS MAY send the following data, in the same response. > > ... > > * an HMAC-based key derivation function (HKDF) algorithm [RFC5869]. It is > specified by the HMAC algorithm value; see Section 3.1 of [RFC9053]. The present document is building on that choice made in RFC 9203. That is: * The HKDF Algorithm is **named** in the text by its plain name, e.g., "HKDF SHA-256". * The HKDF Algorithm is **denoted** in parameter values (e.g., in a corresponding ACE parameter) by the corresponding HMAC Algorithm (e.g., HMAC 256/256). The above is also consistent with the text in Section 14.1 about the default value of the 'hkdf' parameter: > For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF SHA-256, > defined as default in Section 3.2 of [RFC8613]. In the 'hkdf' parameter, this > HKDF Algorithm is specified by the HMAC Algorithm HMAC 256/256 (COSE > algorithm encoding: 5). As to the example in Figure 5, indeed the 'hkdf' parameter has value 5, which abbreviates the HMAC Algorithm HMAC 256/256 and thereby denotes the HKDF Algorithm HKDF SHA-256. That is, the comment "HMAC with SHA-256" in CBOR diagnostic notation strictly and correctly refers to the value 5 that the 'hkdf' parameter has in the example. In Section 6.3, we have further clarified as below: OLD > The 'hkdf' parameter, if present, specifies the HKDF Algorithm that is used > in the OSCORE group. The HKDF Algorithm is specified by the HMAC Algorithm > value. This parameter MAY be omitted, if the HKDF Algorithm used in the group > is HKDF SHA-256. Otherwise, this parameter MUST be present. NEW (emphasis mine) > The 'hkdf' parameter, if present, specifies the HKDF Algorithm that is used > in the OSCORE group. The HKDF Algorithm is specified by the HMAC Algorithm > value. **For example, the HKDF Algorithm HKDF SHA-256 is specified as the > HMAC Algorithm HMAC 256/256.** This parameter MAY be omitted, if the HKDF > Algorithm used in the group is HKDF SHA-256. Otherwise, this parameter MUST > be present. <== Section 6.3 says: This parameter MUST be present if and only if the node does not join the OSCORE group exclusively with the role of monitor, ... Please reword. This is a very complex way of saying that the parameter MUST be present if the node has at least one role other than monitor. ==>MT We have rephrased as below, by removing "and only if" and adding a corresponding new sentence "Otherwise, ...". OLD > This parameter MUST be present if and only if the node does not join the > OSCORE group exclusively with the role of monitor, according to what is > specified in the access token (see Section 5.2). NEW > This parameter MUST be present if the node does not join the OSCORE group > exclusively with the role of monitor, according to what is specified in the > access token (see Section 5.2). Otherwise, this parameter MUST NOT be present. As to the wording "does not join ... exclusively with the role of monitor", it is not equivalent to "does not join ... with at least one role other than monitor". The latter could erroneously be read as not encompassing a joining where the role "monitor" is not involved at all, in which case the parameter must however be present. Instead, assuming that the set of roles (monitor, foo) is legitimate, the wording "does not join ... exclusively with the role of monitor" encompasses both the following sets of roles, according to which the parameter must be present: * (monitor, foo) * (foo) This consideration applies also to some editorial suggestions raised in following comments, as to the wording "exclusively with the role of monitor", "not exclusively as monitor", or similar, which we believe to be more precise and less prone to misunderstanding. <== Section 9.1.1 says that "The 'exp' parameter SHOULD be present." Please provide the consequences if the 'exp' parameter is not present. ==>MT At a high level, there are consequences for Clients that have a reliable way to synchronize their internal clock with UTC and thus can take advantage of the expiration time specified by the 'exp' parameter. If the 'exp' parameter is not present, such Clients rely on the 'exi' parameter (which must be present) to determine the expiration time for the group keying material conveyed by the 'key' parameter. We have updated Section 9.1.1 as below: > OLD > * The 'exp' parameter SHOULD be present. > > * The 'exi' parameter MUST be present. NEW > * The 'exi' parameter MUST be present. > > * The 'exp' parameter SHOULD be present. Omitting the parameter is not > desirable for a requesting group member that has a reliable way to > synchronize its internal clock with UTC. That is, if the 'exp' parameter is > not present, such a requesting group member falls back on using the 'exi' > parameter value to less accurately determine the expiration time of the group > keying material conveyed by the 'key' parameter. <== Section 9.1.2 says that "The 'exp' parameter SHOULD be present." Please provide the consequences if the 'exp' parameter is not present. ==>MT Just like for the previous comment, we have updated Section 9.1.2 as below: OLD > The 'exp' parameter SHOULD be present. > > The 'exi' parameter MUST be present. NEW > * The 'exi' parameter MUST be present. > > * The 'exp' parameter SHOULD be present. Omitting the parameter is not > desirable for a requesting group member that has a reliable way to > synchronize its internal clock with UTC. That is, if the 'exp' parameter is > not present, such a requesting group member falls back on using the 'exi' > parameter value to less accurately determine the expiration time of the group > keying material conveyed by the 'key' parameter. <== In Section 14.1, the text about the HKDF parameter is confusing. Based on the example in Figure 4, which shows "HMAC with SHA-256", the HMAC algorithm should be discussed as the default. ==>MT This relates to the earlier comment about Section 6.3. As explained when addressing that comment, the current text in Section 14.1 is consistent and correct. Among its parameters, the Group OSCORE Security Context specifies an HKDF Algorithm, which is however denoted by means of the HMAC Algorithm that it uses. Therefore: * Here it is still about talking of a default HKDF Algorithm. * The HKDF Algorithm still has to be denoted by the HMAC Algorithm that it uses. <== In Section 16.1, the formatting does not make it clear that two OAuth parameters are being registered. Please make two sets of bullets. ==>MT We have updated the text as suggested. With reference to the first parameter, the update is as follows. OLD > * Name: ecdh_info > * Parameter Usage Location: client-rs request, rs-client response > * Change Controller: IETF > * Reference: [RFC-XXXX] NEW > * Entry #1 > * Name: ecdh_info > * Parameter Usage Location: client-rs request, rs-client response > * Change Controller: IETF > * Reference: [RFC-XXXX] We have consistently applied the same reformatting in the following Sections 16.2-16.11. <== In Section 16.3, the formatting does not make it clear that five ACE Groupcomm parameters are being registered. Please make five sets of bullets. ==>MT We have applied the same reformatting as in Section 16.1 (see earlier comment). <== In Section 16.6, the group_SenderId entry does not include a registry, but the other entries in this section do so. ==>MT That's correct and as intended. The "OSCORE Security Context Parameters" registry is defined in Section 9.4 of RFC 9203, which about the "Registry" field says (emphasis mine): > This field denotes the registry that values **may** come from, **if one > exists**. For the 'group_SenderId' parameter, its value conveys the OSCORE Sender ID assigned to a group member (e.g., upon joining the group). It's the Group Manager that locally selects an available OSCORE Sender ID to assign. Therefore, there is simply no such registry to refer to in the "Registry" field of the entry for the 'group_SenderId' parameter. The same line of reasoning applies to other already registered entries of the same registry (e.g., 'ms' and 'salt'), for which no registry is referred to in the "Registry" field. See https://www.iana.org/assignments/ace/ace.xhtml#oscore-security-context-parameters <== In Section 16.6, the formatting does not make it clear that six ACE OSCORE Security Context parameters are being registered. Please make six sets of bullets. ==>MT We have applied the same reformatting as in Section 16.1 (see earlier comment). <== In Section 16.8, the formatting does not make it clear that two AIF Media-Type sub-parameters are being registered. Please make two sets of bullets. ==>MT We have applied the same reformatting as in Section 16.1 (see earlier comment). <== In Section 16.9, the formatting does not make it clear that two CoAP Content-Formats are being registered. Please make two sets of bullets. ==>MT We have applied the same reformatting as in Section 16.1 (see earlier comment). <== In Section 16.9, the formatting does not make it clear that three ACE Groupcomm Errors are being registered. Please make three sets of bullets. ==>MT We have applied the same reformatting as in Section 16.1 (see earlier comment). <== Nits: Section 4: I suggest rewording: OLD: The joining node is currently a group member acting not exclusively as monitor, and it is re-joining the group not exclusively as monitor. NEW: The joining node is currently a group member with at least one role other than monitor, and it is re-joining the group with at least one role other than monitor. ==>MT Quoting more text for context: > In the following circumstances, a joining node is not required to provide its > authentication credential to the Group Manager when joining an OSCORE group. > > ... > > * The joining node is currently a group member acting not exclusively as > monitor, and it is re-joining the group not exclusively as monitor. Similarly to what is explained when addressing a previous comment about the wording in Section 6.3, we prefer to keep the wording "not exclusively as monitor" here in Section 4, as more precise and less prone to misunderstanding. That is, the wording "not exclusively as monitor" is not equivalent to "with at least one role other than monitor". The latter could be erroneously read as not encompassing the case where the role "monitor" is not involved at all. However, in that case it is still intended that the joining node is not required to provide its authentication credential to the Group Manager when re-joining the group not exclusively as monitor. <== Section 5.3: s/an 8-byte long random nonce/an 8-byte random nonce/ ==>MT When addressing follow-up comments from the AD review, we updated that sentence as below in the Editor's copy on GitHub: OLD > ..., it is RECOMMENDED to use an 8-byte long random nonce. NEW > ..., it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be > a random value. Therefore, this comment does not apply to the latest text in the Editor's copy. <== Section 5.3: s/Consistently with Section/To align with Section/ (twice) ==>MT We have adopted the suggested change in all the three instances of Section 5.3 and one instance of Section 6.3. <== Section 5.3.2: s/to join or interact with/to join or monitor/ (twice) ==>MT We have kept the current phrasing "interact with", for two reasons: * The verb "monitor" points quite specifically to a non-member node that is devoted to monitor the group (e.g., a "probe"). Besides the innocuous fact that there is no role of that kind currently defined, the word "monitor" can raise confusion, as it is already used for a particular role that a group member can take. * The wording "interact with" is deliberately general, as intended to encompass also current and later defined roles that are taken by non-members of the group, irrespective of the exact nature of their interaction with the group. At the moment, a role that reflects this is the signature verifier. The same applies for the two instances of "or interact with" in Section 5.3.1. <== Section 6.1: s/an 8-byte long random nonce/an 8-byte random nonce/ ==>MT When addressing follow-up comments from the AD review, we updated that sentence as below in the Editor's copy on GitHub: OLD > ..., it is RECOMMENDED to use an 8-byte long random nonce. NEW > ..., it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be > a random value. Therefore, this comment does not apply to the latest text in the Editor's copy. <== Section 6.1: s/that could have happened/proof-of-possession could occur/ ==>MT A bit more explicitly than how it is suggested in the comment, we have rephrased the quoted text as below: OLD: > For example, that could have happened upon completing ... NEW: > For example, proof-of-possession could have been achieved upon completing ... <== Section 6.1: s/In either case, the N_S/The N_S/ ==>MT We have rephrased as suggested. We have also applied the same rephrasing to a sentence in Section 15.2, that was revised based on follow-up comments after the AD review. After applying also this update, that sentence in Section 15.2 reads as below: > The N_S value is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED > to be a random value. <== Section 6.1: s/HKDF Algorithm HKDF SHA-256/HKDF Algorithm with SHA-256/ ==>MT We prefer to keep the current naming. This is also consistent with the naming in Group OSCORE (draft-ietf-core-oscore-groupcomm) and OSCORE (RFC 8613) that Group OSCORE builds on. Both documents refer to HKDF SHA-256 as the HKDF Algorithm that is mandatory to implement (see Section 3.2.1 of RFC 8613 and Section 10 of draft-ietf-core-oscore-groupcomm). <== Section 6.2: s/In such a case /In such a case, / ==>MT Fixed. <== Section 6.2: s/stored value (if any)/stored value, if any/ ==>MT Fixed. <== Section 8.6: s/newly defined earlier in Section 8/defined in Section 8/ ==>MT Building on the suggestion, we have rephrased as below: OLD > ... and with reference to the resources at the Group Manager newly defined > earlier in Section 8 of this document ... NEW > ... and with reference to the additional resources at the Group Manager > defined in Section 8 of this document ... <== Section 9.5.2: s/an 8-byte long random nonce/an 8-byte random nonce/ ==>MT When addressing follow-up comments from the AD review, we updated that sentence as below in the Editor's copy on GitHub: OLD > ..., it is RECOMMENDED to use an 8-byte long random nonce. NEW > ..., it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be > a random value. Therefore, this comment does not apply to the latest text in the Editor's copy. <== Section 9.10: s/Furthermore, since it/Since the signature verifier node/ ==>MT Quoting some more text for context: > * As a signature verifier, the node ... > > Furthermore, since it is not a group member, the node does not take part to > a possible group rekeying. The quoted text is within the bullet point about a signature verifier. So, it should not be needed to repeat that the text is about a "signature verifier node". Instead, as a preamble to what follows, we think that it is good to remind that the signature verifier is not a group member. To make the sentence lighter, we have anyway rephrased by removing "Furthermore", i.e.: NEW > Since it is not a group member, the node does not take part to a possible > group rekeying. <== Section 10: s/not exclusively the role of/at least one role other than/ ==>MT Like discussed when addressing a previous comment about Section 6.3, we prefer to keep the current wording as more precise and less prone to misunderstanding. <== Section 15.2: s/an 8-byte long random nonce/an 8-byte random nonce/ ==>MT When addressing follow-up comments from the AD review, we updated that sentence as below in the Editor's copy on GitHub: OLD > For the N_C challenge, it is RECOMMENDED to use an 8-byte long random nonce. NEW > 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. Therefore, this comment does not apply to the latest text in the Editor's copy. <== Section 15.2: s/take 8-byte long values/take 8-byte random values/ ==>MT Building on the suggestion, we have rephrased as below. OLD > If we consider both N_C and N_S to take 8-byte long values, the following > considerations hold. > > * Let us consider both N_C and N_S as taking random values, and the Group > Manager to never change the value of the N_S provided to a Client during the > lifetime of an access token. NEW > If we consider both N_C and N_S to take 8-byte random values, the following > considerations hold. > > * Let us consider the case where the Group Manager never changes the value of > the N_S provided to a Client during the lifetime of an access token. <== Note: I did not review the Appendices.
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
