Re: [OAUTH-WG] Call for Adoption

[Mike Jones <[e-mail]>]

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]>; William Denniss <[e-mail]>; Justin Richer <[e-mail]>
Cc: [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