Agreed. The security ext draft might fit well with the general grab bag of issues around all the "dynamic" cases.
It would be stronger than a new threat model ext draft which would likely be informational. Phil > On Jan 26, 2016, at 12:10, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > Hi Mike, > > I really like the new revision since it is much simpler :-) > > My comments: > > I'm fine with describing all mitigations we talked about in Darmstadt in > one/this spec. But the state check at the tokens endpoint is supposed to be a > mitigation against code injection/cut and paste attack, which is not directly > related to IDP/AS mix up. So I would suggest to change the name of the spec, > probably "OAuth security extensions"? > > I think the code injection/cut and paste attack should be described more > extensively in the introduction. It's important for the reader to understand, > why this mitigation is defined at all. Moreover, I think the description of > the mitigation is still incomplete/spread over the document. In order to > detect code injection, the RP not only needs to send the state to the tokens > endpoint, it also needs to (directly or indirectly) _bind_ the state to the > particular user agent (session). Otherwise, the attacker can inject the state > along with the solen code easily. I would suggest to merge > > "To prevent replay of the state in another browser instance by an > attacker, the state value MUST be tied to the browser instance in a way that > cannot be forged by an attacker. Section 4 of > [I‑D.bradley‑oauth‑jwt‑encoded‑state] > provides several examples of how a client can accomplish this." > > into section 5. > > I thought we had discussed to also give implementors a guideline on using > state to prevent CSRF as well? How will we take care of that topic? > > kinds regards, > Torsten. > > >> Am 21.01.2016 um 07:28 schrieb Mike Jones: >> John Bradley and I collaborated to create the second OAuth 2.0 >> Mix-Up Mitigation draft. Changes were: >> · Simplified by no longer specifying the signed JWT method for >> returning the mitigation information. >> · Simplified by no longer depending upon publication of a discovery >> metadata document. >> · Added the “state” token request parameter. >> · Added examples. >> · Added John Bradley as an editor. >> >> The specification is available at: >> · http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >> >> An HTML-formatted version is also available at: >> · >> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html >> >> -- Mike >> >> P.S. This note was also posted at http://self-issued.info/?p=1526 and as >> @selfissued. >> >> >> >> _______________________________________________ >> 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
