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 < >>> <mailto:ve7...@ve7jtb.com>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 < >>>> <mailto:ve7...@ve7jtb.com>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 >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> -- >> Chief Architect >> Identity Services Engineering Work: george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com> >> AOL Inc. AIM: gffletch >> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch >> <http://twitter.com/gffletch> >> Office: +1-703-265-2544 Photos: http://georgefletcher.photography >> <http://georgefletcher.photography/> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
