<html><body>
<p><font size="2" face="sans-serif">Hi David,</font><br>
<br>
<font size="2" face="sans-serif">This email is long overdue. </font><br>
<br>
<font size="2" face="sans-serif">1. I don't recall ever stating that we were going to use OAuth 1.0a over 2.0, or vice versa. I've checked </font><a href="https://etherpad.openstack.org/havana-saml-oauth-scim"><font size="3" color="#0000FF" face="serif"><u>https://etherpad.openstack.org/havana-saml-oauth-scim</u></font></a><font size="3" face="serif"> </font><font size="2" face="sans-serif">and </font><a href="https://etherpad.openstack.org/havana-external-auth"><font size="3" color="#0000FF" face="serif"><u>https://etherpad.openstack.org/havana-external-auth</u></font></a><font size="3" face="serif"> </font><font size="2" face="sans-serif">and couldn't find anything that said definitively that we were going to use 2.0. </font><br>
<font size="2" face="sans-serif">OAuth provider implementations (in python) of either version of the protocol are few and far between.</font><br>
<br>
<font size="2" face="sans-serif">2. I think I'm going to regret asking this question... (as I don't want to get into a long discussion about OAuth 1.0a vs 2.0), but what are the security weaknesses you mention?</font><br>
<br>
<font size="2" face="sans-serif">3. I think you are disagreeing with the consumer requesting roles? And are suggesting the consumer should be requesting an authorizing user instead? I'm not completely against it, but I'd be interested in what others have to say. </font><br>
<br>
<font size="2" face="sans-serif">4. Regarding the evil consumer; we do not just use the consumer key, the magic oauth variables I mentioned also contain oauth_signature, which (if you are using a standard oauth client) is the consumers secret (and other values) and also hashed. On the server side, we grab the consumer entity from our database and recreate the oauth_signature value, then verify the request. </font>
<ul type="disc" style="padding-left: 36pt">
<li><font size="2" face="sans-serif">If the evil consumer did not provide a provide a secret, (or a wrong secret) it would fail on the verify step on the server side (signatures wouldn't match).</font>
<li><font size="2" face="sans-serif">If the evil consumer used his own library, he would still need to sign the request correctly (done only with the correct consumer key/secret).</font></ul>
<font size="2" face="sans-serif"><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__=0ABBF13EDFB2087B8f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for David Chadwick ---06/19/2013 04:38:56 PM--- Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote:"><font size="2" color="#424282" face="sans-serif">David Chadwick ---06/19/2013 04:38:56 PM--- Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote:</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">06/19/2013 04:38 PM</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"> 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 <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 Auth a<br>
> > la Oauth [1<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>
</font></tt><br>
</body></html>