Open Stack

On 05/12/2014 04:33 AM, Jeffrey Walton wrote:
> On Fri, May 9, 2014 at 3:51 PM, Adam Young <ayoung at redhat.com> wrote:
>> On 05/08/2014 05:51 AM, David Chadwick wrote:
>>>
>>> I dont think there is a correct answer to this. In general you have to
>>> pick a time (any time) that will cater for the majority of transactions,
>>> and then have some sort of refresh mechanism for those that are longer
>>> than this. If you pick too long a time then people will start to ask for
>>> a revocation facility (as happened in the grid for proxy certificates),
>>> which negates the point of having short lived certificates in the first
>>> place
>>
>> ...
>> David has much more specific language for this, but keeping it in terms of
>> Keystone:  certificates should be relatively long lived. Tokens are short
>> lived.  What David said about proxy certs is true for Keystone tokens as
>> well.
> What is the lifetime of the assertion made by Keystone? I just went
> through the OpenStack Security Guide (http://docs.openstack.org/sec/),
> and I did not see a treatment on the subject.

In Havana, the default token validity duration was 24 hours.  In
Icehouse, that was changed to 1 hour.  The duration is configurable, so
it can be tuned to whatever value is deemed appropriate for a particular
deployment.

> 
> Related: can a service, such as Nova, reach back and ask Keystone if a
> user is still valid (and hence infer if the token is still valid)?
> Here, the service is a relying party.

That's how the old UUID tokens worked.  With PKI tokens, Keystone does
not need to be involved with the validation of tokens.  A service is
able to validate the token signature to ensure it was really issued by
Keystone, then it can check if it is still valid.  I don't think you
want to funnel all validation through Keystone, as it would be a
bottleneck.  Token revocation would be able to handle situations where
you can't wait until the token validity expires.

> 
> If the token is long-lived *and* Keystone cannot be queried, then all
> we know is some user was authenticated at some time in the past. 2
> hours in the past is not too bad, but 28 days in the past might leave
> something to be desired. Its the same kind of architectural defect
> incumbent to code signing.
> 
>> Keystone's job is to enforce short duration confirmation of attributes
>> specific to OpenStack that can be used to check policy at a decision point.
>> It is the lifetime of these attributes that should be considered ephemeral.
> 
> State of the Project Keystone
> (https://www.youtube.com/watch?v=jdmUbBgd_1g) states its up to the
> various services to perform entitlement and authorization checks. What
> does "enforce short duration confirmation of attributes" mean?
> 
>> Certificates currently are used for SSL and Keystone token signing. In both
>> these cases, we would be wise to add on CRL checking (OCSP is possible, but
>> probably not right for OpenStack, as we tend to need bulk).
> 
> OCSP has its own set of problems. See, for example, Gutmann's
> Engineering Security
> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf), Chapter 8,
> PKI. Online Revocation Authorities, Problems with OCSP, pp. 643 - 648.
> 
> How about SPKI-like validations and revalidations? See
> http://tools.ietf.org/html/rfc2693.

Adam was referring to actual x.509 certificates and how they are used
today, not Keystone tokens.  I'm not sure if your comments were thinking
of something like OCSP for tokens, or for the certificates used to
enable SSL for the Keystone API endpoint or token signing.

Tokens can be revoked in Keystone, and the services can basically use a
CRL like concept to see if tokens have been revoked when validating them.

Thanks,
-NGK
> 
> Jeff
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>