[OAUTH-WG] Discovery document updates planned

Tomorrow I plan to apply updates to the OAuth Discovery document that have been requested since the -00 version was published. Updates on my list to make are: * Adding an equivalent of token_endpoint_auth_methods_supported for the revocation endpoint * Adding an equivalent of token

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] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

If the OAuth server supports discovery, “iss” can be used. If not, attacker’s OAuth server can describe honest OAuth server’s “iss” in its developer document. So returning “iss” would require discovery support NOW, not in the future. > On Jan 22, 2016, at 10:04, Mike Jones wrote: > > I believe

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

I agree the state token param solves code/token replace attack. However, I still don't think it’s a good idea to introduce "iss" to OAuth servers which aren't going to support discovery at this point. For Mix-up mitigation, RP just need to know Token endpoint they should use (rel=next), or Auth

Re: [OAUTH-WG] Call for Adoption

Right. OAuth-meta is not only for this particular attack. It actually predates the attack by three years. It just happens to mitigate the attack because it is addressing the root issue of decoupled data and meta-data problem. Re: returning as part of JSON payload, my earlier draft actually contain

Re: [OAUTH-WG] Call for Adoption

Re: iss. I discussed this a bit with Nov in more details. It probably is a sloppy language of the specs that is making it difficult to read what you wanted to achieve. In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization server's configuration information location". In OAuth d

Re: [OAUTH-WG] Call for Adoption

Nat, I’m confused by this statement in the message you reference “Unfortunately, this does not match the value of OAuth issuer defined in Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as specified in 3.1. As such, validation as specified in bullet 1 of Section 4 fai

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I believe that it’s simpler and more elegant to return an issuer, from which the discovery metadata document can be retrieved, which contains *all* the configuration information about the authorization server, than to return some of the configuration parameters but not most of them (which is wha

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I will point out for the benefit of the people on the the list who were not at the F2F in Germany, that Mike and I were asked to write up the consensus of the group. We have done that. The work group is free to adopt it or modify it. Brian and others raised issues about how accurately we r

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

The point is, the idea of making discovery mandatory even if the authz server is currently not doing it but giving info through developer documentation, does not sound likely to fly. 2016年1月22日(金) 9:47 John Bradley : > I will point out for clarification that this would be like IdP discovery > in

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I will point out for clarification that this would be like IdP discovery in openID 2 that everyone did. I think IdP not doing RP discovery in openID 2 is a weak argument. There may be other evidence that RP will not do discovery, but if that is the case why are we doing a OAuth discovery spec?

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Still doing the analysis. We spent 1.5 hours today with John, George, nov and me on the OpenID Connect WG call on this issue. John explained the mitigation, but none of us was convinced that it works. Then, after the call, I and nov went on with various scenarios. The interim conclusion is that:

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

There have been a lot of discussions. I think Hannes posted some minutes of the F2F meeting we had with the security researchers. The problem can’t be mitigated without some action on the client side. It boils down to the client making a request to AS1 (From it’s perspective) and getting back

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] Call for Adoption: OAuth 2.0 Device Flow

+1 for adoption On 1/19/16 6:48 AM, Hannes Tschofenig wrote: Hi all, this is the call for adoption of OAuth 2.0 Device Flow, see https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starti

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 On 1/21/16 12:34 PM, Brian Campbell wrote: +1 On Thu, Jan 21, 2016 at 7:48 AM, John Bradley > wrote: Yes we did discuss changing the title as part of adopting it. On Jan 21, 2016, at 11:28 AM, Nat Sakimura mailto:sakim...@gmail.com>> wrote: +1 apart

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption On 1/21/16 2:53 AM, Roland Hedberg wrote: +1 for adoption 21 jan 2016 kl. 07:14 skrev Antonio Sanso : +1 for adoption On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig wrote: Hi all, this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see https://tools.ietf.org/ht

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

