Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24D1B3606 for ; Thu, 21 Jan 2016 18:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmSe7Ob0jtOh for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA7E1B3605 for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id 6so47451003qgy.1 for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0vQA8n+PTUHp1yDiQD/xEcTMK4G4VciZjBAZD9o9Q0o=; b=BGcpq/mAzfrFY/dfAv7pqIPGg9QT4yIrRZoa6NbMB/6UiqMq1HU0P6pTgu0WqX/4SR yXxIEaI3Dz2+yArJ7LW3l698TELE4Tos+vLUHdjX3LQ3en1jyAB3wo704ssgARNlvIdb O707vnoz5ChqFUWHG5jddVXT9uoLwFeOupEtGIgCeVnrWj49FTpxutHaz4dRVxtxkJLG Jupv9sSiNB8u3uFvTQKWSP1NH2B9akpXP18Kf8qWxS8/4TYoj+0yqtjnU8dfQmxsAol8 7KCFshiDQHHQcaaxlVAea3nXQS2g+QqTrF/kfvs437Ngs2h7wBKpSVFxcC/H0gFYdIfD 5D+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=0vQA8n+PTUHp1yDiQD/xEcTMK4G4VciZjBAZD9o9Q0o=; b=lLqq5CKX2ho/8STJ+jmhUvsl3fMr+BUqnSYB2IfbXK/cwnYLnYtsX40dsqXjYKyetN H9GHQK+ClD/nfOMQ93U2/ltWd85p2ZesiFSxoC7ZSmPlzNEckxy28//SqRWie5Y/04i5 l1sMOG2y/lKfOJQlhul6Cbe+gj58FNrNoT+oA9ZJukSp9usj54CmgHPMdb8sFA4FMSfW NIcglLfRPk7BXRRiy8t8yEj+ufHOsba1JaXfPpv0xRiO9w524YV1cW80D+nhY9axiW1U 6rmQBgatRqlc12uM1/s9CJOm6/AS4LNG4HqFh6565Afgj2JAmEtXrf77A3Ziqb+rZxo3 xPGQ== X-Gm-Message-State: AG10YOQURnYfhPb2uXC7a27OuElUyY85Xjm90cHnzhUgshhUSLQKadqGidOl7jRI+uUHEg7pvBJ39Ee0GutrKw== X-Received: by 10.140.180.80 with SMTP id b77mr598154qha.67.1453428487146; Thu, 21 Jan 2016 18:08:07 -0800 (PST) MIME-Version: 1.0 References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> In-Reply-To: From: Nat Sakimura Date: Fri, 22 Jan 2016 02:07:56 +0000 Message-ID: To: Mike Jones , Justin Richer Content-Type: multipart/alternative; boundary=001a113a7e3caed6010529e2b098 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 02:08:14 -0000 --001a113a7e3caed6010529e2b098 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 discovery draft, there is something called "OAuth 2.0 Configuration Information Location URL", which is equal to "OpenID Connect Issuer". When I wrote the statement, I thought you were pointing to the URL that you can actually pull the configuration information by "the URL of the authorizaiton server's configuration information location" since otherwise you would have used the term "OAuth 2.0 Configuration Information Location URL". But after all, you probably meant these two are the same. Then I would strongly recommend to fix the language. Now, even If that is the case, the relationship like - iss + .well-know/openid-configuration =3D Connect OP config endoint - OAuth config endpoint - .well-known/openid-configuration =3D OAuth iss is very confusing. You also claim that your approach is simpler, but to me, your approach seem to be overly complex. It requires discovery and the check for the value of the discovered config information to work as the mitigation. (Right. Draft -01 does not have it, so it does not solve the mix-up issue.) With oauth-meta, you do not need it. Finally, your point that HATEOAS reminds you of WSDL, it is not. If you want to have something similar to WSDL in REST API area, it is Swagger. (Actually, it is gaining a lot of momentum recently, but that's beside the fact ;-). And the point here is not the format but the fact that we need to have a way to associate metadata to the data. The root cause of this mix-up attack is that the metadata and data is not associated properly. We have a standard way of associating the data and metadata with link-rel such as RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most modern web pages actually have it. Using a proper way to associate metadata with data will save you from a lot of other attacks in the future. Instead of doing patch works, we should solve it architecturally. Nat 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones : > Nat, I=E2=80=99m confused by this statement in the message you reference = =E2=80=9CUnfortunately, > 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 > fails in Google's case -- OR it means that the document is internally > inconsistent.=E2=80=9D. The issuer definition in draft-jones-oauth-disco= very is > 100% compatible with the one in OpenID Connect Discovery, by design. In > the Google example, both the OpenID issuer and the OAuth issuer values > would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D. What = is the > inconsistency that you perceive? > > > > The discussion of the duplication problem happened in the private meeting= s > in Yokohama. > > > > I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meetin= gs to > point out that a simpler alternative to oauth-meta was already being > discussed there in private, because then I would have had to talk about t= he > security issues, which we=E2=80=99d decided not to publicly do at that po= int. So I > stayed silent during the poll, out of politeness. Perhaps I should have > found a way to say something then anyway, but that=E2=80=99s water under = the bridge > now. > > > > Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far to= o much of > Web Services Description Language (WSDL) =E2=80=93 part of the complexity= baggage > that helped sink Web Services. The use of =E2=80=9Clink rel=E2=80=9D to = define an > interaction vocabulary and publish endpoints for that vocabulary seems > pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80= =93 another cute =E2=80=9CWebby=E2=80=9D > innovation that never caught on. The industry has pretty much voted with > its feet and is using JSON for publishing discovery data structures =E2= =80=93 not > =E2=80=9Clink rel=E2=80=9D. I am against us reverting to the =E2=80=9Cli= nk rel=E2=80=9D proposal from 2008 > that never caught on when JSON is simpler and does a better job. > > > > -- Mike > > > > *From:* Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Thursday, January 21, 2016 6:24 AM > *To:* Justin Richer ; Mike Jones < > Michael.Jones@microsoft.com> > *Cc:* William Denniss ; < > oauth@ietf.org> > > > *Subject:* 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, nicer, and much simpler to > implement. If you just give up the dynamic response at the authorization > endpoint, then you even do not have to touch the code but just change a > config file. > > > > Please convince me by answering to my questions. > > > > For the record of Yokohama, I do not recall much about duplication in > OAuth session. The poll in the room was 19 for / zero against / 4 persons > need more information. Indeed, it is not duplicating much. And if you mov= e > to a new model without pre-configured discovery, it is not duplicating an= y > but the resource endpoint URI, which is optional and is for the cases whe= re > the client did not know the concrete resource endpoint to start with. > > > > I understand your usecases always start from a concrete endpoint location= . > Mine do not. In a four party model, it is likely not. The user just want = to > have the service to fetch his data from some resource endpoint. He just > hits the service. He does not hit the resource endpoint directly. For > example, in the case of a consumer using a personal finance platform > (PFP)to manage his pension fund, he hits the PFP and not the Pension fund= . > Assuming that the pension fund has delegated the authorization control to > the authorization server, then, the authorization server should return bo= th > the access token and the endpoint of the pension fund so that the PFP can > pull the data using them. A similar model holds for personal health servi= ce > and health care providers. > > > > Best, > > > > Nat > > > > > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer : > > Convergence is exactly what I=E2=80=99m arguing for, though. These things= ought to > work together. > > > > =E2=80=94 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 tha= t > many people felt that it was unnecessarily dynamically duplicating a lot = of > information that the client already had. Most of us that were aware of t= he > attacks then were in favor of a more targeted, minimal approach. You wer= e > listened to in Yokohama, but that didn=E2=80=99t necessarily mean that pe= ople > agreed with the approach. Participants were already aware of the > oauth-meta proposal in Darmstadt but no one spoke up in favor of it that = I > can recall. Rather, I think people were thinking that =E2=80=9Cless is m= ore=E2=80=9D. > > > > There have also been discussions in the last day about how dynamically > returning a resource URL, which oauth-meta does, is both unnecessary (sin= ce > the client initiated the resource authorization already knowing what > resource it wants to access) and often problematic, since many > authorization servers can authorize access to multiple resources. If > anything, the client should be telling the authorization server what > resource it wants to access =E2=80=93 not the other way around. > > > > I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the o= auth-meta draft =E2=80=93 > I=E2=80=99m sure there are, just as there are in the approach designed by= the > participants in Darmstadt. While I volunteered to write the first draft = of > the mix-up-mitigation approach, it really reflects something a lot of > people have already bought into =E2=80=93 as evidenced in the passion in = the > high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, = and not just my > personal project. > > > > If you think there are things missing or wrong in the mix-up-mitigation > draft, please say what they are. That will help us quickly converge on a > solution that will work for everyone. > > > > Sincerely, > > -- Mike > > > > *From:* Nat Sakimura [mailto:sakimura@gmail.com ] > *Sent:* Wednesday, January 20, 2016 11:17 PM > *To:* Mike Jones ; William Denniss < > wdenniss@google.com>; Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption > > > > Hi Mike. > > > > Conversely, I would like to ask why this approach does not work for Mix-u= p > attack. As Nov stated, we in fact have discussed the approach in quite a > length back in Yokohama. I really would like to know why it does not work= . > > > > Besides, for oauth-meta approach, mix-up attack is only one of the thing > it solves. > > > > Nat Sakimura > > > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones : > > Not to be negative, but I disagree with adopting > draft-sakimura-oauth-meta. We should define and promote one mitigation > approach to the mix-up attacks. Having two would confuse implementers an= d > cause compatibility problems =E2=80=93 reducing overall security. > > > > The approach defined in draft-jones-oauth-mix-up-mitigation was created i= n > collaboration with the security researchers who identified the problems i= n > the first place, was vigorously discussed in the security meeting Hannes > and Torsten held in Darmstadt, and has been since refined based on > substantial input from the working group. And at least three implementer= s > have already stated that they=E2=80=99ve implemented it. I=E2=80=99m not= saying that it=E2=80=99s, > but if there are things missing or things that need to be improved in our > approach, we should do it there, rather introducing a competing approach. > > > > Also, standard OAuth deployments register the client and then use the > information gathered at registration time for subsequent protocol > interactions. They do not need all the configuration information for the > authorization server to be retransmitted at runtime. The oauth-meta draf= t > goes too far in that direction, at least as I see it. Returning things t= wo > ways creates its own problems, as discussed in the Duplicate Information > Attacks security considerations section (7.2) of the mix-up-mitigation > draft. > > > > I=E2=80=99ll note that the mix-up-mitigation approach is compatible with = existing > practice in both static and dynamic metadata discovery. Replying to > Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery = document that's > at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th= is is not the > case. The attacks can be performed without either discovery or dynamic > registration. > > > > I would be interested in hearing a technical discussion on whether there > are aspects of the oauth-meta approach that mitigate aspects of the attac= ks > that the mix-up-mitigation approach does not. That could help inform > whether there are additional things we should add to or change in the > mix-up draft. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 10:37 PM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption > > > > +1 to adopt this, and I agree with Justin's comments. > > > > On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer wrote: > > +1 > > Inline discovery and pre-configured discovery (ie, .well-known) should at > the very least be compatible and developed together. It's the > pre-configured discovery document that's at the root of the mix-up attack > in the first place. > > -- Justin > > > > On 1/19/2016 10:30 PM, Nat Sakimura wrote: > > Just to give more context, at IETF 94, I have done a presentation on > discovery. > > > > According to the minutes, > > > > (f) Discovery (Nat) > > > > Nat explains his document as an example of the work that has= to be done > > in the area of discovery, which is a topic that has been ide= ntified > > as necessary for interoperability since many years but so fa= r there > > was not time to work on it. Mike, John and Nat are working o= n a new > > document that describes additional discovery-relevant compon= ents. > > > > Poll: 19 for / zero against / 4 persons need more informatio= n. > > > > The document discussed there was > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a > simple (only 1-page!) but a very powerful document that nudges towards > HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u= p > attack without introducing the concept of issuer which is not in RFC6749. > It is also good for selecting different endpoints depending on the user > authentication and authorization results and more privacy sensitive than > pre-announced Discovery document. It also allows you to find to which > protected resource endpoint you can use the access token against. > > > > In the last sentence of the minutes, it talks about "a new document that > describes additional discovery-relevant components". This is > https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for > the call for adoption. However, it is only a half of the story. I believe > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was > discussed at IETF 94 and had support there should be adopted as well. > > > > Nat Sakimura > > > > > > > > > > 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura : > > Thanks Hannes. > > > > I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, = which > was discussed in Yokohama, and was largely in agreement if my recollectio= n > is correct. Why is it not in the call for adoption? > > > > > > > > 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig : > > Hi all, > > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and > since some IESG members like to see an updated list of milestones as > well. For this reason, based on a suggestion from Barry, we are also > starting a call for adoption concurrently with the review of the charter > text by the IESG. > > We will post separate mails on the individual documents. Your feedback > is important! Please take the time to look at the documents and provide > your feedback. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --001a113a7e3caed6010529e2b098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 t= o read what you wanted to achieve.=C2=A0

