Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Agreed. The security ext draft might fit well with the general grab bag of issues around all the "dynamic" cases. It would be stronger than a new threat model ext draft which would likely be informational. Phil > On Jan 26, 2016, at 12:10, Torsten Lodderstedt > wrote: > > Hi Mike, > >

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hi Mike, I really like the new revision since it is much simpler :-) My comments: I'm fine with describing all mitigations we talked about in Darmstadt in one/this spec. But the state check at the tokens endpoint is supposed to be a mitigation against code injection/cut and paste attack, whic

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Thanks for the write up John and Mike! 1. Editorial: I'd add something like the following to the last paragraph in section 2. "However, if the authorization server does not support OAuth Discovery, then it MUST publicly define it's AS issuer URI." The point being that the client has to have a

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

+1 :-) > 22 jan 2016 kl. 20:05 skrev George Fletcher : > > 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

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

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 ha

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

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 mailto:da...@alkaline-solutions.com>>

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

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 wrote: > > It’s pronounced FronkenSTEEN-ian. > > -DW > >> On Jan 22, 2016, at 10:02 AM, George Fletche

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

It’s pronounced FronkenSTEEN-ian. -DW > On Jan 22, 2016, at 10:02 AM, George Fletcher 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 < >>

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

"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 > wrote: Perhaps Frankenstein response is a better name than cut and paste attack. John B. On J

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

I agree that using a JWT is not the only way to do it, however many clients were not sending state at all or doing something insecure. Particularly some people were having trouble with AS like Google who do exact redirect_uri matching and not being able to see how to pass multiple parameters in

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hi John, Le jeu. 21 janv. 2016 15:42, John Bradley a écrit : > We merged the state verification in with this rather than forcing people > to also look at the JWT encoded State draft. > https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state. > > While JWT encoded state is how I would

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Perhaps Frankenstein response is a better name than cut and paste attack. John B. On Jan 22, 2016 1:22 AM, "David Waite" wrote: > On Jan 21, 2016, at 2:50 PM, John Bradley 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 th

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

> On Jan 21, 2016, at 2:50 PM, John Bradley 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

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Yes if the AS is encoding state + redirect_uri and grants in the code then it could get big. 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. Sending the state to the

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

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

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hans, Thanks; while I see the argument, my counter argument was to ask for a situation where you’d want to protect the state value but not code, client_secret, redirect_uri, and everything else in the request. If you actually want to protect all of that, it’s better to have a message-level pro

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Note that the argument was not about message-level protection: it was about not disclosing the state value verbatim over the token endpoint. I don't feel strongly about it either; it was just what was agreed at first. Since no-one actually came up with even a hypothetical attack I guess it mak

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Just because there’s a potential workaround doesn’t mean this is a good idea, especially when you can easily avoid the need for workarounds in the first place. :) — Justin > On Jan 21, 2016, at 2:15 PM, John Bradley wrote: > > The server could hash the state using the same algorithm the clie

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

The server could hash the state using the same algorithm the client uses if the client passed that as well. I see lots of things being fragile about that. The draft allows the server to use whatever hash it wants to internally to compare them. Given that we are detecting tamping and don’t need

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Thank you for removing state hashing and please don’t add it back. It’s security theater, and that’s giving it the benefit of the doubt. Remember, this is being sent in a request where other parameters (code, client_id, client_secret, redirect_uri) are all sent plain over TLS as well. Either co

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft. https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state. While JWT encoded state is how I would do state in a client and at-least one client I know of uses it, it i

[OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft. Changes were: * Simplified by no longer specifying the signed JWT method for returning the mitigation information. * Simplified by no longer depending upon publication of a discovery metadata d