Hello Cigdem, Thanks a lot for your review and comments!
We have addressed them in the latest version -11 submitted before the IETF 119 cut-off.
Please find our answers to your comments inline below. Best, /Marco On 2024-02-16 23:35, Cigdem Sengul wrote:
Hello ace, I've reviewed the document and found it largely ready.Below, I make some suggestions to improve clarity and list a few editorial comments, hope it helps.Kind regards, --Cigdem Section 2. Group Administration"The AS MAY release Access Tokens to the Administrator for other purposes than accessing admin resources of registered Group Managers"=> Reading further into the document, it becomes clear later that " Building on the above, the same single scope can include user scope entries as well as admin scope entries"i.e., tokens may express permissions for user resources). It would be good to clarify this earlier.
==>MT What we meant here is even more general than that.Not only can the same Access Token include both admin entries and user entries, as made clearer later in the document.
In addition to that, the same Administrator as an ACE Client can obtain from the AS Access Tokens to be consumed at totally different ACE Resource Servers than specifically an OSCORE Group Manager.
We have extended the paragraph as follows. OLD> The AS MAY release Access Tokens to the Administrator for other purposes than accessing admin resources of registered Group Managers.
NEW> The AS MAY issue Access Tokens to the Administrator for other purposes than accessing admin resources of registered Group Managers. For example, an Access Token can specify authorization information for joining OSCORE groups at a Group Manager (see [I-D.ietf-ace-key-groupcomm-oscore]), possibly combined with authorization information for accessing admin resources at the same Group Manager (see Section 3). Also, an AS can of course issue an Access Token that specifies authorization information unrelated to OSCORE groups, but instead pertaining to the access of other resources hosted by the Group Manager or other Resource Servers.
<==
Section 3. Format of Scope=> The object identifier ("Toid") examples for wildcard patterns and complex patterns would be useful.
==>MT Right, although at this point in the text it would be still too early.After the CDDL definition of an admin scope entry, we have added the example below using the CBOR Diagnostic Notation.
Based on a comment from Carsten, we now use the CBOR tag 21065 to tag CBOR text strings as regular expressions. This is now mentioned already in the text of Section 3 defining the concept of complex pattern used in Toid of a scope entry.
<==
=> Can the Create permission be paired with a "literal" Toid? So, the admin has the right to create a specific config for a specific group name?
==>MTYes, for example in case the Administrator is authorized to create groups with any name from a set of exactly 5 names, which however cannot be the only ones expressed by a complex pattern.
In that case, the scope will instead have 5 different scope entries, each associated with one of those groups and having a literal Toid with the corresponding group name.
<==
Figure 2: Write | 3 | Change group configurations =>Instread of "Change", Update group configurations?
==>MTThe word "Change" is intentional here, as covering both the specific actions of entirely "Overwriting" (see Section 6.6) and selectively "Updating" (see Section 6.7) a group-configuration resource.
<==
Section 3.1"The Administrator may have established a secure communication association with the Group Manager based on a first Access Token T1, and then created an OSCORE group G. Following the invalidation of T1 (e.g., due to expiration) and the establishment of a new secure communication association with the Group Manager based on a new Access Token T2, the Administrator can seamlessly perform authorized operations on the previously created group G."The example is not clear to me. Why does the G having a wildcard or complex pattern help in this case?
==>MTHaving more in mind the subsection title as about any type of pattern, that bullet point considers the full set of literal/wildcard/complex patterns, not only the wildcard and complex patterns.
Yet you are right, the wildcard and complex patterns do not help more than a literal pattern does, as long as the name of the targeted group G matches (which is always the case when using a wildcard pattern).
This bullet point was attempting to stress the seamless "coming back" of the same Administrator over a newly established secure communication association, after the issue of a new Access Token.
Admittedly, it can be confusing, as there is nothing special here compared to any other case: the Client can access a resource, as long the RS finds an Access Token associated with the secure association used to protect the request and specifying a scope that grants the requested access.
Therefore, we have just removed the quoted bullet point altogether. <==
5.1.2'group_title', with value either a human-readable description of the OSCORE group encoded as a CBOR text string, or the CBOR simple value "null" (0xf6) if no description is specified.==>If this is group description, group_desc sounds more fitting than group_title?
==>MT Fair point.It's actually ok to have a longer parameter name 'group_description'. What goes on the wire is its CBOR integer abbreviation defined in section 7.
So we have renamed 'group_title' to be 'group_description'. <==
5.2"A possible reason for the Group Manager to consider default values different from those recommended in this section is to ensure that each of those are consistent with what the Group Manager supports, e.g., in terms of signature algorithm and format of authentication credentials used in the OSCORE group."Is this mainly saying, "The Group Manager MAY choose different default values instead of those recommended in this section ... "
==>MT Yes, we have rephrased based on what you suggested. OLDA possible reason for the Group Manager to consider default values different from those recommended in this section is to ensure that ...
NEWThe Group Manager MAY choose different default values instead of those recommended in this section. A possible reason is to ensure that ...
<==
6.2 Retrieve a List of Group Configurations by FiltersIt would be good to give an example with status filters as well. For example, is it possible to use a complex pattern for group_name filter?
==>MT Good point!In Section 6.2, we have added one more example where the request payload includes both configuration and status parameters, as well as the 'group_name' parameter specifying a regular expression as complex name pattern.
This has also required the following two changes.* The table in Section 7 "ACE Groupcomm Parameters must indicate that 'group_name' has CBOR Type "tstr" or "#6.<uint>(any)". The same goes for the entry about 'group_name' in Section 10.1.
* The payload of the FETCH request to the group-collection resource is the only case where the 'group_name' parameter can also be such a tagged CBOR data item. In any other case, the 'group_name' parameter is always encoded as a CBOR text string and specifies an exact group name.
Consistently, the text has required the following changes in different sections.
Section 6.2 OLD> Entry values are the ones admitted for the corresponding labels in the POST request for creating a group configuration (see Section 6.3).
NEW> Entry values are the ones admitted for the corresponding labels in the POST request for creating a group configuration (see Section 6.3), with the exception that the parameter 'group_name' (if present) can also be encoded as a tagged CBOR data item, specifying a group name pattern with the semantics signaled by the CBOR tag.
>> In such a case, the parameter 'group_name' expresses a group name pattern in the same way as a complex pattern Toid does in a scope entry (see Section 3). In particular, the filter criterion is satisfied by any group name that matches with the group name pattern specified by the parameter 'group_name' in the payload of the FETCH request.
Section 6.3 OLD> The payload MUST include the status parameter 'group_name' defined in Section 5.1.2 and specifying the intended group name.
NEW> The payload MUST include the status parameter 'group_name' defined in Section 5.1.2 and specifying the intended group name encoded as a CBOR text string.
<==
6.3 Create a New Group Configuration (and also 6.6.)"Alternatively, the Administrator can perform the registration in the Resource Directory on behalf of the Group Manager, acting as Commissioning Tool."Why consider this option when"Therefore, it is RECOMMENDED that registrations of links to group-membership resources in the Resource Directory are made (and possibly updated) directly by the Group Manager, rather than by the Administrator."
==>MTThe option of using a Commissioning Tool is something generally introduced in RFC 9176 (see, in particular, its Sections 2 and 3.1).
Here the OSCORE Group Manager is clearly not supposed to be resource-constrained, and is in fact RECOMMENDED to be the entity interacting with the Resource Directory (RD), in the interest of well-maintained registrations at the RD.
At the same time, we thought to be prudent and to not rule out altogether the use of a separate Commissioning Tool (in this case the Administrator), which might be in a better position to practically communicate with the RD, or among only few entities authorized to interact with the RD, in line with particular "needs of the application" (cfr. Section 2 of RFC 9176).
<==
Editorial Abstract OLD: A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. NEW: A Group Manager is responsible for handling the joining of new group members, as well as managing and distributing the group keying material. OLD: This document defines a RESTful admin interface at the Group Manager, that NEW: This document defines a RESTful admin interface at the Group Manager that Introduction OLD: When group communication for CoAP is protected with Group OSCORE, nodes are required to explicitly join the correct OSCORE group. NEW: When group communication for CoAP is protected with Group OSCORE, nodes are required to join the correct OSCORE group explicitly. OLD: e.g., based on the current application state or on pre-installed policies. NEW: e.g., based on the current application state or pre-installed policies. TERMINOLOGY OLD: An OSCORE group is used as security group for one or many application groups. NEW: An OSCORE group is usedas a security group for one or many application groups. 3.1 OLD:When relying on wildcard patterns and complex patterns, the Administrator and the AS do not need to know exact group names forrequesting and issuing an Access Token, respectively (see Section 4). NEW:When relying on wildcard patterns and complex patterns, the Administrator and the AS do not need to know the exact group names forrequesting and issuing an Access Token, respectively (see Section 4). 4.1 OLD: With respect to the main Administrator, such assistant Administrators are expected to have less permissions to perform administrative operations related to the OSCORE group at the Group Manager. NEW: With respect to the main Administrator, such assistant Administrators are expected to have fewer permissions to perform administrative operations related to the OSCORE group at the Group Manager. OLD: For example, they may not be authorized to create the OSCORE group if not existing already, or to delete the OSCORE group and its configuration. NEW:For example, they may not be authorized to create an OSCORE group, or to delete an OSCORE group and itsconfiguration. 6.3OLD: "If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in Section 5.2, then the response payload MUST include also thoseparameters, specifying the values chosen by the Group Manager for the current group configuration."NEW: "If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in Section 5.2, then the response payloadMUST also include thoseparameters, specifying the values chosen by the Group Manager for the current group configuration. 6.6.2 OLD: "Retrieve from the Group Manager the new Group Manager's authentication credential " NEW: Retrieve from the Group Manager the Group Manager's new authentication credential
==>MT All fixed. <==
8. Sentence hard to parse: "This option fundamentally relies on the Group Manager freeing up group names, hence it is not viable if considerably or indefinitely postponing the creation of the group is not acceptable."
==>MT Rephrased as follows. NEW> This option fundamentally relies on the Group Manager making the group name available again before the Administrator sends the new POST request. Hence, this option is not viable if it is unacceptable for the Administrator to considerably or indefinitely postpone the creation of the new group.
<==
On Fri, 16 Feb 2024 at 19:48, Tim Hollebeek <[email protected]> wrote:Just as a reminder, this WGLC closes in three days. Please provide feedback as to whether this document is ready to be sent to IESG or not. -Tim *From:*Tim Hollebeek *Sent:* Monday, February 5, 2024 2:18 PM *To:* [email protected] *Subject:* WGLC for draft-ietf-ace-oscore-gm-admin Hello ACE Working Group members, We’re finally ready to do a Working Group Last Call for the document draft-ietf-ace-oscore-gm-admin: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/ <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%7Cc3dc340b1b6f472f607808dc2f3fa592%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638437197625717479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iZavGDhahLE%2BCNes%2B2grRzFRlGRz%2FBQYCzdFnE%2FuL0Q%3D&reserved=0> Admin Interface for the OSCORE Group Manager draft-ietf-ace-oscore-gm-admin-10 Abstract Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession, and server authentication. Please review the document and provide feedback to the list by 19 February 2024. For the chairs, -Tim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc3dc340b1b6f472f607808dc2f3fa592%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638437197625725741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OSZMOrkVrzH%2FPh3%2BIn0Cd9TpYiia86PREM1wMjdTO60%3D&reserved=0> _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
