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

[George Fletcher <[e-mail]>]

Isn't that your department Paul? I have high expectations!

On 1/22/16 2:00 PM, Paul Madsen wrote:
> tshirt or it didnt happen
>
> On 1/22/16 1:57 PM, John Bradley wrote:
>> Now that we have a cool name all we need is a logo for the attack and 
>> per haps an anime character, and we are done with all the hard work:)
>>
>> John B.
>>> On Jan 22, 2016, at 2:54 PM, David Waite 
>>> <[e-mail]> wrote:
>>>
>>> It’s pronounced FronkenSTEEN-ian.
>>>
>>> -DW
>>>
>>>> On Jan 22, 2016, at 10:02 AM, George Fletcher <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> "Frankensteinian Amalgamation" -- David Waite
>>>>
>>>> I like it! :)
>>>>
>>>> On 1/22/16 8:11 AM, William Denniss wrote:
>>>>> +1 ;)
>>>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley <[e-mail]> 
>>>>> wrote:
>>>>>
>>>>>     Perhaps Frankenstein response is a better name than cut and
>>>>>     paste attack.
>>>>>
>>>>>     John B.
>>>>>
>>>>>     On Jan 22, 2016 1:22 AM, "David Waite"
>>>>>     <[e-mail]> wrote:
>>>>>
>>>>>>         On Jan 21, 2016, at 2:50 PM, John Bradley
>>>>>>         <[e-mail]> wrote:
>>>>>>
>>>>>>         In that case you probably would put a hash of the state
>>>>>>         in the code to manage size.  The alg would be up to the
>>>>>>         AS, as long as it used the same hash both places it would
>>>>>>         work.
>>>>>         Yes, true.
>>>>>>
>>>>>>         Sending the state to the token endpoint is like having
>>>>>>         nonce and c_hash in the id_token, it binds the issued
>>>>>>         code to the browser instance.
>>>>>         I think I understand what you are saying. Someone won’t be
>>>>>         able to frankenstein up a state and a token from two
>>>>>         different responses from an AS, and have a client
>>>>>         successfully fetch an access token based on the amalgamation.
>>>>>>         This protects against codes that leak via redirect uri
>>>>>>         pattern matching. failures etc.  It prevents an attacker
>>>>>>         from being able to replay a code from a different browser.
>>>>>         Yes, if a party intercepts the redirect_url, or the AS
>>>>>         fails to enforce one time use (which even for a compliant
>>>>>         implementation could just mean the attacker was faster
>>>>>         than the state propagated within the AS)
>>>>>
>>>>>         Makes sense. Thanks John.
>>>>>
>>>>>         -DW
>>>>>
>>>>>>         If the client implements the other mitigations on the
>>>>>>         authorization endpoint, then it wouldn't be leaking the
>>>>>>         code via the token endpoint.
>>>>>>
>>>>>>         The two mitigations are for different attacks, however
>>>>>>         some of the attacks combined both vulnerabilities.
>>>>>>
>>>>>>         Sending the iss and client_id is enough to stop the
>>>>>>         confused client attacks, but sending state on its own
>>>>>>         would not have stopped all of them.
>>>>>>
>>>>>>         We discussed having them in separate drafts, and may
>>>>>>         still do that.   However for discussion having them in
>>>>>>         one document is I think better in the short run.
>>>>>>
>>>>>>         John B.
>>>>>>
>>>>>>>         On Jan 21, 2016, at 4:48 PM, David Waite
>>>>>>>         <[e-mail]> wrote:
>>>>>>>
>>>>>>>         Question:
>>>>>>>
>>>>>>>         I understand how “iss" helps mitigate this attack
>>>>>>>         (client knows response was from the appropriate issuer
>>>>>>>         and not an attack where the request was answered by
>>>>>>>         another issuer).
>>>>>>>
>>>>>>>         However, how does passing “state” on the
>>>>>>>         authorization_code grant token request help once you
>>>>>>>         have the above in place? Is this against some alternate
>>>>>>>         flow of this attack I don’t see, or is it meant to
>>>>>>>         mitigate some entirely separate attack?
>>>>>>>
>>>>>>>         If one is attempting to work statelessly (e.g. your
>>>>>>>         “state” parameter is actual state and not just a
>>>>>>>         randomly generated value), a client would have always
>>>>>>>         needed some way to differentiate which issuer the
>>>>>>>         authorization_code grant token request would be sent to.
>>>>>>>
>>>>>>>         However, if an AS was treating “code” as a token (for
>>>>>>>         instance, encoding: client, user, consent time and
>>>>>>>         approved scopes), the AS now has to include the client’s
>>>>>>>         state as well. This would effectively double (likely
>>>>>>>         more with encoding) the state sent in the authorization
>>>>>>>         response back to the client redirect URL, adding more
>>>>>>>         pressure against maximum URL sizes.
>>>>>>>
>>>>>>>         -DW
>>>>>
>>>>>     _______________________________________________
>>>>>     OAuth mailing list
>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> -- 
>>>> Chief Architect
>>>> Identity Services Engineering     Work:[e-mail]
>>>> AOL Inc.                          AIM:  gffletch
>>>> Mobile: [phone]           Twitter:http://twitter.com/gffletch
>>>> Office: [phone]           Photos:http://georgefletcher.photography
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: [e-mail]
AOL Inc.                          AIM:  gffletch
Mobile: [phone]           Twitter: http://twitter.com/gffletch
Office: [phone]           Photos: http://georgefletcher.photography