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 E2E231A90BA for ; Mon, 11 Jan 2016 11:59:51 -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 DnDOI_8x1mP8 for ; Mon, 11 Jan 2016 11:59:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562F71A90B7 for ; Mon, 11 Jan 2016 11:59:45 -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=y8p8CGs2JVSdVOD8mZjYkE7Rd9T4sK4tA4RjaluAq5Y=; b=ZEAhiHAH6LONdYBJiu1/QL3zX65+k/iiYkpbdxeI2ZAzehy6G6lAvGFZOObaDRSz+OYY5SSA3mElpXqarwYNxddnUVyY8gcOMz1UJFlV8OMUExeCpC2fck199m7HQWUXqIqTZAtXs3bnwVJ1btcVCgcw7om2gjo0m7d5JtTQZ08= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 19:59:22 +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 19:59:21 +0000 From: Mike Jones To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/A= Date: Mon, 11 Jan 2016 19:59:21 +0000 Message-ID: References: <5693F276.8020501@aol.com> In-Reply-To: <5693F276.8020501@aol.com> 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: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:NJuQnwr+Aez8Y3rptzm43GWBiLZTGNhOpAoe+q38bloVe7U5rNo5IOkoYwVtSwe/pN60AH36zhmVmR6ATwYvi7lxooYiCPH7/3kdRJJrFnH2/VQA88GGegm78eI8rBPJLTmmvQNGUEOjR7R3q0qaPg==; 24:TqicmwXXfKI6f0/zz0YxgymQelFl5aUdyctqBa42OBwiuufnwhZ9EHAT4Lx9WIIf+RA/fPRb+qvSb1H8zxB1IjGPX4FbV93GLcHNQtLP7B8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 72e3a277-305a-45a1-a0e8-08d31ac1b2ac x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(149059832740258); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(189002)(199003)(377454003)(479174004)(164054003)(5004730100002)(81156007)(5003600100002)(5001960100002)(101416001)(790700001)(6116002)(15395725005)(5005710100001)(189998001)(122556002)(10400500002)(2950100001)(107886002)(50986999)(33656002)(19580395003)(86612001)(97736004)(10290500002)(1220700001)(586003)(1096002)(2906002)(15975445007)(5001770100001)(66066001)(19300405004)(3846002)(92566002)(8990500004)(5002640100001)(77096005)(74316001)(76576001)(76176999)(54356999)(2900100001)(40100003)(1600100001)(19617315012)(19625215002)(86362001)(2501003)(99286002)(105586002)(87936001)(106356001)(10090500001)(16236675004)(5008740100001)(19580405001)(102836003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; 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_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 19:59:21.6477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [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 19:59:52 -0000 --_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The alternatives for the code flow are to return them either in a new JWT a= dded to the reply containing them in the "iss" and "aud" claims or to retur= n them in new individual "client_id" and "iss" authorization response param= eters. Both alternatives are described in the draft. I'm sure that we'll = now be having a good engineering discussion on the tradeoffs between the al= ternatives., In a separate draft, John Bradley will shortly also be describing the possi= bility of securing the "state" value using a "state_hash" value that works = in a way that's similar to how "at_hash" and "c_hash" secure the "access_to= ken" and "code" values in Connect. This would be an alternative means of b= inding the authorization request and response to the session - accomplishin= g the same thing that the Connect "nonce" does. While I fully get that some OAuth implementations want to avoid having to h= ave crypto, it seems like at least support for cryptographic hashing (SHA-2= 56, etc.) may be necessary to mitigate some of these attacks (at least for = clients that use more than one authorization server). The other important engineering discussion I know we're going to have is wh= ether, when an OAuth profile already returns the information needed for the= mitigation, whether we want to specify that the client obtain it from the = existing location, or whether to also return it in a duplicate location. I= 'll note that OpenID Connect already returns the client ID and issuer for t= he flows that return an ID Token in the authorization response, so this isn= 't a hypothetical question. Finally, I know that we'll need to discuss the impact of cut-and-paste atta= cks when the issuer and client ID are returned as individual authorization = response parameters that are not cryptographically bound to the rest of the= response. The cut-and-paste attack that returning the issuer and client_i= d values as separate parameters enables, even when state_hash or nonce is u= sed, is for the attacker to capture the legitimate response containing "iss= " and "client_id" results and substitute different values for these fields,= then post that altered response to the legitimate client. The state and/o= r nonce values are protected against substitution but "iss" and "client_id"= are not. And yes, I absolutely agree that good examples are essential. That's high = on my list for the -01 version. Thanks a bunch, -- Mike From: George Fletcher [mailto:gffletch@aol.com] Sent: Monday, January 11, 2016 10:21 AM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different attack vectors = and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the mal= icious endpoint if the client can't verify the endpoints before hand. Also, it would be nice to add some non-normative examples to the spec. Thanks, George On 1/11/16 4:27 AM, Mike Jones wrote: 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The alternatives for t= he code flow are to return them either in a new JWT added to the reply cont= aining them in the “iss” and “aud” claims or to ret= urn them in new individual “client_id” and “iss” au= thorization response parameters.  Both alternatives are described in the draft.&n= bsp; I’m sure that we’ll now be having a good engineering discu= ssion on the tradeoffs between the alternatives.,

 

In a separate draft, J= ohn Bradley will shortly also be describing the possibility of securing the= “state” value using a “state_hash” value that work= s in a way that’s similar to how “at_hash” and “c_h= ash” secure the “access_token” and “code” values in Connect.&n= bsp; This would be an alternative means of binding the authorization reques= t and response to the session – accomplishing the same thing that the= Connect “nonce” does.

 

While I fully get that= some OAuth implementations want to avoid having to have crypto, it seems l= ike at least support for cryptographic hashing (SHA-256, etc.) may be neces= sary to mitigate some of these attacks (at least for clients that use more than one authorization server).

 

The other important en= gineering discussion I know we’re going to have is whether, when an O= Auth profile already returns the information needed for the mitigation, whe= ther we want to specify that the client obtain it from the existing location, or whether to also return it in a duplicate= location.  I’ll note that OpenID Connect already returns the cl= ient ID and issuer for the flows that return an ID Token in the authorizati= on response, so this isn’t a hypothetical question.=

 

Finally, I know that w= e’ll need to discuss the impact of cut-and-paste attacks when the iss= uer and client ID are returned as individual authorization response paramet= ers that are not cryptographically bound to the rest of the response.  The c= ut-and-paste attack that returning the issuer and client_id values as separ= ate parameters enables, even when state_hash or nonce is used, is for the a= ttacker to capture the legitimate response containing “iss” and “client_id” results and subst= itute different values for these fields, then post that altered response to= the legitimate client.  The state and/or nonce values are protected a= gainst substitution but “iss” and “client_id” are n= ot.

 

And yes, I absolutely = agree that good examples are essential.  That’s high on my list = for the -01 version.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Thanks a bunch,

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

 

From:= George Fletcher [mailto:gffletch@aol.com]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

 

Thanks Mike. One question after rea= ding about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't ve= rify the endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:

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.




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth



-- 
Chief Architect         &=
nbsp;         
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.          &n=
bsp;            =
;   AIM:  gffletch
Mobile: +1-703-462-3494       &=
nbsp;   Twitter: http://t=
witter.com/gffletch
Office: +1-703-265-2544       &=
nbsp;   Photos: htt=
p://georgefletcher.photography
--_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_--