Re: [Ace] Review of draft-ietf-ace-key-groupcomm-oscore

Marco Tiloca <marco.tiloca@ri.se> Tue, 05 November 2019 14:50 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 4509B120984; Tue, 5 Nov 2019 06:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=risecloud.onmicrosoft.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 9jgAZicq0_CT; Tue, 5 Nov 2019 06:50:33 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50086.outbound.protection.outlook.com [40.107.5.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF8B120089; Tue, 5 Nov 2019 06:30:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JIMIh3szFu9TH1GLtFMy/qjqbIu6tHn3e22jG1VxjHc6rkrAEyz/dP3pgx5ryLB8ISLQU9tzGW0PuDNrqSVYW8NHV+hbTrhI0CINItBG1qDvqxlnGzrZAobp+i4kvdXtsHZf/PlueoaOSYzyGzyyn3QOQ0wg7I9BBPjw5uKl55f9iURB6Z6mowhPjORRHISM5k4ESJh5d2zyhZ16alyZ2rl2AIYZT0gjFSfhvrsafkYtfVXh6Z401eJKWeurldbHwU5FD5hzgYx7p4TJ7jQ+CytUYkEStJXb0AW0Vy/1J2+vXp10F3JgjwtWSLHxWnaVXJtm9PnKef5b8z6LeK1oYw==
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=wbjahX4oc6TMjEyTo8n6XgMhn/p6YkLgNcrHdx06bPA=; b=dRGfztaZ4mjqvt0Z5utLIOyjkGK7H6b3R7c/5pvB/jd6ViWy5T+RWqVKw+ssCtKETMOfQ6Sv50tjX+wlE1FtZ49Yj01E2DkbKHdXVH5JcfoUFLahCvNmGL7NPHE5K2ZUwpeL6A0N4+KmZ1iFSCQQ/b49283K+TQHQ93voNRqRHbJ42jGtMh0X0OB2TCIb8AAVc0d01jiacR0m8lFej7uPOslmoiTNeYHju7SLn+aC752V8wxWHxfpxVPBlgmR5HmrzwIETA10UeO2C8lyjAWz9MO44uf7i60Q1T0ORlldEhLC5WlvOFOEsCKvQ7l4DybSzTLQ/Sf9iX8aaXzmg3VgA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wbjahX4oc6TMjEyTo8n6XgMhn/p6YkLgNcrHdx06bPA=; b=WpylYjXjBthojG+kAgq8qDWqtY0HynmlHYd0fe6GMjQKU5RNlxaUMbbnV+OGv5xHhMF8IJ6rrwygZUTi0xQ/pVNOCBrnzu5f+V1oAldF42QLBSZplV4gYbq+Gm/9ZxzESYgvtL+Nf2WHI/rFRRecdkj4QaNKNwTBbQ5NpOUud/4=
Received: from HE1P18901CA0024.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::34) by AM5P18901MB0002.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:76::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 14:25:47 +0000
Received: from HE1EUR02FT009.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::200) by HE1P18901CA0024.outlook.office365.com (2603:10a6:3:8b::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2408.24 via Frontend Transport; Tue, 5 Nov 2019 14:25:47 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT009.mail.protection.outlook.com (10.152.10.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2387.20 via Frontend Transport; Tue, 5 Nov 2019 14:25:46 +0000
Received: from [10.8.3.8] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Tue, 5 Nov 2019 15:25:46 +0100
To: Ludwig Seitz <ludwig.seitz@ri.se>, <draft-ietf-ace-key-groupcomm-oscore@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
References: <d217dc87-3eb9-c9a9-6741-8f3ab039bd9a@ri.se>
From: Marco Tiloca <marco.tiloca@ri.se>
Openpgp: preference=signencrypt
Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA==
Message-ID: <b2f06ac6-d8b9-81b6-3b34-629f3827a9f7@ri.se>
Date: Tue, 5 Nov 2019 15:25:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <d217dc87-3eb9-c9a9-6741-8f3ab039bd9a@ri.se>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IdvlrWFiS6lmgASAJMUO6d3Y3AB8U4lzj"
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(136003)(39860400002)(189003)(199004)(2616005)(2906002)(966005)(11346002)(21480400003)(8676002)(4326008)(16526019)(186003)(71190400001)(5024004)(14444005)(22746008)(446003)(568964002)(65806001)(6246003)(58126008)(229853002)(110136005)(316002)(16586007)(36756003)(66574012)(235185007)(40036005)(16576012)(478600001)(450100002)(3846002)(6116002)(53546011)(81156014)(33964004)(126002)(26005)(70586007)(31696002)(70206006)(5660300002)(356004)(6666004)(22756006)(65956001)(106002)(31686004)(8936002)(336012)(305945005)(6306002)(386003)(76176011)(7736002)(86362001)(44832011)(486006)(476003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0002; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: bffed2ba-e4d9-4c6c-2ca7-08d761fc0cc4
X-MS-TrafficTypeDiagnostic: AM5P18901MB0002:
X-Microsoft-Antispam-PRVS: <AM5P18901MB0002CBC07217E9B2D994190C997E0@AM5P18901MB0002.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0212BDE3BE
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: rt9D6B0AbRRLrd2Z0NK1TeZs49bPhMH2vOOixlC0QJJtJyMvPgztLvfM7eEQ+qOugflVS834Gbl6tZ3m0dHDaut7mBD1AEmbme18yhwS7QIvACQ5mtDj3HGvr9ZaRcjAhdVJZXLMAbYBUmrQLx18i8Q0Pd6uMFCOFqPots6UHgwbOXxKxMRZUrUqVoDobdDqBKC+DRPdGmJ1b6DeMcV4ggEqJ3UDMQ9B90ffw1iPiZwynCrbnsMhs0Txwh7q3XBPUVmdB6ureUfakEepw2djiTM2JZhjQ37kwHRlxg6c2tshw+JQELQub3wRImiKj7sFB6BqFwFRlSmpPfLUcZoaZ+TM/bGEH+jxkDDkUx2k+3szZL/2ENMwMWmcHkk6JbIiBoSVMnClYLOlec2A49fFVelFBzGD2NMCUB2NEqW6AxR5j9XH4PT1dSfFY24Bdx8w
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2019 14:25:46.9409 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bffed2ba-e4d9-4c6c-2ca7-08d761fc0cc4
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0002
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Mw_z8MHSULlPNUvZGxhGS9K064c>
Subject: Re: [Ace] Review of draft-ietf-ace-key-groupcomm-oscore
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, 05 Nov 2019 14:50:43 -0000

Hi Ludwig,

Thank you very much for your review! We have addressed your points in
the recently submitted v -03.

https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-03

Please, see our replies inline below.

Best,
/Marco

On 7/22/19 1:14 PM, Ludwig Seitz wrote:
> Hello Marco, Jiye, Francesca,
>
> I have read draft-ietf-ace-key-groupcomm-02 and I have a few comments
> for you:
>
> ==
>  1.1
> "The URI of a join resource is fixed."
>
> How can that be a requirement? The Group Manager might also be a
> mobile unit that changes address as it moves through different networks.
> Perhaps rephrase to "The URI-Path of a join resource is fixed"?

<MT>
Right, we in fact meant URI-Path.

Note that "join resource" has been renamed as "group-membership
resource", consistently with what planned for other related documents.
The joining process itself does not change.
</MT>

>
> ==
> 1.1
> "Monitor: ... This corresponds to the term "silent server" used in
> [I-D.ietf-core-oscore-groupcomm]."
>
> Any special reason for defining an separate equivalent term? Otherwise
> this only makes the set of documents harder to read.

<MT>
Yes, the reason is using the word "server" only for the ACE AS and RS,
while avoiding it for roles of nodes in the OSCORE group, that would
probably create more confusion.
</MT>

>
> ==
> 2.
> "To this end, the AS must signal the specific transport profile to
> use, consistently with requirements and assumptions defined in the ACE
> framework [I-D.ietf-ace-oauth-authz]."
>
> Note that in the ACE framework the AS does not have the obligation to
> signal the profile, since the assumed base-case is that the profiles
> are pre-configured and well-known in most constrained applications
> (this is an update from previous versions of the ACE framework).
>

<MT>
Right, we have relaxed the "must" to "MAY", and mention the most common
case of pre-configured profile usage.
</MT>

> ==
> All document: Update references to OSCORE to point to RFC 8613

<MT>
Done.
</MT>

>
> ==
> 2.
> "2. The joining node transfers authentication and authorization
> information to the Group Manager by posting the obtained Access Token
> (see Section 4)."
>
> Although it is explained in section 4 you might want to mention
> already here _where_ the information is POSTed (or replace "posting"
> with "sending")

<MT>
Done.
</MT>

>
> ==
> 2.
> "5.  The joining node and the Group Manager maintain the secure
> channel, to support possible future communications."
>
> Maintaining such a channel is costly in terms of memory, is that
> really a requirement?
>
> Also in the case of object security, speaking of a 'channel' is
> misleading.

<MT>
Sure, it is very much expected to be used for key management operations,
e.g. asking the GM for new keys, unsolicited (group) rekeying and so on.
We clarified this at the end of step 5.

We have replaced "channel" with "association".
</MT>

>
> ==
> 3.2
> "Also, the 'profile' parameter ..."
>
> See previous comment on profile being optional in the ACE framework

<MT>
Now fixed, also consistently with the other related comment above.
</MT>

>
> ==
>
> 4.
> "the Access Token post"
>
> I don't think this term is well-understood in general. I'd suggest
> removing it with something less REST-centric for the uninitiated
> reader, like e.g. "the sending of the Access Token to ..."

<MT>
Done.
</MT>

>
> ==
> 4.1
> " Note that the CBOR map specified as payload of the 2.01 (Created)
>    response may include further parameters,"
>
> Note that the ACE framework does not specify this response payload to
> be a CBOR map. Please explicitly state here that you are deviating
> from the default payload format in the ACE framework.

<MT>
We added this clarification at the end of the above different paragraph
starting with: "The payload of the 2.01 (Created) response is a CBOR map".
</MT>

>
> ==
> 4.2
> "In case the joining node knows the encoding of public keys in the
> OSCORE group, as well as the countersignature algorithm and possible
> associated parameters used in the OSCORE group, the included public
> key MUST be in a consistent format. "
>
> What is a "consistent format"? Please rephrase to be more specific.
> Or did you mean "compatible format"?

<MT>
We have rephrased it as "MUST be compatible with those criteria"
mentioned right above. Also, we have further clarified what has to match.
</MT>

>
> ==
> 4.3
> "That is, the public key has to be encoded as  expected in the OSCORE
> group, and has to be consistent with the counter signature algorithm
> and possible associated parameters used in the OSCORE group."
>
> What is "consistent with the ... algorithms and ... parameters"?
> Did you mean "compatible"?

<MT>
Yes, just replaced "consistent" with "compatible", here and in the rest
of the document.
</MT>

>
> ==
> 4.3
> "The 'profile' parameter MUST be present and has value
> coap_group_oscore_app (TBD), which is defined in Section 9.3 of this
> specification."
>
> See comments on 'profile' before.

<MT>
This is different, it's an application profile indicated by the GM to
tell the joining node what the keying material is intended for.

It is not indicating a transport profile (e.g., the OSCORE profile)
communicated by the AS when requesting an Access Token.
</MT>

>
> ==
> 6.
> "In this case, the joining node MAY not provide again its own public
> key to the Group Manager,"
>
> This could be misunderstood to mean "MAY NOT ...", how about
> rephrasing this to: "MAY choose not to provide ..." ?
>

<MT>
Done (now current Section 5).
</MT>

> ==
> 7.
> "When doing so, the Group Manager MAY take a best effort to preserve
> the same unchanged Sender IDs for all group members"
>
> This is incorrect use of requirements language. This 'MAY' can not be
> tested and the arguments for claiming conformance to this requirement
> would be quite diffuse. I suggest to require maintaining the Sender
> IDs. Why should the GM change them in the first place?
>
>

<MT>
(Now current Section 13)

As agreed at IETF 105, we have changed it to "Also, the Group Manager
MUST preserve the same ... ".

As to the Group Manager that may more generally end up changing the
Sender ID of a single group member, this is described in current Section
7, as for the reason and the way it happens.
</MT>


<MT>
Thank you very much again for your review!
</MT>

> Regards,
>
> Ludwig
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se