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 >
- [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Tim Hollebeek
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Tim Hollebeek
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Cigdem Sengul
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Göran Selander
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Tim Hollebeek
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Tim Hollebeek
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Marco Tiloca
- Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin Marco Tiloca