Return-Path: 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 720591A8863 for ; Mon, 11 Jan 2016 01:27:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 kOWAwxMTJD65 for ; Mon, 11 Jan 2016 01:27:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B35B1A8862 for ; Mon, 11 Jan 2016 01:27:36 -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=1NILvSMZdf6r6oyd8IJ4tOliOklRP8eWzgGLGI/hcZQ=; b=WfJ2TH3ZVERN5De1FgWsZVSb/ClfvMPQT8DR52+HmLTzv7wknaNN3Ea8/dkeRs3H58M4Zpy6+Wb++s+aw/hmkf635OzTvu/No56fzuiKbJD7LSRVVgyPvQAybjZH7dym1nVdvd0tXB6jIE2H/5ZDZpwIl1lvRWoLIPWf7QmNzKU= 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.361.13; Mon, 11 Jan 2016 09:27:23 +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.0361.006; Mon, 11 Jan 2016 09:27:23 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQ== Date: Mon, 11 Jan 2016 09:27:21 +0000 Message-ID: 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=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:Vb4FOsNyf4FS3go4vBdGvqKmshvkG+aELxsqNGw6o+ceINgYgugrH1xeyyHPbcteosymPmF7187U/8Zxhxg6pC7RXa4Q3bx1OMZM1THkovjAPTcVqPAvMB3IUvc37Sh6KGmIT02z+P7PUdbpnkvWHg==; 24:f1GX6oaNSk5co0RTF4gfXLAkRCzIBWKMZHrhDrwsoLDW1FW9T9ZdwQCjR+ITNlWoNkbulfYOZwIavkbVz0dGVRWAp3gJTf1+P9oTa+D9EfY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-ms-office365-filtering-correlation-id: ecac968a-9547-4af8-ecaf-08d31a696966 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(189998001)(19617315012)(5005710100001)(107886002)(106356001)(110136002)(87936001)(76576001)(1730700002)(102836003)(790700001)(6116002)(2351001)(19300405004)(10290500002)(19625215002)(1220700001)(11100500001)(3846002)(92566002)(5001960100002)(77096005)(229853001)(2501003)(74316001)(81156007)(50986999)(86362001)(105586002)(86612001)(54356999)(8990500004)(97736004)(33656002)(1096002)(586003)(40100003)(16236675004)(450100001)(10400500002)(66066001)(122556002)(5008740100001)(2900100001)(2906002)(10090500001)(5004730100002)(5002640100001)(101416001)(19580395003)(15975445007)(99286002)(5003600100002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 09:27:21.8800 (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: Subject: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:27:40 -0000 --_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authori= zation Server Mix-Up. This note announces the publication of the strawman OA= uth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks cov= ered in the advisory. The abstract of the specification is: This specification defines an extension to The OAuth 2.0 Authorization Fram= ework that enables an authorization server to provide a client using it wit= h a consistent set of metadata about itself. This information is returned i= n the authorization response. It can be used by the client to prevent class= es of attacks in which the client might otherwise be tricked into using inc= onsistent sets of metadata from multiple authorization servers, including p= otentially using a token endpoint that does not belong to the same authoriz= ation server as the authorization endpoint used. Recent research publicatio= ns refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks. The gist of the mitigation is having the authorization server return the cl= ient ID and its issuer identifier (a value defined in the OAuth Discovery s= pecification) so that the client can ver= ify that it is using a consistent set of authorization server configuration= information, that the client ID is for that authorization server, and in p= articular, that the client is not being confused into sending information i= ntended for one authorization server to a different one. Note that these a= ttacks can only be made against clients that are configured to use more tha= n one authorization server. Please give the draft a quick read and provide feedback to the OAuth workin= g group. This draft is very much a starting point intended to describe bot= h the mitigations and the decisions and analysis remaining before we can be= confident in standardizing a solution. Please definitely read the Securit= y Considerations and Open Issues sections, as they contain important inform= ation about the choices made and the decisions remaining. Special thanks go to Daniel Fett (University of Trier), Christian Mainka (R= uhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Gu= ido Schmitz (University of Trier) for notifying us of the attacks and worki= ng with us both on understanding the attacks and on developing mitigations.= Thanks too to Hannes Tschofenig for organizing a meeting on this topic la= st month and to Torsten Lodderstedt and Deutsche Telekom for hosting the me= eting. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00= .html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1524 and as= @selfissued. --_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note= announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draf= t he mentioned that mitigates the attacks covered in the advisory.  Th= e abstract of the specification is:

 

This specification define= s an extension to The OAuth 2.0 Authorization Framework that enables an aut= horization server to provide a client using it with a consistent set of met= adata about itself. This information is returned in the authorization response. It can be used by the client to= prevent classes of attacks in which the client might otherwise be tricked = into using inconsistent sets of metadata from multiple authorization server= s, including potentially using a token endpoint that does not belong to the same authorization server as th= e authorization endpoint used. Recent research publications refer to these = as "IdP Mix-Up" and "Malicious Endpoint" attacks.<= /o:p>

 

The gist of the mitigation is having the authorizati= on server return the client ID and its issuer identifier (a value defined i= n the OAuth Discovery specification= ) so that the client can verify that it is using a consistent set of au= thorization server configuration information, that the client ID is for tha= t authorization server, and in particular, that the client is not being confused into sending information intended fo= r one authorization server to a different one.  Note that these attack= s can only be made against clients that are configured to use more than one= authorization server.

 

Please give the draft a quick read and provide feedb= ack to the OAuth working group.  This draft is very much a starting po= int intended to describe both the mitigations and the decisions and analysi= s remaining before we can be confident in standardizing a solution.  Please definitely read the Security Con= siderations and Open Issues sections, as they contain important information= about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trie= r), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-Uni= versity Bochum), and Guido Schmitz (University of Trier) for notifying us o= f the attacks and working with us both on understanding the attacks and on developing mitigations.  Tha= nks too to Hannes Tschofenig for organizing a meeting on this topic last mo= nth and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting= .

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oa= uth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft= -jones-oauth-mix-up-mitigation-00.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D= 1524 and as @selfissued<= span style=3D"font-size:10.0pt;font-family:"Segoe UI",sans-serif;= color:black">.

--_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_--