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

John Bradley <ve7jtb@ve7jtb.com> Sat, 27 February 2016 23:15 UTC

Return-Path: <ve7jtb@ve7jtb.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 9BA801B2D40 for <oauth@ietfa.amsl.com>; Sat, 27 Feb 2016 15:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 VH9XarXfIEgb for <oauth@ietfa.amsl.com>; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6691B2D3F for <oauth@ietf.org>; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id g127so95772656ywf.2 for <oauth@ietf.org>; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=jA6mcqjy6kykvYTRUDiCVxgRBSs36xBGEDWSP/dUB/I=; b=womQqmQTFzin9QMtxJUqv6hvBgfl10n7lydo9wmK06oPnztWSb57CM/EfRcHapLOKV oldR36rwsD4BomLQrstSiTDpu9m1iyJft85CSt+J8zTtDgil6s9r50HDwyut03esYZ1p gpKOT4UyCH38Jz6jJLRQu8wfC16jeoAzYntuA/X+TXcKd6cyQGFRYAUE85Rfeps2DPxb mrlbcaw8XYUy9d1Bkqv+r/nScYltDH+T1R0oVJ8Lg1G1E4hg3Bk/h8n0dONntZFHNuZA EiCNOzJpGBmN+ENdf5Rpb5k2GuYmPP/TnGxv8PrkQ1hLpnz65TWYDEqUwvQrqGIPiA3R /9UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jA6mcqjy6kykvYTRUDiCVxgRBSs36xBGEDWSP/dUB/I=; b=ZFI2gimm16EKzjK9vfVW8REjgWGJpy2pfgd55x1xDnRWrnCRwZuXoTH8TqzjKE6RVV q+6Un0m1EbkvPNutW1FNFgn4sZLh8/1NeO63JhnWei92MjmDEztXSK386fdAuyYaSeLl UV/z/IFxiLo4+o0/Kab/ZBUocnafg1f3HJy87k+iEET1ZAF7Az61y0B/ient8397sUcp +az4F2+9cGU9JXqcrOYpU6gILy9mYlmPcuYvB+j92aZf1S0DTnOBctiP0ZUTZiyIRMZO INch1YZfXVhakBFY0j+/+4nDMbB2+qx3ljttE50MumBZT8nZtffU4wodjjVuyKLyvX5w 1QvQ==
X-Gm-Message-State: AD7BkJL2qGV4tejZ5GucKCqiZ+QwGmMSw6oyk4m1yvx40/0NNjkTtZJpjFCvSdh6d85igQ==
X-Received: by 10.13.240.194 with SMTP id z185mr4640541ywe.317.1456614940938; Sat, 27 Feb 2016 15:15:40 -0800 (PST)
Received: from [12.35.22.83] ([12.35.22.83]) by smtp.gmail.com with ESMTPSA id j198sm15244298ywg.16.2016.02.27.15.15.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 27 Feb 2016 15:15:40 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2873372F-B68C-4312-8A19-F9E9148CD71D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <56D1E7E7.7070200@connect2id.com>
Date: Sat, 27 Feb 2016 18:15:41 -0500
Message-Id: <C2D34CC8-7B4F-4287-A8EE-F84472B9C4F1@ve7jtb.com>
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>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Gnz6WIsffXZ4O1hyWbVRH1jk_dI>
Cc: oauth <oauth@ietf.org>
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: Sat, 27 Feb 2016 23:15:44 -0000

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.

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 <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