Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

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 <torsten@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