+1 :-) > 22 jan 2016 kl. 20:05 skrev George Fletcher <gffle...@aol.com>: > > 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> 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 >>>>>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
