Open Stack

On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
> On February 13, 2015 at 11:51:10 AM, Lance Bragstad 
> (lbragstad at gmail.com <mailto:lbragstad at gmail.com>) wrote:
>> Hello all,
>>
>>
>> I'm proposing the Authenticated Encryption (AE) Token specification 
>> [1] as an SPFE. AE tokens increases scalability of Keystone by 
>> removing token persistence. This provider has been discussed prior 
>> to, and at the Paris summit [2]. There is an implementation that is 
>> currently up for review [3], that was built off a POC. Based on the 
>> POC, there has been some performance analysis done with respect to 
>> the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].
>>
>> The Keystone team spent some time discussing limitations of the 
>> current POC implementation at the mid-cycle. One case that still 
>> needs to be addressed (and is currently being worked), is federated 
>> tokens. When requesting unscoped federated tokens, the token contains 
>> unbound groups which would need to be carried in the token. This case 
>> can be handled by AE tokens but it would be possible for an unscoped 
>> federated AE token to exceed an acceptable AE token length (i.e. < 
>> 255 characters). Long story short, a federation migration could be 
>> used to ensure federated AE tokens never exceed a certain length.
>>
>> Feel free to leave your comments on the AE Token spec.
>>
>> Thanks!
>>
>> Lance
>>
>> [1] https://review.openstack.org/#/c/130050/
>> [2] https://etherpad.openstack.org/p/kilo-keystone-authorization
>> [3] https://review.openstack.org/#/c/145317/
>> [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> I am for granting this exception as long as it’s clear that the 
> following is clear/true:
>
> * All current use-cases for tokens (including federation) will be 
> supported by the new token provider.
>
> * The federation tokens being possibly over 255 characters can be 
> addressed in the future if they are not addressed here (a “federation 
> migration” does not clearly state what is meant.
>
I think the length of the token is not a real issue.  We need to keep 
them within header lengths.  That is 8k.  Anything smaller than that 
will work.

I think we start with  federation usncoped tokens allowing a list of 
groups.  These tokens only go back and forth from user to Keyston 
anyway, and should not got to other services.

I also have a concernt with the requirement for new cryptoloy. 
Specificcally, the requirement for symmetric crypto and Keys management 
can be a s ignificant barrier to organizations that have to meet 
compliance rules.  Since PKI tokens have already forced this issue, I 
suggest we switch AE tokens to using PKI instead of symmetric crypto for 
the default case.  Putting in an optimization that uses symmetric crypto 
as an enhancement should then be a future enhancement.  Asymmetric 
crypto will mitigate the issues with multiple keystone servers sharing 
keys, and will remove the need for a key sharing mechanism.  Since this 
mechanism is in Keystone already, I think it is a realistic approach.

Symmetric crypto when coupled with the needs to have multiple Keystones 
signing tokens is going to require something like Kite, which is not 
part of the core OpenStack services.  We don't currently rely on a key 
sharing mechanism and I don't think this feature is worth forcing that 
on the deployers.

I think with those two adjustments, AE tokens should be able to progress.


> I am also ok with the AE token work being re-ordered ahead of the 
> provider cleanup to ensure it lands. Fixing the AE Token provider 
> along with PKI and UUID providers should be minimal extra work in the 
> cleanup.
>
> This addresses a very, very big issue within Keystone as scaling 
> scaling up happens. There has been demand for solving token 
> persistence for ~3 cycles. The POC code makes this exception possible 
> to land within Kilo, whereas without the POC this would almost 
> assuredly need to be held until the L-Cycle.
>
>
> TL;DR, I am for the exception if the AE Tokens support 100% of the 
> current use-cases of tokens (UUID or PKI) today.
>
>
> —Morgan
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150215/6df2d366/attachment.html>