Hello Mike, Thanks a lot for your review! 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 to submit the result as version -16 of the document, once the submission system reopens. Thanks, /Marco [PR] https://github.com/ace-wg/ace-oscore-gm-admin/pull/10 ________________________________ From: Mike Bishop via Datatracker <[email protected]> Sent: Monday, March 2, 2026 5:39 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Mike Bishop's No Objection on draft-ietf-ace-oscore-gm-admin-15: (with COMMENT) Mike Bishop has entered the following ballot position for draft-ietf-ace-oscore-gm-admin-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd8b54011e48e4152382d08de787a5b32%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639080664055793790%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FYS5eifHuM3tmKvRb2KWj46%2BRT4ku%2F9mb2xwDvPHC3A%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-oscore-gm-admin%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd8b54011e48e4152382d08de787a5b32%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639080664055818089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ne%2FAroF51mVBxCht0OFCZnYX5freOHY%2F6i8u2gbNCtM%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # IESG review of draft-ietf-ace-oscore-gm-admin-15 CC @MikeBishop ## Comments ### Section 3, paragraph 31-32 ``` When using the scope format as defined in this section, the permission set ("Tperm") of each admin scope entry MUST include the "List" permission. It follows that, when expressing permissions for Administrators of OSCORE groups as defined in this document, an admin scope entry has the least significant bit of "Tperm" always set to 1. ``` What happens when a permission set that doesn't allow Listing is encountered? Is this an error? Invalid according to the scope format? If it's possible to express, then rules for handling it should be outlined. ==>MT This document considers only "admin scope entries", as intended to express a permission set. By definition, an admin scope entry always includes the List permission, and it is recognizable by the Least Significant Bit (LSB) of its Tperm set to 1. That bit has a double meaning: i) the scope entry is specifically an admin scope entry; and (thus) ii) it has the List permission granted. (More about the rationale around this choice comes in the answer to the next comment) Therefore, it is not possible to encounter a permission set without the List permission. However, the scope specified in the access token can include multiple scope entries, and some of those can have the LSB of the corresponding Tperm set to 0. Such scope entries are not admin scope entries, but rather "user scope entries". They are specified and used in draft-ietf-ace-key-groupcomm-oscore, and they do not define a permission set for an Administrator, but rather a role set for a (candidate) group member. That is, a scope entry with the LSB of its Tperm set to 0 is not an error to handle. It's simply a user scope entry, to be handled as per draft-ietf-ace-key-groupcomm-oscore. In the present document, the second from last paragraph in Section 3.0 discusses exactly the case where the scope within an access token can include a mix of user scope entries and admin scope entries, pointing out that the two types of entries are unambiguously distinguished by means of the LSB in their Tperm. <== ``` earlier in this section, respectively. The two types of scope entries can be unambiguously distinguished by means of the least significant bit of their permission set "Tperm", which has value 0 for the user scope entries and 1 for the admin scope entries. ``` If the LSB is going to be used to differentiate these types, omitting the required permission would result in confusion about which type the entry expresses and therefore potential misinterpretation of the remaining bits. Consider fixing the LSB to 1 in the format rather than requiring the presence of a permission at that bit. (The List permission can be implicit from the existence of a scope, leaving the resulting format unchanged.) ==>MT Following-up from the answer to the previous comment, we don't think that there is a source of confusion. In general, the scope in the access token can include a mix of scope entries. Due to the benefits explained in the last paragraph of Section 3.0, it is intentionally admitted that the same scope can specify a mix of "user scope entries" and "admin scope entries". Both types of entries build on the AIF data model AIF-OSCORE-GROUPCOMM defined in Section 3 of draft-ietf-ace-key-groupcomm-oscore and extended in the present document. For a given scope entry: * If the LSB of its Tperm is 0, then the entry is a user scope entry and does not specify a permission set for an Administrator, but rather a role set for a (candidate) group member. The Group Manager handles this type of scope entry as per draft-ietf-ace-key-groupcomm-oscore, which is not considered by the present document. * If the LSB of its Tperm is 1, then the entry is an admin scope entry and specifies a permission set for an Administrator, to be handled as defined in the present document. In particular, an admin scope entry always indicates the List permission as granted. Like also discussed when processing the SECDIR review during IETF Last Call, we actually intended an Administrator as minimally authorized with the List permission. Especially thinking of an Administrator that is also authorized to create/delete groups, having the List permission makes it possible to quickly check the result of those operations. Also, it makes it possible to have an idea of group names that are currently taken, thereby easing the suggestion of an available group name when sending a request to create a new group-configuration (see Section 6.3), if the operation is authorized. This becomes even more relevant if multiple Administrators can operate at the same Group Manager (see Section 4.1). So we think that it is realistic and desirable to have the List permission minimally authorized for an Administrator. With that in mind, also in the interest of saving bits in the encoding of Tperm (see Section 3), we intentionally defined the rightmost bit set to 1 as having a double-meaning: this is a set of administrative permissions; and (therefore) the List permission is authorized. <== ### Section 6, paragraph 2 ``` For each operation, it is defined whether that operation is required or optional to support for an Administrator and for the Group Manager. If an Administrator supports an operation, then the Administrator is able to produce and send the request associated with that operation. If the Group Manager supports an operation, then the ``` It's unclear how the Administrator can be REQUIRED to implement a request that it initiates. If it doesn't implement it, it simply won't happen. Perhaps better to state where information retrieved by one operation is a prerequisite to other operations the Administrator might wish to perform? ==>MT Thanks for pointing this out. There is no actual interdependency among different operations from an Administrator, so it is not the case that information retrieved by one operation is a prerequisite to other operations. The intent was simply to indicate what operations can be reasonably expected by the implementation of a "minimalistic" Administrator. Admittedly, it is excessive to express that by means of normative requirements, and we can just leave it to "whatever the Administrator implements can happen". We have updated the text as below, focusing only on the Group Manager while not talking about what operations the Administrator MUST/MAY support. OLD (Section 6) > For each operation, it is defined whether that operation is required or > optional to support for an Administrator and for the Group Manager. If an > Administrator supports an operation, then the Administrator is able to > produce and send the request associated with that operation. If the Group > Manager supports an operation, then the Group Manager must be able to ... NEW (Section 6) > For each operation, it is defined whether that operation is required or > optional to support for the Group Manager. If the Group Manager supports an > operation, then the Group Manager must be able to ... OLD (Section 6.1) > This operation MUST be supported by the Group Manager and an Administrator. NEW (Section 6.1) > This operation MUST be supported by the Group Manager. OLD (Section 6.2) > This operation MUST be supported by the Group Manager and MAY be supported by > an Administrator. NEW (Section 6.2) > This operation MUST be supported by the Group Manager. OLD (Section 6.3) > This operation MUST be supported by the Group Manager and an Administrator. NEW (Section 6.3) > This operation MUST be supported by the Group Manager. OLD (Section 6.4) > This operation MUST be supported by the Group Manager and an Administrator. NEW (Section 6.4) > This operation MUST be supported by the Group Manager. OLD (Section 6.5) > This operation MUST be supported by the Group Manager and MAY be supported by > an Administrator. NEW (Section 6.5) > This operation MUST be supported by the Group Manager. OLD (Section 6.6) > This operation MAY be supported by the Group Manager and an Administrator. NEW (Section 6.6) > This operation MAY be supported by the Group Manager. OLD (Section 6.7) > This operation MAY be supported by the Group Manager and an Administrator. NEW (Section 6.7) > This operation MAY be supported by the Group Manager. OLD (Section 6.8) > This operation MUST be supported by the Group Manager and an Administrator. NEW (Section 6.8) > This operation MUST be supported by the Group Manager. <== ### Section 10.3, paragraph 6 ``` (see Section 6.4 and Section 6.5). Also aligned with what is allowed by the granted authorization, the Administrator could ultimately delete the group configuration in question by deleting the corresponding group-configuration resource (see Section 6.8) and then create a new group configuration (see Section 6.3). ``` Does this suggest an attack vector where an attacker could corrupt a URI and induce an authorized Administrator to delete a group the attacker could not itself delete? ==>MT Short answer: no, there is no such attack vector. The URI in question is specified in the 'joining_uri' status parameter included in some responses from the Group Manager. Such responses are always protected by means of the secure communication association between the Group Manager and the requesting Administrator. The details of such association depends on the specific transport profile of ACE used (e.g., RFC 9202 or RFC 9203). Furthermore, the URI in question is solely determined by the Group Manager upon creating a new group and the corresponding group-membership resource at /ace-group/GROUPNAME (see Step 3 in Section 6.3). In particular, that URI cannot be set or changed by Administrators. With reference to the corresponding parameter 'joining_uri', it cannot be present in a valid POST request to /manage when creating the group, about which Section 6.3 says: "The payload MUST NOT include any of the status parameters 'rt', 'ace_groupcomm_profile', and 'joining_uri' defined in Section 5.1.2." Also, the parameter cannot be present in any of the follow-up requests for updating the group configuration of an existing group, i.e.: * Section 6.6 says: "In particular, the request payload has the same format as that of the POST request defined in Section 6.3, with the exception that the configuration parameters 'group_mode' and 'pairwise_mode' as well as the status parameters 'group_name' and 'gid_reuse' MUST NOT be included." * Section 6.7 says: "In particular, the request payload has the same format as that of the POST request defined in Section 6.6, with the difference that it MAY also specify names of application groups to be removed from or added to the 'app_groups' status parameter." So the only possible left attacker is a compromised and malicious Group Manager, in which case there would be much more serious problems, e.g., exposure of secret or sensitive information pertaining to its security groups (see the security considerations in Section 10.2). Also, a compromised and malicious Group Manager could simply delete an existing group on a whim, instead of tricking someone else to do so. <== ### Section 11, paragraph 2 Please add links to the relevant registries. ==>MT Rather than in Section 11.0 (where the second paragraph is just a note to the RFC Editor), we have added the links to the relevant registries in the opening paragraph of each respective Section 11.1, 11.2, and 11.3. <== ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd8b54011e48e4152382d08de787a5b32%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639080664055834543%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a410ZTog6RoZTezUiDvXjnqA62p%2BALDwJMyx1IZ3k4c%3D&reserved=0)<https://github.com/larseggert/ietf-reviewtool>, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ==>MT Thanks for flagging those. They are addressed in the GitHub PR. <== ### Typos #### Section 10.2, paragraph 1 ``` - compromised Group Manager would allow an adversary to also monitor - ----- ``` #### Section 10.2, paragraph 3 ``` - responsible for, after having experienced a reboot. - - ``` #### Section 10.3, paragraph 2 ``` - 'joining_uri' parameter, if the URI does not point to the Group - - ``` #### Section 10.3, paragraph 4 ``` - sent by the Group Manager points to the same Group Manager, by - - ``` ### Grammar/style #### Section 3, paragraph 29 ``` erns, the encoded scope can be compact in size while allowing the Administrat ^^^^^^^^^^^^^^^ ``` This wording could be more concise. #### Section 8, paragraph 6 ``` fferent groups. For a given group, oldest log entries are expected to be tho ^^^^^^ ``` A determiner may be missing.
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
