[Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
Adam Young
ayoung at redhat.com
Fri Aug 3 14:55:10 UTC 2012
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>
More information about the Openstack
mailing list