On February 14, 2015 at 9:53:14 PM, Adam Young (ayo...@redhat.com) wrote:
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@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. 



[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-requ...@lists.openstack.org?subject:unsubscribe 

I am for granting this exception as long as it’s clear that the following is 

* 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 

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to