Re: [Ace] draft-ietf-ace-key-groupcomm-13

Marco Tiloca <marco.tiloca@ri.se> Tue, 31 August 2021 16:09 UTC

Return-Path: <marco.tiloca@ri.se>
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 0D9C63A1A98 for <ace@ietfa.amsl.com>; Tue, 31 Aug 2021 09:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlei5Qali44l for <ace@ietfa.amsl.com>; Tue, 31 Aug 2021 09:09:45 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2084.outbound.protection.outlook.com [40.107.22.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642D33A1A92 for <ace@ietf.org>; Tue, 31 Aug 2021 09:09:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lBV3cn9juNr6422LL1045g9igTAKD90KRv85MnAiYC6VvrXJlBsQScnwWbQ6shGjU1agZUwMtOd9Pfg/CzFoYVCpxRDYTrzA/fZSalOLt2S7d/jV3NexWmUtJgXFZdkvFJNUxulg0JJmZZ8MNVUjEKteOI5TjVyCY462PozIRXzTTeI8hF15PfpykVonP5tb8laPKKLF91j4hh8ytflL/q1+shaBz2q5Ai4pDg0ODXZV6acXd6TLTqpud6cTCyT7P1n7eDesxu+UwFvgeENuNXNYVscO911Bg/xOx/gKlieyVmQP8GR9Q67f00lFvvDx3rB5D2F1BA0p76SUaaasJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SxiQVPz6xqKxQHPekmyPEXVIi60h1I6pKKGZCCx2CwQ=; b=K0hC9eEfsc2cnGPfywGDg2U3xS1DWuIgYg0G03FOosIF29ZerkJusAf+4owl+ZWDCJDZGwHb4chdcslXkQAJvv0pCHGgS72xWdD506oMCgGbPKTKjVQ+US1yWr2zrXq6QU6EDUrq8uptKaaygBtkSe9a5iKtOsMo+67ytEvRfw+z0xDIwUWDnRc8f82P+2ZlswmOJOjLXUZbU1gs0dDGukK3LQnObxOa+XFbzOrz4gowz33ENhgJi6fORkHGaFggGlqx3RrKaiFPiPuFdA/RtYBQlwLSh5kcZ4fZPBUU40ch33OoM77tkUIgEmvWUO/wWD6SLPLsGhcgAScxeIH1CQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SxiQVPz6xqKxQHPekmyPEXVIi60h1I6pKKGZCCx2CwQ=; b=A8aU6GAsqF2ggRNFBpqJqXEtcE0bq7i4kLaNGUyxxDEiOEzecZYoopwgiIfPT2p3z3LzGxVZFvCERf+OnVgzvGdZ6/gTHSVAM6ECfgWiAQsaELHTRxHOr0BLsS5R6VIhwSh+03QoUmFrfXQfK8h3BrJAxfVHH/SHMT0iwXTtg0s=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se;
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0934.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:160::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20; Tue, 31 Aug 2021 16:09:41 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a9af:c9af:e0cc:4e53]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a9af:c9af:e0cc:4e53%3]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 16:09:41 +0000
To: =?UTF-8?Q?G=c3=b6ran_Selander?= <goran.selander=40ericsson.com@dmarc.ietf.org>, "ace@ietf.org" <ace@ietf.org>
References: <E59F2C52-F777-4704-90D2-1D04C700A60E@ericsson.com>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <e0d5028c-67c6-fcfd-a5db-de7c46bb4371@ri.se>
Date: Tue, 31 Aug 2021 18:09:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <E59F2C52-F777-4704-90D2-1D04C700A60E@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="26qDZ9Ow5qWuCzy9PGkWJnVRuhZ7HXRju"
X-ClientProxiedBy: HE1PR0902CA0018.eurprd09.prod.outlook.com (2603:10a6:3:e5::28) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.8.2.3] (185.219.140.236) by HE1PR0902CA0018.eurprd09.prod.outlook.com (2603:10a6:3:e5::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Tue, 31 Aug 2021 16:09:40 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d004c1e9-9b55-4930-eba3-08d96c99bd26
X-MS-TrafficTypeDiagnostic: DB8P189MB0934:
X-Microsoft-Antispam-PRVS: <DB8P189MB09345C6F55CB384C9441E40299CC9@DB8P189MB0934.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: pdlINYISxVWaSxe9Qi7dKIpshPk66fZniW2XALLwR0QbPniVtr054V9fPcxeoW2uIWR7D81xZOQ7AauBlNtpC9vh8hojeRSIaQHI/h7nB68Du12Ar4dWq8D1FZBfGO2Pg0uWg5zaiTCQsBd04GZv4sLb0kyzeFIySRRRxYgOjO9USOMODiQHiFTgdIq+fD5tAXn9iUsuJ/9EYqNEIkuVpqEUo1BDy9NxztI91E+wVMLnj6sjO1kX4wTZH+ZpWceB/vgOpu4Na+pc6LWiy2jEYSM/vrYOejjxZ1oZgh7grM1CFpdDUgpoDSiyPJkZW1yIquFfbp/CXgAzTRcHptVCwxhVnLKFd0/jGSi8SRixE+rJXLS+h3+SPuGyA9bB3fRS0KjFurAQ5pERIOBmcteMelmPrfM0cVO7lGn7Tl5xS2hS06qUAfaftVdaKBSfsiIlOGcPIt/tTEBCW53Y/z2E/OuvZmZDKytVnUCJWH8JkqgqgFmxoVRx8HJnm7phkZdBE2bFdYygXB9ohibh+bhGxGeBsRZOzd9luMGfdfR6dAWn97FZcMynhkzNP4nRoHToSMyAQQ+mduGETWfP7vDbSc4oTTGzN8yULQojs7B9j+kw96PGUH4SFOKG55YI+oM1jXnTaAoZt9LIACsw9x8c+n6RgjgZJ2xJzNOBu9D6M1iK8obE04vjIPQuVSLvVd7Sd8Uijl2YX+Blmwfjv/cAVSugOjFMs+EWtqzeSVSueknDAQuTG+20U25W6fx6L4leTAyq3DBdYO/wu1jhbae9fUS34Vd7xGwna8yOaE8r409WtX99vFzi2kknqq05YjU4
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(366004)(136003)(396003)(376002)(38100700002)(86362001)(31696002)(31686004)(36756003)(6486002)(66574015)(83380400001)(45080400002)(5660300002)(66556008)(186003)(33964004)(478600001)(66946007)(316002)(966005)(110136005)(53546011)(66476007)(26005)(2616005)(8936002)(16576012)(8676002)(21480400003)(44832011)(235185007)(2906002)(30864003)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aU5kaWpROVV5T3RrZlZCcmFpb0QveGhmazFSR0ZoWVM1UXkrWWN3cnBHRW84?= =?utf-8?B?OTdtNWNuMjNES3BJMUN5VEprdW1TMnpuNUVtMjc1Y0IzUFR3a21mOE9YWW5q?= =?utf-8?B?UGJvSWd0Z3owa0c4WUo5OXhFN3VRczVGNmE2WDUvcy90Z1d6YndzVC9uZ0ZV?= =?utf-8?B?cVRQL2xIeTVnQVI2L2praFoyejFHcGJidjNBU1J0WStQSkNLMWppMUZMMmZR?= =?utf-8?B?dFlLRUtPdmZ3SnFWSkttWGxjMTdML3JzZW85Q2VLUXMwZjFhZUp3TjBXYVpm?= =?utf-8?B?SWtBUDNxejBrYnY5LzlnMHRqWUhiSlhGa0pxNFBHd3VKajkzUGROVGJWREZT?= =?utf-8?B?TURQTHVFbWlhbVZodDJWaWo4VVhlZEcrWmxsMG5JQy9PdWt0N25vb0pGY1JJ?= =?utf-8?B?M3V3L0pLYnRpSzV1RXYyTEdUNTJLV1NDeWhFaG1uT2dNR1h0SFpiY21rWm1Y?= =?utf-8?B?SmhiVEdDa1pOQVNmVlNQcGY0K2pZSmJzWDdQbU95OEdYZ2ltb0dMNG9MMTIy?= =?utf-8?B?WS9VcnczMm5QczBNbDVod0Z5WTQvVEdqZnZSRnhGSDFSby9MRVhQQk9nVEtt?= =?utf-8?B?RWgwMzFxdTFTR0xoeG40bUxkNHpqbkc3ODFzSGlZU2NaN1RLcUFraXphQVNB?= =?utf-8?B?RnZ2bDdEb3lldlhrNUpJM0xrWWZNNWYvdkZOdE44SnRYblV3d2RaN3JxOE41?= =?utf-8?B?Z3NMUDZIRlRHMG5UajFXZXo1VXRlRTg5cUN2NjN6T0JHVThWR2htcThFUG5I?= =?utf-8?B?dFJMdXp4TGxrOWYrTGlmRHFYa0ViTng5SW1uK2xjM1RuYVhFN2ViVVRXWnlr?= =?utf-8?B?bGt2ZVd1dlE3NktvOC9kRlMwM0ZQUjhUTE5TMjF0TkJGZktET2JaRHpSb3Nm?= =?utf-8?B?WGFJeW5tcXBlVUF4VjJVa1FKTGVDWnJOREd6SzBqTjY2aUhmSWhZbStCTklL?= =?utf-8?B?MFpORDVxNTlvNjRhZnVmYWxKeHNSVGZxcjBoRlVQZzd4emdLaldYWGRMTlJP?= =?utf-8?B?R2NXUjl1OGpVcXRWMTZWSjRqNkg4Vk9TVGlDblNWMVF4VTVMTFJFYWlJL2JP?= =?utf-8?B?b1pVcjIrZ0luZEViTjBmc2ZNQnlwN2tqelRLZXQ1ZzEvS1dFdEhIVHUvZFdh?= =?utf-8?B?empOWUhjS0h5V2dwU2ZxdHhoOFdVUmxMZHhmRENudHZUK1pETytiZGdXM2tR?= =?utf-8?B?Zmh6SkRBOU1La0U3dmJtN1F2TW1DWE9QaDF3ZnVDZWxQZktyQmNsK1RXUFA2?= =?utf-8?B?ZXoydW11VE5ib1M2ZUpYOGtGeG1OVytDNDJqRlBNK1h2bHRsK3pJdTJTdFBr?= =?utf-8?B?azNsTUE3L0VwcGJzMzNaeTBUT05rOEREUkRSd1htVEQwUEV4SXorK2FvYVlJ?= =?utf-8?B?Qyt5a05yeDJEaW82QzZ0cUYrZmdoUVlUaFhiNjlkWDhoVlV1SU9Bd1BjZzQ1?= =?utf-8?B?TFlJcFFZUVJnRmowbFdpNHVISWVNeGswVFpEY1FXcWtZeXAwcERreFQwWnZk?= =?utf-8?B?dk9TZmZPTXJKdTdlNGVZK004NnkvRlNDVDc4VnpVTnl6TklYNC9FREk1elc4?= =?utf-8?B?WEovUkNxVWVrWTN4TU1TQmNBSWVqVWpiVy9nOFlRUVI3MVhvSFdJQ1VVSmhp?= =?utf-8?B?S2U1b0lRRTdtcFpVVzFrTmZ6S1dsdDdFY25MRGx6bWxwVlphRWVxZEZXcVVG?= =?utf-8?B?eFNVWkt3bllNcndmc1NjNlV2eEhtdGYyQjZVdmwxQ0swTjMrTk5LRFI0Y3ZW?= =?utf-8?Q?aJZgoCwSNuchuYF9+UJ0rx9ELabiaZfLj4vuBFi?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: d004c1e9-9b55-4930-eba3-08d96c99bd26
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2021 16:09:41.2500 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: znA22LtZDOZ40nmTjD3kiWKkYEOXHmkWphX2/Ld+dT38DXLaB3ZrrsDild6vNvsVV70GLZF+g1PQw/9wRZPcAg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0934
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo>
Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-13
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 31 Aug 2021 16:09:55 -0000

Hi Göran,

Thanks a lot for your review! Please, see my comments inline marked as 
"==>MT".

Best,
/Marco

On 2021-08-24 18:52, Göran Selander wrote:
> Hi,
>
> Here is a review of ace-key-groupcomm-13.
>
>
> General
> ===
>
> This draft provides a link between the ACE-OAuth authorization framework (including its transport profiles) and specifications of communication security in groups of constrained devices, e.g. the coap-groupcomm work currently developed in CORE. The document is intended to support different group communication schemes, but the details of those are defined in separate “application profiles” such as draft-ietf-ace-key-groupcomm-oscore (for Group OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This draft instead defines a common interface to a KDC acting as RS in the ACE-OAuth architecture, how to use this interface to perform various key management operations, and requirements for such application profiles.
>
> As such, this draft is thus an “intermediary” specification, and its usefulness will be determined by the application profiles which I've glanced at but are not part of this review.
>
> While this approach seems reasonable from a structure point of view, I have a question about abstracting the underlying communication in comment 1 below.
>
> The content of the draft is quite elaborate and with detailed examples which is good but also leads to my comment number 2.
>
> Now for the main comments:
>
> 1. How does this scale to large groups?
>
> Depending on application it may not be necessary to update keys during join of new members, and depending on the dynamics of the members rekeying may not be a major issue. But if it is a large group and all group members need to be updated at joining or leaving then this may require a lot of communication for which the underlying group communication may be helpful.
>
> For example, in case of a new member joining then a new group key or the new node's public key may be distributed using broadcast/multicast and protected with some existing group key.

==>MT
Definitely the new group key material to use before completing the 
joining of the new member.

As to the public key of the new group member (if there is one at all, 
depending on the member's roles), it's actually good to admit its 
provisioning _together_ with the group key material. It would spare 
other group members to perform dedicated retrieval traffic with the KDC 
just for that later on. This can be added to the last paragraph of 
Section 4.3.

As to using "some existing group key", yes, this requires a separate set 
of administrative key material, possibly organized into a hierarchy 
whose root is the administrative group key (see also later comments). 
That's the key material used to protect rekeying messages at the 
application layer, and in principle unrelated to the secure 
communication protocol used in the group.
<==

>
> In case of rekeying a group key after a node has been evicted, a similar method could be used if it was possible to apply some key hierarchy scheme like e.g. LKH, i.e. distributing new keys corresponding to a path from the evicted node to the root in a key hierarchy.

==>MT
Yes. This is explicitly mentioned in Section 4.4, in the second bullet 
point after Figure 15.

As above, this requires a separate set of administrative key material, 
possibly organized into a hierarchy whose root is the administrative 
group key (see also later comments). Also as above, that's the key 
material used to protect rekeying messages at the application layer, and 
in principle unrelated to the secure communication protocol used in the 
group.
<==

>
> Two sub-questions:
>
> a. Is it possible to extend the interface to make use of the underlying group communication?

==>MT
It should already be able to accommodate it. In particular:

* In Section 4.4, the second bullet point after Figure 15 already 
mentions this possibility. An application profile or a separate 
specification that builds on and extends it would have to define the 
exact rekeying scheme to use and its message formats.

* At the end of Section 4.1.2.1, it is defined that the Joining Response 
can include an optional parameter 'mgt_key_material'. In case of 
rekeying schemes more advanced than a basic point-to-point approach 
using pairwise security associations, this parameter provides a group 
member with the administrative key material _it_ needs to have to 
participate in a group rekeying.

    For example, if a hierarchy-based scheme is used, the parameter 
specifies the administrative keys in the key tree from the leaf node 
associated to the group member all the way up along the path from that 
leaf node to the root (which is the administrative group key shared by 
all the group members).

* In Section 4.4, the third bullet point after Figure 15 refers to a 
local "control" resource at a group member, where the KDC can send 
requests such as rekeying messages. The group member can provide the KDC 
with the URI of such a local resource when joining the group, in the 
'control_uri' parameter of the Joining Request.

    This is more generally intended as a resource where the KDC can 
reach the group member with a request, and is potentially usable for 
several administrative operations, including a group rekeying. In the 
previous, second bullet point, it can be explicitly mentioned that this 
resource can also be the target of a group rekeying request sent over 
multicast.

    Note that 'control_uri' may indicate an administrative "root path", 
that the group member determines as relevant for that security group. I 
would imagine requests for different administrative tasks to target 
different sub-resources identified by well-known path segments under 
that path.


There are still two missing things, though.

* A group member would need to know the multicast address where the KDC 
sends group rekeying messages. This might also be provided as an 
additional parameter in the Joining Response.

    Several versions ago, we proposed to include this in draft, but the 
idea was dismissed to keep things simple. Should we revisit this and add 
an optional parameter of this kind in the Joining Response?

    Note that this goes hand-in-hand with _requiring_ a joining node to 
provide also the URI of a local control resource, in the 'control_uri' 
parameter of the Joining Request. Hence, it becomes (even more) 
important for the joining node to know as much as possible about how the 
group works (e.g. by means of early discovery), before attempting to 
join it by sending the Joining Request.

* When joining the group, a node also needs to know the exactly used 
group rekeying scheme. The easiest way I see to signal it is defining 
one more integer-valued ACE Groupcomm Policy (see Figure 9 in Section 
4.1.2.1) to be specified in the optional 'group_policies' parameter of 
the Joining Response.

    Its value would indicate the exact rekeying scheme (and we would 
need a new IANA registry). If the KDC does not say anything about that, 
the joining node assumes that a group rekeying is performed 
point-to-point, thus relying on the pairwise communication channel it 
has with the KDC.
<==

>
> b. Is it possible to apply this interface with a key hierarchy scheme?

==>MT
Yes, it is totally up to the application profile and what it defines. 
The answer above should already give more practical details on what we 
have and what seems to be still missing.
<==

>
> These features are not necessarily in scope of this draft, but it would be good to understand if a specification of these features would be able to use the interface defined here, or if some generalization is required in which case that change may be considered already now.

==>MT
Agree. The draft key-groupcomm-oscore is defining in detail a simple, 
point-to-point approach. Based on a comment above, it can be extended so 
that, in case of rekeying upon joining of a new member, the rekeying 
messages include also the public key and Sender ID of the new node (if 
this is not a Monitor).

More generally, a multicast-based approach (e.g. relying on key 
hierarchy) should be totally possible to separately define and use, once 
some general aspects mentioned in the comments above are finalized here 
in key-groupcomm to be inheritable in an application profile.
<==

>
>
> 2. How would a "minimal" profile look like?
>
> The target setting for ACE in general and this draft in particular is constrained devices and networks. Some parts of the draft give example of thinking about lightweight aspects, but other parts are not at all minimalistic and includes a large number of features, however in many cases optional.
>
> It would be interesting to have a “minimal” example, where care has been taken in trying to define a group setting such that the resulting messages are as few and as small as possible (for a certain security level). The same comment applies to code size and state machine: There are a number of options and “nice to have” features, which if all implemented could have a measurable impact on the footprint.
>
> The use of the word "minimal" is not intended in an absolute sense but to target as little as possible and still provide authorized group key functionality. Perhaps such an exercise makes more sense in an application profile, such as draft-ace-key-groupcomm-oscore. But this draft may be provide a partial answer by indicating what handlers to include (sec. 4), what groupcomm parameters (sec. 7), what error ids (sec 8), etc.

==>MT
I try to reply separately on each of the affected aspects mentioned above.

* The handlers as such (Section 4) run at the KDC, which is not intended 
to be constrained. So, we defined the KDC as expected to offer the full 
interface specified in Section 4.1. I can imagine an application profile 
that really does not need a particular subset of handlers to declare 
them as not to be implemented, possibly under certain conditions.

Thinking of a group member, I can imagine as important to have minimally 
implemented the logic for:

FETCH on ace-group/
- To retrieve the group name and joining URI from the specified group 
identifier.

POST/GET on ace-group/GROUPNAME/
- To join the group (POST) and retrieve the current group key material 
as group member (GET).

GET/FETCH on ace-group/GROUPNAME/pub-key
- To retrieve the public keys of all the other group members (GET) or 
only of some by filtering (FETCH). Admittedly, the latter might be 
sacrificed, but it allows to reduce the number of transferred public 
keys a lot.

GET on ace-group/GROUPNAME/num
- To retrieve only the current version of the group key material.

DELETE on ace-group/GROUPNAME/nodes/NODENAME
- To leave the group.


Instead, the following logic might be omitted in the implementation of a 
minimal group member:

GET on ace-group/GROUPNAME/active
- To check the status of the group

GET on ace-group/GROUPNAME/policies
- To retrieve the group policies. Thus, they would be obtainable only 
when joining the group with a POST on ace-group/GROUPNAME/ (see above).

GET/PUT on ace-group/GROUPNAME/nodes/NODENAME
- GET is for obtaining the current group key material plus the 
"individual node key material" (e.g., the Sender ID in the Group OSCORE 
case). The former can be obtained with a GET on ace-group/GROUPNAME/ 
(see above). The latter would not be possible to re-obtain as group 
member, thus expecting the group member to just remember that 
information, whose possible change happens in a synchronized way with 
the KDC anyway (see right below).
- PUT is requesting new "individual node key material" (which can result 
in the KDC providing new one, or rekeying the group, or both things 
together). This can also be sacrificed, so that a group member needing a 
new individual node key material would re-join the group with a POST on 
ace-group/GROUPNAME/ (see above).

POST on ace-group/GROUPNAME/nodes/NODENAME/pub-key
- To upload a new public key of its own. This can be sacrificed, 
assuming that a group member does not change its public key during its 
membership.


* About the Error IDs (Section 8), error responses will be sent anyway 
in case of errors at the KDC.

    The group members can of course not understand those error IDs. 
Also, based on the third from last paragraph in Section 4.0, the 
accompanying textual 'error_description' is already optional.

    Maybe it can help to:

    - Remove the parameter 'error_description' altogether; or, even more 
aggressively,

    - Make it just optional for the KDC to use these extended error 
responses with content format application/ace-groupcomm+cbor and payload 
the CBOR map with 'error' and 'error_description'.

    Thoughts?


* About the ACE Groupcomm Parameters summarized in Section 7), most of 
them are required or practically required. Some of them can be 
conditionally not supported, e.g. by particular group members. Trying to 
have a first classification below:

Must be supported:
- 'scope', 'gkty', 'key', 'num' and 'exp', as related to the group in 
question and the retrieval of its key material.
- 'gid', 'gname' and 'guri', as required for FETCH to /ace-group .
- 'pub_keys' and 'peer_identifiers', since public keys are sooner or 
later going to be retrieved, accompanied by the node identifiers of the 
corresponding nodes.

Practically must be supported:
- 'get_pub'keys' is practically necessary, except for the inconvenient 
and undesirable behavior where: i) a group member does not ask for the 
other group members' public keys upon joining; and ii) later on, the 
group member only retrieves the public keys of all group members with a 
GET to ace-group/GROUPNAME/pub-key  (i.e., never by using FETCH).

Conditionally not supported
- 'client_cred', 'cnonce' and 'client_cred_verify' are not needed to be 
supported by a node if this does not have a public key of its own that 
it uses in the group.
- 'kdcchallenge' is not needed to be supported by a node if this does 
not have a public key of its own that it uses in the group, or if it 
does not post the Token to /authz-info at the KDC. The PoP input share 
N_S of the KDC has thus to be determined differently and it's up to the 
profiles to define how (see REQ21).
- 'pub_keys_repos' is not needed to be supported by a node if this does 
not have a public key of its own that it uses in the group, or if it 
does not store the public key in a repo to point to with this parameter.
- 'group_policies' might be sent by the KDC anyway. It may not be 
supported by a node if it is already aware of all group policies. These 
may include a particular group rekeying scheme (see comment above). In 
other words, it may not be supported by a node that never joins a group 
without knowing its group policies in advance.
- 'peer_roles' goes hand-in-hand with 'pub_keys' and 'peer_identifiers'. 
Generally, it should be fine that it is not needed to be supported by a 
node if this does not have to care of the exact role of the node 
associated to a retrieved public key.
- 'control_uri', is already optional to include in the Joining Request. 
However, its support is preferable to enable even point-to-point group 
rekeying initiated by the KDC. On the other other hand, it would rather 
become necessary to support, if the group uses an advanced key 
management scheme. In such a case, a node willing to join such a group 
has to support this parameter, in order to indicate the URI of a local 
resource to the KDC.
- 'mgt_key_material' would be sent by the KDC anyway, if the group uses 
an advanced key management schemes. In such a case, a node willing to 
join such a group has to support this parameter. In other words, it may 
not be supported by a node that never joins a group which uses an 
advanced group key management scheme.

May generally be not supported:
- 'error' and 'error_description', see comment above.
- 'ace_groupcomm_profile', as already defined optional in Section 4.1.2.1.


Would this kind of reasoned classification help?

<==

>
> (This comment actually applies also to the transport profiles, which this draft does not need to take responsibility for.)

==>MT
Right, to be kept in mind for the profiles too, considering the 
additional profile-specific parameter that they can add.
<==

>
>
>   
> More detailed comments
> ===
>
>
> I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST Token” for the different message exchanges, respectively, quite confusing. For a long time I thought the latter referred to the former. It is true that the access token is carried with the method POST in the second exchange, but I think that is irrelevant and would suggest to instead use some other consistent terminology. For example, use  “POST /token” and “POST /authz-info” to refer to the exchanges, respectively. Alternatively, call the latter “Token provisioning” or something similar without reference to the actual method by which the token is provisioned.
>
> This applies in particular to:
>
> Figure 2
> “Token Post”
>
> Figure 3
> “POST Token”
>
> “3.3. Token Post”
>
> 3.3.1.
> “an OPTIONAL parameter of the Token Post
>     response message “
>
> 3.3.2
> “Token Post response”
>
> etc.

==>MT
Right, I can replace this occurrences of "Token Post" with "Token 
Uploading".

The use of "POST /token" and "POST /authz-info" is limited to Figures 2 
and 3, where it should be appropriate.
<==

>
>
> 4.1
>
> Section 4.1 specifies the handlers, 20 pages. This is followed by how the handlers are used 4.2 - 4.10, roughly one page per subsection. When reading I ended up having two copies of the draft side by side looking at the handler and its corresponding use. I'm not sure this is a problem, but reading the handlers is more motivating after having read about how they are used. There is a summary in the bullet list in 4.0 but this is merely a forward reference and didn't make me do the mapping from handler to action in my head. Maybe just move content such that 4.2-4.10 comes before 4.1 (and then you can remove the bullet list in 4.0).

==>MT
The issue is that each example in Sections 4.2-4.10 also refers to the 
corresponding handler description, which defines also the payload format 
for that operation. In particular, all the ACE Groupcomm parameters are 
introduced in Section 4.1. An example shown before that risks to not say 
that much.

I think that a middle ground can be the following, and it should also be 
aligned with and address similar comments that Cigdem gave in her review 
[1].

1) Merging the points from the bullet list of Section 4.0 into the 
corresponding resource description of Section 4.1, while still 
preserving the forward pointers. This can make it easier to map between 
actions from a client point of view with resources at the KDC, even 
though no details have been introduced yet.

