"Frankensteinian Amalgamation" -- David Waite
I like it! :)
On 1/22/16 8:11 AM, William Denniss wrote:
+1 ;)
On Fri, Jan 22, 2016 at 8:45 PM John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
Perhaps Frankenstein response is a better name than cut and paste
attack.
John B.
On Jan 22, 2016 1:22 AM, "David Waite"
<da...@alkaline-solutions.com
<mailto:da...@alkaline-solutions.com>> wrote:
On Jan 21, 2016, at 2:50 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
In that case you probably would put a hash of the state in
the code to manage size. The alg would be up to the AS, as
long as it used the same hash both places it would work.
Yes, true.
Sending the state to the token endpoint is like having nonce
and c_hash in the id_token, it binds the issued code to the
browser instance.
I think I understand what you are saying. Someone won’t be
able to frankenstein up a state and a token from two different
responses from an AS, and have a client successfully fetch an
access token based on the amalgamation.
This protects against codes that leak via redirect uri
pattern matching. failures etc. It prevents an attacker from
being able to replay a code from a different browser.
Yes, if a party intercepts the redirect_url, or the AS fails
to enforce one time use (which even for a compliant
implementation could just mean the attacker was faster than
the state propagated within the AS)
Makes sense. Thanks John.
-DW
If the client implements the other mitigations on the
authorization endpoint, then it wouldn't be leaking the code
via the token endpoint.
The two mitigations are for different attacks, however some
of the attacks combined both vulnerabilities.
Sending the iss and client_id is enough to stop the confused
client attacks, but sending state on its own would not have
stopped all of them.
We discussed having them in separate drafts, and may still do
that. However for discussion having them in one document is
I think better in the short run.
John B.
On Jan 21, 2016, at 4:48 PM, David Waite
<da...@alkaline-solutions.com
<mailto:da...@alkaline-solutions.com>> wrote:
Question:
I understand how “iss" helps mitigate this attack (client
knows response was from the appropriate issuer and not an
attack where the request was answered by another issuer).
However, how does passing “state” on the authorization_code
grant token request help once you have the above in place?
Is this against some alternate flow of this attack I don’t
see, or is it meant to mitigate some entirely separate attack?
If one is attempting to work statelessly (e.g. your “state”
parameter is actual state and not just a randomly generated
value), a client would have always needed some way to
differentiate which issuer the authorization_code grant
token request would be sent to.
However, if an AS was treating “code” as a token (for
instance, encoding: client, user, consent time and approved
scopes), the AS now has to include the client’s state as
well. This would effectively double (likely more with
encoding) the state sent in the authorization response back
to the client redirect URL, adding more pressure against
maximum URL sizes.
-DW
_______________________________________________
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
--
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
