Re: [OAUTH-WG] Call for Adoption

I agree that the language describing OAuth issuer could and should be
improved. The text now reads like it is the exact and full URL where the
metadata/discovery document is located. Perhaps something more like "the
URL from which the authorization server's configuration information
location can be derived" and explain that adding the .well-known bits to
the issuer is where the configuration information can actually be found.

On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <sakimura@gmail.com> wrote:

> Re: iss. I discussed this a bit with Nov in more details. It probably is a
> sloppy language of the specs that is making it difficult to read what you
> wanted to achieve.
>
> In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization
> server's configuration information location". In OAuth discovery draft,
> there is something called "OAuth 2.0 Configuration Information Location
> URL", which is equal to "OpenID Connect Issuer".
>
> When I wrote the statement, I thought you were pointing to the URL that
> you can actually pull the configuration information by "the URL of the
> authorizaiton server's configuration information location" since otherwise
> you would have used the term "OAuth 2.0 Configuration Information Location
> URL". But after all, you probably meant these two are the same. Then I
> would strongly recommend to fix the language.
>
> Now, even If that is the case, the relationship like
>
>    - iss + .well-know/openid-configuration = Connect OP config endoint
>    - OAuth config endpoint - .well-known/openid-configuration = OAuth iss
>
> is very confusing.
>
> You also claim that your approach is simpler, but to me, your approach
> seem to be overly complex. It requires discovery and the check for the
> value of the discovered config information to work as the mitigation.
> (Right. Draft -01 does not have it, so it does not solve the mix-up issue.)
> With oauth-meta, you do not need it.
>
> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
> want to have something similar to WSDL in REST API area, it is Swagger.
> (Actually, it is gaining a lot of momentum recently, but that's beside the
> fact ;-). And the point here is not the format but the fact that we need to
> have a way to associate metadata to the data. The root cause of this mix-up
> attack is that the metadata and data is not associated properly. We have a
> standard way of associating the data and metadata with link-rel such as
> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
> modern web pages actually have it. Using a proper way to associate metadata
> with data will save you from a lot of other attacks in the future. Instead
> of doing patch works, we should solve it architecturally.
>
> Nat
>
>
>
> 2016年1月22日(金) 10:34 Mike Jones <Michael.Jones@microsoft.com>:
>
>> Nat, I’m confused by this statement in the message you reference “Unfortunately,
>> this does not match the value of OAuth issuer defined in Section 2
>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>> specified in 3.1. As such, validation as specified in bullet 1 of Section 4
>> fails in Google's case -- OR it means that the document is internally
>> inconsistent.”.  The issuer definition in draft-jones-oauth-discovery is
>> 100% compatible with the one in OpenID Connect Discovery, by design.  In
>> the Google example, both the OpenID issuer and the OAuth issuer values
>> would be the string “https://accounts.google.com”.  What is the
>> inconsistency that you perceive?
>>
>>
>>
>> The discussion of the duplication problem happened in the private
>> meetings in Yokohama.
>>
>>
>>
>> I will admit, in Yokohama, I didn’t speak up in the public meetings to
>> point out that a simpler alternative to oauth-meta was already being
>> discussed there in private, because then I would have had to talk about the
>> security issues, which we’d decided not to publicly do at that point.  So I
>> stayed silent during the poll, out of politeness.  Perhaps I should have
>> found a way to say something then anyway, but that’s water under the bridge
>> now.
>>
>>
>>
>> Finally, for what it’s worth, the HATEOAS stuff reminds me far too much
>> of Web Services Description Language (WSDL) – part of the complexity
>> baggage that helped sink Web Services.  The use of “link rel” to define an
>> interaction vocabulary and publish endpoints for that vocabulary seems
>> pretty baroque and reminiscent of “microformats” – another cute “Webby”
>> innovation that never caught on.  The industry has pretty much voted with
>> its feet and is using JSON for publishing discovery data structures – not
>> “link rel”.  I am against us reverting to the “link rel” proposal from 2008
>> that never caught on when JSON is simpler and does a better job.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
>> *Sent:* Thursday, January 21, 2016 6:24 AM
>> *To:* Justin Richer <jricher@mit.edu>; Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Cc:* William Denniss <wdenniss@google.com>; <oauth@ietf.org> <
>> oauth@ietf.org>
>>
>>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Mike,
>>
>>
>>
>> You just criticize my draft. That's ok, but I would really like to get
>> some response to my questions stated in
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>> me, it just does not seem to work, and the combination of the oauth-meta
>> and PKCE seems to be much more elegan, nicer, and much simpler to
>> implement. If you just give up the dynamic response at the authorization
>> endpoint, then you even do not have to touch the code but just change a
>> config file.
>>
>>
>>
>> Please convince me by answering to my questions.
>>
>>
>>
>> For the record of Yokohama, I do not recall much about duplication in
>> OAuth session. The poll in the room was 19 for / zero against / 4
>> persons need more information. Indeed, it is not duplicating much. And if
>> you move to a new model without pre-configured discovery, it is not
>> duplicating any but the resource endpoint URI, which is optional and is for
>> the cases where the client did not know the concrete resource endpoint to
>> start with.
>>
>>
>>
>> I understand your usecases always start from a concrete endpoint
>> location. Mine do not. In a four party model, it is likely not. The user
>> just want to have the service to fetch his data from some resource
>> endpoint. He just hits the service. He does not hit the resource endpoint
>> directly. For example, in the case of a consumer using a personal finance
>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>> Pension fund. Assuming that the pension fund has delegated the
>> authorization control to the authorization server, then, the authorization
>> server should return both the access token and the endpoint of the pension
>> fund so that the PFP can pull the data using them. A similar model holds
>> for personal health service and health care providers.
>>
>>
>>
>> Best,
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> 2016年1月21日(木) 21:18 Justin Richer <jricher@mit.edu>:
>>
>> Convergence is exactly what I’m arguing for, though. These things ought
>> to work together.
>>
>>
>>
>>  — Justin
>>
>>
>>
>> On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>>
>>
>>
>> My memory of the discussions of the oauth-meta draft in Yokohama were
>> that many people felt that it was unnecessarily dynamically duplicating a
>> lot of information that the client already had.  Most of us that were aware
>> of the attacks then were in favor of a more targeted, minimal approach.
>> You were listened to in Yokohama, but that didn’t necessarily mean that
>> people agreed with the approach.  Participants were already aware of the
>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that I
>> can recall.  Rather, I think people were thinking that “less is more”.
>>
>>
>>
>> There have also been discussions in the last day about how dynamically
>> returning a resource URL, which oauth-meta does, is both unnecessary (since
>> the client initiated the resource authorization already knowing what
>> resource it wants to access) and often problematic, since many
>> authorization servers can authorize access to multiple resources.  If
>> anything, the client should be telling the authorization server what
>> resource it wants to access – not the other way around.
>>
>>
>>
>> I’m not saying that there aren’t some good ideas in the oauth-meta draft
>> – I’m sure there are, just as there are in the approach designed by the
>> participants in Darmstadt.  While I volunteered to write the first draft of
>> the mix-up-mitigation approach, it really reflects something a lot of
>> people have already bought into – as evidenced in the passion in the
>> high-volume “Mix-Up About The Mix-Up Mitigation” thread, and not just my
>> personal project.
>>
>>
>>
>> If you think there are things missing or wrong in the mix-up-mitigation
>> draft, please say what they are.  That will help us quickly converge on a
>> solution that will work for everyone.
>>
>>
>>
>>                                                           Sincerely,
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com <sakimura@gmail.com>]
>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>> *To:* Mike Jones <Michael.Jones@microsoft.com>; William Denniss <
>> wdenniss@google.com>; Justin Richer <jricher@mit.edu>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Hi Mike.
>>
>>
>>
>> Conversely, I would like to ask why this approach does not work for
>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>> quite a length back in Yokohama. I really would like to know why it does
>> not work.
>>
>>
>>
>> Besides, for oauth-meta approach, mix-up attack is only one of the thing
>> it solves.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>> 2016年1月21日(木) 16:02 Mike Jones <Michael.Jones@microsoft.com>:
>>
>> Not to be negative, but I disagree with adopting
>> draft-sakimura-oauth-meta.  We should define and promote one mitigation
>> approach to the mix-up attacks.  Having two would confuse implementers and
>> cause compatibility problems – reducing overall security.
>>
>>
>>
>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>> in collaboration with the security researchers who identified the problems
>> in the first place, was vigorously discussed in the security meeting Hannes
>> and Torsten held in Darmstadt, and has been since refined based on
>> substantial input from the working group.  And at least three implementers
>> have already stated that they’ve implemented it.  I’m not saying that it’s,
>> but if there are things missing or things that need to be improved in our
>> approach, we should do it there, rather introducing a competing approach.
>>
>>
>>
>> Also, standard OAuth deployments register the client and then use the
>> information gathered at registration time for subsequent protocol
>> interactions.  They do not need all the configuration information for the
>> authorization server to be retransmitted at runtime.  The oauth-meta draft
>> goes too far in that direction, at least as I see it.  Returning things two
>> ways creates its own problems, as discussed in the Duplicate Information
>> Attacks security considerations section (7.2) of the mix-up-mitigation
>> draft.
>>
>>
>>
>> I’ll note that the mix-up-mitigation approach is compatible with existing
>> practice in both static and dynamic metadata discovery.  Replying to
>> Justin’s comment that “It's the pre-configured discovery document that's
>> at the root of the mix-up attack in the first place” – this is not the
>> case.  The attacks can be performed without either discovery or dynamic
>> registration.
>>
>>
>>
>> I would be interested in hearing a technical discussion on whether there
>> are aspects of the oauth-meta approach that mitigate aspects of the attacks
>> that the mix-up-mitigation approach does not.  That could help inform
>> whether there are additional things we should add to or change in the
>> mix-up draft.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
>> Denniss
>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>> *To:* Justin Richer <jricher@mit.edu>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> +1 to adopt this, and I agree with Justin's comments.
>>
>>
>>
>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <jricher@mit.edu> wrote:
>>
>> +1
>>
>> Inline discovery and pre-configured discovery (ie, .well-known) should at
>> the very least be compatible and developed together. It's the
>> pre-configured discovery document that's at the root of the mix-up attack
>> in the first place.
>>
>>  -- Justin
>>
>>
>>
>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>
>> Just to give more context, at IETF 94, I have done a presentation on
>> discovery.
>>
>>
>>
>> According to the minutes,
>>
>>
>>
>>     (f) Discovery (Nat)
>>
>>
>>
>>              Nat explains his document as an example of the work that has to be done
>>
>>              in the area of discovery, which is a topic that has been identified
>>
>>              as necessary for interoperability since many years but so far there
>>
>>              was not time to work on it. Mike, John and Nat are working on a new
>>
>>              document that describes additional discovery-relevant components.
>>
>>
>>
>>              Poll: 19 for / zero against / 4 persons need more information.
>>
>>
>>
>> The document discussed there was
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>> simple (only 1-page!) but a very powerful document that nudges towards
>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up
>> attack without introducing the concept of issuer which is not in RFC6749.
>> It is also good for selecting different endpoints depending on the user
>> authentication and authorization results and more privacy sensitive than
>> pre-announced Discovery document. It also allows you to find to which
>> protected resource endpoint you can use the access token against.
>>
>>
>>
>> In the last sentence of the minutes, it talks about "a new document that
>> describes additional discovery-relevant components". This is
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
>> the call for adoption. However, it is only a half of the story. I believe
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>> discussed at IETF 94 and had support there should be adopted as well.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016年1月20日(水) 12:05 Nat Sakimura <sakimura@gmail.com>:
>>
>> Thanks Hannes.
>>
>>
>>
>> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
>> was discussed in Yokohama, and was largely in agreement if my recollection
>> is correct. Why is it not in the call for adoption?
>>
>>
>>
>>
>>
>>
>>
>> 2016年1月19日(火) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
>>
>> Hi all,
>>
>> we have submitted our new charter to the IESG (see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>> since some IESG members like to see an updated list of milestones as
>> well. For this reason, based on a suggestion from Barry, we are also
>> starting a call for adoption concurrently with the review of the charter
>> text by the IESG.
>>
>> We will post separate mails on the individual documents. Your feedback
>> is important! Please take the time to look at the documents and provide
>> your feedback.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>