IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Tue, 20 February 2018 17:05 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 CF43A126CB6 for <ace@ietfa.amsl.com>; Tue, 20 Feb 2018 09:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 SDtOATAu3xU7 for <ace@ietfa.amsl.com>; Tue, 20 Feb 2018 09:05:35 -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 5FED0127978 for <ace@ietf.org>; Tue, 20 Feb 2018 09:05:35 -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 w1KH5UfX022971; Tue, 20 Feb 2018 18:05:30 +0100 (CET)
Received: from client-0032.vpn.uni-bremen.de (client-0032.vpn.uni-bremen.de [134.102.107.32]) (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 3zm6SS5QQ8zDWrl; Tue, 20 Feb 2018 18:05:28 +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: <AM4PR0801MB270626E98E4F698E6A7763DBFACF0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
Date: Tue, 20 Feb 2018 09:05:23 -0800
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Ludwig Seitz <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>
X-Mao-Original-Outgoing-Id: 540839121.751207-654e02626d8201fa5f5cb58269a3c0fa
Content-Transfer-Encoding: quoted-printable
Message-Id: <09794CFF-B354-4153-8430-94A9ACD65482@tzi.org>
References: <A5100B3E-DBA2-4FBF-9AE4-8E54CE161BCB@tzi.org> <AM4PR0801MB2706F84DFA48E37BBED4C512FAC90@AM4PR0801MB2706.eurprd08.prod.outlook.com> <05040BBB-5E6E-4569-8F8C-944CA04BBA3C@tzi.org> <60d737e6-81f2-1c86-63b2-9b58a320bbb5@ri.se> <21896.1519060863@obiwan.sandelman.ca> <AM4PR0801MB270626E98E4F698E6A7763DBFACF0@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/0Ab9o0_3g8Y3E-6wgEi-thPSPpY>
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: Tue, 20 Feb 2018 17:05:38 -0000

On Feb 20, 2018, at 08:43, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
> 
> IMHO the biggest problem with "onboarding" is that people create new terms without specifying what they actually mean and thereby fail to see the relationship with existing work.

Right.  I have no idea what client registration has to do with “onboarding”, but I use that term for the initial integration of a device into a network only.

I continue to believe that we need a clear understanding of what information is exchanged during client registration that is relevant to the ACE OAuth.  There definitely will also be other information (“business logic”, and you can call the exchange of that part of the registration info “onboarding” if you like), and that is where the vendor differentiation can set in, but we should have no trouble defining the ACE content of client registration.  

If we don’t define that ACE content, there is no way to know whether ACE OAuth is secure.

Defining the ACE content of the client registration as a set of data structures also helps with achieving actual interoperability, even if additional business logic is required in a specific case.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email