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

Nat Sakimura <> Tue, 09 February 2016 03:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A85981A00F4 for <>; Mon, 8 Feb 2016 19:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 72H56pJmTpN4 for <>; Mon, 8 Feb 2016 19:23:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65C631A00F3 for <>; Mon, 8 Feb 2016 19:23:48 -0800 (PST)
Received: by with SMTP id o6so66563541qkc.2 for <>; Mon, 08 Feb 2016 19:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=kBT7uI3hVfmBGCsgTL/CiRLcxPAh5T94DmsEScScl+8=; b=KAKEwSIzksVT+4UCe0VTCP71F3E8OWSj+Y9ttmtEzUUU409PjS/GBvXLLtW0rBDuA6 9o/jUtcJvlDq5lhLIJDMeMj+CoBjChwZFEXHCQw1cPT+hFaH5GDL2g626hh4SnjA5Nml O9/jLkuno3mrH89MHZYRukzsSulqRX+TMNfnNuGnwDBWUlliXn6SAHmJvJdlExIeHQGQ XM9qj0kWd3FLpzILDzuV/2C75tiSmHTj7J47DUPgKt1v9dyR5Ox8TJk5OwCnmZtWKKID d9zdH7yAE1hnRdEdinBQUNVonaSok7NVfmNK/A59QO4bNiWy3NW+PLZNzWAaeGyP+urz OPvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=kBT7uI3hVfmBGCsgTL/CiRLcxPAh5T94DmsEScScl+8=; b=WOyPYanlOtIfFrYjV2f0Pn/LOyZemn9qoIuX7+XUlyf3V4KvAYvmLZJLR07bVk+vFx KhpAOL0MQpxYqunettAP2Z7aJ7YsZKceduKSr7aPK8hswND1NTEv4Y3wPGecon8ZuyME qzNY6z1zGS/6XySALcRcIonJCFFV7PWIzLo1Xd+7UTkxwlsZN/mpp7zdYE/xVlwLArFM kletkTuKbI4ZL9FEcxERwXQxJA4TvNt0pqbPpnAcRE64Eyt0+xT2cQIQQ4qe/QF2+BL3 ybMPvHfEHsxayFqvsb9t+WqqxGKTKXOjZxqf9epabUHuNlNnMqmsgR2CiStBX5SwYRkH JN6Q==
X-Gm-Message-State: AG10YOR8VXqzT+vSzsIcojbK16kIPxcmOhGmvZLEAfGDkw9uxrrhyygd6lc8KQHWevl/2yeaZbmgbucFTohxIw==
X-Received: by with SMTP id u63mr38305011qka.67.1454988227517; Mon, 08 Feb 2016 19:23:47 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Tue, 09 Feb 2016 03:23:37 +0000
Message-ID: <>
To: John Bradley <>, Torsten Lodderstedt <>
Content-Type: multipart/alternative; boundary="001a114a797474247b052b4dd8c4"
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions
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: Tue, 09 Feb 2016 03:23:52 -0000

I support keeping those two in a single document.

They actually belong to a same class of problem: the problem of accepting
an input from an untrusted / un-protected source, i.e., the authorization
When this vulnerability is applied to the 'state', it opens up the chance
of authorization code being stollen through a rogue token endpoint.
When it is applied to the authorization code, then it is a cut-n-paste

The reason why 'code id_token' response type is protected in OIDC is that
the authorization response is integrity protected and the origin


2016年2月6日(土) 23:59 John Bradley <>:

