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

[Göran Selander <[e-mail]>]

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 to abbreviate “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.






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 used as 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 payload MUST 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]<mailto:[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]<mailto:[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/

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ace