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

[Paul Madsen <[e-mail]>]

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] <mailto:[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]
>>>>     <mailto:[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]
>>>>>>         <mailto:[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