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

[Justin Richer <[e-mail]>]

Hans,

Thanks; while I see the argument, my counter argument was to ask for a situation where you’d want to protect the state value but not code, client_secret, redirect_uri, and everything else in the request. If you actually want to protect all of that, it’s better to have a message-level protection mechanism instead of a piecemeal solution.

 — Justin

> On Jan 21, 2016, at 2:24 PM, Hans Zandbelt <[e-mail]> wrote:
> 
> Note that the argument was not about message-level protection: it was about not disclosing the state value verbatim over the token endpoint.
> 
> I don't feel strongly about it either; it was just what was agreed at first. Since no-one actually came up with even a hypothetical attack I guess it makes sense to revert that decision.
> 
> Hans.
> 
> On 1/21/16 7:58 PM, Justin Richer wrote:
>> Thank you for removing state hashing and please don’t add it back. It’s
>> security theater, and that’s giving it the benefit of the doubt.
>> Remember, this is being sent in a  request where other parameters (code,
>> client_id, client_secret, redirect_uri) are all sent plain over TLS as
>> well. Either come up with a general mechanism to hash everything or
>> don’t hash anything. The latter is more likely to win, and it’s the only
>> thing that makes sense currently.
>> 
>> Also, keep in mind that if the client hashes the state on the second
>> request, then the server can’t store the state parameter using its own
>> hash methods (for data-at-rest protection) and still be able to do the
>> comparison. Having the client send it over plain is really better all
>> around in terms of simplicity and adoptability.
>> 
>> Now if we really wanted to have message-level protection of HTTP
>> requests, I can think of a good way to do that…
>> 
>>  — Justin
>> 
>> 
>>> On Jan 21, 2016, at 9:41 AM, John Bradley <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>> 
>>> We merged the state verification in with this rather than forcing
>>> people to also look at the JWT encoded State draft.
>>> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>>> 
>>> While JWT encoded state is how I would do state in a client and
>>> at-least one client I know of uses it, it is not the only way to
>>> manage state, and I am hesitant that developers might be scared away
>>> by thinking they need to encode state as a JWT.
>>> 
>>> I decided that cross referencing them is better.   This made sending
>>> much simpler to describe.
>>> 
>>> I also removed the hashing from state.   That cut the text by about
>>> 2/3 by not having to describe character set normalization so that both
>>> the client and the AS could calculate the same hash.
>>> That also achieved the goal of not requiring a simple OAuth client
>>> doing the code flow to add a crypto library to support SHA256.
>>> 
>>> Once we make a algorithm mandatory, we need to defend why we don’t
>>> have crypto agility eg support for SHA3 etc.  We would be forced by
>>> the IESG to add another parameter to the request to specify the hash
>>> alg if we went that direction.
>>> 
>>> Given that we assume state to be public info in the request that an
>>> attacker can see, hashing state provides not much value for a lot of
>>> complexity that people may get wrong or not implement.
>>> 
>>> I appreciate why from a theory point of view hashing it would have
>>> been better.
>>> 
>>> If people really want it I can add it back.
>>> 
>>> John B.
>>> 
>>>> On Jan 21, 2016, at 3:28 AM, Mike Jones <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>> 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
>>>> athttp://self-issued.info/?p=1526andas@selfissued
>>>> <https://twitter.com/selfissued>.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> 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
>> 
> 
> -- 
> Hans Zandbelt              | Sr. Technical Architect
> [e-mail] | Ping Identity