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

Josh Mandel <> Thu, 21 January 2016 14:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F2EA61A70FD for <>; Thu, 21 Jan 2016 06:50:42 -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 NX73zqG3ssiP for <>; Thu, 21 Jan 2016 06:50:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4C1A1A7D84 for <>; Thu, 21 Jan 2016 06:50:39 -0800 (PST)
Received: by with SMTP id v14so50426035ykd.3 for <>; Thu, 21 Jan 2016 06:50:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JlsI1VrGHf4meSFWlfiP+i3gQnmpMe3xf88sLA/IHWY=; b=XL+xMjiJzlYs0lcG+k1vLK10/V9wozhmlz+Om9Kx2L4hQ/OOST1tc69hZR0pA1cYmt 92957FfZGc8j08l0wM1wDjtCtjNtitiJzNSNMHIVw/oYsbT1eX5lqRVQwhripdp1n978 RykUXjJHOGbmvrzAj51SzYVyv/SBxi5d00GiQ9ZLJ4AY8mzib5XadzRlysq3lu3LHVLl XkTrf+MwhH4CoSbVKxA+L05k+0vxgbj+tzxAJq1Z5/E1FgQn8WKm7hL/0I08sf9pLVb0 0+AliuSVfonsMWxCJMT+e/OO36RLOMiIQgYmSe+52r+pwmJThPYjmQPEEPp+7RanD5f3 LEKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JlsI1VrGHf4meSFWlfiP+i3gQnmpMe3xf88sLA/IHWY=; b=EW+y8csv2D6BQrL6FuTPM0JmuhBFQbYnKeSX+6gZa0HyTOiyZmsWNcJCrq91BODI+2 BRdN62IU55IplzCgCM0DbwZqNQabVAnTkL6kI1Sk3fsf55v8nfe8387xt03cH6tbtOaW ff4Tgc8QRG+Ba9Tv6nQ91JGPJ38oyFjn7BeeoAA7cApkHwqFTgvjybU+7SNxCXixh4vk M/7cOVNBW8bCc1vMC2yE2VHzxnRpEpbPFJfKPcs6NIwqyvnYSdbYv0Go9uNf40bL0FtU LFQD8E7s5FxLvz/KTcL9AwpfwUVVYoUuKTkMh0VD4S07+dyopnzg7wRfyPX2QcPM6zZV MIIw==
X-Gm-Message-State: ALoCoQm6Zk4q1y3Nujev1R5rJrp3mMVWatsLBkl/M22JKZCT0mLh0kD7+6Lq7wDxnvbIYQQ+JGKq0CzR6U/8BAcDOUv4xvB8Lg==
MIME-Version: 1.0
X-Received: by with SMTP id e129mr13538528ybh.145.1453387839174; Thu, 21 Jan 2016 06:50:39 -0800 (PST)
Received: by with HTTP; Thu, 21 Jan 2016 06:50:39 -0800 (PST)
Received: by with HTTP; Thu, 21 Jan 2016 06:50:39 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 21 Jan 2016 09:50:39 -0500
Message-ID: <>
From: Josh Mandel <>
To: Nat Sakimura <>
Content-Type: multipart/alternative; boundary="94eb2c0b0faae0060a0529d9393a"
Archived-At: <>
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Call for Adoption: 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 14:50:43 -0000

Thanks Nat - that's helpful. If both mitigations *can* work effectively,
then I would like to see this group consider the decision between them
carefully (if that hasn't happened yet). Again, don't hesitate to let me
know if this is the wrong place/time for such discussion.

At a high level, I would rather ask server developers to do some "coding",
for two reasons:

1. Most OAuth servers talk to many, many clients. So consolidating the
security critical work in one place (server) is a net savings of work
(rather than asking each client to implement these checks.

2. OAuth server developers are typically more sophisticated than client
developers, and therefore more likely to understand the implications and
more likely to get these critical details correct. Asking each client
developer to do something right is likely to result in heterogenius
implementation and persistent security holes. But if the server does the
heavy lifting, and clients just have to pass along an extra parameter, this
is more likely to see consistent implementation (for example, clients will
fail to work if misconfigured, which will prompt developers to fix them).
On Jan 21, 2016 09:40, "Nat Sakimura" <> wrote:

> Hi Josh,
> It is similar but slightly different IMHO.
> Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit
> resource server.
> The mix-up attack described here is the code phishing by a counterfeit
> token endpoint.
> In my view, both can be mitigated by the server returning the next step:
> i.e., authorization endpoint returning the legitimate token endpoint uri,
> and token endpoint returning legitimate resource endpoint uris. This
> involves no discovery endpoint, which is good.
> Your way also works. It is just the reverse of my proposal. The difference
> being that my proposal does not need any coding on the server but just
> configuration, and it can return more metadata if needed.
> Cheers,
> Nat
> 2016年1月21日(木) 23:04 Josh Mandel <>:
>> Apologies if this is the wrong forum for my comment (and please direct me
>> to the appropriate place in that case), but I have two questions about the
>> propose mitigation (and the thinking behind it) that I think the write-up
>> could address:
>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>> differs from what RFC6819 identifies as in section 4.6.4?
>> 2. Has the workgroup considered a mitigation that puts more
>> responsibility on the authorization server, and less on the client? For
>> example, if would be helpful for the writeup to clarify why having the
>> client send an "audience field" (in the terminology of RFC6819) to the
>> authorization endpoint would not mitigate the threat. (In that scenario,
>> the authorization server can recognize that the audience does not
>> correspond to a resource server it knows, rather than asking clients to
>> make this check). I assume this approach has been considered and rejected
>> as an incomplete mitigation, but I don't have visibility into where/how
>> that discussion went.
>> Thanks,
>> Josh
>> Hi all,
>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> More
>> time for analysis is provided due to the complexity of the topic.
>> Ciao
>> Hannes & Derek
>> _______________________________________________
>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list