<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/01/2012 11:05 PM, Maru Newby wrote:
<blockquote
cite="mid:1685849A-66D1-4C28-82A5-E76FC6A23C27@internap.com"
type="cite">
<div>Hi Adam,</div>
<div><br>
</div>
<div>I apologize if my questions were answered before. I wasn't
aware that what I perceive as a very serious security concern
was openly discussed. The arguments against revocation support,
as you've described them, seem to be:</div>
<div><br>
</div>
<div> - it's complicated/messy/expensive to implement and/or
execute</div>
<div> - Kerberos doesn't need it, so why would we?</div>
<div><br>
</div>
<div>I'm not sure why either of these arguments would justify the
potential security hole that a lack of revocation represents,
but I suppose a 'short enough' token lifespan could minimize
that hole. But how short a span are you suggesting as being
acceptable?</div>
<div><br>
</div>
<div>The delay between when a user's access permissions change
(whether roles, password or even account deactivation) and when
the ticket reflects that change is my concern. The default in
Keystone has been 24h, which is clearly too long. Something on
the order of 5 minutes would be ideal, but then ticket issuance
could become the bottleneck. Validity that's much longer could
be a real problem, though. Maybe not at the cloud
administration level, but for a given project I can imagine
someone being fired and their access being revoked. How long is
an acceptable period for that ticket to still be valid? How
much damage could be done by someone who should no longer have
access to an account if their access cannot be revoked, by
anyone, at all?</div>
</blockquote>
<br>
<br>
I realize that I had been thinking about the revocation list as
something that needs to be broadcast. This is certainly not the
case.<br>
<br>
A much better approach would be for the Keystone server to have a
list of revoked tokens exposed in an URL. Then, as service like
Glance or Nova can query the Revocation list on a simple schedule.
The time out would be configurable, of course.<br>
<br>
There is a question about what to do if the keystone server cannot
be reached during that interval. Since the current behavior is for
authentication to fail, I suppose we would continue doing that,
but also wait a random amount of time and then requery the Keystone
server.<br>
<br>
In the future, I would like to make the set of Keystone servers a
configurable list, and the policy for revocation checking should be
able to vary per server: some Keystone servers in a federated
approach might not be accessible. In those cases, it might be
necessary for one Keystone server to proxy the revocation list for
another server.<br>
<br>
Let me know if this scheme makes sense to you. If so, we can write
it up as an additional blueprint. It should not be that hard to
implement.<br>
<br>
<br>
<blockquote
cite="mid:1685849A-66D1-4C28-82A5-E76FC6A23C27@internap.com"
type="cite">
<div><br>
</div>
<div>I'm hearing that you, as the implementer of this feature,
don't consider the lack of revocation to be an issue. What am I
missing? Is support for revocation so repugnant that the
potential security hole is preferable? I can see that from a
developer's perspective, but I don't understand why someone
deploying Keystone wouldn't avoid PKI tokens until revocation
support became available.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div><br>
</div>
<div>Maru </div>
<div> </div>
<div><br>
</div>
<br>
<div>
<div>On 2012-08-01, at 9:47 PM, Adam Young wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> On 08/01/2012 09:19 PM,
Maru Newby wrote:
<blockquote
cite="mid:71BD4F07-1B97-46E4-BF67-08BB8B765A5B@internap.com"
type="cite">I see that support for PKI Signed Tokens has
been added to Keystone without support for token
revocation. I tried to raise this issue on the bug
report:
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://bugs.launchpad.net/keystone/+bug/1003962/comments/4">https://bugs.launchpad.net/keystone/+bug/1003962/comments/4</a></div>
<div><br>
</div>
<div>And the review:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://review.openstack.org/#/c/7754/">https://review.openstack.org/#/c/7754/</a></div>
<div><br>
</div>
<div>I'm curious as to whether anybody shares my concern
and if there is a specific reason why nobody responded
to my question as to why revocation is not required for
this new token scheme. Anybody?</div>
</blockquote>
<br>
It was discussed back when I wrote the Blueprint. While it
is possible to do revocations with PKI, it is expensive and
requires a lot of extra checking. Revocation is a policy
decision, and the assumption is that people that are going
to use PKI tokens are comfortable with out revocation.
Kerberos service tickets have the same limitation, and
Kerberos has been in deployment that way for close to 25
years.<br>
<br>
Assuming that PKI ticket lifespan is short enough,
revocation should not be required. What will be tricky is
to balance the needs of long lived tokens (delayed
operations, long running operations) against the needs for
reasonable token timeout.<br>
<br>
PKI Token revocation would look like CRLs in the Certificate
world. While they are used, they are clunky. Each time a
token gets revoked, a blast message would have to go out to
all registered parties informing them of the revocation.
Keystone does not yet have a message queue interface, so
doing that is prohibitive in the first implementation.<br>
<br>
Note that users can get disabled, and token chaining will no
longer work: you won't be able to use a token to get a new
token from Keystone.<br>
<br>
<br>
<blockquote
cite="mid:71BD4F07-1B97-46E4-BF67-08BB8B765A5B@internap.com"
type="cite">
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div><br>
</div>
<div>Maru</div>
<div><br>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
Post to : <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
More help : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>