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

Cigdem Sengul <cigdem.sengul@gmail.com> Fri, 16 February 2024 22:35 UTC

Return-Path: <cigdem.sengul@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42161C14F5FA for <ace@ietfa.amsl.com>; Fri, 16 Feb 2024 14:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3xKC-4S27K6 for <ace@ietfa.amsl.com>; Fri, 16 Feb 2024 14:35:45 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F451C14F5EE for <ace@ietf.org>; Fri, 16 Feb 2024 14:35:45 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-29928451390so1020145a91.3 for <ace@ietf.org>; Fri, 16 Feb 2024 14:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708122944; x=1708727744; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xWaYw4SRKZ0swhMY4VVYuw8UOVSegr+FCmYr5pgfSvQ=; b=cmU+4jDBlZT4UPNWOwL/QEeO6/8F265jW81Kxi5AyMSAkI3ZoflcYgfrVBZQEqXUZu 1VDY3Jo3+S2rztUwQ3yYs/2UM+5C3lAMOx1c+dUlAozPQ/W8MxEjo/jNQXVhcghPXQt7 YvN95gf8133QF+TkY/9LcuX91Eek0Vc+y7jyW8KDj1hyg3m7ZRwA/2AlpmyUAVfTuihw FBippJQXU7KHFKlTxtuKAZ91IjeBpjdtHa488ZCAE8+Z/Sja7tV/ut9N5hFbkM6fxbO9 655ezOREfVsWrsUChdGW6lYoOMY2AXpGj85LXFk92l0L+OawG9zhklji5unDA0XgLfsy 7IUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708122944; x=1708727744; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xWaYw4SRKZ0swhMY4VVYuw8UOVSegr+FCmYr5pgfSvQ=; b=IUdqhSeyGBY6s6xJjZsF7t2KHoRWe7n4iTB7N+eSdKh4u1/a3FlF9dOyOh0s1S6SN0 Wc1WocOe/7zq10akCInYmJ6MkNlCBTo2tsUNCRDwsdx1uNPVtmEXZSJHXYmd+kV+YEg7 Ojt0HHUbht5teib7ruzsO0mRcY+zOgcwEYIV0KVQDNpRCpOWz/Zx8+yA2PeyzLAWh7AS nKgO3v1/DiVtgYHIFQmuYnpACQBRoH4T04Yl5hmisnMNtJgYzQN7MqGP7kcZObGPVclY YrpJf5YwOL4UgeAtqn2j6/w1oFXDFN8wb67hebQO28/P5YKtpph4INOYOOPtIDpt6F8c IRvQ==
X-Gm-Message-State: AOJu0YzeYg0VQy3e77q1rB9U0vtKE43ybs+ELdLw3IP3rICtWW363QC/ +qHl/1zYjIM2J3JUKwNfHYaleRAiD1jKnx5rb5tXPzT3XfEbuu0bYA24nt3GvBFm1h76Z+TjPOi rzkI72arz8jlZuiKSGrX+Y2oq349QK/UVmmJDkg==
X-Google-Smtp-Source: AGHT+IEaCIHOWHNSB5ovAUW/uvsQz7cHs8d+6Np8qFAR3J+MmCt7oEGBOA7wfN0/1KwvgqwWccNGHDMaMo2XZK19NNM=
X-Received: by 2002:a17:90a:df15:b0:297:1b6a:8561 with SMTP id gp21-20020a17090adf1500b002971b6a8561mr6258921pjb.5.1708122943588; Fri, 16 Feb 2024 14:35:43 -0800 (PST)
MIME-Version: 1.0
References: <SN7PR14MB64923C9DDDB116F7D6512B9783472@SN7PR14MB6492.namprd14.prod.outlook.com> <SN7PR14MB6492D843C3596805AB0B1826834C2@SN7PR14MB6492.namprd14.prod.outlook.com>
In-Reply-To: <SN7PR14MB6492D843C3596805AB0B1826834C2@SN7PR14MB6492.namprd14.prod.outlook.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Fri, 16 Feb 2024 22:35:37 +0000
Message-ID: <CAA7SwCPSQTZV4WD_b6pCQY=kPjUEiYxFSmfOxHmrtjOiUL5Pjw@mail.gmail.com>
To: "ace@ietf.org" <ace@ietf.org>
Cc: Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000490e3f0611875d26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/JelX3H5rTtOUedGlPhCs0WImun0>
Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2024 22:35:46 -0000

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.com@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
> *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
> https://www.ietf.org/mailman/listinfo/ace
>