<html><body>
<p><font size="2" face="sans-serif">Hi David,</font><br>
<br>
<font size="2" face="sans-serif">I don't want to derail anything, as there are still open issues in your note; but it's worth mentioning that the session fixation attack issue you mentioned was in OAuth1.0, it was addressed in OAuth1.0a. <br>
<br>
Thanks,<br>
<br>
_____________________________________________<br>
Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
Software Developer - OpenStack<br>
Phone: (905) 413-2851<br>
E-Mail: stevemar@ca.ibm.com</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF13EDFC4E8BE8f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for David Chadwick ---07/19/2013 07:15:35 AM---On 19/07/2013 07:10, Steve Martinelli wrote: > Hi David,"><font size="2" color="#424282" face="sans-serif">David Chadwick ---07/19/2013 07:15:35 AM---On 19/07/2013 07:10, Steve Martinelli wrote: > Hi David,</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">David Chadwick <d.w.chadwick@kent.ac.uk></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Steve Martinelli/Toronto/IBM@IBMCA, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">openstack-dev@lists.openstack.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">07/19/2013 07:15 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2"><br>
<br>
On 19/07/2013 07:10, Steve Martinelli wrote:<br>
> Hi David,<br>
><br>
> This email is long overdue.<br>
><br>
> 1. I don't recall ever stating that we were going to use OAuth 1.0a over<br>
> 2.0, or vice versa. I've checked<br>
> _https://etherpad.openstack.org/havana-saml-oauth-scim_and<br>
> _https://etherpad.openstack.org/havana-external-auth_and couldn't find<br>
> anything that said definitively that we were going to use 2.0.<br>
> OAuth provider implementations (in python) of either version of the<br>
> protocol are few and far between.<br>
<br>
As I recall, there was a presentation from David Waite, Ping Identity, <br>
about OAuth2, and after this it was agreed that OAuth2 would be used as <br>
the generic delegation protocol in OpenStack, and that OAuth1 would only <br>
be used as an alternative to the existing trusts delegation mechanism. <br>
If this is not explicitly recorded in the meeting notes, then we will <br>
need to ask others who were present at the design summit what their <br>
recollections are.<br>
<br>
<br>
><br>
> 2. I think I'm going to regret asking this question... (as I don't want<br>
> to get into a long discussion about OAuth 1.0a vs 2.0), but what are the<br>
> security weaknesses you mention?<br>
<br>
These are documented in RFC 5849 (</font></tt><tt><font size="2"><a href="http://tools.ietf.org/rfc/rfc5849.txt">http://tools.ietf.org/rfc/rfc5849.txt</a></font></tt><tt><font size="2">) <br>
which is presumably the specification of OAuth1 that you are implementing.<br>
<br>
There is also a session fixation attack documented here<br>
</font></tt><tt><font size="2"><a href="http://oauth.net/advisories/2009-1/">http://oauth.net/advisories/2009-1/</a></font></tt><tt><font size="2"><br>
<br>
><br>
> 3. I think you are disagreeing with the consumer requesting roles? And<br>
> are suggesting the consumer should be requesting an authorizing user<br>
> instead? I'm not completely against it, but I'd be interested in what<br>
> others have to say.<br>
<br>
If the use case is to replace trusts, and to allow delegation from a <br>
user to one or more openstack services then yes, it should be the user <br>
who is wanting to launch the openstack service, and not any user who <br>
happens to have the same role as this user. Otherwise a consumer could <br>
get one user to authorise the job of another user, if they have the same <br>
roles.<br>
<br>
If the use case is general delegation, then relating it to Adam's post:<br>
<br>
</font></tt><tt><font size="2"><a href="http://adam.younglogic.com/2013/07/a-vision-for-keystone/">http://adam.younglogic.com/2013/07/a-vision-for-keystone/</a></font></tt><tt><font size="2"><br>
<br>
in order to future proof, the consumer should request authorising <br>
attributes, rather than roles, since as Adam points out, the policy <br>
based authz system is not restricted to using roles.<br>
<br>
><br>
> 4. Regarding the evil consumer; we do not just use the consumer key, the<br>
> magic oauth variables I mentioned also contain oauth_signature, which<br>
> (if you are using a standard oauth client) is the consumers secret (and<br>
> other values) and also hashed.<br>
<br>
This solves one of my problems, because now you are effectively saying <br>
that the consumer has to be pre-registered with Keystone and have a <br>
un/pw allocated to it. I did not see this mentioned in the original <br>
blueprint, and thought (wrongly) that anything could be a consumer <br>
without any pre-registration requirement. So the pre-registration <br>
requirement removes most probability that the consumer can be evil, <br>
since one would hope that the Keystone administrator would check it out <br>
before registering it.<br>
<br>
regards<br>
<br>
david<br>
<br>
<br>
On the server side, we grab the consumer<br>
> entity from our database and recreate the oauth_signature value, then<br>
> verify the request.<br>
><br>
> * If the evil consumer did not provide a provide a secret, (or a wrong<br>
> secret) it would fail on the verify step on the server side<br>
> (signatures wouldn't match).<br>
> * If the evil consumer used his own library, he would still need to<br>
> sign the request correctly (done only with the correct consumer<br>
> key/secret).<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> _____________________________________________<br>
> Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
> Software Developer - OpenStack<br>
> Phone: (905) 413-2851<br>
> E-Mail: stevemar@ca.ibm.com<br>
><br>
> Inactive hide details for David Chadwick ---06/19/2013 04:38:56 PM--- Hi<br>
> Steve On 19/06/2013 20:56, Steve Martinelli wrote:David Chadwick<br>
> ---06/19/2013 04:38:56 PM--- Hi Steve On 19/06/2013 20:56, Steve<br>
> Martinelli wrote:<br>
><br>
> From: David Chadwick <d.w.chadwick@kent.ac.uk><br>
> To: Steve Martinelli/Toronto/IBM@IBMCA,<br>
> Cc: openstack-dev@lists.openstack.org<br>
> Date: 06/19/2013 04:38 PM<br>
> Subject: Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth<br>
> a la Oauth<br>
> ------------------------------------------------------------------------<br>
><br>
><br>
><br>
> Hi Steve<br>
><br>
> On 19/06/2013 20:56, Steve Martinelli wrote:<br>
> > Hey David,<br>
> ><br>
> > 1. and 5. The delegate is not always known to keystone. The delegate (I<br>
> > like to say consumer) would use an oauth client (web-based one here<br>
> > _http://term.ie/oauth/example/client.php_); in an oauth flow, the<br>
> > delegate requires a key/secret pair, they don't have to be already known<br>
> > to keystone. (Apologies if my keystoneclient example led you to believe<br>
> > that)<br>
><br>
> I know that in Oauth the consumer is not always known to the resource<br>
> provider (Keystone) but Oauth has security weaknesses in it which OAuth2<br>
> has fixed. So I would hope we are not going to use Oauth as the general<br>
> delegation model. I thought that the last design summit agreed that<br>
> Oauthv2 should be the right way to go for general delegation, and that<br>
> Oauth was only going to be used to replace Adam's existing delegation<br>
> scheme in which all the entities are known to Keystone.<br>
><br>
> So consider this, where the consumer is not known to Keystone.<br>
> Keystone trusts the user, and the user trusts the consumer to access his<br>
> resources on Keystone/OpenStack. Keystone has no idea who the consumer<br>
> is. Now we all know that users are easily tricked by spear phishing,<br>
> spam and the rest into trusting evil sites, so an evil consumer tricks<br>
> the user and now OpenStack is open to abuse as the naive user has given<br>
> his privileges away to an evil consumer. Surely you cannot be saying<br>
> that we should build support for this into OpenStack and Keystone are you?<br>
><br>
> So I would propose that the OAuth delegation system you are building is<br>
> restricted to only work with entities that are already known to Keystone<br>
> and have been registered there by trusted administrators, who should be<br>
> much more difficult to trick than naive users. In other words, Keystone<br>
> should not provide full unrestricted support for OAuth delegation, that<br>
> should be reserved for OAuthv2 (or whatever the group decides).<br>
><br>
> ><br>
> > 3. The authorizing step happens later on, 1e; any user with sufficient<br>
> > credentials (the role matching the requested role), can authorize the<br>
> > request token. If you don't expect the delegate to have knowledge of<br>
> > roles, they shouldn't have knowledge of users either; so specifying one<br>
> > wouldn't make things easier.<br>
><br>
> The delegate/consumer has knowledge of the user (delegator) since it is<br>
> in direct communication with him/her. (They have to be in order for the<br>
> secret to be passed between themselves). The delegate does not a priori<br>
> have any knowledge of what should be delegated to it (the role). Only<br>
> the delegator knows this. So I do not follow your logic.<br>
><br>
><br>
> ><br>
> > 2. Continuing with my previous answer, to authorize a request token, the<br>
> > requested role would have to be a subset of the delegator roles.<br>
> > Otherwise any user could authorize the token.<br>
><br>
> We are agreed on this point, for sure.<br>
><br>
><br>
> ><br>
> > 4. When using an oauth client, the delegate would input both the key and<br>
> > secret; the client would then sign the request and send only the key and<br>
> > *other oauth specific variables* over to the server side.<br>
> ><br>
><br>
> this worries me a bit. Consider the case of the evil consumer again, who<br>
> is not using any standard oauth client software, but is using his own.<br>
> We have to make sure that the protocol exchange strongly authenticates<br>
> the consumer, and I dont see how your exchange does this with only the<br>
> username/key and some unspecified magic oauth variables.<br>
><br>
> The last thing we want to do is knowingly introduce security<br>
> vulnerabilities into Keystone<br>
><br>
> regards<br>
><br>
> David<br>
><br>
> ><br>
> > Thanks,<br>
> ><br>
> > _____________________________________________<br>
> > Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
> > Software Developer - OpenStack<br>
> > Phone: (905) 413-2851<br>
> > E-Mail: stevemar@ca.ibm.com<br>
> ><br>
> > Inactive hide details for David Chadwick ---06/14/2013 10:45:34 AM---Hi<br>
> > Steve Can I ask a few questions about this pleaseDavid Chadwick<br>
> > ---06/14/2013 10:45:34 AM---Hi Steve Can I ask a few questions about<br>
> > this please<br>
> ><br>
> > From: David Chadwick <d.w.chadwick@kent.ac.uk><br>
> > To: OpenStack Development Mailing List<br>
> <openstack-dev@lists.openstack.org>,<br>
> > Cc: Steve Martinelli/Toronto/IBM@IBMCA<br>
> > Date: 06/14/2013 10:45 AM<br>
> > Subject: Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth<br>
> > a la Oauth<br>
> ><br>
> > ------------------------------------------------------------------------<br>
> ><br>
> ><br>
> ><br>
> > Hi Steve<br>
> ><br>
> > Can I ask a few questions about this please<br>
> ><br>
> > 1. Step 0b. Why do we need a new consumers table containing essentially<br>
> > un/pw pairs for the delegate (called key/secret in the spec) when the<br>
> > delegate is already known to keystone and can authenticate using its<br>
> > existing credentials?<br>
> ><br>
> > 2. Step 1b. How does the delegate know which role to request? This is<br>
> > unintuitive. A delegator (rather than delegate) knows the role he wants<br>
> > to delegate. One would normally expect the delegator to request Keystone<br>
> > to delegate this role to the named delegate, rather than the delegate<br>
> > asking for a role to be delegated to it, since it requires an out of<br>
> > band communications between the delegator and delegate to take place<br>
> > before the delegation, in which the delegator tells the delegate its<br>
> > un/pw and the role it should ask for. This seems to be a rather<br>
> > contrived exchange of messages.<br>
> ><br>
> > 3. Step 1b. Why does the delegate not specify who should do the<br>
> > delegation?. This is another unintuitive feature. A delegate would not<br>
> > normally simply ask a service to give it a role, since the service is<br>
> > not empowered to do this. It has to be the existing role holder (the<br>
> > delegator) who has to authorise this, but in step 1b the delegator is<br>
> > not mentioned.<br>
> ><br>
> > 4. In step 1b the delegate is only authenticating itself via its<br>
> > username/key, and this was specified by the delegator when he created<br>
> > the new consumer in step 0b. So the delegator could have used a simple<br>
> > name/key like Fred, which means that it would then be very easy for<br>
> > anyone to masquerade as the delegate. Wouldnt it be better to require<br>
> > both the un/pw (key/secret) in this exchange rather than simply the key?<br>
> > The same security weakness is in step 1f as well.<br>
> ><br>
> > 5. What is the purpose of having the delegate's secret?<br>
> ><br>
> > regards<br>
> ><br>
> > David<br>
> ><br>
> ><br>
> > On 14/06/2013 14:31, Steve Martinelli wrote:<br>
> > > Greetings!<br>
> > ><br>
> > > I've implemented the following blueprint for keystone: Delegated<br>
> Auth a<br>
> > > la Oauth [1<br>
> > ><br>
> ><br>
> <</font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth">https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth</a></font></tt><tt><font size="2">>].<br>
> > > The original spec [2 <</font></tt><tt><font size="2"><a href="https://gist.github.com/termie/5225817">https://gist.github.com/termie/5225817</a></font></tt><tt><font size="2">>] has a<br>
> > > use case to help understand why we are providing this ability in<br>
> > Keystone.<br>
> > > If you're familiar with keystone, or just familiar with Oauth, I'd<br>
> > > really appreciate your input. There are two change sets; a keystone<br>
> > > patch [3 <</font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/29130/">https://review.openstack.org/#/c/29130/</a></font></tt><tt><font size="2">>] and keystoneclient<br>
> > > patch [4 <</font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/30043/">https://review.openstack.org/#/c/30043/</a></font></tt><tt><font size="2">>].<br>
> > ><br>
> > > Thanks!<br>
> > ><br>
> > > References:<br>
> > > 1.<br>
> > </font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth">https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth</a></font></tt><tt><font size="2"><br>
> > > 2. </font></tt><tt><font size="2"><a href="https://gist.github.com/termie/5225817">https://gist.github.com/termie/5225817</a></font></tt><tt><font size="2"><br>
> > > 3. </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/29130/">https://review.openstack.org/#/c/29130/</a></font></tt><tt><font size="2"><br>
> > > 4. </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/30043/">https://review.openstack.org/#/c/30043/</a></font></tt><tt><font size="2"><br>
> > ><br>
> > ><br>
> > > Thanks,<br>
> > ><br>
> > > _____________________________________________<br>
> > > Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
> > > Software Developer - OpenStack<br>
> > > Phone: (905) 413-2851<br>
> > > E-Mail: stevemar@ca.ibm.com<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > OpenStack-dev@lists.openstack.org<br>
> > > </font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
<br>
</font></tt><br>
</body></html>