Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Vladimir Dzhuvinov <> Tue, 01 March 2016 08:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 58C7F1B360F for <>; Tue, 1 Mar 2016 00:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IPDfMAABPWnY for <>; Tue, 1 Mar 2016 00:51:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55E671B2CEA for <>; Tue, 1 Mar 2016 00:51:10 -0800 (PST)
Received: from [] ([]) by with id QYr81s00A15ZTut01Yr9k0; Tue, 01 Mar 2016 01:51:09 -0700
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Cc: oauth <>
From: Vladimir Dzhuvinov <>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <>
Date: Tue, 01 Mar 2016 10:51:07 +0200
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: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040003020704030207000007"
Archived-At: <>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
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, 01 Mar 2016 08:51:12 -0000

Hi John,

On 28/02/16 01:15, John Bradley wrote:
> If the malicious client is registering it’s own redirect URI then option A won’t help. 
> On the other hand the Good AS should identify the malicious client to the user.

How could that be done in practice, especially with an AS that provides
a channel for dynamic discovery and registration?

> I think this is a separate problem of client impersonation being used for Phishing.
> This is really a case of bad guy registers client and phishes the user to login pretending to be some other client.
> That can all be done with the good client not being involved at all. 



> John B.
>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov <> wrote:
>> Hi Brian,
>> On 27/02/16 00:27, Brian Campbell wrote:
>>> My preference is for Option A.
>>> The mix-up attack, in all it's variations, relies on there being no means
>>> in OAuth for the AS to identify itself to the client when it returns the
>>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation'
>>> addresses that fundamental missing piece by including the 'iss'
>>> authorization response parameter.
>> This fundamental piece is indeed missing. I'm not sure measure "A" can
>> also cover dynamic discovery and registration though. The mixup attack
>> was originally described there, with OpenID Connect.
>> How about this variation:
>> Suppose the malicious IdP:
>> 1. Registers the client under attack for
>> a) malicious authz endpoint
>> b) malicious token endpoint (optional)
>> ... while also acting as proxy, where there are two variants:
>> a) repeats the client registration with the honest IdP to obtain
>> client_id + credentials that it keeps for itself; or
>> b) is already registered as a client with the honest IdP
>> Then:
>> 1. When the authz request is made to the malicious authz endpoint, the
>> request is rewritten with the client_id and redirect_uri which the
>> malicious IdP has with the honest IdP. The state may or may not be replaced.
>> 2. The browser is then given a second redirect with the rewritten
>> parameters to the authz endpoint of the honest IdP.
>> 3. The user doesn't notice this double redirect, and logs in / gives
>> consent.
>> 4. The honest IdP sends the browser back to the registered malicious
>> redirect_uri. The attacker receives the code or tokens (depending on the
>> response type)
>> 5. A second redirect is made back to the redirect_uri of the client,
>> with rewritten state, iss, client_id
>> What is your take on this?
>> The ideal fix for me would be one that covers dynamic discovery and
>> registration as well. I'm not convinced option A does that.
>> Cheers,
>> Vladimir
>>> During the course of the discussions in Darmstadt Hans and I independently
>>> implemented and successfully interop tested the 'iss' and 'client_id'
>>> authorization response parameters, which is what was anticipated to be in
>>> the mitigation draft. Doing so was very simple and straightforward. And it
>>> addresses the vulnerability. We decided, unfortunately, to pull that
>>> functionality out of a looming a product release due to the churn in this
>>> WG and the perceived risk of changes in what would eventually become the
>>> standard solution. Of course, that kind of risk is always present with
>>> draft standards but it's been very frustrating in this case to have worked
>>> towards a simple solution to a known problem only to have progress get hung
>>> up in lack of agreement in this WG.
>>> I'll also say that in many/most cases the AS doesn't explicitly know all of
>>> the resources that tokens it issues can or will be used at (and there are
>>> often more than one). So the ruri/Resource URI parameter isn't really a
>>> workable option.
>>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
>>>> wrote:
>>>> Vladimir,
>>>> yes, we could do a formal analysis and it would be a very good idea.
>>>> It would even go faster if a few of us work together on it. Anyone
>>>> interested?
>>>> This would be a good contribution for the workshop in July, btw.
>>>> Ciao
>>>> Hannes
>>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>>>> Hi Mike,
>>>>> You mention that you spent considerable time in research. I wonder if
>>>>> there is existing theory, in communications or information theory, that
>>>>> can be used to formally establish and prove (or disprove) the security
>>>>> of the proposed OAuth measures? Perhaps some work that is totally
>>>>> unrelated to identity and the web protocols, but could well apply here?
>>>>> My reasoning is that we have a closed system that is fairly simple, so
>>>>> formal analysis must be entirely possible.
>>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>> 2. The OAuth protocol follows a simple and well-defined pattern of
>>>>> messages between the parties.
>>>>> 3. The points and the number of ways by which an adversary may break
>>>>> into OAuth must therefore be finite.
>>>>> 4. The security requirement is essentially to guarantee the precedence
>>>>> and authenticity of the messages from discovery endpoint to RS, and the
>>>>> preferred way to do that is by establishing a binding between the
>>>>> messages, which can be forward or backward binding.
>>>>> Right now the WG concern is whether all possible attacks have been
>>>>> recognised, and then taken care of. If we can have a formal model that
>>>>> can reliably reveal and prove that, this will be a huge breakthrough.
>>>>> Cheers,
>>>>> Vladimir
>>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>>> Suggesting that they be read is of course, the right long-term
>>>> approach.  But as someone who spent 20+ years as a researcher before
>>>> switching to digital identity, I was sensitive to not wanting to upstage
>>>> their work by copying too much of their material into our draft before
>>>> their publications were widely known.  I'll of course commit to working the
>>>> researchers and the working group to create a self-contained concise
>>>> description of the threats and mitigations in the working group document.
>>>>>>                             Cheers,
>>>>>>                             -- Mike
>>>>>> -----Original Message-----
>>>>>> From: Hannes Tschofenig []
>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>> To: Mike Jones <>; William Denniss <
>>>>>; Phil Hunt (IDM) <>
>>>>>> Cc:
>>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call
>>>> for Adoption
>>>>>> Hi Mike,
>>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>>>> Have you read both of their publications?  If not, do yourself a favor
>>>>>>> and do.  They're actually both very readable and quite informative.
>>>>>> I have read both documents. In context of this discussion the question
>>>> is whether we
>>>>>> (a) require them to be read (in which case they should be a normative
>>>> reference), or
>>>>>> (b) suggest them to be read (since they provide additional background
>>>> information). In this case they are an informative reference.
>>>>>> I believe believe we want (b) for the OAuth WG document. While I
>>>> encourage everyone to read the publications I also believe that there is
>>>> lots of material in there that goes beyond the information our audience
>>>> typically reads (such as the text about the formal analysis).
>>>>>> There is probably also a middle-ground where we either copy relevant
>>>> text from the papers into the draft or reference specific sections that are
>>>> "must-read".
>>>>>> One other issue: I actually thought that the threat that is outlined in
>>>> the research paper is sufficiently well described but the second threat,
>>>> which is called 'cut-and-paste attack', requires more work.
>>>>>> I noted this in my summary mail to the list, see
>>>>>> Ciao
>>>>>> Hannes
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>> _______________________________________________
>>>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list