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

William Denniss <wdenniss@google.com> Mon, 25 January 2016 04:11 UTC

Return-Path: <wdenniss@google.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 AAFB31A6FD7 for <oauth@ietfa.amsl.com>; Sun, 24 Jan 2016 20:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 lmK8n8W8CSx4 for <oauth@ietfa.amsl.com>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 348D31A6FD8 for <oauth@ietf.org>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: by mail-ob0-x234.google.com with SMTP id is5so106606782obc.0 for <oauth@ietf.org>; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=Yn8pERt5Z162+ppEjm4OnRFXuxSk1ftu9cWL9qwser6cC3xltHcD+ekmUQ0iHx6sae mE7byzGKt8Bn+pznudXc/lw6C8D9CiK2KsyyRdu5dutWcqb5ab61LiDZmiu51KXs9qGk VZFTk68qsAzfuW6ZeSu6+WE1C6W9FTmOQ20aK9nrN/3la1iM581N+qj+0y6p6oEujDRc 4sEqM/S6YyH7sTd3ZesIDoboN6c0BHBrtASCujvZ3DmInpWzOjq6W1q3iu+NMZzCWicE D4A9nxL/PKK69ZStialUZfSXqxiW9WP+FE5kcQCGFQUErhHv0oMnR2oT1rwWmh+OO03V XQgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=V7SNgQorIsrfgWFyuGE1POCCICADMWueQa5iZt5Thy1JEe/uMU+GK90IJ1oDmOqxQy cHHhMPrw9oUweT06GtPbxaRlS5mA3cn3RMc6EALS1FJB5+jd8gUgUmxdrUiOGd7TxD4P ma7QGhV8rIpvwWiBwCLDPnu6OLH535pY7Bi2mLFVu2xQoa95XgJzPCTotI1BPw5SvOG1 5qCkxzRYDrG03/2fF9SzN+2fJebdforw048ofMwck5rHEkBgGNrVzRFLa4tRc4AW/UtD 6iKKaVLmGoCiIg5bsfYIME51QsytDt32RsPGF69pmrTK4ruDP5mIyzmKGiPDE9otaZVu VQ0A==
X-Gm-Message-State: AG10YOS6jkD7M/7eDohjFbGZFpbachDzkUTgTi1NN0xV3+FBmZqbfRQi4V5oNNBsVFU8OF363JOQM2KrxYMFGAmP
X-Received: by 10.60.138.67 with SMTP id qo3mr11334350oeb.80.1453695084361; Sun, 24 Jan 2016 20:11:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Sun, 24 Jan 2016 20:11:04 -0800 (PST)
In-Reply-To: <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
References: <569E22E1.5010402@gmx.net> <CANSMLKHjAHr6rUZny5EkX0KBHnOcLuUOZBL0Wwf6V8Y3tt_kNw@mail.gmail.com> <CABzCy2C-_57dO5n6GN6wazA9ozuPivrQd95g_XvdkPWx6zDwAA@mail.gmail.com> <CANSMLKE98FVdDV-7bwW3wZ=-ao5=oXkn9LO5s_M1KmMAt7Drcw@mail.gmail.com> <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
From: William Denniss <wdenniss@google.com>
Date: Sun, 24 Jan 2016 20:11:04 -0800
Message-ID: <CAAP42hDUciKpS51dyx7Zy-kSCB_JUZqooXiaGTopHaFr_QkF5Q@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=047d7b2e465a1dc151052a20c392
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/dMek7vJk3ykk5x3iAN2qdfiflIU>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
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: Mon, 25 Jan 2016 04:11:28 -0000

On Thu, Jan 21, 2016 at 2:59 PM, John Bradley <ve7jtb@ve7jtb.com>; wrote:

> There have been a lot of discussions. I think Hannes posted some minutes
> of the F2F meeting we had with the security researchers.
>
> The problem can’t be mitigated without some action on the client side.  It
> boils down to the client making a request to AS1 (From it’s perspective)
> and getting back a response from AS 2 (that it thinks is AS1)
>
> This can be done if AS1 is a good AS but has it’s logs compromised so that
> an attacker can read them. Hans Zandbelt built a proof of concept for the
> attack.
>

So for mix-up, we're only talking about a compromised logs attack and not a
completely compromised AS?


> In some cases the attacker gets the code and the credential to use it at
> the good AS token endpoint and in others it just gets the code and can
> replay that at the client to extract information from the API through the
> client by binding the api access to a new account.
>
> PKCE unfortunately mitigates a different attack, where the client is
> impersonated and trys to replay a intercepted code.  It however assumes the
> token endpoint is good, and is no help in the case of a compromised token
> endpoint.
>
> The client in these attacks is vulnerable because it relies on some local
> state, or the value of the state parameter to know who the response is
> coming from.  This allows a authorization request that is intercepted to be
> used to create a new request in that browser to a different AS, or trick
> the client into using a Authorization endpoint for a different
> authorization server.
>
> One problem is that OAuth doesn’t really have a unified concept of what a
> AS is.  Traditionally it is a Authorization endpoint URI, token end point
> URI and resource server URI that some one gives the client in some
> documentation.
>
> As ling as a client only talks to one AS then there is no problem.
> However once a client is configured to talk to more than one AS, we have
> problems if one of those AS lies about it’s endpoints, or is compromised
> and used to attack another AS.   As a design goal you don’t want the
> overall  security to be limited by the weakest system.
>
> One approach as Nat promotes is to have the authorization endpoint return
> the next hop, token endpoint for code or RS URI for token. The token
> endpoint must also return the RS URI or the client must push the RS URI to
> the token endpoint or the attacker just replaces the RS URI in the config
> and captures the token that way.
>

I believe the RS URI would not be needed to defeat the compromised logs
mix-up attack for the code flow. The client will send the client_id it got
when registering at AS1 to the token endpoint returned by AS2 (using Nat's
spec), which will then cause a failure due to client_id mis-match. So
simply returning the "token_endpoint" URI in the AS2 authorization response
would defeat the compromised-logs mix-up attack, would it not?


> The other way is to provide a name for each AS as part of registration and
> the client not allow duplicate registrations with the same name.  When the
> response comes back the client checks the name against the one it made the
> request to.  If the name dereferences to a discovery document then the
> client can check that name at registration or runtime to validate the net
> hops.
>
> I think the two approaches mitigate the attack in similar ways.  Nat’s is
> more REST friendly and returns the next hop as a parameter of header.
>
> The one Mike and I wrote up based on the meeting in Germany provides
> identifiers (iss and client_id) that can be checked for validity in the
> simple case and be dereferenced via .well-known to get the information
> Nat’s proposal is providing.
>


>
> Perhaps the main difference is Nat is using the token endpoint as the
> identifier for the AS and Mike’s is using location for a discovery document
> as the identifier.
>
> I don’t recall the reasons using the token endpoint as the identifier was
> rejected at the meeting.  Perhaps others can post the reasons.
>

Can you help clarify something that I've yet to discern from the minutes,
does OpenID Connect solve the mix-up attack by binding all the tokens
together and to the issuer via the ID Token?


We need to close on this quickly, otherwise if we are indecisive fixes will
> not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>
> On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com>; wrote:
>
> 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" <sakimura@gmail.com>; 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 <jmandel@gmail.com>;:
>>
>>> 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
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>
>>> 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
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>> time for analysis is provided due to the complexity of the topic.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>> _______________________________________________
>>> 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
>
>