← Back to team overview

openstack team mailing list archive

Re: Keystone: 'PKI Signed Tokens' lack support for revocation

 

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@xxxxxxxxxx <mailto: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  <https://launchpad.net/%7Eopenstack>
    Post to     :openstack@xxxxxxxxxxxxxxxxxxx  <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
    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@xxxxxxxxxxxxxxxxxxx
    <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
    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@xxxxxxxxxxxxxxxxxxx
    <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~openstack
    <https://launchpad.net/%7Eopenstack>
    More help   : https://help.launchpad.net/ListHelp



References