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:36 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 BCD543A0DCC; Tue, 28 Jul 2020 08:36:56 -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 Fl32X81M9n8R; Tue, 28 Jul 2020 08:36:54 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2072.outbound.protection.outlook.com [40.107.223.72]) (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 47F933A0DDD; Tue, 28 Jul 2020 08:36:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nuUBFpWHa9RBoFYFqjaabU+NLkJ2JY2G9fS4Yn66NUBAQFlxIDjgVmgQgZBAwjnc3zXGQsiIsplg4CDXu9gp6vwo19XzkHO6sVlag9/UcP0sicrc3wvAuY0cPcz/rS4nqle4C11/zpX4Ui5tY/9REQus4wtj+wy7vP3fpKLNBoXBMA5KX2F9eRkSVPOgOdiH7XXFNqDIsyqq5zP/mUqC0kLVf3szeMFqp4pYC5dVzgRI/155aLXTC615e4yANbvo5TDSGa/kwdnjtg/Cy8RrWrM1Jyl2iZoimEt3JjbG15t2dl5fsMjZzjjMv0tetQm69tk9ofObVjU0g1LbV3RYHQ==
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=2vzmTMLe2zK3Ci03RSLbFvqagyu1lifLzIlD8Fw44R8=; b=fSgiAJL+YvUeIdHuUJXXhrugRjQHUWCvU4ZZ3U4dqXkalALeQhDA2oKYeLyxW8MyJ/QqfDprF0hFTzumID0o2a+3lVBjv0atmUD0cHysOeTIZ4ihUvtQU7P8hj/rqKZyxmyrEbFwiTat2vd60ZKlebgHRdgibmtmyMlGxnjIHP3aE2CJAzHizet+Yt53S3ZTQ8cdBNHorzQ6aGbwCOb6LkrX8wKvW2lXDIyg62uGuMRSCQCGX5wXxfoHO2DtFpzBBqELgnMNWBL/TZRKol+7R/ueK7MucDnO3oZKOq/AkwdmYWy/FvvnndV722keFNiftosszPHxj3U0c0LA4nqdeg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=mit.edu 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=2vzmTMLe2zK3Ci03RSLbFvqagyu1lifLzIlD8Fw44R8=; b=SoTtImGwSJGVyLGtgJNNgX+bhXhf78qJ45zCkCtGxZbZ0h1ifDorll16+XlaXYrMt6KCO9ld/CmAHO56YtwDD6dZOZNDIJ92qdRSwmCQ+pi3UyO5ZKgF7OgDP2FEGRgU3YdgDUw9gMqjCzhtwqNI5F0yf8R6bJSaWIdsR/aMb+w=
Received: from SN4PR0201CA0022.namprd02.prod.outlook.com (2603:10b6:803:2b::32) by MWHPR12MB1744.namprd12.prod.outlook.com (2603:10b6:300:111::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:36:52 +0000
Received: from SN1NAM02FT048.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2b:cafe::51) by SN4PR0201CA0022.outlook.office365.com (2603:10b6:803:2b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Tue, 28 Jul 2020 15:36:52 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; 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 SN1NAM02FT048.mail.protection.outlook.com (10.152.72.202) 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:36:51 +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 06SFamVu012225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 11:36:49 -0400
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, General Area Review Team <gen-art@ietf.org>
References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> <20200727191052.GI41010@kduck.mit.edu>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <74ae7beb-61f3-6ff3-fa36-0b7e0f311558@alum.mit.edu>
Date: Tue, 28 Jul 2020 11:36:48 -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: <20200727191052.GI41010@kduck.mit.edu>
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: 8b490793-f951-48d0-8edd-08d8330c0c84
X-MS-TrafficTypeDiagnostic: MWHPR12MB1744:
X-Microsoft-Antispam-PRVS: <MWHPR12MB1744A309731AAB84457655A4F9730@MWHPR12MB1744.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: gMBTxREHiOrlnbaINXK9fqwqWyva4OBlAvLARodndh8DJXsOAvRWBO6HmpTFpkfI/UXjU9BAxKhTJWIkZRuiTaASbR6OnQJZZo2hPRLrgJZ2sffzMNpNw3OdsVrNiTyfwBs1Uih+InJbNxf7539niiQ1bE1GoXnXkd7NvjPdjQ5o+S5AvLwmvUpGfwUnFwfS7Q8I7wzZeHolD6b5Rly1ayOmJreqy5suzgfsttO9gLgQFzS4jJe087MH8kshHeSTWqQRzT18f1iVmZ6Dg7dlTYgWCvCEBvMbofbY1Eg8FTiLKpMnw6YS6iFQYs42efA61ry7+rQjPXBvB5T9JQe/kC+T/r+xrggF3reJfNEiUb7rpEeAUJZ6bvde1pH69Gy9+bWSvrl5oN+HWOQ8AkOrK27xvno0DulqSKNdk8ToXtgcm7pQ0UnlzJHXgn9nMq+x4jtdubPHF/21g5CHxPt+d3EpzVIkGJBsHhyfmC5OAJochPU33yt8WAAOOYFUFrhn
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)(346002)(396003)(376002)(136003)(46966005)(47076004)(478600001)(86362001)(70586007)(6916009)(82740400003)(316002)(70206006)(36906005)(786003)(8676002)(75432002)(26005)(336012)(7596003)(186003)(2906002)(5660300002)(83380400001)(356005)(53546011)(2616005)(956004)(4326008)(31696002)(8936002)(31686004)(82310400002)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 15:36:51.2854 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b490793-f951-48d0-8edd-08d8330c0c84
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: SN1NAM02FT048.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1744
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/lw5Xznid-_mnLLuySzJS--vObIQ>
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:36:57 -0000

Hi Ben,

Please find my comments inline.

On 7/27/20 3:10 PM, Benjamin Kaduk wrote:
> Hi Paul,
> 
> Just a couple notes in addition to what Jim already mentioned.
> 
> On Sun, Jul 19, 2020 at 04:23:46PM -0400, Paul Kyzivat wrote:
>> 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.
>>
>> 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.
> 
> Both this and the previous item are scoped by the following text:
> 
>     The method for how the resource server determines the symmetric key
>     from an access token containing only a key identifier is application-
>     specific; the remainder of this section provides one example.
> 
> So it's not entirely clear that normative language is appropriate in the
> discussion of the example behavior.

OK. That makes sense.

>> * 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".
>>
>> * 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".
> 
> My understanding is that this is just talking about the text in the
> document itself.  But as far as I remember we always require PoP tokens, so
> this could just be removed.

It gets simpler if you always require PoP tokens. Does it state that 
normatively somewhere?

The "unless" construct opens a can of worms about how things are to work 
in that case.

>> * 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"?
> 
> I don't think this is a "MUST"; it refers to some behavior in the core
> framework that is merely suggested and not mandatory.

I commented on this in my reply to Jim.

	Thanks,
	Paul

> Thanks for the review; it brought up some good points!
> 
> -Ben
> 
>> 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.
>>
>> 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.