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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 17 September 2020 15:26 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 71A5D3A00C9; Thu, 17 Sep 2020 08:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 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] 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 Dw8YWJQsBC7a; Thu, 17 Sep 2020 08:26:04 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2057.outbound.protection.outlook.com [40.107.92.57]) (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 CD7113A09F5; Thu, 17 Sep 2020 08:26:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aGlx5bNBweIL6lmswtmp6lQ0brvGA6mYUYPcbU69yvKysgJxlX1DcT6Xm1BLsYQiMlp4KXKt/r0vw/Ajqk0AaS6g0Rkv8trjVuzz597ZhcKvVJhu/8JYaqLzPVGHXTDGKnM7xTefLdDrzRCYEhX02uvKQVniHFRpFsSBjo3Gp3FL2zT2FFMtnaJra0joL+ni6Ujk+WCwi1Alq5ooYdLi/T+Me9mT8OFlDPa06j1/HbmvC6zIDsGfqXZ4qE9o6WdMkFar1mJ9/ZtnZmvyq9aLdM6q1f5MNm2kP49t+yZJzFBNSae0chBGHCV6WupuxjXjPDjfjWReed+vOuNP6EQBjQ==
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=6c/xtGL2tE4a7ved3Zz8XsSAxfmias7xycCUxob4Jo0=; b=Hf2hCXVqNdf8wsCRJR7C2fJUkxV9oddr5JqL05QDDd/HJAqB6v9rs4x3hpTT63wLRxt/jT9XfS4w2n8hwNKGYt51GZ7LiDYX0mwaDqfSajU3nhhqFrHVs1qS6tstannKmdT/m+tCJx96bgpmNTsRwECsDf2ktxWnaIb3WnQZ5yIKbqUmGi/NSb3lBBWcwnBkqKgbMpOVgZizyK1C4aXi6j6wHnPjSlMt3aP5qwCQ1+bzEgS8PsPY3HH7eR/dLCefM93TtAHRs1cQzS0EutgbKsRIgdOLgUoJxbPOpQBznn6kTGixzJXxxIMLSbdtSb9JLjHTih50S9YnoDr9ROfwOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=tzi.org 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=6c/xtGL2tE4a7ved3Zz8XsSAxfmias7xycCUxob4Jo0=; b=CJlOQzzh0WtfRU7ayNOxrKhNxvQShBYhovUbhdonJik2V77cHb6Sl37W+F3/7Kn5qhEkyp+uBxH4U4GoEd1ohwf8zBDYzA25OzN4gxdlHWciTpyKPnx9EVPTOzvR8LnzPs8xkWyAd9z6XXBT6ImAoE01Nn7nwuCPM/2fx1ode1o=
Received: from CY4PR21CA0024.namprd21.prod.outlook.com (2603:10b6:903:dd::34) by BL0PR12MB2514.namprd12.prod.outlook.com (2603:10b6:207:43::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Thu, 17 Sep 2020 15:25:59 +0000
Received: from CY1NAM02FT034.eop-nam02.prod.protection.outlook.com (2603:10b6:903:dd:cafe::5f) by CY4PR21CA0024.outlook.office365.com (2603:10b6:903:dd::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.0 via Frontend Transport; Thu, 17 Sep 2020 15:25:58 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; 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 CY1NAM02FT034.mail.protection.outlook.com (10.152.75.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Thu, 17 Sep 2020 15:25:58 +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 08HFPtSW029879 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 17 Sep 2020 11:25:55 -0400
To: Olaf Bergmann <bergmann@tzi.org>
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> <87y2muo6ix.fsf@wangari> <87v9gomsf4.fsf@wangari> <b0e2088b-ab24-3d35-c98a-161955d3fc7a@alum.mit.edu> <87v9gcg6za.fsf@wangari>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <b8a6b44d-ff4d-448c-6ca0-779cb98187c5@alum.mit.edu>
Date: Thu, 17 Sep 2020 11:25:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2
MIME-Version: 1.0
In-Reply-To: <87v9gcg6za.fsf@wangari>
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: 5f381d6e-fba6-4ce0-b9f0-08d85b1dfa4a
X-MS-TrafficTypeDiagnostic: BL0PR12MB2514:
X-Microsoft-Antispam-PRVS: <BL0PR12MB2514599F5FA0B847D7451500F93E0@BL0PR12MB2514.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: GWLnew46EF2rlrbfmEdIbn2RCza1bP1ftdfJodY2J2t82bdzd3LQQRqJw8rMzLd6N3G88NW6D7LA3AGGQJsCDYSFdOAH4nc1H3h6MmUzDxSpg/4l+i7ZRjXCt8/YZCjNqwcXVeg92yx1Y09u85Z4oCjKBSRkU3Q4s5xg+aCVM9flTfzQTNDBXQ4A62WY8cEm+eZHE+crT+Tvs+K2QLn5987UI8knQ63xRchRLcy9/vu4BE9waBHQcot73fYtSJKIlJ7dkpwLGOKYk4hCfKh1m3fNMhovUd+Y9D8XBFbeHiF7HpLnED6hhVgsDU+j4rlB7MuUCXx+dAWS1FT6oyUKtTBI5jDevEf72ecekPrlA0neHr/oNhSxxyV6hK4cth37Vhm523N45LtBszSfWM8NPLPjxfkrVJi+bWqHpsCpfCdRJG+oAY3mTLfxzQp7qH1A
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; SFS:(396003)(376002)(39860400002)(346002)(136003)(46966005)(316002)(8936002)(2616005)(70586007)(6916009)(82310400003)(956004)(5660300002)(26005)(53546011)(75432002)(31686004)(4326008)(83380400001)(47076004)(356005)(2906002)(336012)(8676002)(70206006)(786003)(186003)(478600001)(86362001)(7596003)(31696002)(36906005)(82740400003)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2020 15:25:58.1397 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f381d6e-fba6-4ce0-b9f0-08d85b1dfa4a
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: CY1NAM02FT034.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2514
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Zt86C0lzjSpJmzg3iWgABFa-oyI>
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: Thu, 17 Sep 2020 15:26:07 -0000

Hi Olaf,

On 9/17/20 4:09 AM, Olaf Bergmann wrote:
> Hi Paul,
> 
> Responding to you remaining comments please see inline.
> 
> Paul Kyzivat <pkyzivat@alum.mit.edu> writes:
> 
>>>>> * 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.
>>>>
>>>> I take it that you and Ben have agreed that the example description does
>>>> not necessarily need normative language as the description of this key
>>>> derivation procedure is meant as an example how the authorization server
>>>> and the resource server can securely agree on a shared secret to be used
>>>> between the client and the resource server.
>>
>> This still confuses me. IIUC preferred serialization and deterministic
>> encoding are *optional* in CBOR. The text hear seems to require it,
>> but doesn't use normative language to do so.
>>
>> If these are required for things to work then you make a normative
>> statement about it. E.g., "The "type" and "L" components MUST use the
>> minimum length encoding."
>>
>> Or do you intend that some other (non-minimum-length) MAY be used? (In
>> which case both sides would need a side agreement on what encoding is
>> used.)
> 
> The text here just gives an example how key derivation may be used by
> the authorization server and the resource server to agree on a shared
> secret (that is used to encrypt the traffic between the resource server
> and the to-be-authorized client).
> 
> To that regard, the text is not really normative. The only normative
> language we need here would be to avoid security issues. Commenting on
> the data representation here is to be understood as a suggestion to use,
> e.g., preferred CBOR serialization according to 7049bis.
> 
> [...]

Sorry to be so dense, but I'm still not getting it.

I take your point that this is only an example of a way to agree on a 
shared secret. But at the end of the day they indeed must somehow agree 
on a shared secret. *If* they use this technique then it will only work 
if they also agree on a consistent way to do the serialization and 
encoding that is otherwise not standardized. So they need a side 
agreement, which is not a good situation for a standardized protocol.

At the very least it seems like you should highlight that some sort of 
out of band communication is required between the authorization and 
resource servers to establish the shared secret or the algorithm to be 
used for deriving the shared secret.

>>>> OLD:
>>>>
>>>>     New access tokens issued by the authorization server are supposed to
>>>>     replace previously issued access tokens for the respective client.
>>>>
>>>> NEW:
>>>>
>>>>     New access tokens issued by the authorization server replace
>>>>     previously issued access tokens for the respective client.
>>
>> The above is still non-normative. Perhaps:
>>
>>        New access tokens issued by the authorization server MUST replace
>>        previously issued access tokens for the respective client.
> 
> Following Section 5.8.1 of the framework document, this should be a
> SHOULD (the text there reads as: "This specification RECOMMENDS that an
> RS stores only one token per proof-of-possession key, meaning that an
> additional token linked to the same key will overwrite any existing
> token at the RS."
> 
> The text then would read as follows (changes are the new SHOULD and
> "needs a common understanding" instead of "must have":
> 
> OLD:
> 
>     According to
>     Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
>     access token for each client.  New access tokens issued by the
>     authorization server replace previously issued access tokens for the
>     respective client.  The resource server therefore must have a common
>     understanding with the authorization server how access tokens are
>     ordered.  The authorization server may, e.g., specify a "cti" claim
>     for the access token (see Section 5.8.3 of
>     [I-D.ietf-ace-oauth-authz]) to employ a strict order.
> 
> NEW:
> 
>     According to
>     Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
>     access token for each client.  New access tokens issued by the
>     authorization server SHOULD replace previously issued access tokens for the
>     respective client.  The resource server therefore needs a common
>     understanding with the authorization server how access tokens are
>     ordered.  The authorization server may, e.g., specify a "cti" claim
>     for the access token (see Section 5.8.3 of
>     [I-D.ietf-ace-oauth-authz]) to employ a strict order.

That seems ok.

	Thanks,
	Paul