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

Göran Selander <goran.selander@ericsson.com> Tue, 14 September 2021 08:57 UTC

Return-Path: <goran.selander@ericsson.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 EBD6C3A1110 for <ace@ietfa.amsl.com>; Tue, 14 Sep 2021 01:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ericsson.com
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 tQKDPbNcfCFd for <ace@ietfa.amsl.com>; Tue, 14 Sep 2021 01:57:47 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150050.outbound.protection.outlook.com [40.107.15.50]) (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 76CEB3A1104 for <ace@ietf.org>; Tue, 14 Sep 2021 01:57:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BG7wiE4XWCV83LTOT4dfHHYqdWreMKaTytAE3stiH4yHI0pf6O9+UFI2imEpSorhvj5oOezGuNbFRB7H5BX58V5KweOsI4ZsYDkbaCTMD9rM3WSICp24zPir0efm2ww1FhfL6BnAhfYmbmUJwnwI6a5h4Qdeq+DIJVOOOQ1uWJ3jUSDW6n//cB6J/M7GVD6MsZSZCFejpUZ4ub1xE16L8Gp9QUjqY5WROmPQKPsb9t9wblFXkMNbbGwVIxQ/OUVGDAmPcZ/MR1234a+PP56qNH9PRIMcdGh0n7laiAWvLH9iT3oI9Mo+xZGPODk9sze+7+gYDJLdQN0zo0WTi1LlxQ==
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; bh=aGbvXZl9BGNkx01SilfDYhjqXWK7Mr9lDpCp4uzmYu4=; b=KhunY68JokKHRMOe3ZIJgc8Ec2MkzUPlbSLDw2quteW2QhiZu+uYMb/UcafSnITZvrvJzb7ftQnfqJcXCd8CUeCQJnnxBqIho1+hn/RkN91CG40wA4noXlRpNlz3tbnfT40vJ3eR/J3lTv0vBs0ZlJm79/QH68Yq0Bb3ZqhSNdA+wMNcfSQw3EAqzAhUTn1rWyVhxyqd31Iwe+7eKk0+qVp/JsKtt7Ani3cQDRKWazAwQNgMGb/vvNvPIfzXt66pRvsCssqBK41hbEOGfuARaZEDYpgOlrVVkWh4xVuZ8hWnd+70vxIaeX1vMelfLRKkWRD1lTR+rF0mzpwj206u9g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aGbvXZl9BGNkx01SilfDYhjqXWK7Mr9lDpCp4uzmYu4=; b=aoTpNa/3lUE4iZ25zDYZthe8a6T+UYWGmUTHA8jY0XYNvwudL8wQ2ijVpnDGSVJRISt6Jw/0XYfkQIrYOIq2qV6YkBvToOvgq4yfmxZzTfMbyKy8Y8i/Yi6GIHQKg+yajuoDH4Z2V4yG1aIx7OtLihacOHsCGrrFkXFVT3zjYWc=
Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2729.eurprd07.prod.outlook.com (2603:10a6:3:93::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.8; Tue, 14 Sep 2021 08:57:38 +0000
Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::bc2f:cb60:1534:245e%7]) with mapi id 15.20.4523.014; Tue, 14 Sep 2021 08:57:38 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] draft-ietf-ace-key-groupcomm-13
Thread-Index: AQHXlTNlf0RDV9YpEE+v7sk1YG68dquN2ssAgAMDyoA=
Date: Tue, 14 Sep 2021 08:57:38 +0000
Message-ID: <A692A685-A1EA-465B-B15B-40884115E52E@ericsson.com>
References: <E59F2C52-F777-4704-90D2-1D04C700A60E@ericsson.com> <e0d5028c-67c6-fcfd-a5db-de7c46bb4371@ri.se>
In-Reply-To: <e0d5028c-67c6-fcfd-a5db-de7c46bb4371@ri.se>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.52.21080801
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4376a99f-d1e4-4999-a31f-08d9775db433
x-ms-traffictypediagnostic: HE1PR0701MB2729:
x-microsoft-antispam-prvs: <HE1PR0701MB272948AB8AEC56D27616A0BEF4DA9@HE1PR0701MB2729.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G0pOi/V+fT0RfOUvE4rqwYBrx0zcRwI51ktoEKZKOkpOJgwdjuJNg5qYTXwOF/zKB+HXxsRw65BrvuLszQN/4v1AfpEo8BvnPDuSSthfTbhvHSSEcctRWzY4cR9R4wCHFriGJpkkOf5iehVpAIT1mO1FiZdwE7dQdNzRMpPeTFHFaGcSZput7CWcbpM+H/4jjKoQnZyVW/VGNButs7QYVIL6mjIs60bY6KK7mKhdv9IDgqCDOpeCCxcDdBEv58XlUi6dnxzEs7GkhNXLb15Q0eTIA5X9W0kI7JOeOjXrbD/7RGatuCmYqxzzuakQUebQXdrwBmGEhg2SsrRVyxYCsqwEynsrH0/UGQl2NOR88e+/6ZBk9gLnqwR8J7iWDeHTbGGVaPujWFR/kxOn4ER6TauyytywjQL9LH5bAlaMKM2OQBdw0ZEy0zR/vl3QMwskt48FC2S/8giZOezuQYaN6kCipmf08Vgs24ek+v07yy/Vrhf0aXGD8CjlpvwV/9uh5QvMHaZrzaFpz635GNiQZzkqWD1VuJuK/y2xLtmXj8GKNIShFOMmsyNvWU+IwDBiIh6P4Pr76PFKM0FNkkcRgg2/Db4HojV+HqUDgsR8XJaDFCnZoBiCcyvLHFxsO2FkEOAFG09riiP41n8i4KrdMF0vuTit7Ya8A6CiBdlmUAeHnLx8qCNJdOrlBgKDnoLZeT3hLDz0GbRPRBG2O1TNTTTy9Ec3G700iS2MQI1JHzRh5/MAQD7xCHSwhrSoz/Ttz945RQ2UfU0Wh8Tom5zWnfULdlEnm5/wVBvCIqKUqlwZNazMzpm1Fp/otIl04XoL
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(110136005)(5660300002)(85202003)(53546011)(6512007)(30864003)(316002)(2616005)(186003)(66574015)(2906002)(38070700005)(85182001)(508600001)(66556008)(33656002)(36756003)(83380400001)(122000001)(66476007)(8676002)(76116006)(8936002)(64756008)(66446008)(86362001)(6486002)(66946007)(71200400001)(26005)(38100700002)(6506007)(45980500001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cndCZmt2R3c0cmZDem1lSDlXWHMraFFaRWdYY2pZZWlpcW40QkM2alJ4dytL?= =?utf-8?B?UXUrSWN0azkyd05IRkNMR2RKWHNTRnNya0lxVkN0aFY4SDFGNjlxQmY1cEJY?= =?utf-8?B?Zkxid3RhWFRHekNOUnpmU3c1TkJuY0l2TW9QYzM5K0JGTDZnazh0UmVteEto?= =?utf-8?B?YnhTRTMrY1Urb21EckV1a0FWMnFwbjMwU2g1a1crdXEwTThnZzFlQkdoVlRy?= =?utf-8?B?eFdFK0ZmcHZ4dEl2TnZqUW5MVlNOczZURjJ6MXd4MldMZ1l1M3I1SFdxWFNj?= =?utf-8?B?SER3VnBla2x0cEpNZjUrV0JseStDWFQ3NkZhL0UyOGMxbThtdDFDNnZVQkIx?= =?utf-8?B?WU9ZVkV2QW56WkF6SGxBQ2o0eHBuL1haKzRxeGtLVk91UGZMZG1HRFRuVi9z?= =?utf-8?B?TmxhMERNY1dZQ1RlS0hxLys2NG1oNkRDQlc5VTgvZ0RnUTQrTnZ1RWxxV2Yz?= =?utf-8?B?bGJxKzZORlJIalo4UEt1TnFyUE5ILzErR2VoT2hwWGJRN2V5TmpNdFA5RUw3?= =?utf-8?B?OERFYnJVUWp1Y3JGQlRWZnlka08wZ1hPNllwMk1VMnpqL2FHTUhTVWVxb0Y2?= =?utf-8?B?T0xhZXFxejlWYk1nUnNEV2dWTlQ4S0pkMWg5WUNZNlF4LzBRWk02NDBuaFRN?= =?utf-8?B?NzdCaEtWb0tiall2VFcweEpFN014ampTNHZHeU5YR2VaNS9zZW5oSzVpc2Jt?= =?utf-8?B?blNSays5QWNGOENMc1FmNktCajlVM0oyRlpRemR0ZWZCNmNMcUg5dStCaUc2?= =?utf-8?B?WjFtV0NuOXFkc1Y4WDM4Qnk1K1pUUWFmL2dYbmp5MjdmU2RMOXBJVzZCbHIw?= =?utf-8?B?NVAveWlvc2lLeG00UE5qQkN2KzhycnlWWEptNS91NDlvNWU4b3FTYkFadlNY?= =?utf-8?B?NGNjcGRnblpYZkhLNVkyNFpVdGhEei9nWTRVMDE1YzVsYkcxd0Jzc0FIT2to?= =?utf-8?B?aGV5R2hNVmNZV1IvTU5rODR0Q2lFYWRWRHJJNFJER2IvNEFaNVhlQlRnQkxo?= =?utf-8?B?YzVxM3dPZDF6c2RaZjhKWHNlZWNLbnh2OWV1VUdaM2lYYnVpb2p6N09KUDl5?= =?utf-8?B?bjBLU25LeTJBbkFuK2hhSU1xS1htbjhhYWV1bzRmMUcrY0h3UnJqL3JrZ08w?= =?utf-8?B?R0dtRnJOajBocjE3SzNyWUlNMm53eUpnbERkSUFwSDVSUHorQnQ0Uk01cklm?= =?utf-8?B?YXJRNnhRKzl2aWJLZTc1OE8zRm1heExQUWVTUThPdlJsTEw3TGZ1L2RLcW9M?= =?utf-8?B?cWJuTkkwdTVTVkNFUzhyQzlVa2NMbXRZTkVTWEhaaVBnVWRRQWZJL2J2WUFw?= =?utf-8?B?QUh1eU5HVGQrZkFNOXMwOXJ1Y3Y2cE5semY0VGhkbTl4Kzd1QUtaM0ExNVVS?= =?utf-8?B?d21oc3grNndCS09MNkI1a2FSNWZaaVFid2hZWlNiK0t4YVZFVUlybHZvRG85?= =?utf-8?B?WkVlR2dUMGZ2WXVzZGdDUDJQZlVrM0RiVy9UblcveVozL0ZKK01KdU8rVE43?= =?utf-8?B?NU5ZMjUzM25SdUJKQ2FiTXVLWU1mTFlrZXVOUEl1Wnc3cHkranBGci9ETVF0?= =?utf-8?B?OXorcHNLUGJuWFg5MVJMR0g4dEEvZHhsaTBmc2hPc3JNQno4MngvWW1LNFBE?= =?utf-8?B?TGVnT002SXgwYm1OQlJ2ZHpmRDdWdGRYMlRvQkRaV2hTaTJWSkJuN28xcmVZ?= =?utf-8?B?bnl2UWJnZ3dBM2hhVmppVmpkcTlJMnRFZ1R5RURvMnJtZmJlNXROY1AvVXpG?= =?utf-8?B?dEtEaHIwR3BWZGRkaGlRNHZtdmNaYzJxQmJiYmdqUnNTQ2QxNXJWZG9PdkIy?= =?utf-8?B?SkVxcFhiVTQvYWpnNUJwZz09?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <BFB4E52A7259A04FAD8CB0F23E9AB41B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4376a99f-d1e4-4999-a31f-08d9775db433
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 08:57:38.7253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tGt1W8TwHpFT4fhee+TPw9ZByIzIcPCTfxJMErhv+5RYS3sdg8V6QdlywHAtH0isDx5ybXjTKr7+Nd78OgY6ee+BBD6fx5C/e19LoEGs8RE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2729
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/fzOYguO-I7B9epDdwBuKp1bIt4A>
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, 14 Sep 2021 08:57:53 -0000

Hi Marco,

Please find responses inline.

On 2021-08-31, 18:10, "Marco Tiloca" <marco.tiloca=40ri.se@dmarc.ietf.org> wrote:
    On 2021-08-24 18:52, Göran Selander wrote:
    > Hi,
    >
    > Here is a review of ace-key-groupcomm-13.
    >
    >
    > General
    > ===
  
    > 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.

[GS: OK.]

    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.

[GS: Sure, I could have been more accurate and written "a key derived from some existing shared key". This can be done in different ways but since this draft is about rekeying for group communication in resource constrained settings, shouldn't the use of the existing secure group communication be defined here or in an application profile?]

    >
    > 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.
    <==

[GS: Thanks, I missed that. It seems inevitable for good scalability that at least the application profiles define this. More below.]


    >
    > 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.

[GS: Right, so there are components defined which can be used for this purpose.]

    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?

[GS: If needed for simple configuration, then I'd say "yes", see below.]

        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.
    <==

[GS: Thanks for elaborate response. Maybe what I'm missing is a simple example of how to apply the different components of  this draft for using a key hierarchy scheme (again, could go into a profile). On the latter topic of what information needs to be provided before joining, some configuration data can be assumed to be pre-configured. To re-iterate: I'm not looking for a "complete" scheme which takes into account all information flows in all possible key distribution schemes, but making sure that there is a simple deployment which scales to very large groups.]

    >
    > 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.
    <==

[GS: OK! Any thoughts on where to put such an example?]

    >
    >
    > 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.


[GS: This type of discussion makes sense to me and I think it should be somewhere in the draft. The specification of exactly what of these to support is not part of this draft, but could go into an application profile, or some "compliance" document used for a particular deployment.]


    * 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?

[GS: I think the focus should be on what actions follow from the error message, either autonomous or by humans. Detailed error codes can make sense for these settings when there are different autonomous actions that can follow from the errors. In case the errors anyway needs to be resolved by a human, a human readable diagnostic message could be an alternative. Having said this, it is not clear to me what can be predicted about deployment of a particular profile of this draft. One question to ask is if the error semantics should be left more to the profiles or does the current error codes have value for intended profiles?]

    * 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?


[GS: Yes, I think some reasoning or classification would be instructive.]

    <==

    >
    > (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".

[GS: Good. (Perhaps consider also other synonyms to "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/

    <==

[GS: Sounds good!]

    >
    >
    > "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".
    <==

[GS: OK]

    >
    >
    >
    > 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.
    <==

[GS: 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

    ...


[GS: Yes, that reads better to me]

Göran