Re: [OAUTH-WG] Call for Adoption
Hans Zandbelt <hzandbelt@pingidentity.com> Wed, 27 January 2016 08:01 UTC
Return-Path: <hzandbelt@pingidentity.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 0F87D1B356D for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 00:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sZ78aHL88YCW for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 00:01:21 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D93881B356B for <oauth@ietf.org>; Wed, 27 Jan 2016 00:01:20 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id n5so13351137wmn.0 for <oauth@ietf.org>; Wed, 27 Jan 2016 00:01:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=1ifCgI8aRU5Q6b6+gvPqVUhj3DZA2Qkn2qcnPAryZnA=; b=Did04DOxQvGX7yJSUM7qwjZanGh/paVU4OqmOIfo4eznARYgaVMXbtN4qerw+cgjh3 U1vq1Nw3dJEBo4UR6KaTJxomAk9BdIl64T+xYpObQ/09paIqJGuZPBLwZ2+Aw6mqS76J FTQ+shpepYYJ15kU84frMWYLKBscg/i9Jfxxw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=1ifCgI8aRU5Q6b6+gvPqVUhj3DZA2Qkn2qcnPAryZnA=; b=CPxjlcToHo1ktTna/hFBj8AIrOjjAjEZiEX4itXIfuqIsZAAlNabvVm4+YFUgCMBkl EAtNmwu4IFEKlc8ThqZmu4zN2KkruCYmL3XQNFoQtztaUVapGS9lyeEEFPwjc1GmrthH P98tkniXXzPMSi4enkemGhXnAPCa9Q7CGXALtTxdiQDvqIt3ytTrWYWAGEB1PEMxOQm9 quCoEyB4hOajVjY/yuCqdtuIIu9qHQjrDMuA4cSbZa6UQwy3j+TxOBzMA61YAdCGYCmP /+DpayALi+ofzbaej+rnz790M7zDT5fwn3vm0M0yXUWcslAeMJxs6FZgMRZd1SK8tCkw vL/Q==
X-Gm-Message-State: AG10YOS2bjjhv5VlWFWvBsnBfkC7Oo2ognRXvx0/S15bMTedKEPF2eLSK8+4RipfJYijixtD
X-Received: by 10.28.137.213 with SMTP id l204mr30368666wmd.100.1453881679414; Wed, 27 Jan 2016 00:01:19 -0800 (PST)
Received: from [192.168.1.95] (host-92-27-103-110.static.as13285.net. [92.27.103.110]) by smtp.gmail.com with ESMTPSA id 198sm6327935wml.22.2016.01.27.00.01.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 00:01:17 -0800 (PST)
To: Nat Sakimura <sakimura@gmail.com>, Brian Campbell <bcampbell@pingidentity.com>, George Fletcher <gffletch@aol.com>
References: <569E2076.2090405@gmx.net> <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> <CABzCy2CC8jN6kzxbJ70m900g4J1VW2b65gM_M1dhx6YXfWVhdQ@mail.gmail.com> <CA+k3eCSiEcE-YRG+ej+zJuEHOwqO4oyvvGmKWv5SeMUu4dVPrA@mail.gmail.com> <56A78EEF.4090706@aol.com> <CA+k3eCQh+KfX8+NONECjVj2ZX_e=JFFM4fF7XXcxwWJ-kii9Tw@mail.gmail.com> <56A7C3E8.8080601@aol.com> <CA+k3eCREJUx4Mb_aciKJoq03j0tdmwB2LEPw7GvZA1ZOBNhq+w@mail.gmail.com> <CABzCy2C69JAadYfaZNXgfMaAiJJOuXoKGkC3vC+x8KnhXPHpKw@mail.gmail.com>
From: Hans Zandbelt <hzandbelt@pingidentity.com>
Message-ID: <56A8794C.2040304@pingidentity.com>
Date: Wed, 27 Jan 2016 08:01:16 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CABzCy2C69JAadYfaZNXgfMaAiJJOuXoKGkC3vC+x8KnhXPHpKw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/R-TceJNSbqarAdArYdA7RvJF1WQ>
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: Wed, 27 Jan 2016 08:01:26 -0000
I don't see how that can deal with the specific form of the attack where the Client would have sent the authorization request to the legitimate authorization endpoint of a compromised AS and believes it gets the response from that, where in fact it was redirected away to the good AS. IOW, I don't think this is so much about mixing up endpoints where to send stuff to, but mixing up the entity/endpoint from which the Client believes the response was received. That may just be terminology though. Bottom line as far as I see is that a wire protocol element in the response is needed to tell the Client who issued it, regardless of how the Client deals with configuration of the AS information. Hans. On 1/27/16 1:31 AM, Nat Sakimura wrote: > So, is there a lot of cases that the authority section of the Good AS's > Authorization Endpoint and the Token Endpoints are different? > If not, then requiring that they are the same seems to virtually remove > the attack surface for the mix-up related attacks. It does not introduce > new parameter nor discovery. If it can be done, it probably is not worth > adding a new wire protocol element to mitigate the mix-up variants. > > > > 2016年1月27日(水) 4:44 Brian Campbell <bcampbell@pingidentity.com > <mailto:bcampbell@pingidentity.com>>: > > I understand what you're saying but disagree with the premise. > > On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> wrote: > > So I'm fine with not requiring discovery in the simple case of > an RS supporting a single AS. However, once the RS moves to > supporting multiple authorization servers then I believe that > discovery based on the 'iss' string is required. The discovery > results can be cached so a discovery lookup per transaction is > not required. > > Thanks, > George > > On 1/26/16 1:58 PM, Brian Campbell wrote: > >> I'm staying that it's sufficiently unlikely that it shouldn't >> be part of the threat model and that a discovery lookup on iss >> isn't necessary. >> >> >> On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher >> <gffletch@aol.com <mailto:gffletch@aol.com>> wrote: > >> While it's a different way of getting the endpoints mixed >> up, I don't think that makes it invalid. If we are going >> to address the attack vector I believe we should solve it >> for "all" cases not just the ones that seem most likely. >> >> Thanks, >> George >> >> On 1/26/16 8:37 AM, Brian Campbell wrote: > >>> I'm not sure what's described in the blog post is >>> actually a variant of an attack that anyone is really >>> concerned about? A client developer would have to change >>> a production system to use an unfamiliar value for the >>> token endpoint based solely on a an email without even >>> looking at service documentation or metadata. >>> >>> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura >>> <<mailto:sakimura@gmail.com>sakimura@gmail.com >>> <mailto:sakimura@gmail.com>> wrote: > >>> 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 >>> <mailto: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:<mailto:bcampbell@pingidentity.com>bcampbell@pingidentity.com >>> <mailto:bcampbell@pingidentity.com>] >>> *Sent:* Friday, January 22, 2016 3:26 PM >>> *To:* Nat Sakimura >>> <<mailto:sakimura@gmail.com>sakimura@gmail.com >>> <mailto:sakimura@gmail.com>> >>> *Cc:* Mike Jones >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto:Michael.Jones@microsoft.com>>; Justin >>> Richer <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto:jricher@mit.edu>>; <oauth@ietf.org >>> <mailto:oauth@ietf.org>> <oauth@ietf.org >>> <mailto: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 >>> <<mailto:sakimura@gmail.com>sakimura@gmail.com >>> <mailto: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 >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto: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>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:<mailto:sakimura@gmail.com>sakimura@gmail.com >>> <mailto:sakimura@gmail.com>] >>> *Sent:* Thursday, January 21, 2016 6:24 AM >>> *To:* Justin Richer >>> <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto:jricher@mit.edu>>; Mike Jones >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto:Michael.Jones@microsoft.com>> >>> *Cc:* William Denniss >>> <<mailto:wdenniss@google.com>wdenniss@google.com >>> <mailto:wdenniss@google.com>>; >>> <<mailto:oauth@ietf.org>oauth@ietf.org >>> <mailto:oauth@ietf.org>> >>> <<mailto:oauth@ietf.org>oauth@ietf.org >>> <mailto: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>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 >>> <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto: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 >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto: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>mailto:sakimura@gmail.com] >>> >>> *Sent:* Wednesday, January 20, >>> 2016 11:17 PM >>> *To:* Mike Jones >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto:Michael.Jones@microsoft.com>>; >>> William Denniss >>> <<mailto:wdenniss@google.com>wdenniss@google.com >>> <mailto:wdenniss@google.com>>; >>> Justin Richer >>> <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto:jricher@mit.edu>> >>> *Cc:* >>> <mailto:oauth@ietf.org>oauth@ietf.org >>> <mailto: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 >>> <<mailto:Michael.Jones@microsoft.com>Michael.Jones@microsoft.com >>> <mailto: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:<mailto:oauth-bounces@ietf.org>oauth-bounces@ietf.org >>> <mailto:oauth-bounces@ietf.org>] >>> *On Behalf Of *William Denniss >>> *Sent:* Wednesday, January >>> 20, 2016 10:37 PM >>> *To:* Justin Richer >>> <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto:jricher@mit.edu>> >>> *Cc:* >>> <mailto:oauth@ietf.org>oauth@ietf.org >>> <mailto: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 >>> <<mailto:jricher@mit.edu>jricher@mit.edu >>> <mailto: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><https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>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>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>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 >>> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity
- [OAUTH-WG] Call for Adoption Hannes Tschofenig
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption William Denniss
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption William Denniss
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Hans Zandbelt
- Re: [OAUTH-WG] Call for Adoption sakimura
- Re: [OAUTH-WG] Call for Adoption John Bradley
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Antonio Sanso
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption John Bradley
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura