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

Ludwig Seitz <ludwig.seitz@ri.se> Mon, 22 July 2019 11:14 UTC

Return-Path: <ludwig.seitz@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 D9923120164; Mon, 22 Jul 2019 04:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 0EmLHLpBCEpj; Mon, 22 Jul 2019 04:14:49 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150072.outbound.protection.outlook.com [40.107.15.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255C41200DB; Mon, 22 Jul 2019 04:14:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BMKkmp6F0KJQOYr/D2a5CU2PRBcrHLBrCuWBtKoqdk7PaprMz0PR39h9OY/f/V6/b2nEoFV1IFBRIZfo62Mjuzx3Goc/nc2l5j3S5JqcNkxecJ17web4taJUvdJD3R3QfC4CfJAoj6+HOx/GrTNCOBmx+kOwpw1zy1TExUQiC6n789eidR7N+uE/u+l7ijdAjWIu7RUL56/YEm3xTCkshjfKSy4iUAoJk7BwfoubtpJjh+W+gCYvkJ/Q6rNVKhrBXSuz4v3DyHnbVRnAYoZxXBdlu6Yeu3U+cqk1lcZWWTAxHVEhbgXzUwnR4iOC4Xlbkah4C4opqHoGjU6vbsKanQ==
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=twTtgK2U+DJs4c0W1cAeFdKG/mLpEjfwU6IZST5Ym+o=; b=O9wH5hab/xqfYxjqPA1eaMFL1+EDe+QYCPGUDYkDZatCqYVoTndfr0zpSJgn9wE2GWMO8vkkM49Db5hNQRt5jhfEG5gltFpgUztXOa8+F7WQQnBboH+Z+PSmAiwGuqVTXKlKTNYoHCW1e8rBNnOAt96IDOZhViZzWQAbbisRmJxggyMcjuVnPvyropX7/KiG1O3t2Kk1tj9c8LiviGORMFUSvVkUhpC+61MrsmA/iMg7W+OcNUrFd0JXxj1yQH/8jG95meB4Nh9o/mcAxj/byQTpyEiTcbDoaYMl/P/y0eBeNB18IBT6fjncB04rNfOkN6sAcQAcuBFirWbLv+C+ZQ==
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=bestguesspass 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=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=twTtgK2U+DJs4c0W1cAeFdKG/mLpEjfwU6IZST5Ym+o=; b=E0kB+t3NrvL/5eFbociNPky4K/pS9cHojNaYgMe0uIh/ylo1M+y1o5JGzA1dpSkRg/aVLrN7aX3l52CjAPuRhcf0n6wbHFNtMbDpwqxxASS6kUv+ZU3dkHqGjNhUHB45YsC8IP9SGXoErfWGEBVpnqKoNDeQBsD8Bk6GcpM724E=
Received: from HE1P18901CA0022.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::32) by VI1P18901MB0221.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 11:14:46 +0000
Received: from AM5EUR02FT012.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::202) by HE1P18901CA0022.outlook.office365.com (2603:10a6:3:8b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.12 via Frontend Transport; Mon, 22 Jul 2019 11:14:46 +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=bestguesspass 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 AM5EUR02FT012.mail.protection.outlook.com (10.152.8.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2052.19 via Frontend Transport; Mon, 22 Jul 2019 11:14:46 +0000
Received: from [10.112.134.122] (10.100.0.158) 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.1713.5; Mon, 22 Jul 2019 13:14:46 +0200
To: <draft-ietf-ace-key-groupcomm-oscore@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <d217dc87-3eb9-c9a9-6741-8f3ab039bd9a@ri.se>
Date: Mon, 22 Jul 2019 13:14:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080609060609060809080201"
X-Originating-IP: [10.100.0.158]
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)(136003)(39860400002)(346002)(396003)(376002)(2980300002)(199004)(189003)(568964002)(44832011)(476003)(2616005)(126002)(86362001)(65956001)(8936002)(336012)(65806001)(31696002)(2351001)(70206006)(2906002)(68736007)(70586007)(235185007)(5024004)(14444005)(6116002)(3846002)(69596002)(81156014)(81166006)(5660300002)(58126008)(486006)(316002)(16576012)(16586007)(53936002)(71190400001)(8676002)(16526019)(36756003)(186003)(106002)(22756006)(40036005)(7736002)(386003)(305945005)(6916009)(64126003)(33964004)(4326008)(65826007)(6666004)(356004)(22746008)(450100002)(31686004)(26005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P18901MB0221; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c19acef4-47e3-46eb-7a3a-08d70e95cdf8
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:VI1P18901MB0221;
X-MS-TrafficTypeDiagnostic: VI1P18901MB0221:
X-Microsoft-Antispam-PRVS: <VI1P18901MB02217B0B4D66F6F8A89E62B682C40@VI1P18901MB0221.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 01068D0A20
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: CEf+L9Iu2ws8clDu9rwMsJAzXwZhQESSi5zNoN7oNP7ChHPj6+AHyULFAR++3lwIMvl1TkNAUfDnyi1QrRFsc0Ci05aolqVLPKQujrfFUpkQvS+Omuj/LVe/Gp/vEWRd1P4tAfMnM6DJCGxCSiXbsn+6qMlhVwRxzoCkRQW9cQ8rMPxvHjoa/WkNOwlsVs6NrkPtAafRCo3SRgyahAubl0Iw9lBP/S0RNEAuCejfMutDvne7DfXSY6xiDXrPoHaxwKfVm7lWvudO/JuPaIi74ggyOktd9gY6qpy6rx43H+UqToh3OsePgUGlhTWmZlGgXP3L+9ImH/Y0pEO422zZtS0aE/24rkjP7KQiou3K4tgvZ9H3Q5qjZhBiaJeBmG5UyRMsMeNRYvCzRVKGEbD6BZQ7VGEigFxep9sHMP4MHpg=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2019 11:14:46.3793 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c19acef4-47e3-46eb-7a3a-08d70e95cdf8
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: VI1P18901MB0221
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/71zNXwQvSD4gUtKtWrxkA4x0XJI>
Subject: [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: Mon, 22 Jul 2019 11:14:53 -0000

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

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

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

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

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

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

==
3.2
"Also, the 'profile' parameter ..."

See previous comment on profile being optional in the ACE framework

==

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

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

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

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

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

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

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


Regards,

Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51