Thanks Mike (and reluctantly John, I guess). I'm pleased to hear about the direction things are taking and look forward to reviewing -01.
On Tue, Jan 12, 2016 at 3: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 <bcampb...@pingidentity.com> > Sent: 1/12/2016 5:24 PM > To: oauth <oauth@ietf.org> > 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 > <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>) > 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 > <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00> > 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
