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) 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 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
