<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/02/2012 10:54 PM, Nathanael Burton wrote:
<blockquote
cite="mid:CAHTGUNSVSHW7GZXi_HrsH+4znxKscBOBaK1V81ga6i89dKgcGg@mail.gmail.com"
type="cite">
<p>Adam, </p>
<p>I haven't yet had a chance to review how the new PKI signed
tokens is implemented, but what you're describing sounds quite
similar to online certificate status protocol (OCSP) but for
tokens. </p>
</blockquote>
<br>
Yes, I don't really have new idea here, just reimplementaiton of
ideas from other projects.<br>
<br>
<blockquote
cite="mid:CAHTGUNSVSHW7GZXi_HrsH+4znxKscBOBaK1V81ga6i89dKgcGg@mail.gmail.com"
type="cite">
<p>Nate</p>
<div class="gmail_quote">On Aug 2, 2012 10:24 PM, "Adam Young"
<<a moz-do-not-send="true" href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> On 08/01/2012 11:05 PM,
Maru Newby wrote:
<blockquote 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 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>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> On 08/01/2012
09:19 PM, Maru Newby wrote:
<blockquote 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"
target="_blank">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/"
target="_blank">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 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></fieldset>
<br>
<pre>_______________________________________________
Mailing list: <a moz-do-not-send="true" href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a>
Post to : <a moz-do-not-send="true" href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>
Unsubscribe : <a moz-do-not-send="true" href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a>
More help : <a moz-do-not-send="true" href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net"
target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack"
target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp"
target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack" target="_blank">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" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>