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