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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 01 March 2016 08:51 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7F1B360F for <oauth@ietfa.amsl.com>; Tue, 1 Mar 2016 00:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPDfMAABPWnY for <oauth@ietfa.amsl.com>; Tue, 1 Mar 2016 00:51:10 -0800 (PST)
Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E671B2CEA for <oauth@ietf.org>; Tue, 1 Mar 2016 00:51:10 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa12-09.prod.phx3.secureserver.net with id QYr81s00A15ZTut01Yr9k0; Tue, 01 Mar 2016 01:51:09 -0700
References: <56C7702B.2000401@gmx.net> <BY2PR03MB442E9BF84AFA890378C5116F5A00@BY2PR03MB442.namprd03.prod.outlook.com> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <CAAP42hD96u0Nepdo8YcHeXEo2v1Mo=a_Zo4OcS9ppu7rU-=8Ag@mail.gmail.com> <56C8360C.8010203@gmx.net> <BY2PR03MB44257DFC0BD58DC443A5BB3F5A10@BY2PR03MB442.namprd03.prod.outlook.com> <56C83EEA.8000306@gmx.net> <BY2PR03MB442B1EFAAB9911D5569A833F5A10@BY2PR03MB442.namprd03.prod.outlook.com> <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net> <CA+k3eCTeAULzW+JQ0P2i8sx=+uxMKjgemaPwKKSmr0_F7MXE6w@mail.gmail.com> <56D1E7E7.7070200@connect2id.com> <C2D34CC8-7B4F-4287-A8EE-F84472B9C4F1@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D557FB.30701@connect2id.com>
Date: Tue, 1 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: <C2D34CC8-7B4F-4287-A8EE-F84472B9C4F1@ve7jtb.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040003020704030207000007"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EPdV-4o7heDIlqsKeOYIPFpBkpo>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=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. 

OK.

Vladimir


>
> John B.
>
>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> 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 <
>>> hannes.tschofenig@gmx.net> 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:hannes.tschofenig@gmx.net]
>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>> To: Mike Jones <Michael.Jones@microsoft.com>om>; William Denniss <
>>>> wdenniss@google.com>gt;; Phil Hunt (IDM) <phil.hunt@oracle.com>
>>>>>> Cc: oauth@ietf.org
>>>>>> 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
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth