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

[Hans Zandbelt <[e-mail]>]

+1 to everything Mike stated

Hans.

On 1/22/16 2:04 AM, Mike Jones wrote:
> I believe that it’s simpler and more elegant to return an issuer, from
> which the discovery metadata document can be retrieved, which contains
> **all** the configuration information about the authorization server,
> than to return some of the configuration parameters but not most of them
> (which is what the oauth-meta proposal does).  There’s lots more in a
> typical discovery document than just a few endpoint addresses. For
> instance, there are statements about what response types are supported,
> other configuration choices, keys, etc.
>
> I also think that returning the issuer is more future-proof than trying
> to decide now what all the configuration information is that might want
> to be verified by the client and hoping we get it right.  With the
> issuer, assuming that discovery is supported, it can retrieve and check
> all of it, should the client want/need to do so.  Even when discovery
> isn’t supported, the issuer still provides a concrete identifier for the
> authorization server that can be checked for equality.
>
> We talked about the value of that approach in the side meetings in
> Yokohama and people were supportive then.
>
>                                                                  -- Mike
>
> *From:*OAuth [mailto:[e-mail]] *On Behalf Of *John Bradley
> *Sent:* Thursday, January 21, 2016 4:48 PM
> *To:* Nat Sakimura <[e-mail]>
> *Cc:* [e-mail] WG <[e-mail]>
> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>
> I will point out for clarification that this would be like IdP discovery
> in openID 2 that everyone did.  I think IdP not doing RP discovery in
> openID 2 is a weak argument.
>
> There may be other evidence that RP will not do discovery, but if that
> is the case why are we doing a OAuth discovery spec?
>
> Many people see your spec as discovery as well just in a different way.
>
> I think both ways can work, but doing both leaves too many options.
>
> John B.
>
>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     Still doing the analysis. We spent 1.5 hours today with John,
>     George, nov and me on the OpenID Connect WG call on this issue. John
>     explained the mitigation, but none of us was convinced that it works.
>
>     Then, after the call, I and nov went on with various scenarios. The
>     interim conclusion is that:
>
>       * client_id response parameter does not help. There are legitimate
>         cases that client_id duplicates out there and we cannot ban that.
>       * iss response parameter does not help unless the discovery is
>         performed and the value of iss is checked against the value of
>         OAuth issuer inside the document. (<- Discovery becomes
>         mandatory. From our experience on RP discovery step in OpenID
>         2.0, chance of this being done properly seems to be rather slim.)
>       * sending the state to the token endpoint helps in the case code
>         was stollen, but code should not be stolen to start with.
>
>     Cheers,
>
>     Nat
>
>     2016年1月22日(金) 7:59 John Bradley <[e-mail]
>     <mailto:[e-mail]>>:
>
>         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]
>             <mailto:[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]
>             <mailto:[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]
>                 <mailto:[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] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>                     _______________________________________________
>                     OAuth mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>             _______________________________________________
>             OAuth mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[e-mail] | Ping Identity