In mix-up-mitigati= on draft, OAuth issuer is "the URL of the authorization server's c= onfiguration information location". In OAuth discovery draft, there is= something called "OAuth 2.0 Configuration Information Location URL&qu= ot;, which is equal to "OpenID Connect Issuer".=C2=A0

When I wrot= e the statement, I thought you were pointing to the URL that you can actual= ly pull the configuration information by "the URL of the authorizaiton= server's configuration information location" since otherwise you = would have used the term "OAuth 2.0 Configuration Information Location= URL". But after all, you probably meant these two are the same. Then = I would strongly recommend to fix the language.=C2=A0

Now, even If that is = the case, the relationship like=C2=A0

  • iss + .well-know/openid-configurat= ion =3D Connect OP config endoint
  • OA= uth config endpoint - .well-known/openid-configuration =3D OAuth iss
    • is very confusing.=C2=A0

    You also claim that your approach is simpler, but to me, you= r approach seem to be overly complex. It requires discovery and the check f= or the value of the discovered config information to work as the mitigation= . (Right. Draft -01 does not have it, so it does not solve the mix-up issue= .) With oauth-meta, you do not need it.=C2=A0

    Fin= ally, your point that HATEOAS reminds you of WSDL, it is not. If you want t= o have something similar to WSDL in REST API area, it is Swagger. (Actually= , it is gaining a lot of momentum recently, but that's beside the fact = ;-). And the point here is not the format but the fact that we need to have= a way to associate metadata to the data. The root cause of this mix-up att= ack is that the metadata and data is not associated properly. We have a sta= ndard way of associating the data and metadata with link-rel such as RFC598= 8 so why not use it? Link-rel-href pattern is used a lot now. Most modern w= eb pages actually have it. Using a proper way to associate metadata with da= ta will save you from a lot of other attacks in the future. Instead of doin= g patch works, we should solve it=C2=A0architecturally.=C2=A0=

    Nat


=
2016=E5=B9=B41=E6=9C=8822= =E6=97=A5(=E9=87=91) 10:34 Mike Jones <Michael.Jones@microsoft.com>:

Nat, I=E2=80=99m confused by this sta= tement in the message you reference =E2=80=9CUnfortunately, this does not match the value of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-miti= gation-01 nor the 'iss' returned as specified in 3.1.=C2=A0As such,= validation as specified in bullet 1 of Section 4 fails in Google's cas= e -- OR it means that the document is internally inconsistent.=E2=80=9D.=C2=A0 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi= th the one in OpenID Connect Discovery, by design.=C2=A0 In the Google exam= ple, both the OpenID issuer and the OAuth issuer values would be the string= =E2=80=9Chttps:/= /accounts.google.com=E2=80=9D.=C2=A0 What is the inconsistency that you perceive?

=C2=A0

The discussion of the duplication pro= blem happened in the private meetings in Yokohama.

=C2=A0

I will admit, in Yokohama, I didn=E2= =80=99t speak up in the public meetings to point out that a simpler alterna= tive to oauth-meta was already being discussed there in private, because then I would have had to talk about the security issues, = which we=E2=80=99d decided not to publicly do at that point.=C2=A0 So I sta= yed silent during the poll, out of politeness.=C2=A0 Perhaps I should have = found a way to say something then anyway, but that=E2=80=99s water under the bridge now.

=C2=A0

Finally, for what it=E2=80=99s worth,= the HATEOAS stuff reminds me far too much of Web Services Description Lang= uage (WSDL) =E2=80=93 part of the complexity baggage that helped sink Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define a= n interaction vocabulary and publish endpoints for that vocabulary seems pr= etty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 an= other cute =E2=80=9CWebby=E2=80=9D innovation that never caught on.=C2=A0 T= he industry has pretty much voted with its feet and is using JSON for publishing discovery data s= tructures =E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us r= everting to the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never ca= ught on when JSON is simpler and does a better job.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Thursday, January 21, 2016 6:24 AM
To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com> Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

Mike,=C2=A0

=C2=A0

You just criticize my draft. That's ok, but I wo= uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.= html=C2=A0. To me, it just does not seem to work, and the combination of the oauth-met= a and PKCE seems to be much more elegan, nicer, and much simpler to impleme= nt. If you just give up the dynamic response at the authorization endpoint,= then you even do not have to touch the code but just change a config file.=C2=A0

=C2=A0

Please convince me by answering to my questions.=C2= =A0

=C2=A0

For the record of Yokohama, I do not recall much abo= ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4 persons need mor= e information. Indeed, it is not duplicating much. And if you move to a new model without pre-configured discovery, it = is not duplicating any but the resource endpoint URI, which is optional and= is for the cases where the client did not know the concrete resource endpo= int to start with.=C2=A0

=C2=A0

I unders= tand your usecases always start from a concrete endpoint location. Mine do = not. In a four party model, it is likely not. The user just want to have th= e service to fetch his data from some resource endpoint. He just hits the service. He does not hit the resource = endpoint directly. For example, in the case of a consumer using a personal = finance platform (PFP)to manage his pension fund, he hits the PFP and not t= he Pension fund. Assuming that the pension fund has delegated the authorization control to the authorization = server, then, the authorization server should return both the access token = and the endpoint of the pension fund so that the PFP can pull the data usin= g them. A similar model holds for personal health service and health care providers.=C2=A0<= /u>

=C2=A0

Best,=C2= =A0

=C2=A0

Nat

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer <jricher@mit.edu>:

Convergence is exactly what I=E2=80=99m arguing for,= though. These things ought to work together.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

=C2=A0

My memory of the discussions of the o= auth-meta draft in Yokohama were that many people felt that it was unnecessarily dynamically duplicating a lot of information that the cl= ient already had.=C2=A0 Most of us that were aware of the attacks then were= in favor of a more targeted, minimal approach.=C2=A0 You were listened to = in Yokohama, but that didn=E2=80=99t necessarily mean that people agreed with the approach.=C2=A0 Participants were already awar= e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i= t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80= =9Cless is more=E2=80=9D.

=C2=A0

There have also been discussions in t= he last day about how dynamically returning a resource URL, which oauth-meta does, is both unnecessary (since the client initiated the resou= rce authorization already knowing what resource it wants to access) and oft= en problematic, since many authorization servers can authorize access to mu= ltiple resources.=C2=A0 If anything, the client should be telling the authorization server what resource it wan= ts to access =E2=80=93 not the other way around.

=C2=A0

I=E2=80=99m not saying that there are= n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s= ure there are, just as there are in the approach designed by the participants in Darmstadt.=C2= =A0 While I volunteered to write the first draft of the mix-up-mitigation a= pproach, it really reflects something a lot of people have already bought i= nto =E2=80=93 as evidenced in the passion in the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa= d, and not just my personal project.

=C2=A0

If you think there are things missing= or wrong in the mix-up-mitigation draft, please say what they are.=C2=A0 That will help us quickly converge on a solution that will work= for everyone.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sincerely,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<= /a>>; Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

Hi Mike.=C2=A0

=C2=A0

Conversely, I would like to ask why this approach do= es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse= d the approach in quite a length back in Yokohama. I really would like to know why it does not work.=C2=A0

=C2=A0

Besides, for oauth-meta approach, mix-up attack is o= nly one of the thing it solves.=C2=A0

=C2=A0

Nat Sakimura

=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

Not to be negative, but I disagree wi= th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf= use implementers and cause compatibility problems =E2=80=93 reducing overal= l security.

=C2=A0

The approach defined in draft-jones-o= auth-mix-up-mitigation was created in collaboration with the security researchers who identified the problems in the first place, was vigorously= discussed in the security meeting Hannes and Torsten held in Darmstadt, an= d has been since refined based on substantial input from the working group.= =C2=A0 And at least three implementers have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m= not saying that it=E2=80=99s, but if there are things missing or things th= at need to be improved in our approach, we should do it there, rather intro= ducing a competing approach.

=C2=A0

Also, standard OAuth deployments regi= ster the client and then use the information gathered at registration time for subsequent protocol interactions.=C2=A0 They do not need all the = configuration information for the authorization server to be retransmitted = at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l= east as I see it.=C2=A0 Returning things two ways creates its own problems, as discussed in the Duplicate Information Attack= s security considerations section (7.2) of the mix-up-mitigation draft.

=C2=A0

I=E2=80=99ll note that the mix-up-mit= igation approach is compatible with existing practice in both static and dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha= t =E2=80=9CIt's the pre-configured discovery document that's= at the root of the mix-up attack in the first place=E2=80= =9D =E2=80=93 this is not the case.=C2=A0 The attacks can be performed without either discove= ry or dynamic registration.

=C2=A0

I would be interested in hearing a te= chnical discussion on whether there are aspects of the oauth-meta approach that mitigate aspects of the attacks that the mix-up-mitigation a= pproach does not.=C2=A0 That could help inform whether there are additional= things we should add to or change in the mix-up draft.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

+1 to adopt this, and I agree with Justin's comm= ents.

=C2=A0

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:

+1

Inline discovery and pre-configured discovery (ie, .well-known) should at t= he very least be compatible and developed together. It's the pre-config= ured discovery document that's at the root of the mix-up attack in the = first place.

=C2=A0-- Justin

=C2=A0<= /p>

On 1/19/2016 10:30 PM, Nat Sakimura wrote:=

Just to give more context, at IETF 94, I have done a= presentation on discovery.=C2=A0

=C2=A0

According to the minutes,=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.
=C2=A0

The document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim= ple (only 1-page!) but a very powerful document that nudges towards HATEOAS= which is at the core of RESTful-ness. It also mitigates the Mix-up attack = without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different= endpoints depending on the user authentication and authorization results a= nd more privacy sensitive than pre-announced Discovery document. It also al= lows you to find to which protected resource endpoint you can use the access token against.=C2=A0

=C2=A0

In the last sentence of the minutes, it talks about = "a new document that describes additional discovery-relevant component= s". This is=C2=A0https://tools.ietf.org/html/draft-jones= -oauth-discovery-00.=C2=A0 It went for the call for adoption. However, it is only a half of the story= . I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau= th-meta-05=C2=A0that was discussed at IETF 94 and had support there=C2=A0should be adopted as well.=C2=A0 <= /u>

=C2=A0

Nat Sakimura

=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura <sakimura@gmail.com>:

Thanks Hannes.=C2=A0

=C2=A0

I did not find=C2=A0https://tools.ietf.o= rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed in Yokohama, and was largely in agreement if my recollection is correct. W= hy is it not in the call for adoption?=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0<= /p> 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

--001a113a7e3caed6010529e2b098--