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 <hzandb...@pingidentity.com> 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 <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