> I think Toresen states it well.
> The reason we looked at 2 again is that #1 in some of the attacks was
> being used to leak the code.
> In some of those cases the attacker had the client credentials and could
> use the directly to get access tokens.
> In other cases the attacker doesn’t have the client credentials, but could
> still get access to the information protected  by the API by presenting the
> code back to the client as part of a new flow, and bind it to a new account
> or if the clint is unwise and using the code for authentication,
> impersonate the user.
> There are certainly other ways an attacker could get code, via logs, open
> redirectors etc.
> The closest mention of this in 6819 is sec ,  but that considered
>  two clients with two client_id.
> that was mitigated by having the client send it’s client_id with code to
> exchange it.
> The difference with 2 is that only one client_id is used, and that is not
> mitigated by the current counter measures in 6819.
> Perhaps referring to 6819 sec is a distraction, in this case.
> We however were concerned at the time about codes leaking and being
> replayed but missed some of the ways that could happen.
> The two opportunities that we are leaving for attackers,  1 not knowing
> who is sending the authorization response, and not tying the authorization
> request and response to the same browser instance open a whole world of
> attacks.
> What we think currently is that there are two basic flaws that are being
> exploited (some attacks use one or the other and some use them together) .
>   We should probably keep the fixes separate from documents that are more
> how to guides to attack un-patched clients.
> Both issues are around the client being mislead or confused by an
> authorization response, in that it is coming back from the wrong place or
> in the wrong browser instance.  That is why the two mitigations probably
> belong in the same document.
> John B.
> On Feb 6, 2016, at 8:32 AM, Torsten Lodderstedt <>
> wrote
> Hi Hannes,
> #2 is not directly described in the paper but was used to replay the
> code/token the attacker obtained via #1. In my observation, the discussion
> in Darmstadt has shown that OAuth (and its built-in mitigations) so far
> focused on preventing code/token leakage but we lake mitigation for replay
> in this particular case.
> #2 does not require the attacker to control the network or the victim's
> device. The attacker (using #1 or other attacks, e.g. on referrer headers
> or log files) obtains a code and injects this code into a legitimate
> OAuth/OIDC flow on its device. All she has to do is starting a authz code
> flow on the legitimate client, the particular code was issued for, and
> replace the code in the response from the AS. From the client's
> perspective, the response looks ok, since it carries the correct state
> value bound to the client in the particular user agent (since this is not a
> XSRF). But since there is no way (currently) to bind the code to a certain
> user agent, the client would accept the code and exchange it for token(s)
> on the AS. That gives the attacker access to resources of the victim and/or
> impersonates the attacker as the victim.
> There are several way to mitigate this issue:
> - OIDC has the "code id_token" response type, which uses nounce and c_hash
> in the id_token to bind the code to the user agent session
> - in Darmstadt we came up with the idea to utilize the state value for
> that purpose.
> Do we need to describe the threat and mitigation if
> draft-jones-oauth-mix-up-mitigation? I don't think so.
> We could describe the mechanisms in a different draft.
> I personally would prefer (and Phil already states this as well) the WG to
> work on a single draft, providing a consolidated view on all threats caused
> by the more dynamic usage of OAuth. We could also include all
> threats/mitigations/issues we have seen in the wild since RFC 6749 was
> published. This would also include stronger advice regarding XSRF
> prevention and open redirectors. I don't think we serve the community well
> be spreading those issues and mitigation over 3 or 4 drafts.
> best regards,
> Torsten.
> Am 04.02.2016 um 21:27 schrieb Hannes Tschofenig:
> Hi all,
> when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation'
> solution <draft-jones-oauth-mix-up-mitigation> I wasn't expecting such a
> heavy debate on the list. While the call for adoption is still ongoing I
> would like to share my view as someone who has to judge consensus in a
> few days together with Derek.
> Regardless of where we are with respect to oauth-meta vs.
> draft-jones-oauth-mix-up-mitigation we should keep an eye on the threats
> we are trying to address (and we have to document them).
> Here is how I would summarize the situation after reviewing the drafts,
> blog posts and various emails sent to the list.
> We have two types of threats:
> #1: Threat described in the papers referenced in my email to the list
> The attack assumes that '... the presence of a network attacker who can
> manipulate the request in which the user sends her identity to the RP as
> well as the corresponding response to this request ...' (see page 15 of
> I believe that this threat is well documented (at least in the paper).
> #2: Cut-and-Paste Attacks
> Here things get a bit more difficult since the threat is less well
> described. In Section 7.3 of Mike
> makes an attempt to describe the attack and refers to Section
> of RFC 6819, which talks about 'Code Substitution'. I am not convinced
> that the description in RFC 6819 exactly matches the intention of
> Section 7.3 of draft-jones-oauth-mix-up-mitigation-01 but I might be
> misinterpreting.
> Anyway, here is a copy-and-paste from the draft:
>    A "cut-and-paste" attack is performed
>    by the attacker creating what appears to be a legitimate
>    authorization response, but that substitutes some of the response
>    parameter values with values of the attacker's choosing.
> Clearly, this attack makes different assumptions than what is stated in
> the papers listed under item #1. It appears that the attacker will have
> to be on the users device /browser itself. If that's true then the text
> needs to state that.
> Nat also provides a description of a similar attack in his blog post
> under the name of 'Code Phishing' at
> In his description the attacker assumption is that the developer is
> tricked into re-configuring the token endpoint so that the attacker is
> able to obtain the authorization code.
> While I believe the group is well advised to tackle the attack described
> in item #1 to mitigate the attacks discovered late last year. I am
> curious whether the group also sees the mitigation of threat #2 in scope
> of this document. In some sense, one could argue that cut-and-paste is
> more generic and a concern also for those cases where an OAuth client
> does not talk to multiple ASs.
> So, here are my questions:
> - Can we describe the threat #2 in more details and by stating the
> assumptions about the attacker?
> I believe that this is important for understanding the attack within the
> participants of the group but also for those who stumble over our
> documents. Once we have a good description we should move on and answer
> the next two questions:
> - Should the document describe mitigations for attacks #1 and #2?
> - Should the solution mandate a solution for dealing with both attacks?
> Finally, we can talk about the details of the attack mitigation itself.
> As far as the work from Mike (oauth-mix-up-mitigation) and Nat
> (oauth-meta) is concerned Derek and I will find ways to ensure that the
> prior work by all involved participants is appropriately attributed and
> acknowledged!
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing listOAuth@ietf.org
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list