Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin

[Marco Tiloca <[e-mail]>]

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?

==>MT

Yes, 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?

==>MT

The 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?

==>MT

Having 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.

OLD
A possible reason for the Group Manager to consider default values 
different from those recommended in this section is to ensure that ...

NEW
The 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 Filters
>
> It 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."

==>MT

The 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 for
>       requesting 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 for
>       requesting 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 its
>    configuration.
>
> 6.3
> OLD: "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 those
>    parameters, 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 those
>    parameters, 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 
> <tim.hollebeek=[e-mail]> 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:* [e-mail]
>     *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
>     [e-mail]
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se