IETF Logo Mail Archive

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Ludwig Seitz <ludwig.seitz@ri.se> Mon, 19 February 2018 09:15 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 C23FB126CBF for <ace@ietfa.amsl.com>; Mon, 19 Feb 2018 01:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rs_69FF0jbje for <ace@ietfa.amsl.com>; Mon, 19 Feb 2018 01:15:35 -0800 (PST)
Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDB212711D for <ace@ietf.org>; Mon, 19 Feb 2018 01:15:34 -0800 (PST)
Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 84CE72282F4 for <ace@ietf.org>; Mon, 19 Feb 2018 09:15:34 +0000 (UTC)
Received: from [192.168.0.166] (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.1261.35; Mon, 19 Feb 2018 10:15:32 +0100
To: ace@ietf.org
References: <A5100B3E-DBA2-4FBF-9AE4-8E54CE161BCB@tzi.org> <AM4PR0801MB2706F84DFA48E37BBED4C512FAC90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <05040BBB-5E6E-4569-8F8C-944CA04BBA3C@tzi.org>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <60d737e6-81f2-1c86-63b2-9b58a320bbb5@ri.se>
Date: Mon, 19 Feb 2018 10:15:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <05040BBB-5E6E-4569-8F8C-944CA04BBA3C@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.2 cv=K9NSJ2eI c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=Op4juWPpsa0A:10 a=7CQSdrXTAAAA:8 a=1SteP1iEppvqJWz3LrAA:9 a=V9DH2deglXVIcE3R:21 a=Rik4e0k8626fV9ar:21 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Virus-Scanned: clamav-milter 0.99.3 at MailSecurity
X-Virus-Status: Clean
X-MailSecurity-Status: 0
X-Scanned-By: WeCloud MailSecurity
X-MailSecurity-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/cFBwmjfra7NpfxasIZJf_3sy178>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Feb 2018 09:15:37 -0000

On 2018-02-18 17:45, Carsten Bormann wrote:
> On Feb 18, 2018, at 08:35, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>>
>> Hi Carsten,
>>
>> We should maybe add that this information is provisioned either during manufacturing, via a commissioning tool or some other mechanisms. Not sure whether this will indeed add more but it might be useful to know.
> 
> For a protocol that is meant to be interoperable, there need to be standard (if not MTI) ways of getting this done.
> At least we need to have a defined interface between CAM (“commissioning tool”) and C for letting C know what was agreed about how to address AS and which RSes it should be used for.
> 
> Grüße, Carsten
> 

Why don't you make a new draft where you propose such a mechanism?

I don't think this fits in the scope of the framework draft, since the 
framework is supposed to deal with the interaction between C-AS and C-RS 
(after the onboarding has happened).

I agree that onboarding is a valid concern (which is why I wrote 
appendix B), but lets not delay draft-ietf-ace-oauth-authz any further 
by adding a whole new set of functionality in it.

/Ludwig

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

v2.23.0 | Report a Bug | By Email