2) Separately moving each current Section 4.2-4.10 right after the 
corresponding handler section, now numbered 4.1.x.y. After that, a 
better structuring can also be achieved, so that:

- Section 4.1 is renamed "Overview of the Interface at the KDC".
- The following sections lose one numbering level, e.g. current 4.1.1 
"ace-group" becomes 4.2 "ace-group".
- Each Section 4.x can be about a KDC resource. This in turn includes 
4.x.y with a handler description for resource x, followed by 4.x.y.z 
with the example for handler y or resource x (taken from current 
Sections 4.2-4.10).

That is:

4. Keying Material Provisioning and Group Membership Management

4.1 Overview of the Interface at the KDC

4.2 ace-group
4.2.1 FETCH handler
4.2.1.1 Example <Content from current Section 4.2>

4.3 ace-group/GROUPNAME
4.3.1 POST handler
4.3.1.1 Example <Content from current Section 4.3>
4.3.2 GET handler
4.3.1.1 Example <currently missing>

...


How does it sound?

[1] https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0/

<==

>
>
> "It is REQUIRED of the application profiles of this specification to
>     define what operations (e.g., CoAP methods) are allowed on each
>     resource"
>
> It speaks of operations on each resource, but it does not say which resources are mandatory to implement. Where is that written?

==>MT
Building on a comment above, the KDC is supposed to implement all these 
resources (and possibly add more if needed and defined by a specific 
application profile).

