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

[William Denniss <[e-mail]>]

On Thu, Jan 21, 2016 at 2:59 PM, 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.
>

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