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

[Marco Tiloca <[e-mail]>]

Hello Göran,

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-18 09:52, Göran Selander wrote:
>
> Hi,
>
> I’ve been following the development of this draft and think it is 
> ready in the working group. In addition to some comments already made 
> by Cigdem, I found only a few nits in the latest version:
>
> Section 3
>
> ’In the rest of this section, these are referred to as "user scope 
> entries".’
>
> …
>
> ’In the rest of this section, these are referred to as "admin scope 
> entries".’
>
>   * Remove “In the rest of this section”in these sentences, as the
>     terms are used throughout the document.
>   * Move the text about the convention toabbreviate “admin scope
>     entry” with “scope entry” from the end of section 3.0 to where the
>     former is defined, to keep definitions of “scope” together in the
>     document.
>

==>MT

Yes. Taking both comments above into account, we have made the following 
three changes in Section 3.0.

OLD
 > In the rest of this section, these are referred to as "user scope 
entries".
NEW
 > Hereafter, these are referred to as "user scope entries".

OLD
 > In the rest of this section, these are referred to as "admin scope 
entries".
NEW
 > Hereafter, these are referred to as "admin scope entries", or simply 
as "scope entries" unless otherwise indicated.

Removed the sentence:
 > Throughout the rest of this document, the term "scope entry" is used 
as referred to "admin scope entry", unless otherwise indicated.

<==

> Thanks,
>
> Göran
>
> *From: *Ace <[e-mail]> on behalf of Cigdem Sengul 
> <[e-mail]>
> *Date: *Friday, 16 February 2024 at 23:36
> *To: *[e-mail] <[e-mail]>
> *Cc: *Tim Hollebeek <tim.hollebeek=[e-mail]>
> *Subject: *Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin
>
> 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.
>
> Section 3. Format of Scope
>
> => The object identifier ("Toid") examples for wildcard patterns and 
> complex patterns would be useful.
> => 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?
>
> Figure 2:
> Write  | 3     | Change group configurations
>
> =>Instread of "Change", Update group configurations?
>
> 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?
>
> 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?
>
> 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 ... "
>
>
> 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?
>
> 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."
>
>
> 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
>
> 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."
>
> 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%7Cea30fb6873634b149f1608dc305ef72a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638438431642439559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NFLFDXUh0Z5TlWQy1hiYXITs5kP4NTzJzoGGVDPbxa0%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%7Cea30fb6873634b149f1608dc305ef72a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638438431642449729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zzCnMLwvE94s7xrG5zOz%2FezCLlVGWxO11uWssBIvRQQ%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