As discussed above, a minimal group member may however not need to 
implement the logic to use some of those resources.

This requirement was more intended to require application profiles to 
produce something like Figure 2 of ace-key-groupcomm-oscore , see its 
Section 5.5 "Admitted Methods".
<==

>
>
>
> 9.
>
> The security consideration speaks about different key update strategies. I was looking for considerations when to not rekey in case of new member joining a group. I would imagine in e.g. a building automation setting where a new actuator device is added into a group it may not always be necessary to renew the group key of existing actuators. This is in particular assuming by the nature of security for actuations there are already means in place to determine freshness etc. preventing misuse of an old group key.

==>MT
We can add something along these lines, especially on when it might be 
acceptable to not ensure backward security (or anyway not rigorously 
upon every single new joining). Ultimately, it is up to the specific 
application to decide and define policies for the KDC to enforce.

Besides the freshness aspects you mention, this is more about accepting 
that the newly joined node would have access to communications in the 
group prior its joining, if it has recorded such exchanged messages.
<==

>
>
>
>
> Nits
> ===
>
>
> 3.1
>
> s/Toid/“Toid”
> s/Tperm/“Tperm”

==>MT
OK
<==

>
>
> 3.2
>
> If this parameter is not present, the granted scope is equal to the one requested in Section 3.1}.
>
> - remove the “}”

