<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/02/2012 01:56 AM, Joseph Heck wrote:
<blockquote cite="mid:0057FA99-322E-405E-A999-753ECAC1E811@me.com"
type="cite">
<div>Hey Maru,</div>
<div><br>
</div>
<div>I think you're putting too many words in Adam's mouth here.
First, Adam didnt assert is wasnt valuable, useful, or nessecary
- simply that it wasnt in the first cut and not in the list that
we agreed was critically essential to an initial implementation.
As you noted, its a complex and somewhat tricky issue to get
right.</div>
<div><br>
</div>
<div>There's always room for more participation to correct the
flaws you see in the existing system - the beauty of open
source. I would love to see continued work on the signing and
revocation work to drive in these features that mean so much to
you. I'd be happy to open a blueprint if you can stand behind
it, define what you think it required, and commit to the work to
implement that revocation mechanism.</div>
<div><br>
</div>
<div>Implying negative emotions on Adam's part when he's been one
driving the implementation and doing the work is simply
inappropriate. Please consider the blueprint route, definition
of a viable solution, and work to make it happen instead of name
calling and asserting how the developers doing the work are
screwing up.</div>
</blockquote>
<br>
Thanks for the support Joe. I don't think Maru was being too
harsh. So long as he doesn't start calling me "Sir" as that is
always an followed by "you are making a scene."<br>
<blockquote cite="mid:0057FA99-322E-405E-A999-753ECAC1E811@me.com"
type="cite">
<div><br>
- joe</div>
<div><br>
On Aug 1, 2012, at 8:05 PM, Maru Newby <<a
moz-do-not-send="true" href="mailto:mnewby@internap.com">mnewby@internap.com</a>>
wrote:<br>
</div>
<blockquote type="cite">
<div>
<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>
<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>
</blockquote>
</blockquote>
I think you have valid concerns. Realistically, I think 5 minutes
is too short, and for many operations, 24 hours would be the right
granularity. However, The timespan of the tokens is configurable,
and the policy of the deploying organization should dictate.<br>
<br>
Remember, this is the administrative interface for virtual machines,
and not the applications running in them. Removing someone from
access to creating/rebooting/destroying virtual machines is a much
more deliberate decision than banning someone from a public forum.
Aside from someone getting fired, I am not sure how essential it is
that we have rapid revocation of tokens. And firing someone is
usually part of the whole "escort from the building" routine.<br>
<br>
So, let me put the onus on you: make the argument for rapid
revocation of tokens.<br>
<br>
<br>
<blockquote cite="mid:0057FA99-322E-405E-A999-753ECAC1E811@me.com"
type="cite">
<blockquote type="cite">
<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>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></span><br>
<span>Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></span><br>
<span>Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></span><br>
<span>More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>