Re: [OAUTH-WG] Call for Adoption

Nat Sakimura <sakimura@gmail.com> Fri, 22 January 2016 02:25 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 296D71B365C for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 18:25:47 -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 m5hMcKgPb0pa for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 18:25:41 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 5DB841B3659 for <oauth@ietf.org>; Thu, 21 Jan 2016 18:25:41 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id s68so23853770qkh.3 for <oauth@ietf.org>; Thu, 21 Jan 2016 18:25:41 -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=GGM0o4YxHx95GUNNcwH4rVAT9MQ1LivSB984jPl0G00=; b=XkusDrFa83TrwbtxeAJoi7y95i/jNdsx4FOJfPHdfJPIOhvhDnFb0O6CsesLcc/Gr8 GY2/SARq8qeSOZyVvBvP3AtLsOXST/xnR1Yq0/lyCTcQV116wzU+PJ0jt0qCUInrAgYa SUgdY54IA9WBwzj72ivQ5sXidfin5XJzBjmXm+pdqZWtY42PS3uUqO9KPAPgAHFC+I5N VZ9HnKS2IdmcUrULL5H3pumRfiRY0oPUDDKZPVrwsRTueSB90j4XT9uclYvsxq+klil0 87FLHfdPE+jKiD11TnLBkIZ3SOrOO/811TYJFWQiHjVsHSu+zIMj+oxh7/eBmz0Cidvk h1Yw==
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=GGM0o4YxHx95GUNNcwH4rVAT9MQ1LivSB984jPl0G00=; b=TM7z1Lxz3mQcYS6xnehFGRLKHP1gIRoWEfNiVNZYl5QrXvKNtlzaQfgJK7YdqnOek4 NyWEjRhUqFzQ4QNI3fOoiMmpb5ODU4TZQBgCduV72Xv15zrnCvSBwFaEECzBd3gu5f5z Khe29ZPOo/rslfMEGYxeUx4CHfOpeIhrPItwoO7C/HyZEx/D1bfT8JQAzl2xxXijS1Zr U0HMex4Nj5SeIeMurQ8EjTRjloFYQD3hfaB+DGMKW+r5MHLQb+fOMaINUb20QZqPNr54 YwBaTN6dkTsfZu/+NJDT1wreqrpSTJCpTsOoV4+uwlNvFq5FmF6DF+QP0mXIzsPqzHSP Yoew==
X-Gm-Message-State: AG10YOT+fR28UxsgL25i4+ABwJhlWefkDpYPpG4QLWtrz1bpjGFEzlTyf6rBm2vBktDmX1T5C2cDPU031bLxyw==
X-Received: by 10.55.78.207 with SMTP id c198mr698072qkb.34.1453429540470; Thu, 21 Jan 2016 18:25:40 -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> <CAAP42hDvZmxkGb0npCn6ZOD5Xs+xVpg-Z-WmDY944w2B8DkFwg@mail.gmail.com>
In-Reply-To: <CAAP42hDvZmxkGb0npCn6ZOD5Xs+xVpg-Z-WmDY944w2B8DkFwg@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 22 Jan 2016 02:25:31 +0000
Message-ID: <CABzCy2DTa9n2atO6SndLqCp9pXPaEjCjjCVek8z_Snz2ye=uxQ@mail.gmail.com>
To: William Denniss <wdenniss@google.com>, Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a114a7c9c776ad40529e2ef03
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/43fpAS_Y4hMi0uH5dmkb6vWndog>
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: Fri, 22 Jan 2016 02:25:47 -0000

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 contained
a way to return the metadata within JSON (see
https://tools.ietf.org/html/draft-sakimura-oauth-meta-04). RFC5988 works as
long as we are using HTTPS, but once we get to other protocols, it does
not. So we need a way to represent it in native JSON. Swagger is using JSON
Schema way of it. I slightly prefer HAL way of it as you can leverage on
the JSON parser directly, making the code shorter, but I am fine either
way. I removed all those staff from OAuth-meta because that's not oauth
specific, but if people wants it, I can always bring it back.

Also, +1 for your point on "discovery does not solve the question of
authorization-grant specific RS endpoint metadata."

When I gave the idea back in 2012 in the work group meeting, a lot of
people said YES, but we needed complete other stuff and this thing has been
sitting there for 3 years now. IMHO, it should be adopted as a WG item now.
It will save a lot of headache down the road.

Nat

2016年1月22日(金) 11:11 William Denniss <wdenniss@google.com>;:

> These params could also be part of the OAuth2 JSON response payload.
> Perhaps we should evaluate the concept of incremental discovery and how
> it's delivered separately?
>
> Also, discovery does not solve the question of authorization-grant
> specific RS endpoint metadata.
>
> On Fri, Jan 22, 2016 at 9:34 AM, Mike Jones <Michael.Jones@microsoft.com>;
> wrote:
>
>> 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
>>
>>
>>
>>
>