Re: [OAUTH-WG] Call for Adoption

[George Fletcher <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>>:
>
>         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:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* Friday, January 22, 2016 3:26 PM
>         *To:* Nat Sakimura <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Mike Jones <[e-mail]
>         <mailto:[e-mail]>>; Justin Richer
>         <[e-mail] <mailto:[e-mail]>>; <[e-mail]
>         <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>
>
>
>         *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
>         <[e-mail] <mailto:[e-mail]>> 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
>             <[e-mail]
>             <mailto:[e-mail]>>:
>
>                 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:[e-mail]
>                 <mailto:[e-mail]>]
>                 *Sent:* Thursday, January 21, 2016 6:24 AM
>                 *To:* Justin Richer <[e-mail]
>                 <mailto:[e-mail]>>; Mike Jones
>                 <[e-mail]
>                 <mailto:[e-mail]>>
>                 *Cc:* William Denniss <[e-mail]
>                 <mailto:[e-mail]>>; <[e-mail]
>                 <mailto:[e-mail]>> <[e-mail]
>                 <mailto:[e-mail]>>
>
>
>                 *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 <[e-mail]
>                 <mailto:[e-mail]>>:
>
>                     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
>                         <[e-mail]
>                         <mailto:[e-mail]>> 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:[e-mail]]
>                         *Sent:* Wednesday, January 20, 2016 11:17 PM
>                         *To:* Mike Jones <[e-mail]
>                         <mailto:[e-mail]>>; William
>                         Denniss <[e-mail]
>                         <mailto:[e-mail]>>; Justin Richer
>                         <[e-mail] <mailto:[e-mail]>>
>                         *Cc:* [e-mail] <mailto:[e-mail]>
>                         *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
>                         <[e-mail]
>                         <mailto:[e-mail]>>:
>
>                             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:[e-mail]
>                             <mailto:[e-mail]>] *On
>                             Behalf Of *William Denniss
>                             *Sent:* Wednesday, January 20, 2016 10:37 PM
>                             *To:* Justin Richer <[e-mail]
>                             <mailto:[e-mail]>>
>                             *Cc:* [e-mail] <mailto:[e-mail]>
>                             *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 <[e-mail]
>                             <mailto:[e-mail]>> 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 <[e-mail]
>                                     <mailto:[e-mail]>>:
>
>                                         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
>                                         <[e-mail]
>                                         <mailto:[e-mail]>>:
>
>                                             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
>                                             [e-mail]
>                                             <mailto:[e-mail]>
>                                             https://www.ietf.org/mailman/listinfo/oauth
>
>                                     _______________________________________________
>
>                                     OAuth mailing list
>
>                                     [e-mail] <mailto:[e-mail]>
>
>                                     https://www.ietf.org/mailman/listinfo/oauth
>
>
>                                 _______________________________________________
>                                 OAuth mailing list
>                                 [e-mail] <mailto:[e-mail]>
>                                 https://www.ietf.org/mailman/listinfo/oauth
>
>                             _______________________________________________
>                             OAuth mailing list
>                             [e-mail] <mailto:[e-mail]>
>                             https://www.ietf.org/mailman/listinfo/oauth
>
>
>             _______________________________________________
>             OAuth mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth