Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 28 July 2020 15:22 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCF33A0DC1; Tue, 28 Jul 2020 08:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 7cat1fKYMH9v; Tue, 28 Jul 2020 08:22:54 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760044.outbound.protection.outlook.com [40.107.76.44]) (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 C05483A0E3B; Tue, 28 Jul 2020 08:22:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dddRTVJc6oRcriSHXyJjOdvCHPzFlZSe6Sw8x0vgn+P8Gv3vBe9PO4Xb1azgHerwmdl0JoQJ1jZCIjF4quHfTHv7I4JSygTKobILcoPLR7dp7vj9Czb+pxistuRRzcnZmJYnX76aGaUlezBy509qY3ZS88lNZgXum5nCMhyZVYRgfL6i36ue2kOqMKkreFfvteK5MgIvTO6JWn1OSF7moR60L2UnCqNhoi/woItmCpyFHtLYEH0jIISd8lI1SvlwTZwzXvvRUwFBuN/3UEHcdU+M/Z31rNdLpGI7UjYE4m66eRyIk+9j1ZvHnu86ATTAsTsP4j4L9HAruKFC+riuYg==
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=fA39s6EohXd/mqteI8QlcbScsZNB8ztSpB7gpGDUcxw=; b=C4QB+vXdPbKH+DbaIglRQCH6baZuSxDd6eYzkfEfzlrWD2Ly3omb4kf0F5ydYWQIaHnoQJJag76W3TfUvzU/d8R1dROlFtnJUtfpA3TZoL85k58mEb3v3bm7nXHBzYBYIUxxwCG0/siVFHGEr8Ca1IjvG9LYvgXiVare9xcFjOMa8NGAku3GvS06qvXKhD+7BFTQDGhYPsZDqmCiSNT2CoN7FO3YIRcO+UipIvQo3kDN9F0qnqoQHq+4YczhZaUEu0YEG8ei6yWkuS0SjSkOGQk5EfxoRJlGhMwwqRLipy1v5d6sCQm2w5dMsiOzIRZdaEJgAifu5atp32a7oZVN/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=augustcellars.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fA39s6EohXd/mqteI8QlcbScsZNB8ztSpB7gpGDUcxw=; b=SOo03GwCES9SSI/TDhP40XfX2WpQKNLpAbh3BpWs7sCi1/ty5GxxK37YIiQ6WDS/a23chrMFpAkfuPVRsDB1goh5vK6fCG0nOkukrPiI+LHb6qaEDdX+ZjttZSFqHFZ6koDd8QRlXBSE8LEaZfdTtGVqt/PbMeXbf3Qiwz8TTU4=
Received: from CY4PR13CA0041.namprd13.prod.outlook.com (2603:10b6:903:99::27) by CH2PR12MB4054.namprd12.prod.outlook.com (2603:10b6:610:a6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Tue, 28 Jul 2020 15:22:48 +0000
Received: from CY1NAM02FT013.eop-nam02.prod.protection.outlook.com (2603:10b6:903:99:cafe::98) by CY4PR13CA0041.outlook.office365.com (2603:10b6:903:99::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9 via Frontend Transport; Tue, 28 Jul 2020 15:22:48 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT013.mail.protection.outlook.com (10.152.75.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Tue, 28 Jul 2020 15:22:47 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06SFMj0B011083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 11:22:45 -0400
To: Jim Schaad <ietf@augustcellars.com>, draft-ietf-ace-dtls-authorize.all@ietf.org
Cc: "'General Area Review Team'" <gen-art@ietf.org>, ace@ietf.org
References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> <000001d65e1c$1eed9430$5cc8bc90$@augustcellars.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <8aa8ff52-8237-6609-28fb-39f0485d978d@alum.mit.edu>
Date: Tue, 28 Jul 2020 11:22:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <000001d65e1c$1eed9430$5cc8bc90$@augustcellars.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1ba16125-ce70-41e5-d806-08d8330a159c
X-MS-TrafficTypeDiagnostic: CH2PR12MB4054:
X-Microsoft-Antispam-PRVS: <CH2PR12MB4054F15C145B6C3C3ADD6062F9730@CH2PR12MB4054.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: FkjQpOgW1uyzQECS9xX4sTQMFeeJdD+g3SpvDrLKrWb0KxKQ+cPD/ymF6s7Bsb0HP0aDUm8hO3LVAd59fMA8bpzVMl2E94i0R3ru4XBi33/oJtRTV+Z6pCtJTMGkqnDctwtH9WsK0qhNkvsmVhFiICQ8w1EBTRfnDy3tNZJ7J3co2YYtXBUDFoqDPFF3EK3OxuF8udq9/zQbU4UsvhXj8m2HzJ5URCPi0YHwNHb72Oiy1ZwemkzDqJkvf9hNG2WoYROfORxsoEPZrEPhPa9HwW/Fq9ExabYVYq72il0bv4DV5aDHjI/MGf1Jx+SDHTQ20uCbcCJLaxqhGyeJG8ChoG3C+KFNyzHKmkJ1uptEUQlJoz4XujuAx6AF3t/Nlyffd/T4Yt5RbxcGM8CcS907ddLBVaHnUoArY+sfEbq1kVprg7YXOSGCqTQGsC6dms8V7b391t6OhYVVKQ1fCX1dFx82kuKi1329IY/5x4iTayLhr2BMYHX6w9nOwxBYJ73s
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(346002)(396003)(376002)(46966005)(356005)(8676002)(75432002)(956004)(70206006)(82310400002)(2616005)(86362001)(83380400001)(2906002)(5660300002)(70586007)(8936002)(336012)(186003)(36906005)(786003)(316002)(53546011)(31696002)(82740400003)(47076004)(26005)(478600001)(31686004)(4326008)(7596003)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 15:22:47.6034 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ba16125-ce70-41e5-d806-08d8330a159c
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT013.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4054
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/tVYGTIxnolR_fssNShRMd4ZT5rg>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 15:23:02 -0000

Jim,

Sorry - I forgot to respond sooner.

Please see comments inline.

	Thanks,
	Paul

On 7/19/20 6:29 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message-----
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>> Sent: Sunday, July 19, 2020 1:24 PM
>> To: draft-ietf-ace-dtls-authorize.all@ietf.org
>> Cc: General Area Review Team <gen-art@ietf.org>
>> Subject: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review
>> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
>> the IETF Chair.  Please treat these comments just like any other last call
>> comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-ace-dtls-authorize-12
>> Reviewer: Paul Kyzivat
>> Review Date: 2020-07-19
>> IETF LC End Date: 2020-07-20
>> IESG Telechat date: ?
>>
>> Summary:
>>
>> This draft is on the right track but has open issues, described in the
> review.
>>
>> General:
>>
>> TBD
>>
>> Issues:
>>
>> Major: 2
>> Minor: 1
>> Nits:  1
>>
>> 1) MAJOR: Management of token storage in RS
>>
>> There seems to be an expectation that when the client uploads an access
> token
>> that the RS will retain it until the client attempts to establish a DTLS
>> association. This seems to require some sort of management of token
> lifetime
>> in the RS. The only discussion I can find of this issue is the following
> in section 7:
>>
>>      ... A similar issue exists with the
>>      unprotected authorization information endpoint where the resource
>>      server needs to keep valid access tokens until their expiry.
>>      Adversaries can fill up the constrained resource server's internal
>>      storage for a very long time with interjected or otherwise retrieved
>>      valid access tokens.
>>
>> This seems to imply a normative requirement to keep tokens until their
> expiry.
>> But I find no supporting normative requirements about this. And, this
> section
>> only presents it as a DoS attack, rather than a potential problem with
> valid
>> usage.
>>
>> ISTM that there is an implied requirement that the RS have the capacity to
>> store one access token for every PoP key of every authorized client.
>> If so, that ought to be stated. If not, then some other way of bounding
> storage
>> ought to be discussed.
> 
> In section 5.8.1 of draft-ietf-ace-oauth-authz is the sentence "The RS MUST
> be prepared to store at least one access token for future use."   When this
> was put in, this is exactly what we were discussing.  There is no
> requirement that an RS needs to store two access tokens for future use.  I
> think this means that there is a strongly bounded requirement on storage.

When I read that, it seems that the stated requirement is to store one 
token *in total*, yet the context implies that it ought to be one token 
*per* client.

The procedures defined aren't going to work unless there is one per client.

> Authors - It might be worthwhile to re-iterate this requirement in both of
> the profile documents.
> 
>>
>> 2) MAJOR: Missing normative language
>>
>> I found several places where the text seems to suggest required behavior
> but
>> fails to do so using normative language:
>>
>> * In section 3.3:
>>
>>      ... Instead of
>>      providing the keying material in the access token, the authorization
>>      server includes the key identifier in the "kid" parameter, see
>>      Figure 7.  This key identifier enables the resource server to
>>      calculate the symmetric key used for the communication with the
>>      client using the key derivation key and a KDF to be defined by the
>>      application, for example HKDF-SHA-256.  The key identifier picked by
>>      the authorization server needs to be unique for each access token
>>      where a unique symmetric key is required.
>>      ...
>>      Use of a unique (per resource server) "kid" and the use of a key
>>      derivation IKM that is unique per authorization server/resource
>>      server pair as specified above will ensure that the derived key is
>>      not shared across multiple clients.
>>
>> The uniqueness seems to be a requirement. Perhaps "needs to be unique"
>> should be "MUST be unique". (And something similar for the IKM.)
>>
>> * Also in section 3.3:
>>
>>      All CBOR data types are encoded in CBOR using preferred serialization
>>      and deterministic encoding as specified in Section 4 of
>>      [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
>>      and "L" components use the minimum length encoding.  The content of
>>      the "access_token" field is treated as opaque data for the purpose of
>>      key derivation.
>>
>> IIUC the type of serialization and encoding is a requirement. Will need
> some
>> rewording to make it so.
>>
>> * In section 3.3.1:
>>
>>      ... To
>>      be consistent with the recommendations in [RFC7252] a client is
>>      expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8
>>      [RFC6655] to the resource server.
>>
>> I think "is expected" should be "MUST".
> 
> The rule would be MUST implement not MUST offer.  A client could offer a
> completely different ciphersuite that is consistently used in the group and
> that would be fine.

That implies that the client be configured to *know* that the server 
supports something else. I guess that is ok.

>> * Also in section 3.3.1:
>>
>>      ... This
>>      specification assumes that the access token is a PoP token as
>>      described in [I-D.ietf-ace-oauth-authz] unless specifically stated
>>      otherwise.
>>
>> I think "assumes ... unless" should be "MUST ... unless".
>>
>> * Also in section 3.3.1:
>>
>>      ... New access tokens issued by the
>>      authorization server are supposed to replace previously issued access
>>      tokens for the respective client.
>>
>> Is this normative? Should "are supposed to" be "MUST"?
>>
>> 3) MINOR: Insufficient specification
>>
>> (I'm waffling whether this is minor or major.)
>>
>> There are a couple of places where what seem to be requirements are stated
>> too vaguely to be implemented consistently:
>>
>> * In the previously mentioned paragraph in 3.3.1:
>>
>>      ... This
>>      specification assumes that the access token is a PoP token as
>>      described in [I-D.ietf-ace-oauth-authz] unless specifically stated
>>      otherwise.
>>
>> The "unless specifically stated otherwise" is too vague to be normative.
>> How would the alternative be indicated? Is this an escape hatch for future
>> extensions? If so, it needs more work to make that clear and to open a
> path for
>> that future work.
>>
>> * Also in section 3.3.1:
>>
>>      ... The resource server therefore must
>>      have a common understanding with the authorization server how access
>>      tokens are ordered.
>>
>> The last statement ("must have a common understanding") is mysterious.
>> IIUC section 4 is covering the same topic in a less mysterious way.
> 
> I am seeing this in section 3.4 - did I miss something?

I'm sorry. This issue should have referred to that passage in 3.4, not 
3.3.1.

>> 4) NIT: Subsection organization
>>
>> Both 3.2 and 3.3 share a common structure:
>>
>> * The section begins with discussion of the interaction between the client
> and
>> the AS.
>>
>> * it is followed by a subsection discussing the interaction between the
> client
>> and the RS.
>>
>> It is odd to have a section with a single subsection. And the structure
> isn't easily
>> discerned from the TOC.
>>
>> I suggest it would be clearer if each of these sections had *two*
> subsections,
>> one covering the AS interactions and the other the RS interactions. IOW,
> put the
>> material covering the AS interactions into a new subsection.
>