==>MT
OK
<==

>
>
>
> 3.3.  Token Post
>
> - - -
>
>     “The CBOR map MAY additionally include the following
>     parameter, which, if included, MUST have the corresponding values:
>
>     *  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
>        value Null to require information about the signature algorithm,
>        signature algorithm parameters, signature key parameters and on
>        the exact encoding of public keys used in the group.”
>
>
> This seems to unnecessary duplicate information coming just after:
>
>
> “3.3.1.  'sign_info' Parameter
>
>     The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
>     response message defined in Section 5.10.1. of
>     [I-D.ietf-ace-oauth-authz].  This parameter contains information and
>     parameters about the signature algorithm and the public keys to be
>     used between the Client and the RS.  Its exact content is application
>     specific.
>
> - - -
>
>     When used in the request, the 'sign_info' encodes the CBOR simple
>     value Null, to require information and parameters on the signature
>     algorithm and on the public keys used.
>
>     The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
>     in the request is given below.
>
>        sign_info_req = nil”

==>MT
Ok, we can remove the redundancy and also be more explicit, pointing to 
the exact format 'sign_info_req' or 'sign_info_resp' used in the message 
in question.
<==

>
>
> 3.3.1
>
> I got the impression from the text above that ‘sign_info’ is the name of the parameter, but it turns out that the actual parameter is either called “sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’ encoding the CBOR simple value Null, which seems like a straightforward assignment, there is actually no ‘sign_info’ parameter. This is a minor, still slightly confusing.

