It’s pronounced FronkenSTEEN-ian. -DW
> On Jan 22, 2016, at 10:02 AM, George Fletcher <[email protected]> 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:[email protected]>[email protected] <mailto:[email protected]>> >> wrote: >> Perhaps Frankenstein response is a better name than cut and paste attack. >> >> John B. >> >> On Jan 22, 2016 1:22 AM, "David Waite" <[email protected] >> <mailto:[email protected]>> wrote: >>> On Jan 21, 2016, at 2:50 PM, John Bradley < >>> <mailto:[email protected]>[email protected] <mailto:[email protected]>> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > -- > Chief Architect > Identity Services Engineering Work: [email protected] > <mailto:[email protected]> > 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/>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
