Re: [OAUTH-WG] Call for Adoption

Nat Sakimura <sakimura@gmail.com> Sat, 23 January 2016 01:29 UTC

Return-Path: <sakimura@gmail.com>
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 A57471B2E9D for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 17:29:26 -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 bi8RnmuOnUMd for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 17:29:20 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 438041B2E9B for <oauth@ietf.org>; Fri, 22 Jan 2016 17:29:20 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id x1so35590591qkc.1 for <oauth@ietf.org>; Fri, 22 Jan 2016 17:29:20 -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=8oCouqo4EEBfDuMHY9lxS9+6ENsI9Du1vxwXrGWHQE8=; b=yHBhJoguZb39JDhJ4mtscYG4AuFUObBUV9y1WQmfA5z8AwpUa2T9avjAqnKitwGoqj ic8P9fafayrofkwPafrJDyrYB0swaUv1nFa6iP5oHlROhZD37LWKecq0p8KFPmvEQrqW LcNstVkp+j/Qp7UNISvtWcb9VlpbXRtOo9n1Cgx6UnrqTRlRD2zMiMJsAyIwDTyVfyDv srwRT+DzK4t5SoQe3aOim3slXJsY2HLwRxzJ7v4cpndbP4g3ufENeHhRzmave8iTP2PU ykMrqKP6ZvdfzfFiHaZ7XgqdB6yYQJ5T2GD25FoIyoE0k+64wIm9AJ3XoK9A5PahfxV2 ycXg==
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=8oCouqo4EEBfDuMHY9lxS9+6ENsI9Du1vxwXrGWHQE8=; b=JrAaINa7UQbJIPoC7STnXfzMFy2imjHzY8Q9S+w9mju0XGDMQBNbAZe17INZg+SSIc lJze3OhUNYqoYctdocE8lJ6gzcCaMv2RSu+DW4+mlHBg2WV85kIp+J24DQxKBcBqrk5W r8jIk5wiLKEn/WSxVLxBdBNdluGGYP54ie00nk0O6/ogtUlafCoMLs9FFc/rEZarCdKm 6LQ8P/Z5v7q2t8lY7hklYOYfEGNGAVOk8lWXHpldvxifmUjqZccf6jEQRPs/6A1WsKW5 rEDjqveETEuDck6jfEhaRhyNZEX5HBsSkH2Hv5904EnL+DpU9kL1UHNIIcmrTMFWMNZp ZzsQ==
X-Gm-Message-State: AG10YORq7BjQcmoDWyVfeb0EzH5kRkVnmq/IVS8+iWq0VUgjXePvPqGDW8cftrJDtTiFHTWwx3vZQDzAQhneQA==
X-Received: by 10.55.71.135 with SMTP id u129mr7689358qka.26.1453512559372; Fri, 22 Jan 2016 17:29:19 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net> <CABzCy2D8BvJkLCc543=pEdE4FZa+p1ekyuMs=TtVSnSCrTrviw@mail.gmail.com> <CABzCy2D1gca2OR2qp_gakThjkoLGfaZAo=GE85Lz4+3TrPbFVQ@mail.gmail.com> <569F915D.8020806@mit.edu> <CAAP42hC+L-7irdR7Y2pfNWyhP6cWLn0wNyauA5TQb4jr=4UH4Q@mail.gmail.com> <BY2PR03MB442C2801F09B2B7A103E673F5C30@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2DehwZh2gd_6oNy69O+qxowva00qZWnX8uWX2n4h+kPLw@mail.gmail.com> <BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <EE414329-AA2A-4F99-841B-0581E4F4605F@mit.edu> <CABzCy2A9RCONixTG+ZFD8sz6FTD-o1Do8iV2gX2=pKu+PenT-A@mail.gmail.com> <BY2PR03MB442DE057967872C63A56DF8F5C40@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2Co2okoC_hxy3bLTzbGm3nuQiULM3XqkJMwiV_5iU9-=Q@mail.gmail.com> <CA+k3eCSfXQng6PzhWR-Qjyp=SO1LYnfXH7qqzb-5btqWaJJX-A@mail.gmail.com> <BY2PR03MB4422882B74ED659DB47CECDF5C40@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB4422882B74ED659DB47CECDF5C40@BY2PR03MB442.namprd03.prod.outlook.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Sat, 23 Jan 2016 01:29:08 +0000
Message-ID: <CABzCy2CC8jN6kzxbJ70m900g4J1VW2b65gM_M1dhx6YXfWVhdQ@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary=001a114a7d20c730a30529f64304
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/rkL4IH2TMoPvpcBO5ePH34byHyY>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jan 2016 01:29:26 -0000

I wrote a blog on why the current mix-up draft approach does not solve the
issue.

http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/

Hopefully, the point I am making is clearer by this.