==>MT
Yes, there is only one actual parameter, 'sign_info', and we want a 
single CBOR abbreviation registered for it to use in the payload map.

Using the different _req and _resp versions in Section 3.3.1 is just a 
way to make a hard distinction between the request and response case. It 
might help to improve the CDDL definition, i.e.:

sign_info = sign_info_req / sign_info_resp

sign_info_req  = nil                    ; used in a request
sign_info_resp = [ + sign_info_entry ]  ; used in a response

...
<==

>
>
> 3.3.1
>
> "This format is consistent with every signature algorithm currently
>     considered in [I-D.ietf-cose-rfc8152bis-algs], "
>
>
> s/considered/defined

==>MT
Ok
<==

>
>
>
> 3.3.2
>
> "(see the 'client_cred_verify' parameter in
>     Section 4)"
>
> Refer instead to 4.1.2.1

==>MT
Ok
<==

>
>
>
>
> 4.1.3.1
>
> “in case both the 'role_filter' array and the 'id_filter'
>     array are not empty”
>
>
> s/not empty/non-empty

==>MT
Ok
<==

>
>
> 4.1.3.1
>
>   "Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
>     and 'id_filter' MUST NOT be both empty."
>
> replace with
>
>     "Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter'
>     and 'id_filter' MUST NOT both be empty."
>

