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

The token endpoint mix-up attack was originally discussed in the context of OIDC, in August 2015. Back then John Bradley noted that by simply replacing Basic client authentication with JWT (client_secret_jwt or private_key_jwt) the attack is successfully prevented. Yes, the authz code will be captu

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

Right, JWT client authentication prevents the “code phishing”. However, when you generalize it, it amounts to the phishing of any “bearer tokens”, including not only code+client_secret pair but also access token against resources. . So, the general solution would either be: 1) Let th

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

The mixup attack where the client is confused about who the response is coming from is posable both by providing bad configuration information and by compromising a existing AS. The point was that telling clients to only register with “good” AS or somehow validating the configuration informatio

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

Using client secret JWT works as long as long as the attacker doesn’t know the client secret of the client_id associated with the “good AS”. The reason is that the attacker cannot replay a signed assertion because it contains a audience and client_id that would not match. In the case where the

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

I'm still catching up... but to this point specifically... Doesn't this require that the same client_id NOT be used simultaneously at two (or more) Authorization Servers? If so, I don't believe that is a viable option. It's a little late in the game to be putting requirements on the AS as to h

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

No, client id_are scoped by issuer. There is no need for AS to make the client_id globally unique. The client needs to not allow two AS to provide it with the same issuer client_id pair. That would probably be imposable for many clients anyway. For Connect clients typically manage configur

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

Comments inline On 1/25/16 12:32 PM, John Bradley wrote: No, client id_are scoped by issuer. This makes sense, but I'm not sure it's a current assumption by OAuth2 implementations :) There is no need for AS to make the client_id globally unique. The client needs to not allow two AS to provi

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

The presumption is that registration would need to add a issuer, as an identifier of the AS, and that would be optionally be used in discovery. OAuth as is supports the single AS model. To support multiple AS for a single client something needs to change.Adding issuer and client_id to the r

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

+1 Phil @independentid www.independentid.com phil.h...@oracle.com > On Jan 21, 2016, at 6:26 AM, Nat Sakimura wrote: > > +1. Even as the main editor of the spec., I tend to forget the history ;-) > > 2016年1月21日(木) 23:17 John Br

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

+1. I think this helps clarify some mis-conceptions that are out there. Phil @independentid www.independentid.com phil.h...@oracle.com > On Jan 21, 2016, at 10:14 AM, George Fletcher wrote: > > I'm also +1 for adoption > > On 1

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

So now, in addition to the dynamic client registration spec, the client would need to support OAuth2 Discovery. I guess my concern is that it feels like we are adding a lot of little things to try and mitigate these attacks in OAuth2 and it's confusing when they are needed and when they aren't

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

+1. I agree with Nat’s comment re the title. Also, I would like to have a discussion in the WG around organization of the docs. What can we amend as errata (to give some of this stuff more prominence), and what new docs we should have? With PKCE, mix-up, and this, we may end up causing more c

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

+1 On 1/25/16 1:41 PM, Phil Hunt wrote: Also, I would like to have a discussion in the WG around organization of the docs. What can we amend as errata (to give some of this stuff more prominence), and what new docs we should have? With PKCE, mix-up, and this, we may end up causing more confus

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

I recall making this point in Germany. 99% of existing use is fine. OIDC is probably the largest community that *might* have an issue. I recall proposing a new security document that covers oauth security for dynamic scenarios. "Dynamic" being broadly defined to mean: * clients who have configu

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] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

Yes sorry. code_challenge_method is the query parameter so code_challenge_methods_supported > On Jan 25, 2016, at 6:12 PM, William Denniss wrote: > > > > On Thu, Jan 21, 2016 at 6:17 AM, John Bradley > wrote: > The code_challenge and code_challenge_method paramet

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

OK great! It seems that we have consensus on this. So this is what we plan to add to our discovery doc, based on this discussion: "code_challenge_methods_supported": ["plain","S256"] What are the next steps? Can we we add it to https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I s

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

I'll add it to the discovery draft in the next day or so. Also, please see my questions in the message "[OAUTH-WG] Discovery document updates planned". I was waiting for that feedback before doing the update. Thanks, -- Mike From: William Denniss

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

Hi Phil, Since I was not in Darmstadt, I really do not know what was discussed there, but with the compromised developer documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC6749 clients with a naive implementer will be affected. The client does

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

Sorry, meant to reply-all. Phil @independentid www.independentid.com phil.h...@oracle.com > Begin forwarded message: > > From: Phil Hunt > Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation > Date: January 25

Re: [OAUTH-WG] Discovery document updates planned

On Thu, Jan 21, 2016 at 10:37 PM, Mike Jones wrote: > 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 >

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

+1 > On Jan 25, 2016, at 1:39 PM, George Fletcher wrote: > > So now, in addition to the dynamic client registration spec, the client would > need to support OAuth2 Discovery. > > I guess my concern is that it feels like we are adding a lot of little things > to try and mitigate these attacks

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

The first assumption is coming from the original security report at http://arxiv.org/abs/1601.01229 . RFC 6749 requires TLS between RS and AS, and also between UA and AS, but not between UA and RS. The blog post is based on my Japanese post, and it describes mult

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

I would find it hard to believe that is true. From 6749 Sec 3.1 Since requests to the authorization endpoint result in user authentication and the transmission of clear-text credentials (in the HTTP response), the authorization server MUST require the use of TLS as described in Sectio

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

It doen't say anything about the first request which initiate the login flow. It is still a reasonable assumption that RP puts a "login with FB" button on a non TLS-protected page. nov > On Jan 26, 2016, at 10:45, Phil Hunt wrote: > > I would find it hard to believe that is true. > > From 674

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

When the RP acting as the client issues a authorize redirect to the UA it has to make it with TLS Phil > On Jan 25, 2016, at 17:53, Nov Matake wrote: > > It doen't say anything about the first request which initiate the login flow. > It is still a reasonable assumption that RP puts a "login wi

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

Also the authz endpoint is required to force tls. So if the client doesn't do it the authz should reject (eg by upgrading to tls). Phil > On Jan 25, 2016, at 19:29, Phil Hunt (IDM) wrote: > > When the RP acting as the client issues a authorize redirect to the UA it has > to make it with TLS

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

In this flow, AuthZ endpoint is forced to be TLS-protected. http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png However, RP’s redirect response which causes following AuthZ request is still not TLS-protected, and modified on the attacker’s proxy. Section 3.2 of this report al

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

Still don't see it. Though i think the diagram is wrong (the rp should redirct to the ua and not call the authz direct), the IDP should either return an error or redirect the RP to TLS. I don't see this as proper oauth protocol since the RP is MITM the UA rather than acting as a client. Phil