Isn't that your department Paul? I have high expectations!
On 1/22/16 2:00 PM, Paul Madsen wrote:
tshirt or it didnt happen
On 1/22/16 1:57 PM, John Bradley wrote:
Now that we have a cool name all we need is a logo for the attack and
per haps an anime character, and we are done with all the hard work:)
John B.
On Jan 22, 2016, at 2:54 PM, David Waite
<da...@alkaline-solutions.com> wrote:
It’s pronounced FronkenSTEEN-ian.
-DW
On Jan 22, 2016, at 10:02 AM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
"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>
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> wrote:
On Jan 21, 2016, at 2:50 PM, John Bradley
<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> 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
_______________________________________________
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