I'm also +1 for adoption On 1/21/16 2:56 AM, Roland Hedberg wrote: +1 for adoption 21 jan 2016 kl. 07:11 skrev William Denniss : I believe this is important work. The original OAuth 2 spec left the topic of native apps largely undefined which is fair enough, the mobile-first revolution had

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 On Thu, Jan 21, 2016 at 7:48 AM, John Bradley wrote: > Yes we did discuss changing the title as part of adopting it. > > On Jan 21, 2016, at 11:28 AM, Nat Sakimura wrote: > > +1 apart from the title... It sounds like the spec is implementing OAuth > Open Redirector... > Something like "preve

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Thanks Nat - that's helpful. If both mitigations *can* work effectively, then I would like to see this group consider the decision between them carefully (if that hasn't happened yet). Again, don't hesitate to let me know if this is the wrong place/time for such discussion. At a high level, I woul

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

Yes we did discuss changing the title as part of adopting it. > On Jan 21, 2016, at 11:28 AM, Nat Sakimura wrote: > > +1 apart from the title... It sounds like the spec is implementing OAuth Open > Redirector... > Something like "preventing OAuth open redirector" or so might be more > descrip

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

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Hi Josh, It is similar but slightly different IMHO. Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit resource server. The mix-up attack described here is the code phishing by a counterfeit token endpoint. In my view, both can be mitigated by the server returning the nex

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 apart from the title... It sounds like the spec is implementing OAuth Open Redirector... Something like "preventing OAuth open redirector" or so might be more descriptive. Nat 2016年1月21日(木) 23:08 John Bradley : > +1 for adoption > > On Jan 21, 2016, at 3:18 AM, William Denniss wrote: > > +1

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

+1. Even as the main editor of the spec., I tend to forget the history ;-) 2016年1月21日(木) 23:17 John Bradley : > The code_challenge and code_challenge_method parameter names predate > calling the spec PKCE. > > Given that some of us deployed early versions of PKCE in products and > opensource to m

Re: [OAUTH-WG] Call for Adoption

Mike, You just criticize my draft. That's ok, but I would really like to get some response to my questions stated in https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To me, it just does not seem to work, and the combination of the oauth-meta and PKCE seems to be much more elegan

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

The code_challenge and code_challenge_method parameter names predate calling the spec PKCE. Given that some of us deployed early versions of PKCE in products and opensource to mitigate the problem before the spec was completed we decided not to rename the parameter names from code_verifier_me

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

+1 for adoption > On Jan 21, 2016, at 3:18 AM, William Denniss wrote: > > +1 for adoption. > > On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig > wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 Security: OAuth Open > Redirector, see > https:

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Apologies if this is the wrong forum for my comment (and please direct me to the appropriate place in that case), but I have two questions about the propose mitigation (and the thinking behind it) that I think the write-up could address: 1. Could the writeup clarify whether/how the primary "mixup"

Re: [OAUTH-WG] Call for Adoption

Convergence is exactly what I’m arguing for, though. These things ought to work together. — Justin > On Jan 21, 2016, at 2:55 AM, Mike Jones wrote: > > My memory of the discussions of the oauth-meta draft in Yokohama were that > many people felt that it was unnecessarily dynamically duplicat

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

Hi On 11/01/16 19:59, Mike Jones wrote: The alternatives for the code flow are to return them either in a new JWT added to the reply containing them in the “iss” and “aud” claims or to return them in new individual “client_id” and “iss” authorization response parameters. Both alternatives are d

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Hi Brian In our own code both authorization code and implicit flow requests can accommodate an audience property too. You are right in the latter case there won't be a separate request to a token endpoint hence we are treating what follows after the user has authorized the implicit client as i

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Hi Hannes, thanks for supporting it, I agree the audience concept is not tied to the PoP work Cheers, Sergey On 20/01/16 14:27, Hannes Tschofenig wrote: Hi Sergey, that's a good question. After this document was published the functionality had been integrated into the PoP solution document. R

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Well, re-reading, I have a bit of problem with the draft. It is defining a new concept 'issuer', which is not found in RFC6749, as the authorization server's configuration information location. It is returned in 'iss' authorization response parameter. On the other hand, there is an existing concep

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

Sorry to be slow responding, Nov. I wanted to wait to respond until a draft with the “state” token request parameter was published, which just happened. I think the oauth-meta spec solves some of them but not others. There were a bunch of different attacks discussed by the security researchers