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

I support adoption of this document by the working group. -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, January 19, 2016 3:50 AM To: oauth@ietf.org Subject: [OAUTH-WG] Call for Adoption

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

But that's cut-n-paste protection using "state" token endpoint parameter, is it not? 2016年1月29日(金) 14:14 Phil Hunt (IDM) : > We discussed that redirecr helps but we wanted the Token endpoint to also > be able to detect assuming many client devs won't implement the check. > > > Phil > > On Jan 28,

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

We discussed that redirecr helps but we wanted the Token endpoint to also be able to detect assuming many client devs won't implement the check. Phil > On Jan 28, 2016, at 20:54, Nat Sakimura wrote: > > My preferred way of dealing with mix-up has been to use separate redirection > URI but yo

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

My preferred way of dealing with mix-up has been to use separate redirection URI but your using issuer instead is for the backward compatibility? Nat 2016年1月29日(金) 2:53 John Bradley : > Yes, I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 > will stop this attack. > > White li

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

Yes, I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 will stop this attack. White listing AS seems tempting, but is just sweeping the problem partially under the rug. There are probably good policy reasons to whitelist AS but we shouldn’t let this AS mixup be one of them.

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

I see. That's like double cut-n-paste. I tried to capture this case of used-to-be-good AS turning Compromised AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD Given this, just relying on not using random AS is not good enough. You would probably require AS w/ISMS with the policy of

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

to access. The use of transport-layer security is particularly >>>>>>>>>> critical when the authorization process is used as a form of >>>>>>>>>> delegated end-user authentication by the client (e.g., third-party >&

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

t; >>>>>>>>>> sensitive credentials over an open network. This > specification does > >>>>>>>>>> not mandate the use of TLS because at the time of > this writing, > >>>>>>&

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

; wrote: Sorry, meant to reply-all. Phil @independentid <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <mailto:phil.h...@oracle.com>phil.h...@oracle.com <mailto:phil.h...@oracle.com&

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

t;Lack of transport-layer security can have a severe impact on the >>>>>>>>>security of the client and the protected resources it is authorized >>>>>>>>>to access. The use of transport-layer security is particularly >>>>&

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

out transmission of authorization codes in >> connection with redirects. >> >> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz >> codes. >> >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.co

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

ase too. http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ nov On Jan 26, 2016, at 08:22, Phil Hunt wrote: Sorry, meant to reply-all. Phil @independentid www.independentid.com phil.h...@oracle.com Begin forwarded

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

t;http://www.independentid.com/> phil.h...@oracle.com <mailto:phil.h...@oracle.com> Begin forwarded message: *From: *Phil Hunt mailto:phil.h...@oracle.com>> *Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation* *Date: *January 25, 201

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

ption 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 multi-AS case. > Nat's another

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

phil.h...@oracle.com> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake >>>>>> <mailto:mat...@gmail.com>> wrote: >

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

dentid www.independentid.com <http://www.independentid.com/> phil.h...@oracle.com <mailto:phil.h...@oracle.com> Begin forwarded message: *From: *Phil Hunt <mailto:phil.h...@oracle.com>> *Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation* *Dat

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

entid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Jan 25, 2016, at 4:52 PM, nov matake wrote: >>>>>> >>>>>>

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

rst assumption is coming from the original security report at >>>>> http://arxiv.org/abs/1601.01229 <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. >&g

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

n UA and RS. >>>> >>>> The blog post is based on my Japanese post, and it describes multi-AS case. >>>> Nat's another post describes the case which can affect single-AS case too. >>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oau

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

an affect single-AS case too. >>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ >>> >>> nov >>> >>>> On Jan 26, 2016, at 08:22, Phil Hunt wrote: >>>> >>>> Sorry, meant to reply-all. >>>>

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

49/ >> >> nov >> >>> On Jan 26, 2016, at 08:22, Phil Hunt wrote: >>> >>> Sorry, meant to reply-all. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>>

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

>> Phil >> >> @independentid >> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >> <mailto:phil.h...@oracle.com> >> >> >> >> >> >>> Begin forwarded message: >>> >>> From: Phil Hunt mailto:ph

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

; >> From: Phil Hunt mailto:phil.h...@oracle.com>> >> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation >> Date: January 25, 2016 at 3:20:19 PM PST >> To: Nat Sakimura mailto:sakim...@gmail.com>> >> >> I am having trouble wit

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

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

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

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] 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 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] 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

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

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

ides a concrete identifier for the >>>> authorization server that can be checked for equality. >>>> >>>> We talked about the value of that approach in the side meetings in >>>> Yokohama and people were supportive then. >>>> >>>>

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

: [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

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

in >>> Yokohama and people were supportive then. >>> >>> -- Mike >>> >>> *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley >>> *Sent:* Thursday, Januar

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

o:oauth-boun...@ietf.org>] *On Behalf Of *John Bradley > > *Sent:* Thursday, January 21, 2016 4:48 PM > > *To:* Nat Sakimura mailto:sakim...@gmail.com>> > > *Cc:* oauth@ietf.org <mailto:oauth@ietf.org> WG > <mailto:oauth@ietf.org>> > > *Subject:* Re: [OAUTH-W

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

*John Bradley > > *Sent:* Thursday, January 21, 2016 4:48 PM > > *To:* Nat Sakimura > > *Cc:* oauth@ietf.org WG > > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation > > > > I will point out for clarification that this would be like IdP d

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

then. -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley *Sent:* Thursday, January 21, 2016 4:48 PM *To:* Nat Sakimura *Cc:* oauth@ietf.org WG *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix

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

e meetings in Yokohama > and people were supportive then. > > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley > Sent: Thursday, January 21, 2016 4:48 PM > To: Nat Sakimura > Cc: oauth@ietf.org WG > Subje

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

. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Thursday, January 21, 2016 4:48 PM To: Nat Sakimura Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation I will point out for clarification that this would be like IdP

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

+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/html/draft-jones-oauth-mix-up-mitigation-

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

+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/html/draft-jones-oauth-mix-up-mitigation-00 > > Please let us know by Feb 9th whether you accept / object to the > ado

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

t; phil.h...@oracle.com> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation > > > > +1 for adoption, this is important work. > > > > On Thu, Jan 21, 2016, 9:48 AM John Bradley wrote: > > +1 for adoption > &g

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

+1 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss Sent: Wednesday, January 20, 2016 6:30 PM To: John Bradley ; Phil Hunt (IDM) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation +1 for adoption, this is important work. On Thu

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

+1 for adoption Mike and I are working on addressing the comments in a new draft for your reading pleasure shortly. John B. > On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) wrote: > > +1 for adoption > > +1 for Brian's comments > > Phil > > On Jan 20, 2016, at 14:42, Brian Campbell

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

+1 for adoption +1 for Brian's comments Phil > On Jan 20, 2016, at 14:42, Brian Campbell wrote: > > I conditionally accept this document as a starting point for work in the > OAuth working group on the assumption that the considerable simplifications > discussed and accepted at > http://www

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

I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be incorporated. This document is (should be) intende

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

Hi all, this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 Please let us know by Feb 9th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: T