And I agree with Phil’s agreement with Brian :-) I should also add that I during the last part of the meeting and on my flight home afterwards implemented the techniques I felt we had come to an agreement on at the meeting. That is the new authorization request response parameters iss and client_id as well as the use of state_hash at the token endpoint.
> 13 jan 2016 kl. 05:31 skrev Phil Hunt (IDM) <phil.h...@oracle.com>: > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
