Re: [Ace] Review of draft-ietf-ace-pubsub-profile-03

Marco Tiloca <marco.tiloca@ri.se> Tue, 12 October 2021 09:08 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 E1F673A0D09; Tue, 12 Oct 2021 02:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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 xTXi6rLo1bQx; Tue, 12 Oct 2021 02:08:46 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::623]) (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 C4F7C3A0C59; Tue, 12 Oct 2021 02:08:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WIz15erceRDL+4dkXAjpMqhCc9A3YC3uOdT1Jz4+iZ6/4WOw6yG6JnM/gWTgcdnBLtl5cQ8aJF9EB6l3X+KD7f5uX1xZgEFTNMHRwClaU/sJ4Pbd6ebUGRlrl8l94F5TULHqyx+gWaX2HXxOmg6/0kBpFO5Uw/R5FtbJaiWW4gUETtn9hcprorhL3e+wppr2MZ74tvotbVjs7jj6rM10sHVH0stnP8ZPifDB6U7IDeNUJu1biUY0S50V5fUAGV88s5zlUrV0apoKb0VlOB2ADui+UP87kwujh8kz/tOQQNbT+LI/1F32+U+NUy8FCSmxuT6MyRoNU2xHeMX4516tKQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LoY1fmqgQVZemVNrVC3U1+sru1NMeoyh7U6N2bhVfXM=; b=mCjDVS8J0xshwTJQ+yh6TMDcTSfgFzFKz2jMcdsne47iH7D0oumq99T8MApfvKOTzxZ6DhpCXeMf9jVD82j3fsuf90ZAWe5PTu15zRjzg44cMia/li+4z04qWqIXKUJzpQYC9oxup5JIX9priFvUfBZEy/0+T14ksA1M05PZwZ16n3fii7CuMDGVPYuJc6D5HZx2e18RKTmp4AY4okH/cK0x9j4/ZuyHVXDlAZmK8zuImYvfCrH9SbsJNIxN4UR8ZM0sZwriCgswefzf4mnk6sZGLAyBEsX8K8yH0W1E6l2a9SBLe+d1GFkLd4DxjzJvUo/76FTuU1FcceY3apzxvQ==
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=LoY1fmqgQVZemVNrVC3U1+sru1NMeoyh7U6N2bhVfXM=; b=HQOvBqFYZAsOsccXYSlXXc0ocmXvk1XwwMyKlhcyki6IqnL7rpSt0PXTFXbq3QPdINUC+6ezEIJ4OCXqk3Ti5Bo/tSBDKNClj71bEBrl4oi8FG6imfOZ1NLjrFSpJa7CbjrfMiGtbBPoc+43HUCVjX0VTAxOOhV8fxhnenQArNk=
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 DB6P18901MB0198.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Tue, 12 Oct 2021 09:08:33 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%3]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 09:08:33 +0000
To: Cigdem Sengul <cigdem.sengul@gmail.com>
Cc: draft-ietf-ace-pubsub-profile@ietf.org, Ace Wg <ace@ietf.org>
References: <7312f414-23c6-fefa-7528-ab4ffb3575e6@ri.se> <CAA7SwCPcN6=O4J98CGYKnzaOPNtyoMA3XxcD4c1V1QwOmZtFMg@mail.gmail.com>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <c8924f71-8a9f-b9cf-00ea-16c0beda38da@ri.se>
Date: Tue, 12 Oct 2021 11:08:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <CAA7SwCPcN6=O4J98CGYKnzaOPNtyoMA3XxcD4c1V1QwOmZtFMg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="VteI55IvSxel7vs9LLGSw91Lsh9CYkBnR"
X-ClientProxiedBy: OL1P279CA0048.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::17) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
Received: from [10.8.0.5] (185.236.42.79) by OL1P279CA0048.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.26 via Frontend Transport; Tue, 12 Oct 2021 09:08:33 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1b2e8b6e-c279-4b7e-999d-08d98d5fddec
X-MS-TrafficTypeDiagnostic: DB6P18901MB0198:
X-Microsoft-Antispam-PRVS: <DB6P18901MB0198229D2BD5900B3A1662BB99B69@DB6P18901MB0198.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: Ej56tg5UnDDrOdWnN+1CHhrErx3uBH4NwD9AF4HJFtfEMi6fZxkCSbPS56MD6dGQ2fFoPPZiVzbMGUYlucCT7xVLlELB0xHOA+uZsRyh9mI+5yHUszuc1ETxDWmLFC+rdB9LLbG1fweqn6VRZVnwF+P2LijulKqnmAcd3cHXpNX1ksnKsVrYAuv5PeEec7AB5WKHEj7NHX9AoA6IArmcBAcfJvqcXU8QTfEIzXasUzlNtx3mTi8/rC8CElWxIoJWRI9zUeCBDarcnYJmM5Waowe4SC9ZzC6Ffjusyn1pB4nChG6l2kkKceDx33/kojCxfLWuAVAGFYiS8RImg+p30gNNLG9F/od5oatomVVAg6+k5WshG8Qp/Xz24R+BjbSwEgYEUJarwIN9oVYQVDwkQVxMtdb82w15LeKiag6NWsU3u/EelaJy6junr6sro47BG3ayCLr5GbMjsJJypHDR19TKl2zlpallfPWANuk+HiwUPbzbkzlpT0f4z9iNBYPrs1zqHIO+ny5r06NSpHAN54Ucqa/Mg8WWlvjWNNOLlUskgSs0lDGAcQEqh7anfIGnqBIenkrS5YPl4UeXNVYFxJa9qxPSyuAx6NxGLWB9+4zsjVfXt8HSxHv/62VgkoX9bbBisdt+wOQkIR6Z4HN1oEJK8jZzLv6+7UhZodPSQxfYmar3omYoLM8QHwPqXuVeLv1iho1Lk6AHgXS/fBtkRWUUBZwgfCutGACyYWqZ6JI6ObRF0iDJ2UxobdZ7BkpuTmeWG5Cq+Jexf7kiRYg3pS8c5WVJTE13abxzuFKT61gGQtHPYU9TD5RkgST/YdOF
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)(366004)(8936002)(66574015)(31686004)(66476007)(66556008)(66946007)(19627235002)(36756003)(83380400001)(30864003)(2906002)(31696002)(956004)(2616005)(186003)(8676002)(45080400002)(16576012)(508600001)(235185007)(5660300002)(38100700002)(966005)(166002)(53546011)(6916009)(86362001)(316002)(6486002)(4001150100001)(44832011)(21480400003)(26005)(33964004)(4326008)(45980500001)(43740500002)(579004)(559001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 3zRz+KHfb5fF1WZDbT7Rez3Smn8kG2glrmVaKWQgUO669A2Z6dgmSi6m2vUt4JVHWK/7GcLNM0J0SDNKOdVIT/hrpewx++2LAeVFrfYxvsnzcShzq1/0xD7fnvgZF8Awaa/dYrf4Xfcho1p9kaEEJnHlJItGZ74tqXjrHy6HW+yKYzHwM+mjrPaSeyRw/ms15sy9mngflnauyT9+9zGno+4aFvqhg589P+LyuMhI0UCJJpy5WVgkRXABKt7GFEwHnwaabbkxqiUypli2MmRVPdZblxJQnZCnUy7cbheKoVjc5cR9Bl2XAb38YB2T8JPgjz1U4JJ3h8pxP0M5TpyPkgKJypSMC1EZlnObRIcktVtNwwrCeGBRF2oLb6RklcpajClImIGGRn6XapPb1Qc+o5fEtCvX4Ifxj3FO4GX517CD3/tVMYxL6MPirT3jchJqFTG8boAmFyJxgm4BpIvhZoh6+GbzjuAKDU0YH44/ucT4iR9DVkAF+pu+yoLHFF81O4zuYoPrfvv1evi501Ts9jPIbcM7tdRnIrXegY5kIc6EElTXYnjnKG8Emtk9PRmBihoxiHM0+qVlohzZRcTM9tniA7TUcp8DAq45veTMig09Fxu803ib/1WsZoSTP0m99Qf2Me+ru4gu+NB+s4q+QsN7bW6FkPub0Rcqi9LpGjrpo6ax95rjCXeBGhaa/a2Eetg3A6aB3HzEmD0k3SEFfRkkN6LhjL+x4fFQeBehIzmqdtvZqbgo2aq0FxrxYC34Bj+tA+o2JEa6/mcOYUoXY8chlyBp/thcHEkCCzx2UMsts39twLOJL1O8/j02AhiaR3TNnFUKDkTJOisH1fgJwleqgvdLo+3Vg3CzfIW9fDsl8esuo3PHz4sl9I/dspm6/zyk/UaW7yvmsyKeoIUMUS4x/zYl5IaI2HqFYPj2r/d3affX7ssxT9ObVrF7dk8aRtGZ0roCeWKnaZDPeLDUdESrm2hdLmHA8JbOTJhvfGhjvYWLn43eJnjmbaS53+eaZVsF7F6PkoGdSF53Wq0DOBEMPin3mCMlbwysxHcwW17NosM5wXjG3hI7YA3Vv/wdqnbw2JylfJ9PYUuuG/ULq551FNemdPBXz3t3FWRmbQ3o9kxYSEm9eVgXEBjep/Y7+wmgDKkUe7za8EIqf0Xu+GkSEJTSPDfJkKjYIwlbN1hPJc4oNLHJb3UknVfjzTWp9VCbUrXGjbaHkJssT1eGOyshSLDtZn8wRlk8+LwT4XqW5z8amNApLZYF5IE9CNJE6OxZofn+Zgd64rUyCAq51nwKghF7iC6OmpvT0emgkEGznjD657NigbvbzSRqradf
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b2e8b6e-c279-4b7e-999d-08d98d5fddec
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2021 09:08:33.7472 (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: bz0+CUe0p7kx4Xgm+wGw7wfvjfLEOr3CbUix29IBPCZPDGv7CRj9jb3bq5Rk+aWtPH9fg6VElnmcD3vQQsLpTA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0198
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/hC44nTuvuqj6xuSoiZm_uHKClLA>
Subject: Re: [Ace] Review of draft-ietf-ace-pubsub-profile-03
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, 12 Oct 2021 09:08:56 -0000

Hi Cigdem!

Please, see my replies inline, marked as "==>MT".

Thanks,
/Marco

On 2021-10-11 18:28, Cigdem Sengul wrote:
> Hello Marco,
> Apologies for the late response - many thanks for the review.
> I think there will be some items to discuss further with Francesca, 
> but I tried to make sure we have a plan for revisions as much as possible.
> Comments as usual uses [CS:] inline.
> Kind regards,
>
> On Mon, Aug 30, 2021 at 7:15 PM Marco Tiloca <marco.tiloca@ri.se 
> <mailto:marco.tiloca@ri.se>> wrote:
>
>     Hi all,
>
>     Please, see below my review of version -03.
>
>     Overall, I think this is on the right track and I do appreciate
>     having
>     converged to a single AS :-)
>
>     I hope the comments can help improving and progressing the document!
>
>     Best,
>     /Marco
>
> [CS: Many thanks, we appreciate it]
>
>
>
>
>
>     This review uses "KG" to refer to draft-ietf-ace-key-groupcomm-13
>     [KG],
>     and "KGO" to refer to draft-ietf-ace-key-groupcomm-oscore-11 [KGO].
>
>     [KG]
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639370672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=iSm06pxr%2BrhtsQC287IG1n9646N9Veii8IwPILXAdSQ%3D&reserved=0>
>
>     [KGO]
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-11
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-oscore-11&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639380626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=8Ap5YW95cHjOgFZVPhK9DODoq7KaSjVXFoTkIabUj2w%3D&reserved=0>
>
>
>     [General]
>
>     * Please, replace references to RFC 8152 with references to
>     draft-ietf-cose-rfc8152bis-algs and
>     I-draft-ietf-cose-rfc8152bis-struct.
>
> [CS: OK, will do]
>
>
>     * This draft is basically using only the ace-group/GROUPNAME
>     resource at
>     the KDC defined in KG, and only its POST handler for joining a group.
>     Will this draft describe/mention also how the rest of the KDC
>     interface
>     is used by the pub-sub clients?
>
> [CS: I think we should definitely look into it; will go through all 
> resources available, and will try to create
> a table of what MUST be used, what is RECOMMENDED to use, and what 
> will not be used by the profile.]

==>MT
Please consider the classification and profile guidelines now in Section 
4.1 "Interface at the KDC" and Section 4.1.1 "Operations Supported by 
Clients" from the Editor's copy of ace-key-groupcomm.

In particular, a profile can declare some resources/operations as not 
needed to be supported by the KDC. Also, operations from a Client point 
of view follows a more fine-grained classification, that can be made 
stricter or extended in profiles.

These aspects are captured by mandatory-to-address profile requirements, 
some of which (and further related ones) are newly introduced following 
review comments to ace-key-groupcomm.
<==

>
>
>     [Abstract]
>
>     * "This profile relies on transport layer or application layer
>     security
>     to authorize the pub-sub clients to the broker".
>
>         This is aligned with the currently existing transport profiles of
>     ACE (based on DTLS and OSCORE). However, do you actually want to
>     limit
>     that security enforcement to those two layers?
>
>
>         More in general, I think this application profile can build on
>     any
>     transport profile of ACE that the broker and the KDC are fine to use
>     with the pub-sub clients. This seems in fact the intention later in
>     Section 2 and Section 4.2, where some transport profiles are
>     mentioned
>     as a non final set to choose from. 
>
>
>
>     * Proposed expansion of the last sentence:
>
>         "... it describes the use of application layer security to
>     protect
>     the content that pub-sub clients exchange by communicating through
>     the
>     broker."
>
>
> [CS:  So your suggestion is not to limit the coap pub-sub or mqtt, and 
> how they are secured
> but be more generic?]

==>MT
Keeping it for pub-sub and mqtt is fine. I was thinking on being more 
explicit on what application layer security is used for, trying to 
anticipate what later explained in Section 5.
<==

>
>
>     * While it is mentioned later in Section 1, I think that the abstract
>     should already mention that this profile covers both CoAP and MQTT.
>
>
> [CS: OK, will do]
>
>
>     [Section 1]
>
>     * "This document defines a way to authorize pub-sub clients using the
>     ACE framework ...".
>
>          Please, clarify what they are authorized to do. Conceptually, it
>     should be about joining a security group that uses certain key
>     material
>     and is associated to one or more topics (application groups).
>     Practically, this should mean being authorized to getting access
>     to the
>     broker and to obtaining the key material for protecting the topic
>     content exchanged through the broker.
>
> [CS: OK. how the clients get authorisation to talk to the Broker is 
> actually covered in other profiles (e.g., MQTT-TLS profile)
> This one describes how they are authorised to get the keying material 
> to protect the payload of their communications from the
> Broker.]
>
>
>     * "... for protecting the communication between them".
>
>         I would emphasize that it is about protecting the content,
>     exhanged
>     by communicating through the broker (see also the related comment
>     above
>     for the Abstract).
>
>
> [CS: Yes]
>
>     * After "(CoAP)", please add a reference to RFC 7252.
>
>
> [CS: OK]
>
>
>     [Section 2]
>
>     * "Note that both publishers and subscribers use the same profiles."
>
>         I suggest to expand as follows: "Note that both publishers and
>     subscribers use the same pub-sub communication protocol and the same
>     transport profile of ACE in their interaction with the broker. The
>     same
>     profile of ACE is also used in the interaction with the KDC."
>
> [CS: OK]
>
>
>     * Caption of Figure 1: s/Authorization Servers/Authorization Server
>
> [CS: Will fix]
>
>
>
>     * "... so that RS can authorize the Clients ..."
>
>         Well, the AS is the one authorizing the Clients. I think you mean
>     "... so that RS can assert the Clients to be authorized ..."
>
> [CS: yes, that's too much of a short cut, will fix.]
>
>
>     * I suggest to move the following points out of the last
>     paragraph, and
>     instead have them after "... to as Client in short."
>
>         - The broker acts as ACE RS.
>         - The broker corresponds to the Dispatcher in KG.
>
> [CS: OK]
>
>
>     * The last sentences can be expanded for clarity, e.g.: "... the
>     Broker
>     MAY accept subscriptions from unauthorised Subscribers. In this
>     case, a
>     Subscriber client can skip setting up Security Association 1 with the
>     Broker, before subscribing to topics of interest at the Broker."
>
> [CS: OK]
>
>
>     [Section 3.2]
>
>     * Consistently with the first paragraph, the section title can be
>     "Authorising to the KDC and the Broker".
>
> [CS: OK]
>
>     * About 'scope', s/the topic identifier/the topic identifiers
>
> [CS: Will fix]
>
>     * About 'audience', it cannot be an array, but only a single text
>     string, see [1]. If you want to keep a single Token intended to
>     both KDC
>     and broker, then you neeed to rely on a single audience value that
>     both
>     the KDC and the broker recognize as valid. A possible way can rely on
>     the KDC identifier and the broker identifier separated by a
>     well-known
>     and unambiguous separator.
>
>     [1]
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-5.8.5
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-oauth-authz-45%23section-5.8.5&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639380626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=J7EMHpexA16%2Bp61zzhGQIV9PSx7ltYiwgsMChslFib8%3D&reserved=0>
>
>     [CS: My bad, was thinking here a JWT, where  in the general case,
>     the "aud" value is an array of case-sensitive strings.
>
> But I think we won't be able to keep a single token, but will have to 
> use multiple tokens, once for KDC and one for Broker, where the Client
> will have to make two calls two /token to the AS for two different 
> audiences. Since the AS is the same, we do not think there will be an 
> issue
> of policy mix-ups, and hence this should be all cleaner.]

==>MT
Agreed.
<==

>
>     * More generally about using a single Token intended to both KDC and
>     broker, that requires additional security when protecting the
>     Token, as
>     per [2].
>
>         First, you would need the AS to also protect the Token with an
>     asymmetric signature, that both the KDC and the broker have to verify
>     using the AS' public key. See the second paragraph of [2].
>
>         Second, since the same Token is targeting multiple Resource
>     Servers
>     as part of a broader audience, you cannot have a same single
>     secret used
>     as symmetric PoP key, see the third paragraph of [2]. This seems to
>     limit the use of the DTLS profile to its aymmetric mode only, and to
>     rule out the use of the OSCORE profile.
>
>         I don't see an obvious way out, other than reverting to two
>     separate
>     Tokens, i.e. one to post to the KDC and one to post to the broker.
>
>         [2]
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-6.1
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-oauth-authz-45%23section-6.1&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639390590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=lWYVqkWVdhRB5vjvDDcRwjBmbDT8hdZY2SmvfhU0QiY%3D&reserved=0>
>
>
> [CS: Yes, because of all these, we will most probably just go for two 
> tokens esp. when ACE defaults
> to symmetric crypto.]

==>MT
+1
<==

>
>
>
>
>     * If a single Token is used for both the KDC and the broker, one
>     additional clarification is probably required.
>
>         Since the 'scope' claim in Token indicates names of application
>     groups, posting the the Token to the broker indicates which topics
>     the
>     client is authorized to publish/subscribe to.
>
>         However, what does it mean when posted to the KDC? I suppose it
>     authorizes the pub-sub client to obtain from the KDC the key material
>     for any security group associated to any of the application groups
>     mentioned in the Token.
>
>         Note that the 'scope' parameter of the Joining Request to the KDC
>     specifies the name of the security group for which the key
>     material is
>     requested. So, the KDC will need a kind of internal mapping from
>     names
>     of application groups (in the Token) to names of security groups
>     (in the
>     'scope' of the Joining Request). Even in the simple (and most common)
>     case where only one security group is associated to an application
>     group, the two names might differ and it's up to the client to
>     know both
>     of them in advance --- through pre-configuration, discovery, etc.
>
>
> [CS: yes, some kind of internal mapping from scopes to security groups 
> would be needed.
> This possibly answers my previous question to groupcomm Why KDC would 
> keep a different naming for
> groups :) ]

==>MT
Right, although, as above, this is probably going to be moot when two 
distinct Access Tokens are used, separately for the KDC and the Broker.

Then, the Access Token to be consumed by the KDC would have a scope 
indicating security groups (just as per ace-key-groupcomm), while the 
Access Token to be consumed by the Broker would have a scope indicating 
application groups.

The access policies configured at the AS have to be such that, following 
the Authorization Request/Response exchange, a Client can successfully 
access all the security groups associated to the application groups in 
question.
<==

>
>
>     * s/'profile' is set/the 'ace_profile' claim is set  (two occurrences)
>
>
> [CS: Will fix]
>
>
>     [Section 4.1]
>
>     * By using 'sign_info' during the Token post, the client cannot
>     ask for
>     the public keys already, but only for the format of public keys
>     used in
>     the group.
>
> [CS: Will revise those parts more carefully]
>
>
>     * "The KDC verifies that the Client is authorized to access the topic
>     with the requested role."
>
>         Well, the KDC is in a trust relation with the AS issuing the
>     posted
>     Token (and only following a successful check of a Token request
>     against
>     stored access policies). So, at this stage on the KDC, isn't this
>     just
>     about verifying that the Token is valid?
>
>
> [CS: Yes, the language used is weird, what is meant is the KDC 
> verifies the token]
>
>
>     [Section 4.2]
>
>     * Considering its content and the examples, the section can be
>     renamed
>     as "Join Request and Join Response".
>
>
> [CS: +1]
>
>
>
>     * The content-format of the Joining Request is
>     "application/ace-groupcomm+cbor". That's the "namespace" where
>     these new
>     ACE Groupcomm parameters have been registered, see Section 7 of KG.
>
> [CS: Will add]
>
>
>     * As to 'scope', here it is not "as defined earlier". In
>     comparison with
>     the format defined earlier, it specifies only one scope entry,
>     i.e. the
>     one indicating the exact topic for which the client wants to
>     obtain the
>     key material with this Joining Request. This is also defined in
>     Section
>     4.1.2.1 of KG.
>
>
> [CS: True, will fix]
>
>
>
>     * "... Client's public key formatted as a COSE_Key"
>
>         In KG, there has been a change about the format of public keys
>     used
>     in a group.
>
>         Pure COSE Keys are not admitted anymore, due to their
>     limitations to
>     represent identities or other metadata. This is aligned with
>     corresponding changes done for the same reasons in
>     draft-ietf-lake-edhoc
>     and draft-ietf-core-oscore-groupcomm .
>
>         The format of public keys used in the group and indicated in the
>     parameter 'pub_key_enc' now takes value from the "COSE Header
>     Parameters" registry, for which some entries are under pending
>     registration.
>
>         The easiest way to "somehow still use COSE Keys" is to use the
>     public key format Unprotected CWT Claim Set (UCCS) [3], including
>     a COSE
>     Key as value of its 'cnf' claim. Please, see an example below. You
>     can
>     find some more detail on this point in Sections 6.1 and 6.4 of KGO.
>
>     {                                              /UCCS/
>        2 : "42-50-31-FF-EF-37-32-39",               /sub/
>        8 : {                                        /cnf/
>          1 : {                                      /COSE_Key/
>            1 : 1,                                   /alg/
>            3: -8,                                   /kty/
>           -1 : 6,                                   /crv/
>           -2 : h'C6EC665E817BD064340E7C24BB93A11E   /x/
>                  8EC0735CE48790F9C458F7FA340B8CA3'
>          }
>        }
>     }
>
>         [3] https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rats-uccs%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639390590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=AUrp%2FNmOzzA21EqwI7MqGlGD0Gjmw6wsGDe5ntKDhUI%3D&reserved=0>
>
>
> [CS: Will look into aligning with the current drafts]
>
>     * On expectable actions around "TODO: Check 'cnonce'", you may
>     also want
>     to look at Sections 6.2.1 and 6.3 of KGO.
>
> [CS: Will do]
>
>
>     * "The Subscriber MUST have access to the public keys of all the
>     Publishers; this MAY be achieved ... using "pub" as the
>     'role_filter' ..."
>
>         Why do you need the filtering feature here? It would still
>     work, but
>     based on the previous sentence in the same paragraph, the KDC has
>     available to provide only public keys of publishers anyway. So,
>     asking
>     for all the public keys in the group with 'get_pub_keys' encoding the
>     CBOR simple value Null will return only the public keys of
>     publishers by
>     construction.
>
> [CS: That's true, will revise]
>
>
>
>     * "Note that the alg parameter in the 'client_cred' COSE_Key ..."
>
>         See the comment above about the format of public keys not
>     using pure
>     COSE Keys anymore.
>
> [CS: Will revise, thanks]
>
>
>     * s/The KDC response to Joining Response/The KDC replies with a
>     Joining
>     Response
>
> [CS: Will fix]
>
>
>     * The fields of the joining response are defined in Section
>     4.1.2.1 of
>     KG (not in its Section 4.2).
>
> [CS: Will fix]
>
>
>     * The content-format of the Joining Response is
>     "application/ace-groupcomm+cbor".
>
> [CS: Will add]
>
>     * When describing 'key', "defined by the AS2" is mentioned for both
>     'alg' and 'Base IV'. I guess this is a remnant from previous
>     versions of
>     the draft having both AS1 and AS2.
>
> [CS: Yes, will fix]
>
>
>     * Before defining the format of the Joining Response, it's good to
>     introduce the symmetric key as generated by the KDC, later
>     provided to
>     all the clients joining the group, and what it is used for.
>
>
> [CS: +1]
>
>
>     * "... public keys of all authorized signing members ...", which
>     means
>     just the publishers, right?
>
> [CS: yes]
>
>
>     * "... formatted as COSE_Keys ..."
>
>          See the comment above about the format of public keys not using
>     pure COSE Keys anymore.
>
>
> [CS: Yep, will revise]
>
>
>     * "... For Subscriber Clients, the Joining Response MUST contain the
>     'pub_keys' parameter."
>
>          Why? Even if the client did not ask for them in the Joining
>     Request? The sub-resource at ace-group/GROUPNAME/pub-key allows for a
>     later retrieval, possibly spreading the provisioning of public
>     keys in
>     different exchanges through filtering.
>
>
>          If you really want what you're saying here, it might be just
>     easier
>     to say upfront for the Joining Request that Subscriber Clients MUST
>     include 'get_pub_keys' --- While that uses a MAY at the moment.
>
>
> [CS: I am not sure about this MUST either, it was in the draft with 
> these conditions, and I did
> not question until now. I will check with Francesca]
>
>
>     * Figure 6 and Figure 9 will need to be revised based on the comment
>     above about the format of public keys not using pure COSE Keys
>     anymore.
>
> [CS: Added to the to-do list]
>
>
>     * The public key of Figure 6 (in 'client_cred') and of Figure 9 (in
>     'pub_keys') includes also the 'kid' header parameter. This is not
>     mentioned earlier in the text describing the Joining Request and
>     Joining
>     Response.
>
>
>         In particular for 'client_cred' in the Joining Request, this
>     gives
>     the impression that it is up to the client to self-assign a 'kid'
>     value
>     to its own public key. This can later result in collisions, i.e. two
>     publishers may have a public key with the same 'kid' value. Later on,
>     this in turn puts a subscriber at least in a situation where it might
>     have to try verifying a message signature using different public
>     keys,
>     until the right one is used.
>
>         I think it's better that the KDC exclusively determines these
>     identifiers, as uniquely associated not only to the public key for
>     its
>     retrieval but also to the corresponding publisher client. As to the
>     actual provisioning of these identifiers, there are two ways:
>
>         a) The one currently used in the Joining Response, where that
>     identifier is the value of the 'kid' header parameter; or, as I
>     believe
>     a better option,
>
>         b) The separate 'peer_identifiers' parameter defined in Section
>     4.1.2.1 of KG.
>
>         In either case, I think it's fine later on in Section 5.1 to
>     have a
>     published message specifying in the 'kid' COSE parameter the
>     identifier
>     to use for retrieving the right public key.
>
>
> [CS: Will need to think about this - but yes, it needs fixing]
>
>
>
>     * Based on a comment above on which public keys the KDC actually
>     stores,
>     Figure 8 may have 'get_pub_keys' simply encoding the CBOR simple
>     value Null.
>
>
> [CS: OK]
>
>
>
>     [Section 5]
>
>     * s/is protected with COSE/is protected with COSE by the publisher
>     (two
>     occurrences)
>
>
>
> [CS: Will fix]
>
>     * Figure 11 and the following paragraph should show/mention that,
>     when
>     using CoAP, Observe (RFC 7641) is used together with GET in order to
>     effectively subscribe. See also [4].
>
>     [4]
>     https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09#section-4.4
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-coap-pubsub-09%23section-4.4&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639390590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=dQjJSzyXlNXtI%2B425mryJ0fyFy99DD8jNVUdYK0pdKk%3D&reserved=0>
>
> [CS: OK]
>
>
>     * I think it can be better to swap this current Section 5 with the
>     current Section 6. Even though separately for the CoAP and MQTT case,
>     Section 6 covers the Token posting at the broker, which happens
>     before
>     the actual pub-sub communication described in Section 5.
>
>
> [CS: Let me think about this but I think you are right]
>
>
>     [Section 5.1]
>
>     * s/COSE_Encrypt0/COSE_Encrypt0 object
>
> [CS: Will fix]
>
>
>     * I suppose the empty string for the 'external_aad' applies to
>     both the
>     encryption and the signing process. Correct?
>
> [CS: That was my understanding]
>
>
>     * In order to encrypt the message, how do you build the AEAD nonce?
>
>         All the group members have the same Base IV received in the
>     Joining
>     Response, and clearly they are not expected to synchronize with one
>     another about their individual message counter used as Partial IV.
>     Hence, the basic Message IV construction constisting in xoring the
>     Base
>     IV with the zero-padded Partial IV yields the risk of reusing the
>     same
>     (nonce, key) pair.
>
>         If the KDC exclusively assigns the identifiers for public keys
>     and
>     group members (see comment above), it should work to build the AEAD
>     nonce in a similar way like OSCORE does, see [5].
>
>         That would also mean having a quite smaller Partial IV in the
>     unprotected header of the COSE_Encrypt0 object, while now in
>     Figure 12
>     it consistently has a size of 7 bytes as expected for the AEAD
>     nonce by
>     AES-CCM-64-64-128.
>
>         [5] https://datatracker.ietf.org/doc/html/rfc8613#section-5.2
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8613%23section-5.2&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639400532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=yImA9pV2JxMtVxlZuHtffiyNLyVKIxpu6qmzOiLR6L8%3D&reserved=0>
>
> [CS: I need to have Francesca's opinion on this, as I have not 
> contributed here.]
>
>
>     * Please, add a reference to draft-ietf-cose-countersign , and
>     specify
>     that you are using the structure COSE_Countesignature.
>
>         As a related point, the value 7 used for 'countersign' in
>     Figure 12
>     is going to be deprecated [6], so it'll need to be updated later on.
>
>         [6]
>     https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign-05#section-5.2
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign-05%23section-5.2&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639400532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=JoF4q6y8fGFbjjbnIgw%2BKLo9jUvms3JNRzPGdUgFpoA%3D&reserved=0>
>
> [CS: Will revise]
>
>
>     * "The protected Headers ... MAY contain the kid parameter, ..."
>
>         It is optional for the KDC to provide one in the Joining
>     Response,
>     but I guess that if one is provided, then it MUST be included in the
>     protected header.
>
> [CS: OK]
>
>
>     [Section 6.1]
>
>     * "For implementation simplicity, it is RECOMMENDED that the ACE
>     transport profile used and this specification use the same format of
>     "scope".
>
>         Is this actually meaningful and enforceable?
>
>         The format of scope is related to the application that the Client
>     and the RS want to run. In fact, these _application_ profiles for
>     group
>     communication are defining formats to use for scope, in Tokens
>     used to
>     access resources related to such applications.
>
>         In other words, I think the format of scope is orthogonal to the
>     used transport profile, that basically does not care (and should
>     not). I
>     also can't find anything suggesting otherwise in the ACE framework
>     [7]
>     or in the DTLS and OSCORE profiles.
>
>         Unless I'm missing something, it's probably just fine to
>     remove the
>     sentence.
>
>         [7]
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#appendix-C
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-oauth-authz-45%23appendix-C&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639410503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=USe7Tn5PSwr8lkQ5pjzeDXO3pQWF%2B%2Bc0ZQtQifexcIc%3D&reserved=0>
>
> [CS: I think this was triggered by MQTT-TLS Profile providing a scope 
> format to be used
> in access tokens, and it would be useful the scope format is used 
> towards KDC. But, it may not
> be necessary at the end. Will remove]
>
>
>     [Section 6.2]
>
>     * "An application group has relevance at the application level - for
>     example, in MQTT an application group could denote all topics stored
>     under ""home/lights/"."
>
>         For what is worth, I thought of one exact topic to be one
>     application group. So, in the example above, "home/lights/" can be
>     seen
>     a reasoned collection of related application groups, but not as an
>     application group itself.
>
>
> [That's not how I see it in MQTT context - the broker may be hosting 
> multiple topics,
> and home/lights/* maybe one application group that all the group 
> members should be aware of.
> and then there could be other sub-groups home/lights/kitchen/* etc.]

==>MT
I see, so it's actually an application group that can comprise multiple 
associated pub-sub topics, and application groups can be further 
organized into a hierarchy. I think it's worth clarifying this, possibly 
with examples.
<==

>
>
>     * "... the client needs to discover the (application group, security
>     group) association. In MQTT, $SYS/ ... can be used by the broker for
>     this purpose."
>
>         The security group here is related to the key material used to
>     protect the content with COSE, which is competence of the KDC.
>     That key
>     material is intended for the security group members, which do not
>     include the broker.
>
>         Hence, unless the KDC and the broker are components of a same
>     system
>     under the same authority, I would have expected the broker to have no
>     idea of how the application groups it manages are related to the
>     security groups that the KDC manages.
>
>         I would rather expect the KDC to be aware of such
>     associations, e.g.
>     by learning about them when the security groups are actually
>     created on
>     it. The KDC can later on advertise these associations. For the Group
>     OSCORE case targeted in KGO, this can happen through a Resource
>     Directory, as discussed in [8] and using the approach defined in [9].
>
>         [8]
>     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-oscore-gm-admin%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639410503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=dOAe1IrARB2Ch6gfW4tFZ%2BE%2FHWCC%2F0DJhRfDp0GryLk%3D&reserved=0>
>
>         [9]
>     https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-discovery/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639420452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=OOTWZra3jtYb8n0aQlMrTnqRu%2FZdyq%2FDTn%2BkC2v%2FG9s%3D&reserved=0>
>
> [CS: OK, I agree - I did not see how KDC can support this, so put it 
> under Broker, but
> I acknowledge that this has several shortcomings. Will look into 
> OSCORE impl.]
>
>
>     * "Client computes the corresponding security groups ..."
>
>         Do you mean "Client considers ..." ?
>
> [CS: Nope, it definitely needs to compute. If the client plans to 
> subscribe to
> home/lights/* but home/lights/kitchen/* is one security group, and 
> home/lights/bathroom/*
> is one security group, it needs to ask for these two scopes in the token
> and it needs to subscribe to these separately etc.]

==>MT
Ok, I probably got confused by the exact word "compute" and thought of 
something else. Based on your explanation, I guess it should be intended 
as "determine".
<==

>     * "RS validates the PUBLISH message by checking the topic's security
>     group association and the stored token."
>
>         Even having the broker aware of the association (application
>     group,
>     security group) as defined in the draft, how does this validation
>     work?
>
>
> [CS: This will be revised - if the complexity falls on the client, 
> learning information from KDC, these problems
> should go away. But note that when a client makes a PUBLISH or 
> SUBSCRIBE request, the Broker
> checks if it can accept the request by checking the Topic Name/Topic 
> Filter against the stored token scopes.]

==>MT
Sure, which is consistent with the Broker storing an Access Token that 
expresses a scope about application groups (not about security groups).
<==

>
>         - The protected message targets a resource at the broker
>     associated
>     to the application group.
>         - By assumption, the broker knows the security group(s)
>     associated
>     to the application group.
>         - From the broker's point of view, the Token specifies the
>     application group.
>
>         I understand checking whether the request to the broker targets a
>     topic resource (an application group) where the client is
>     authorized to
>     publish as per the Token. But how does the mentioned validation
>     involve
>     checking that the request is also related to the security group?
>
>
> [CS: We will move away
> from this scheme. We will make the Broker agnostic to security groups, 
> and
> let the Client ask with proper topic filter matching the scope in the 
> token (ie. which consequently matches the security group).]
>
>
>         Also, is that actually important for the broker, which by the way
>     does not have the key material of the security group?
>
> [CS: Well the Broker only cares it only accepts Publishers/Subscribers 
> publish/subscribe
> to their authorised topics]
>

==>MT
Right, which are application groups :-) (see above)
<==

>
>     [Section 7]
>
>     * "... by the same entity having control of the topic, i.e. KDC."
>
>         Perhaps here you mean "... by the same entity having control
>     of the
>     key material for that topic, i.e. KDC."
>
> [CS: Yes]
>
>
>     * The second paragraph seems to mix together authorization to publish
>     and source-authentication of messages.
>
>         If it is not critical that only authorized publishers can
>     publish,
>     then the broker might not necessarily enforce access control on
>     publishers. That is, a publication request would be accepted and
>     processed even if there was no posted Token supporting this operation.
>
>         Instead, not using an additional signature and relying only on
>     integrity-protected encryption based on group key material, is
>     about: i)
>     accepting that subscribers cannot be able to precisely identify the
>     actual publisher that has sent a message to the group; and ii)
>     accepting
>     that any group member (subscribers included) can modify content
>     published by the actual publisher, in case communications between the
>     broker and the subscribers are not protected.
>
>
> [CS: Will check with Francesca, but I agree with you. I think what she 
> describes is that if it's only symmetric crypto
> and no publisher authorisation (i.e.,  it is not checked who is 
> allowed to publish), subscribers can
> turn into publishers being able to protect the content of the message 
> acceptable to the group.]
>
>
>     * "Subscribers can be excluded from future publications through
>     re-keying for a certain topic. ... How this could be done is out of
>     scope for this work."
>
>          Doesn't the same hold for publishers too?
>
> [CS: Will clarify with Francesca. But I do agree. I think she thought 
> the publishers would know the content of
> their messages anyway]
>
>
>          Is there any plan about defining a rekeying approach in this
>     document? I think that a basic point-to-point approach can be pretty
>     much like the one defined in Section 20 of KGO, although filling the
>     'key' parameter as defined in this document. It might actually be
>     even
>     simpler as to the provided content, since you may not need to provide
>     additional information to support a recovery for group members
>     that have
>     missed a rekeying instance, like KGO has to do.
>
>
> [CS: I think we should]

==>MT
Please, see also the new Section 6 "Group Rekeying Process" in the 
Editor's copy of ace-key-groupcomm, which considers also guidelines for 
a point-to-point rekeying scheme.

This is supposed to be minimally supported by a KDC, which can however 
opt for a more advanced scheme to be indicated in the Joining Response 
(see Section 4.3.1 "POST Handler" in the Editor's copy of 
ace-key-groupcomm).
<==

>
>     [Section 8.2]
>
>     * Shouldn't the field "Profile" indicate both coap_pubsub_app and
>     mqtt_pubsub_app ?
>
>
> [CS: Yes]
>
>
>     [Appendix A]
>
>     * The list of requirements has been greatly revised and extended in
>     Appendix A of KG, with new mandatory and optional requirements. So
>     this
>     list will need to be re-aligned with the list in KG, and parts of
>     this
>     document will need to be revised/extended to say how the updated
>     set of
>     requirements is fulfilled
>
>
> [CS: Will do]

==>MT
Note that, following the review comments to ace-key-groupcomm, the list 
of requirements has been extended and the requirements have been renumbered.

THE END
<==

>
>
>     == Nits ==
>
>     [Section 3.2]
>
>     s/data model is described/data model described
>
>
>     [Section 4.2]
>
>     s/singature/signature
>
>
>     [Section 6.2]
>     s/To be able join/To be able to join
>
>
>     [Appendix A]
>
>     s/Specity/Specify
>
>     s/tranport/transport
>
>
> [CS: Will fix]
>
>
>     -- 
>     Marco Tiloca
>     Ph.D., Senior Researcher
>
>     Division: Digital System
>     Department: Computer Science
>     Unit: Cybersecurity
>
>     RISE Research Institutes of Sweden
>     https://www.ri.se
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695666639420452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0LbEZ30%2FyNTgJ%2BN%2FZtzpnHES4ZI2lkcBNgIAlDoKCVs%3D&reserved=0>
>
>     Phone: +46 (0)70 60 46 501
>     Isafjordsgatan 22 / Kistagången 16
>     SE-164 40 Kista (Sweden)
>
>

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