Open Stack

On 08/02/2012 10:54 PM, Nathanael Burton wrote:
>
> Adam,
>
> 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.
>

Yes, I don't really have new idea here, just reimplementaiton of ideas 
from other projects.

> Nate
>
> On Aug 2, 2012 10:24 PM, "Adam Young" <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 08/01/2012 11:05 PM, Maru Newby wrote:
>>     Hi Adam,
>>
>>     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:
>>
>>      - it's complicated/messy/expensive to implement and/or execute
>>      - Kerberos doesn't need it, so why would we?
>>
>>     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?
>>
>>     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?
>
>
>     I realize that I had been thinking about the revocation list as
>     something that needs to be broadcast.  This is certainly not the case.
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>
>>
>>     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.
>>
>>     Thanks,
>>
>>
>>     Maru
>>
>>
>>     On 2012-08-01, at 9:47 PM, Adam Young wrote:
>>
>>>     On 08/01/2012 09:19 PM, Maru Newby wrote:
>>>>     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:
>>>>
>>>>     https://bugs.launchpad.net/keystone/+bug/1003962/comments/4
>>>>
>>>>     And the review:
>>>>
>>>>     https://review.openstack.org/#/c/7754/
>>>>
>>>>     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?
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>     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.
>>>
>>>
>>>>
>>>>     Thanks,
>>>>
>>>>
>>>>     Maru
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Mailing list:https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>>>     Post to     :openstack at lists.launchpad.net  <mailto:openstack at lists.launchpad.net>
>>>>     Unsubscribe :https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>>>     More help   :https://help.launchpad.net/ListHelp
>>>
>>>     _______________________________________________
>>>     Mailing list: https://launchpad.net/~openstack
>>>     <https://launchpad.net/%7Eopenstack>
>>>     Post to     : openstack at lists.launchpad.net
>>>     <mailto:openstack at lists.launchpad.net>
>>>     Unsubscribe : https://launchpad.net/~openstack
>>>     <https://launchpad.net/%7Eopenstack>
>>>     More help   : https://help.launchpad.net/ListHelp
>>
>
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack at lists.launchpad.net
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120803/33b91d0f/attachment.html>