Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
Mike Jones <Michael.Jones@microsoft.com> Fri, 19 February 2016 20:19 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3B61B2D82 for <oauth@ietfa.amsl.com>; Fri, 19 Feb 2016 12:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 kIX9HLumvQyE for <oauth@ietfa.amsl.com>; Fri, 19 Feb 2016 12:19:15 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2AE1B2A7A for <oauth@ietf.org>; Fri, 19 Feb 2016 12:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iXKzrUrjG8ZD6H3Oz2m/bLq1vUqElz2yittqpsAubj0=; b=jycKl6de36L1SoPjEX2Mp9cP6QHaB+7gtlV2+0XZYT1vZOhRuiPhXnCYGnugxdNwu5cIYJxXfw+QNEZW438uZv6JRN2N24maC3F9GhXVF4QJyigcMUQNdxQHH2wjCv1YAODr7SekWVq8aoXtncFHiR7aAoY/EPCE+agrLKYub2c=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:18:55 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:18:55 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
Thread-Index: AQHRa02vcYDFrUX6M06+JVJIk0JwsZ8zyRTA
Date: Fri, 19 Feb 2016 20:18:55 +0000
Message-ID: <BY2PR03MB442E9BF84AFA890378C5116F5A00@BY2PR03MB442.namprd03.prod.outlook.com>
References: <56C7702B.2000401@gmx.net>
In-Reply-To: <56C7702B.2000401@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 31b81990-ce68-4aba-8701-08d33969e450
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:xwrFzgZ99SoZrrcrLrXdDOhwrJ2xdjAWWrpc/mW0rC7x5fwOyHmtdKOb88rhKndVNSWK3SCRJ534yyuXIECmvYmuLPJEVEUnu9lZFoiBozwcOW8bNdpOD29aysJNcSjaXmecPM6qZKV3CXh4BcGYKg==; 24:5y+0ku8wMBWMGqCNQ/ExAp2ypC2h93FIO4g++StXb1FCoGMBPC71XT6t4K2up6CwglQrhuC+Q70O46bHuzxupu68e8Dcozhsw/w+R44E8Mo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: <BY2PR03MB44281A3053DF1CFB86FA195F5A00@BY2PR03MB442.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442;
x-forefront-prvs: 08572BD77F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(72854002)(13464003)(377454003)(86362001)(19580405001)(5001960100002)(86612001)(19617315012)(586003)(3660700001)(790700001)(1220700001)(87936001)(2900100001)(2501003)(15975445007)(77096005)(5001770100001)(19580395003)(1096002)(102836003)(2950100001)(6116002)(189998001)(92566002)(107886002)(3846002)(54356999)(5003600100002)(5004730100002)(11100500001)(99286002)(16236675004)(33656002)(5008740100001)(10090500001)(5002640100001)(66066001)(50986999)(76576001)(5005710100001)(122556002)(10400500002)(3280700002)(106116001)(2906002)(19300405004)(10290500002)(40100003)(76176999)(19625215002)(74316001)(15940465004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E9BF84AFA890378C5116F5A00BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:18:55.1860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/BJs3DWR4UoSYEYJGt7LF9WgWM2k>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2016 20:19:19 -0000
Option A. I have higher confidence that this specification solves the problems because it was designed during a 4-day security meeting dedicated to this task by a group of over 20 OAuth security experts, including both sets of researchers in Germany who originally identified the problem. This solution has also been implemented and interop tested by Roland Hedberg, Brian Campbell, and I believe others. Note that the reason I am advocating this specification is *not* because I'm an editor of it; my role was to record in spec language what the OAuth security experts designed together over the 4-day period in Darmstadt. I’ll also note that even if Option B also solves the problem, it comes at significant adoption costs and complexity not found in A. In particular, it requires that developers understand support a new “Link Relation” syntax not used elsewhere in OAuth. As Nat writes about his own draft in http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there is not a standard JSON syntax for link relations. He writes “we could easily create a parallel to it”. I’d rather we solve the problem using standard mechanisms already employed in OAuth, rather than risk bifurcating OAuth in the developer community by unnecessarily inventing/creating new syntax that is unfamiliar to developers and that many of them may reject using. -- Mike P.S. Information about the OAuth security meeting can be found at https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit and https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit . -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, February 19, 2016 11:43 AM To: oauth@ietf.org Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Early February I posted a mail to the list to make progress on the solution to the OAuth Authorization Server Mix-Up problem discovered late last year. Here is my mail about the Authorization Server Mix-Up: http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html Here is my mail to the list that tries to summarize the discussion status and asked a few questions: http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html Unfortunately, my mail didn't lead to the intended success. While there was some feedback I wasn't getting the desired response. In order to move forward I believe we need a working group document that serves as a starting point for further work in the group*. We have two documents that provide similar functionality in an attempt to solve the Authorization Server Mix-Up problem. So, here is the question for the group. Which document do you want as a starting point for work on this topic: -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley Link: https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha Preibisch Link: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 Deadline for feedback is March, 4th. Ciao Hannes & Derek PS: (*) Regardless of the selected solution we will provide proper acknowledgement for those who contributed to the work.
- [OAUTH-WG] Fixing the Authorization Server Mix-Up… Hannes Tschofenig
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Mike Jones
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Hans Zandbelt
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Phil Hunt (IDM)
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… William Denniss
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Hannes Tschofenig
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Mike Jones
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Hannes Tschofenig
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Mike Jones
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Nat Sakimura
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… William Denniss
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Antonio Sanso
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Daniel Fett
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- [OAUTH-WG] JWS Access Token concerns Sergey Beryozkin
- Re: [OAUTH-WG] JWS Access Token concerns Antonio Sanso
- Re: [OAUTH-WG] JWS Access Token concerns Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Roland Hedberg
- Re: [OAUTH-WG] JWS Access Token concerns Sergey Beryozkin
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Anthony Nadalin
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Anthony Nadalin
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Nat Sakimura
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… George Fletcher
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Hannes Tschofenig
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Brian Campbell
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Donald F. Coffin
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Torsten Lodderstedt
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… John Bradley
- Re: [OAUTH-WG] Fixing the Authorization Server Mi… Vladimir Dzhuvinov