IETF Logo Mail Archive

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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 20 February 2018 17:12 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
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 CF70C127978 for <ace@ietfa.amsl.com>; Tue, 20 Feb 2018 09:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=armh.onmicrosoft.com
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 DmzRWOG8iT0k for <ace@ietfa.amsl.com>; Tue, 20 Feb 2018 09:12:31 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0054.outbound.protection.outlook.com [104.47.1.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9361612D960 for <ace@ietf.org>; Tue, 20 Feb 2018 09:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FN0RFxNnKXmOH2PhMkD5eGaNvShfvDhNKjNFlosMCeg=; b=erHqlCF8om4BJ1fju+Nk7/rIX222TFHHzobgZ2jX73rN9a06JgfEOZJ0dG/sdoO6LQCJleZgK00qrMNXEPbdjtkRERRHEtMaUfqtPFNoJc+KKRMmeMpvGFUMSRm7FJ8q4N+eknbkztX/5SoRqI7IMTH51jv5zss828BdLt4jaJM=
Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB1460.eurprd08.prod.outlook.com (10.168.5.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 17:12:27 +0000
Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::7954:44ac:aab4:bc2c]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::7954:44ac:aab4:bc2c%14]) with mapi id 15.20.0506.023; Tue, 20 Feb 2018 17:12:27 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, Ludwig Seitz <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
Thread-Index: AQHTqM6IxAS77gQkjk+VU/b7JuvkYaOqWx3wgAAC+4CAARSsgIAAh6iAgAGHpmCAAAZOgIAAAS3g
Date: Tue, 20 Feb 2018 17:12:27 +0000
Message-ID: <AM4PR0801MB2706F7A61AFC9DCAB2ADE645FACF0@AM4PR0801MB2706.eurprd08.prod.outlook.com>
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> <09794CFF-B354-4153-8430-94A9ACD65482@tzi.org>
In-Reply-To: <09794CFF-B354-4153-8430-94A9ACD65482@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [193.92.70.80]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0801MB1460; 7:203WtvQ/JZczzVXAeWpK76oCwMPSIsb+j3qOSakFv8R/XdZCQweWZIneX/S+jXUVyG1EA9bbfMS6sP4o+ILcGlPziuAr946Y7wlHicqeXH4eBE1wu7dkTUEMZ2eK5xtO4BSBT9cBJOT2MxlMTjnLbShPF2cXgY6hIRrM44T7qTOeaWuNhz2Q1FPPHWX14T5vDJuh5ChzIJcANa1OacrpXZvZ0dQtD2aNxjc3pV48WMNk4z9yQ02XQ5DldHkL5Z8I
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7afc2a48-f093-4028-c62f-08d578851e62
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM4PR0801MB1460;
x-ms-traffictypediagnostic: AM4PR0801MB1460:
x-microsoft-antispam-prvs: <AM4PR0801MB1460F1A563175D526ACB836EFACF0@AM4PR0801MB1460.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(180628864354917);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231101)(944501161)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR0801MB1460; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0801MB1460;
x-forefront-prvs: 05891FB07F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(39380400002)(39860400002)(13464003)(189003)(199004)(40434004)(99286004)(97736004)(66066001)(7736002)(3280700002)(305945005)(2906002)(105586002)(74316002)(14454004)(6916009)(8676002)(8936002)(81156014)(86362001)(81166006)(478600001)(59450400001)(68736007)(72206003)(966005)(26005)(102836004)(6506007)(53546011)(5250100002)(2950100002)(5890100001)(229853002)(33656002)(76176011)(3660700001)(7696005)(106356001)(6306002)(55016002)(5660300001)(9686003)(316002)(93886005)(6246003)(25786009)(186003)(2900100001)(53936002)(4326008)(6116002)(3846002)(6436002)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB1460; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iXX9X9PCDktsde8q/MtZBh3yE1V78vj2y2aQeN4T7TGNB9k6HjeB08/DJ4ylsIM6ngXnGtnUkQTr2RKU7Nn+IlXmEbwGjxJyDe26JWROcxLuRK+hvxNsacc1MzDiwpSMBdp4si/t/1Luuo9snPGta3+ne2gXtlEavdqcQNahaXc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7afc2a48-f093-4028-c62f-08d578851e62
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 17:12:27.7472 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB1460
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/kp4Cm9bg6h9zvSG4tWTIr9Okytc>
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:12:33 -0000

Hi Carsten,

OAuth defined something called "Dynamic Client Registration", which gives you an idea what type of information is typically needed. Here is the RFC: https://tools.ietf.org/html/rfc7591

Regarding "initial integration of a device into a network only" isn't this sometimes called "network access authentication"?

In any case, I agree with you that we should add some text about what information is assumed to be present.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: 20 February 2018 19:05
To: Hannes Tschofenig
Cc: Michael Richardson; Ludwig Seitz; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

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

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.

v2.23.0 | Report a Bug | By Email