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 <ace-boun...@ietf.org> on behalf of Cigdem Sengul
<cigdem.sen...@gmail.com>
Date: Friday, 16 February 2024 at 23:36
To: ace@ietf.org <ace@ietf.org>
Cc: Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org>
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=40digicert....@dmarc.ietf.org<mailto:40digicert....@dmarc.ietf.org>>
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: ace@ietf.org<mailto:ace@ietf.org>
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
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
