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

[William Denniss <[e-mail]>]

When I first heard Nat's proposal in Yokohama I thought it was pretty
elegant. And remember that it was first proposed to add more RESTful
behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I wonder if this comes down to: if you are already
doing OpenID Connect, the issuer/discovery path feels natural, as that's
what you're used to. But if you're pure OAuth, without those concepts then
Nat's solution is more natural?

I do recall some contention in Yokohama around returning the same info
twice (e.g. returning the token endpoint, and returning a discovery
document URL which could potential reference a different token endpoint).

There's something quite nice about the possibility for the AS returning
more detailed configuration like the relevant resource servers where the
token can be used – something that discovery can't do as it doesn't have
the context of the authorization grant.

On Fri, Jan 22, 2016 at 6:59 AM, John Bradley <[e-mail]> 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.
>
> 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.
>
> 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.
>
> 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 <[e-mail]> 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" <[e-mail]> 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 <[e-mail]>:
>>
>>> 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
>>> [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
>
>