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

Reply via email to