Best,

Nat

2016年1月23日(土) 8:32 Mike Jones <Michael.Jones@microsoft.com>;:

> I like the “from which the authorization server's configuration
> information location can be derived” language.  Thanks.  I’ll plan to
> incorporate that the next time the draft is revised.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
> *Sent:* Friday, January 22, 2016 3:26 PM
> *To:* Nat Sakimura <sakimura@gmail.com>;
> *Cc:* Mike Jones <Michael.Jones@microsoft.com>;; Justin Richer <
> jricher@mit.edu>;; <oauth@ietf.org>; <oauth@ietf.org>;
>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> I agree that the language describing OAuth issuer could and should be
> improved. The text now reads like it is the exact and full URL where the
> metadata/discovery document is located. Perhaps something more like "the
> URL from which the authorization server's configuration information
> location can be derived" and explain that adding the .well-known bits to
> the issuer is where the configuration information can actually be found.
>
>
>
> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <sakimura@gmail.com>; wrote:
>
> 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 = Connect OP config
> endoint
>
> ·         OAuth config endpoint - .well-known/openid-configuration =
> 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年1月22日(金) 10:34 Mike Jones <Michael.Jones@microsoft.com>;:
>
> 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
> fails in Google's case -- OR it means that the document is internally
> inconsistent.”.  The issuer definition in draft-jones-oauth-discovery 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 “https://accounts.google.com”.  What is the
> inconsistency that you perceive?
>
>
>
> The discussion of the duplication problem happened in the private meetings
> in Yokohama.
>
>
>
> I will admit, in Yokohama, I didn’t speak up in the public meetings 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 the
> security issues, which we’d decided not to publicly do at that point.  So I
> stayed silent during the poll, out of politeness.  Perhaps I should have
> found a way to say something then anyway, but that’s water under the bridge
> now.
>
>
>
> Finally, for what it’s worth, the HATEOAS stuff reminds me far too much of
> Web Services Description Language (WSDL) – part of the complexity baggage
> that helped sink Web Services.  The use of “link rel” to define an
> interaction vocabulary and publish endpoints for that vocabulary seems
> pretty baroque and reminiscent of “microformats” – another cute “Webby”
> innovation that never caught on.  The industry has pretty much voted with
> its feet and is using JSON for publishing discovery data structures – not
> “link rel”.  I am against us reverting to the “link rel” 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 <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
>
>
>
> 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 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 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 both
> 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 service
> and health care providers.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
>
>
> 2016年1月21日(木) 21:18 Justin Richer <jricher@mit.edu>;:
>
> 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 <Michael.Jones@microsoft.com>;
> wrote:
>
>
>
> My memory of the discussions of the oauth-meta draft in Yokohama were that
> 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 the
> attacks then were in favor of a more targeted, minimal approach.  You were
> listened to in Yokohama, but that didn’t necessarily mean that people
> 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 “less is more”.
>
>
>
> There have also been discussions in the last day about how dynamically
> returning a resource URL, which oauth-meta does, is both unnecessary (since
> 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 – not the other way around.
>
>
>
> I’m not saying that there aren’t some good ideas in the oauth-meta draft –
> I’m 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 – as evidenced in the passion in the
> high-volume “Mix-Up About The Mix-Up Mitigation” 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 <sakimura@gmail.com>]
> *Sent:* Wednesday, January 20, 2016 11:17 PM
> *To:* Mike Jones <Michael.Jones@microsoft.com>;; William Denniss <
> wdenniss@google.com>;; Justin Richer <jricher@mit.edu>;
> *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-up
> 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年1月21日(木) 16:02 Mike Jones <Michael.Jones@microsoft.com>;:
>
> 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 and
> cause compatibility problems – reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-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, and has been since refined based on
> substantial input from the working group.  And at least three implementers
> have already stated that they’ve implemented it.  I’m not saying that it’s,
> 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 draft
> goes too far in that direction, at least as I see it.  Returning things two
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I’ll note that the mix-up-mitigation approach is compatible with existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin’s comment that “It's the pre-configured discovery document that's
> at the root of the mix-up attack in the first place” – this 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 attacks
> 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 <jricher@mit.edu>;
> *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 <jricher@mit.edu>; 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 identified
>
>              as necessary for interoperability since many years but so far there
>
>              was not time to work on it. Mike, John and Nat are working on a new
>
>              document that describes additional discovery-relevant components.
>
>
>
>              Poll: 19 for / zero against / 4 persons need more information.
>
>
>
> 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-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 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年1月20日(水) 12:05 Nat Sakimura <sakimura@gmail.com>;:
>
> 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 recollection
> is correct. Why is it not in the call for adoption?
>
>
>
>
>
>
>
> 2016年1月19日(火) 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/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
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>