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

[Tim Hollebeek <[e-mail]>]

Thank you to both of you for the excellent comments and feedback, it is very
much appreciated.

 

We’ll see what the authors think about these comments and any additional
comments from Carsten, and get them incorporated into the draft.

 

Once we’ve achieved consensus on the WGLC draft, we’ll assign a document
shepherd, get the shepherd writeup written, and forward the document on to
IESG for publication.

 

-Tim

 

From: Göran Selander <goran.selander=[e-mail]> 
Sent: Sunday, February 18, 2024 3:52 AM
To: Cigdem Sengul <[e-mail]>; [e-mail]
Cc: Tim Hollebeek <[e-mail]>
Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin

 

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] <mailto:[e-mail]> > on behalf of
Cigdem Sengul <[e-mail] <mailto:[e-mail]> >
Date: Friday, 16 February 2024 at 23:36
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]>
>
Cc: Tim Hollebeek <tim.hollebeek=[e-mail]
<mailto: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