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

[Vladimir Dzhuvinov <[e-mail]>]

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. 

OK.

Vladimir


>
> John B.
>
>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov <[e-mail]> 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 <
>>> [e-mail]> 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 [mailto:[e-mail]]
>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>> To: Mike Jones <[e-mail]>; William Denniss <
>>>> [e-mail]>; Phil Hunt (IDM) <[e-mail]>
>>>>>> Cc: [e-mail]
>>>>>> 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
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth