I fully agree with Brian. We came up with a rather simple (== w/o crypto) solution to mitigate the mix-up attack. We should first specify them as discussed and then have a discussion in the working group - also about additional attack vectors.
As discussed in Darmstadt, we should also come up with a comprehensive description of the threats arising from the more dynamic way OAuth is used meanwhile. I hope the researches will support this effort. kind regards, Torsten. Am 13.01.2016 05:31, schrieb Phil Hunt (IDM): > I am in agreement with Brian. > > I understand what Mike is trying to do is safer, but I too am concerned that > the escalation in knowledge/skills for oauth clients is significant. > > This may not be the same concern as for OIDC where we can expect more > sophistication. > > Phil > > On Jan 12, 2016, at 20:03, Justin Richer <jric...@mit.edu> wrote: > > +1 to Brian's point, and points to Mike for promising to address this. I > wasn't able to attend the meeting in Darmstadt, but I've been following the > discussion and original papers. Let's take this one piece at a time and not > overreach with a solution. > > In particular, the whole "late binding discovery" bit would cause huge > problems on its own. There's good reason that OpenID Connect mandates that > the "iss" value returned from the discovery endpoint MUST be the same as the > "iss" value coming back from the ID Token, so let's not ignore that. > > -- Justin > > On Jan 12, 2016, at 5:53 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > John Bradley and I went over this today and I'm already planning on > simplifying the draft along the lines described. I would have written this > earlier but I've been busy at a NIST meeting today. > > John has also stated writing a note about how cut-and-paste does and doesn't > apply here but hasn't finished it yet because he's been similarly occupied. > He's also started writing up the state_hash token request parameter, as he > agreed to do. > > Watch this space for the new draft... > > Best wishes, > -- Mike > > ------------------------- > From: Brian Campbell > Sent: 1/12/2016 5:24 PM > To: oauth > Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation > > The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on > them) take advantage of the fact that there's nothing in the OAuth > authorization response to the client's redirect_uri that identifies the > authorization server. As a result, a variety of techniques can be used to > trick the client into sending the code (or token in some cases) to the wrong > endpoint. > > To the best of my recollection the general consensus coming out of the > meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: > Authorization Server Mix-Up [1]) was to put forth an I-D as a simple > extension to OAuth, which described how to return an issuer identifier for > the authorization server and client identifier as authorization response > parameters from the authorization endpoint. Doing so enables the client to > know which AS the response came from and thus avoid sending the code to a > different AS. Also, it doesn't introduce application/message level > cryptography requirements on client implementations. The mitigation draft > that was posted yesterday [2] diverges considerably from that with a > significantly expanded scope that introduces OpenID Connect ID Tokens (sort > of anyway) to regular OAuth and the retrieval of a metadata/discovery > document in-between the authorization request and the access token request. > > It is possible that my recollection from Darmstadt is wrong. But I expect > others who were there could corroborate my account of what transpired. Of > course, the agreements out of the Darmstadt meeting were never intended to be > the final word - the whole WG would have the opportunity to weigh, as is now > the case. However, a goal of meeting face-to-face was to come away with a > good consensus towards a proposed solution that could (hopefully) be > implementable in the very near term and move thought the IETF process in an > expedited manner. I believe we'd reached consensus but the content of -00 > draft does not reflect it. > > I've made the plea off-list several times to simplify the draft to reflect > the simple solution and now I'm doing the same on-list. Simplify the response > validation to just say not to send the code/token back to an AS entity other > that the one identified by the 'iss' in the response. And remove the id_token > and JWT parts that . > > If this WG and/or the larger community believes that OAuth needs signed > responses, let's develop a proper singed response mechanism. I don't know if > it's needed or not but I do know that it's a decent chunk of work that should > be conscientiously undertaken independent of what can and should be a simple > to understand and implement fix for the idp mix-up problem. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w [2] http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 [3] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