==>MT
Ok
<==

>
>
>
> 4.4
> A  missing comma at the end of the following line:
>
> "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY

==>MT
Ok
<==

>
>
>
> Göran
>
>
>
>
> On 2021-07-12, 18:16, "Ace on behalf of internet-drafts@ietf.org" <ace-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:
>
>
>      A New Internet-Draft is available from the on-line Internet-Drafts directories.
>      This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.
>
>              Title           : Key Provisioning for Group Communication using ACE
>              Authors         : Francesca Palombini
>                                Marco Tiloca
>      	Filename        : draft-ietf-ace-key-groupcomm-13.txt
>      	Pages           : 78
>      	Date            : 2021-07-12
>
>      Abstract:
>         This document defines message formats and procedures for requesting
>         and distributing group keying material using the ACE framework, to
>         protect communications between group members.
>
>      Discussion Venues
>
>         This note is to be removed before publishing as an RFC.
>
>         Source for this draft and an issue tracker can be found at
>         https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5%26q%3D1%26e%3Dfd87b927-3fdc-4d5a-ab71-6248ac68bf5d%26u%3Dhttps%253A%252F%252Fgithub.com%252Face-wg%252Face-key-groupcomm&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jG%2Fl8n4csOXfzoKTQSg9ajkCz21q7wjqAjt2GSFECyY%3D&amp;reserved=0p;reserved=0.
>
>
>      The IETF datatracker status page for this draft is:
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lDO4CzJ0LM%2F7hB3C8giMlJdNAUGkrJjqygkUCsZZUVM%3D&amp;reserved=0
>
>      There is also an htmlized version available at:
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=X%2FkLzQBW4i9tol6MvK304fGENoTlZgRT7skgeg4KH%2FM%3D&amp;reserved=0
>
>      A diff from the previous version is available at:
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Szj2SV16cyAp2YJYN149C22YRR1oaSBb%2Bvk1NYFidRU%3D&amp;reserved=0
>
>
>      Internet-Drafts are also available by anonymous FTP at:
>      https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Cg%2FMHmh0M9fwDouhpjAM%2FjKyXdk4nshAazRn5llh84M%3D&amp;reserved=0
>
>
>      _______________________________________________
>      Ace mailing list
>      Ace@ietf.org
>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&amp;reserved=0
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)