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

Carsten Bormann <cabo@tzi.org> Sun, 18 February 2018 17:14 UTC

Return-Path: <cabo@tzi.org>
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 306811201F2 for <ace@ietfa.amsl.com>; Sun, 18 Feb 2018 09:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 P0IgXSeVdGIg for <ace@ietfa.amsl.com>; Sun, 18 Feb 2018 09:14:51 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 DE96D1200B9 for <ace@ietf.org>; Sun, 18 Feb 2018 09:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1IHEkWg001589; Sun, 18 Feb 2018 18:14:46 +0100 (CET)
Received: from [172.25.0.142] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zktm55gMrzDXrn; Sun, 18 Feb 2018 18:14:45 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <AM4PR0801MB270639E05AEB6201860503A4FAC90@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Date: Sun, 18 Feb 2018 09:14:40 -0800
Cc: ace <ace@ietf.org>
X-Mao-Original-Outgoing-Id: 540666879.118325-f3dc61d0c287c7a397a745eb02cbc274
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EEA7253-4C7B-423A-8A3F-B0C9D798A257@tzi.org>
References: <A5100B3E-DBA2-4FBF-9AE4-8E54CE161BCB@tzi.org> <AM4PR0801MB2706F84DFA48E37BBED4C512FAC90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <05040BBB-5E6E-4569-8F8C-944CA04BBA3C@tzi.org> <AM4PR0801MB270639E05AEB6201860503A4FAC90@AM4PR0801MB2706.eurprd08.prod.outlook.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/AbqAIOGpeMhqXoVPsVBmXENYhFg>
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: Sun, 18 Feb 2018 17:14:52 -0000

On Feb 18, 2018, at 08:52, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
> Hi Carsten,
> 
> The challenge is that there is not a single way used in deployments. Some of the techniques fall outside the scope of the IETF (such as the manufacturing-related interactions), link layer specific approaches (such as a Blueooth Smart App), or Secure Element-based concepts.
> 
> Note that related solutions, such as ZeroTouch, ANIMA, EST, also leave this initial provisioning undefined.

But this is not about initial provisioning (CAM-C), this is about C talking to an RS.
If there are only intra-silo ways in ACE to get this going, we should clearly document this.
Also, we need to clearly state what we believe needs to be achieved in that intra-silo step so the ACE protocol can rely on the security properties achieved there.

> I am not saying that nothing should be standardized but it will be difficult to recruit the appropriate expertise and to get the relevant companies to participate.

The IETF is generally most successful when it works on building blocks that then can be picked up by implementers and other SDOs (that pickup process then serves as another layer of quality control for us).  I don’t know why we have to be shy about this specific area for building blocks.

Grüße, Carsten

> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: 18 February 2018 17:45
> To: Hannes Tschofenig
> Cc: ace
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
> 
> 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
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
>