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

[George Fletcher <[e-mail]>]

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