Re: [OAUTH-WG] Call for Adoption

[Brian Campbell <[e-mail]>]

I understand what you're saying but disagree with the premise.

On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <[e-mail]> 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 <[e-mail]> 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 < <[e-mail]>
>> [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]>:
>>>
>>>> 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]>
>>>> [e-mail]]
>>>> *Sent:* Friday, January 22, 2016 3:26 PM
>>>> *To:* Nat Sakimura < <[e-mail]>[e-mail]>
>>>> *Cc:* Mike Jones < <[e-mail]>
>>>> [e-mail]>; Justin Richer < <[e-mail]>
>>>> [e-mail]>; <[e-mail]> <[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]>
>>>> [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]>
>>>> [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>
>>>> 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]>[e-mail]]
>>>> *Sent:* Thursday, January 21, 2016 6:24 AM
>>>> *To:* Justin Richer < <[e-mail]>[e-mail]>; Mike Jones <
>>>> <[e-mail]>[e-mail]>
>>>> *Cc:* William Denniss < <[e-mail]>[e-mail]>; <
>>>> <[e-mail]>[e-mail]> < <[e-mail]>[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>
>>>> 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]>[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]>
>>>> [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 [ <[e-mail]>mailto:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>>>> *To:* Mike Jones < <[e-mail]>
>>>> [e-mail]>; William Denniss < <[e-mail]>
>>>> [e-mail]>; Justin Richer < <[e-mail]>[e-mail]>
>>>> *Cc:* <[e-mail]>[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]>
>>>> [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]>[e-mail]] *On
>>>> Behalf Of *William Denniss
>>>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>>>> *To:* Justin Richer < <[e-mail]>[e-mail]>
>>>> *Cc:* <[e-mail]>[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]>
>>>> [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>
>>>> <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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016年1月20日(水) 12:05 Nat Sakimura < <[e-mail]>
>>>> [e-mail]>:
>>>>
>>>> Thanks Hannes.
>>>>
>>>>
>>>>
>>>> I did not find
>>>> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>
>>>> 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]>
>>>> [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>
>>>> 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]>[e-mail]
>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> [e-mail]
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> <[e-mail]>[e-mail]
>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> <[e-mail]>[e-mail]
>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
> --
> Chief Architect
> Identity Services Engineering     Work: [e-mail]
> AOL Inc.                          AIM:  gffletch
> Mobile: [phone]           Twitter: http://twitter.com/gffletch
> Office: [phone]           Photos: http://georgefletcher.photography
>
>