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 <sakim...@gmail.com> 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 <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>>: > 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 <jman...@gmail.com >> <mailto:jman...@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" <sakim...@gmail.com >> <mailto:sakim...@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 <jman...@gmail.com >> <mailto:jman...@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 >> <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 >> <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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
