openstack team mailing list archive

[Nathanael Burton <nathanael.i.burton@xxxxxxxxx>]

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.

Nate
On Aug 2, 2012 10:24 PM, "Adam Young" <ayoung@xxxxxxxxxx> 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
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>  _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>