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 <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> 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 <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>> 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
