Thanks for the write up John and Mike!
1. Editorial: I'd add something like the following to the last paragraph
in section 2. "However, if the authorization server does not support
OAuth Discovery, then it MUST publicly define it's AS issuer URI." The
point being that the client has to have a way to obtain this value so
that it can compare it later on in the protocol.
2. Question: If OAuth2 discovery is not required, how does a simple
issuer compare prevent the attack? It seems like the malicious AS could
get the client to statically configure Good Issuer, Good AuthZ, Bad
Token endpoint and assign the client a client_id that is valid at the
Good AS. When the Good AS returns the response data it would include
it's iss and the client_id which would match and the client would still
send the code and client credentials to the Bad AS. I believe that
supporting OAuth discovery is going to be required to fully mitigate
this attack.
3. Question: In section 7.3 the phrase "unsigned cookie" is used but
it's not clear exactly what that means. While the attacker can set
cookies in the forged response, they shouldn't be able to set cookies on
the specific domain of the AS. If the cookie identifying the AS session
is HTTP Only and Secure, then the attacker should not be able to see or
forge a value for this cookie. The attacker could bypass the browser
completely and just forge a request to the client specifying whatever
values they like. These could be taken from a valid session the attacker
created and can see from their browser. It seems like the key protection
in this case is binding the state value into the code so the code can't
be substituted.
Thanks,
George
On 1/21/16 1:28 AM, Mike Jones 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=1526 and
as @selfissued <https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
