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 7E8971A8F4D for ; Mon, 11 Jan 2016 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 3AOjs9vhxLEy for ; Mon, 11 Jan 2016 10:19:52 -0800 (PST) Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CE81A8F48 for ; Mon, 11 Jan 2016 10:19:52 -0800 (PST) Received: from mtaout-aaj01.mx.aol.com (mtaout-aaj01.mx.aol.com [172.27.3.205]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 154D83800119; Mon, 11 Jan 2016 13:19:51 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B082C38000092; Mon, 11 Jan 2016 13:19:50 -0500 (EST) To: Mike Jones , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <5693F276.8020501@aol.com> Date: Mon, 11 Jan 2016 13:20:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030307010605080804060601" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1452536391; bh=9H+eYrpqCjb6buFB6J28sLv87RkddxvgG/GEyJ4nz48=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=6yFPSeKGNtzH2RFyr1AHfm762X0bpJd0/z2N5wusrq6R9nvp1NFjCk3L5hf+x4R29 TfXzAus9XH7R4nXXuUx20YM3XaxLML2tJF88Wj8CZeZd9ZayJ2X16+lJCoIXRgKXui fM+tyygpa4fMdCJnPNlDs5imbvn0CsgePldMaX2g= x-aol-sid: 3039ac1b03cd5693f2462638 X-AOL-IP: 10.172.102.124 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 18:19:54 -0000 This is a multi-part message in MIME format. --------------030307010605080804060601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious 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 > Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 Mix-Up > Mitigation draft he mentioned that mitigates the attacks covered in > the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 Authorization > Framework that enables an authorization server to provide a client > using it with a consistent set of metadata 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 servers, including potentially using a token > endpoint that does not belong to the same authorization server as the > authorization endpoint used. Recent research publications refer to > these as "IdP Mix-Up" and "Malicious Endpoint" attacks. > > The gist of the mitigation is having the authorization server return > the client ID and its issuer identifier (a value defined in the OAuth > Discovery specification ) so that the > client can verify that it is using a consistent set of authorization > server configuration information, that the client ID is for that > authorization server, and in particular, that the client is not being > confused into sending information intended for one authorization > server to a different one. Note that these attacks 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 feedback to the OAuth > working group. This draft is very much a starting point intended to > describe both the mitigations and the decisions and analysis remaining > before we can be confident in standardizing a solution. Please > definitely read the Security Considerations 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 Trier), Christian > Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University > Bochum), and Guido Schmitz (University of Trier) for notifying us of > the attacks and working with us both on understanding the attacks and > on developing mitigations. Thanks too to Hannes Tschofenig for > organizing a meeting on this topic last month and to Torsten > Lodderstedt and Deutsche Telekom for hosting the meeting. > > 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=1524 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 --------------030307010605080804060601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious 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 Authorization Server Mix-Up.  This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory.  The abstract of the specification is:

 

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata 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 servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks.

 

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one.  Note that these attacks 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 feedback to the OAuth working group.  This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution.  Please definitely read the Security Considerations 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 Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations.  Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

 

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=1524 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
--------------030307010605080804060601--