Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Sergey Beryozkin <> Thu, 21 January 2016 11:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A17941A8A76 for <>; Thu, 21 Jan 2016 03:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id izavv5pPcndE for <>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51C6D1A8A6B for <>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
Received: by with SMTP id 123so170647363wmz.0 for <>; Thu, 21 Jan 2016 03:47:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=hGZ7F39fwJ3CB65YL6Fnc6Q6DKm7immqRhO7WQXACf3V5G6pXla3ahK9wMhYd4HLgi 6QVD5w4wzYg/GejF8eeonMlFbICWE4Qb8eD/b2AnI9TYvdFlJV/oZNAwG1E9glWrW9+H buFDX1tkRA1ftgwPe3Bw1JfkuAVzocgBSsNRS4t57+mCn5E1qtsnKSE7X+cjAY8s97Ww 94Ar85xrKm7GFKgnmHaSVb0jBvveSsNhS716UvLUi8VCCnp6DuT3IgHNGC1gBpFYspjB ILALFF+5LDEZ7lfb8TUE1+54ZR5rZNkX5Xik0hdaKRQpfFuTSo3VnoqO5BpPPcgwfkhy /KtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=BDaysOXL+aA4CZ9XzucNeiLM5c2mESqlcLAB31BZIS/2Orz3Q46k8kKPccUjvvAhem WKdozyWkBn2R/OcMBt6dACIVEqxNSuSY9DVGDvCndgc5vm1h0aFfmagR2rgnOPmvPwlS Wp39jte8i3YoEMTOrJUN2B9VVhf550RT+mo//wTju7GDqSPzt21zvrMc4d4F4g3UEcfj ni5Bk/l6d/G9rz6PCFzMRGRYFy+ey1i1SVTZnIJBTZ9OItMY1U98blV07grl/Ra0zP+y lqnPYhg7juT4KNBoK+llcg61wPlZfc91WPfYuqt7SjYkwAHGYRt5ZQF2Jhfcjsvxaner 3Mqg==
X-Gm-Message-State: ALoCoQkmu2Ctq5TG8GYAGvsK501TaIPXkge+5omggs/PiKudAxSnwarRaaEgd+jCk/c5zwQLysaksSArJo1sj+6R4ZKYFaErAg==
X-Received: by with SMTP id ws9mr47457446wjb.40.1453376848854; Thu, 21 Jan 2016 03:47:28 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id yz5sm1078416wjc.36.2016. for <> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 03:47:27 -0800 (PST)
References: <> <> <>
From: Sergey Beryozkin <>
Message-ID: <>
Date: Thu, 21 Jan 2016 11:47:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
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: Thu, 21 Jan 2016 11:47:32 -0000


On 11/01/16 19:59, Mike Jones wrote:
> The alternatives for the code flow are to return them either in a new
> JWT added to the reply containing them in the “iss” and “aud” claims or
> to return them in new individual “client_id” and “iss” authorization
> response parameters.  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 alternatives.,
> In a separate draft, John Bradley will shortly also be describing the
> possibility 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_token” and “code” values in Connect.  This would be an
> alternative means of binding the authorization request 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 like at least support for cryptographic hashing
> (SHA-256, etc.) may be necessary to mitigate some of these attacks (at
> least for clients that use more than one authorization server).

I'm not sure if it is relevant or misses the point, if so then my 
apologies, but I guess it is +1 to the *optional* hashing of the *whole* 
response as opposed to of some individual response properties. Awhile 
back I posted some proposal to use a JWK thumbprint idea to calculate a 
thumbprint of the response and sign in and include the result of it as 
an extra response property.

Cheers, Sergey

> The other important engineering discussion I know we’re going to have is
> whether, 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 the 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
> attacks 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_id values as separate parameters enables, even when
> state_hash or nonce is used, 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/or 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 []
> *Sent:* Monday, January 11, 2016 10:21 AM
> *To:* Mike Jones <>;
> *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'
> 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:
>     ·
>     An HTML-formatted version is also available at:
>     ·
>                                                                -- Mike
>     P.S.  This note was also posted at
>     and as @selfissued <>.
>     _______________________________________________
>     OAuth mailing list
> <>
> --
> Chief Architect
> Identity Services Engineering <>
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter:
> Office: +1-703-265-2544           Photos:
> _______________________________________________
> OAuth mailing list

Sergey Beryozkin

Talend Community Coders