Open Stack

fwiw, the latest patch set has logic built in that determines the purpose
of the key repository. If you want your deployment to sign tokens you can
point Keystone to a key repository for that purpose. Likewise, tokens will
only be encrypted if you tell Keystone to use a key repository for
encrypting.

On Sun, Feb 15, 2015 at 12:03 AM, Morgan Fainberg <morgan.fainberg at gmail.com
> wrote:

> On February 14, 2015 at 9:53:14 PM, Adam Young (ayoung at redhat.com) wrote:
>
> 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)
> 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.
>
>
> Scoped tokens via Federation (iirc this is possible) could end up
> including the groups. I think you hit the nail on the head though, the 255
> limit is artificial, and we’ve made a lot of efforts here to limit the
> token size already. These tokens need to handle 100% of the current token
> use cases, and limiting federated tokens to unscoped only is likely going
> to break that requirement. Future enhancements can ensure federated tokens
> fall below the 255 character limit (IIRC Dolph said he had a fix for this
> but it’s not something that can hit Kilo and will be proposed in the
> future).
>
> 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.
>
>
> I would rather see this spec crypto all together and strictly rely on HMAC
> with any form of crypto (Asymmetric or Symmetric) being the addon. I am
> worried if we go down the path of starting with PKI (or even symmetric
> crypto) instead of just HMAC signature validation (live-validated such as
> what keystone does today with UUID tokens) we are going to back ourselves
> into a similar corner we’re in today.
>
> I agree that adding new crypto and key management is a good deal more
> overhead than the basic implementation. As I commented on the spec, I’m not
> sure encryption is buying us a lot here. So, lets make the adjustment to
> avoid encrypting data and rely on the UUID validation mode utilizing HMAC
> signatures (keystone owns the keys) with future enhancements to add in the
> actual encryption (in any form). Requiring ASN1 signed data would also not
> really the low opportunity cost this spec is trying to be. This eliminates
> easy multiple-signer deployments but can be an addon once the core is in
> place.
>
> —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/457068ad/attachment.html>