Open Stack

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.

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.

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.

Jeff