Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Samuel Merritt]

On 2/16/15 11:48 AM, Lance Bragstad wrote:



On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt mailto:s...@swiftstack.com>> wrote:

On 2/14/15 9:49 PM, Adam Young 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.

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@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'd like to respectfully disagree here. Large tokens can
dramatically increase the overhead for users of Swift with small
objects since the token must be passed along with every request.

For example, I have a small static web site: 68 files, mean file
size 5508 bytes, median 636 bytes, total 374517 bytes. (It's an
actual site; these are genuine data.)

If I upload these things to Swift using a UUID token, then I incur
maybe 400 bytes of overhead per file in the HTTP request, which is a
7.3% bloat. On the other hand, if the token + other headers is 8K,
then I'm looking at 149% bloat, so I've more than doubled my
transfer requirements just from tokens. :/

I think that, for users of Swift and any other OpenStack data-plane
APIs, token size is a definite concern. I am very much in favor of
anything that shrinks token sizes while keeping the scalability
benefits of PKI tokens.


Ideally, what's the

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Lance Bragstad]

On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt  wrote:

> On 2/14/15 9:49 PM, Adam Young 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.

 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-requ...@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'd like to respectfully disagree here. Large tokens can dramatically
> increase the overhead for users of Swift with small objects since the token
> must be passed along with every request.
>
> For example, I have a small static web site: 68 files, mean file size 5508
> bytes, median 636 bytes, total 374517 bytes. (It's an actual site; these
> are genuine data.)
>
> If I upload these things to Swift using a UUID token, then I incur maybe
> 400 bytes of overhead per file in the HTTP request, which is a 7.3% bloat.
> On the other hand, if the token + other headers is 8K, then I'm looking at
> 149% bloat, so I've more than doubled my transfer requirements just from
> tokens. :/
>
> I think that, for users of Swift and any other OpenStack data-plane APIs,
> token size is a definite concern. I am very much in favor of anything that
> shrinks token sizes while keeping the scalability benefits of PKI tokens.


Ideally, what's the threshold you consider acceptable for token length from
a non-persistent perspective? Does under 255 work or do you need something
smaller?


>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Adam Young]

On 02/16/2015 02:21 PM, Samuel Merritt wrote:

On 2/14/15 9:49 PM, Adam Young 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.

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-requ...@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'd like to respectfully disagree here. Large tokens can dramatically 
increase the overhead for users of Swift with small objects since the 
token must be passed along with every request.


For example, I have a small static web site: 68 files, mean file size 
5508 bytes, median 636 bytes, total 374517 bytes. (It's an actual 
site; these are genuine data.)


If I upload these things to Swift using a UUID token, then I incur 
maybe 400 bytes of overhead per file in the HTTP request, which is a 
7.3% bloat. On the other hand, if the token + other headers is 8K, 
then I'm looking at 149% bloat, so I've more than doubled my transfer 
requirements just from tokens. :/


I think that, for users of Swift and any other OpenStack data-plane 
APIs, token size is a definite concern. I am very much in favor of 
anything that shrinks token sizes while keeping the scalability 
benefits of PKI tokens.


Actually, the only tokens that are going to be non-fixed size will be 
the ones for Federation, since they need groups.  They won't be within 
the 255 byte boundary, but they will be small.







__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Samuel Merritt]

On 2/14/15 9:49 PM, Adam Young 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.

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-requ...@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'd like to respectfully disagree here. Large tokens can dramatically 
increase the overhead for users of Swift with small objects since the 
token must be passed along with every request.


For example, I have a small static web site: 68 files, mean file size 
5508 bytes, median 636 bytes, total 374517 bytes. (It's an actual site; 
these are genuine data.)


If I upload these things to Swift using a UUID token, then I incur maybe 
400 bytes of overhead per file in the HTTP request, which is a 7.3% 
bloat. On the other hand, if the token + other headers is 8K, then I'm 
looking at 149% bloat, so I've more than doubled my transfer 
requirements just from tokens. :/


I think that, for users of Swift and any other OpenStack data-plane 
APIs, token size is a definite concern. I am very much in favor of 
anything that shrinks token sizes while keeping the scalability benefits 
of PKI tokens.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Marek Denis]

+1 from me.

On 13.02.2015 22:19, 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.

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-requ...@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 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Lance Bragstad]

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  wrote:

> 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.
>
> 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-requ...@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. S

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Morgan Fainberg]

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. 

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-requ...@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


__

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Adam Young]

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.

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Henry Nash]

So I’m Ok with an exception for this, but still have reservations of the this 
AE technique (at least the one that is currently proposed). I assume this will 
be marked as experimental - since we have not formally agreed that this is a 
standard we want to lock into core?

Henry
> On 14 Feb 2015, at 05:09, Lin Hua Cheng  wrote:
> 
> ++ One of the feature that I am looking forward to see in Kilo, this feature 
> will solve one of the pain points from operators in maintaining the token db 
> backend.
> 
> -Lin
> 
> On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli  <mailto:steve...@ca.ibm.com>> wrote:
> It would be great to see this land in Kilo, I'll definitely be willing to 
> review the code. 
> 
> Steve 
> 
> Morgan Fainberg  <mailto:morgan.fainb...@gmail.com>> wrote on 02/13/2015 04:19:15 PM:
> 
> > From: Morgan Fainberg  > <mailto:morgan.fainb...@gmail.com>> 
> > To: Lance Bragstad mailto:lbrags...@gmail.com>>, 
> > "OpenStack Development 
> > Mailing List (not for usage questions)"  > <mailto:openstack-dev@lists.openstack.org>> 
> > Date: 02/13/2015 04:24 PM 
> > Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated 
> > Encryption (AE) Tokens 
> > 
> > On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@gmail.com 
> > <mailto: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. 
> > 
> > Thanks! 
> > 
> > Lance 
> > 
> > [1] https://review.openstack.org/#/c/130050/ 
> > <https://review.openstack.org/#/c/130050/> 
> > [2] https://etherpad.openstack.org/p/kilo-keystone-authorization 
> > <https://etherpad.openstack.org/p/kilo-keystone-authorization> 
> > [3] https://review.openstack.org/#/c/145317/ 
> > <https://review.openstack.org/#/c/145317/> 
> > [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ 
> > <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 
> > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > <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 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

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Lin Hua Cheng]

++ One of the feature that I am looking forward to see in Kilo, this
feature will solve one of the pain points from operators in maintaining the
token db backend.

-Lin

On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli 
wrote:

> It would be great to see this land in Kilo, I'll definitely be willing to
> review the code.
>
> Steve
>
> Morgan Fainberg  wrote on 02/13/2015 04:19:15
> PM:
>
> > From: Morgan Fainberg 
> > To: Lance Bragstad , "OpenStack Development
> > Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Date: 02/13/2015 04:24 PM
> > Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated
> > Encryption (AE) Tokens
> >
> > 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.
> >
> > 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-requ...@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 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-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Steve Martinelli]

It would be great to see this land in Kilo, I'll definitely be willing to 
review the code.

Steve

Morgan Fainberg  wrote on 02/13/2015 04:19:15 
PM:

> From: Morgan Fainberg 
> To: Lance Bragstad , "OpenStack Development 
> Mailing List (not for usage questions)" 

> Date: 02/13/2015 04:24 PM
> Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated 
> Encryption (AE) Tokens
> 
> 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. 
> 
> 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-requ...@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 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Morgan Fainberg]

To Clarify, I meant I support this exception if the new provider supports all 
of our current use-cases. I was not stating this exception was approved without 
time for feedback from the community.

-- 
Morgan Fainberg

On February 13, 2015 at 1:19:17 PM, Morgan Fainberg (morgan.fainb...@gmail.com) 
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. 

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-requ...@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 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Dolph Mathews]

Big +1 from me if we can land something solid.

On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang  wrote:

>  ++
>
>
>
> As for the unbound groups concern, our initial internal Federation POCs
> worked well with a single group so far. The proposed hierarchical role
> groups, or perhaps even supporting nested user groups down the road should
> offer us more flexibility in terms user and permission management. For
> example, having a single aggregated group to map to for the federated users.
>
>
>
> Personally, I think the max 255 characters constraint is somewhat
> artificial, unless I am missing something here.
>

It's a limitation made for social reasons: that's sort of the tipping point
where tokens become unwieldy and require special treatment.


>
>
>
>
> Guang
>
>
>
>
>
> *From:* Brant Knudson [mailto:b...@acm.org]
> *Sent:* Friday, February 13, 2015 12:59 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption
> (AE) Tokens
>
>
>
>
>
> We get a lot of complaints about problems caused by persistent tokens, so
> this would be great to see in K. Given the amount of work required to get
> it done, which includes taking care of some other issues, like getting
> revocation events working and refactoring the token code (things which
> could have been progressing all along...), and considering how long it
> takes to get changes merged, it seems unlikely that this will make it, but
> I've been planning all along to prioritize these reviews if that helps.
>
> - Brant
>
>
>
> On Fri, Feb 13, 2015 at 1:47 PM, Lance Bragstad 
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Morgan Fainberg]

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. 

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-requ...@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 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Yee, Guang]

++

As for the unbound groups concern, our initial internal Federation POCs worked 
well with a single group so far. The proposed hierarchical role groups, or 
perhaps even supporting nested user groups down the road should offer us more 
flexibility in terms user and permission management. For example, having a 
single aggregated group to map to for the federated users.

Personally, I think the max 255 characters constraint is somewhat artificial, 
unless I am missing something here.


Guang


From: Brant Knudson [mailto:b...@acm.org]
Sent: Friday, February 13, 2015 12:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) 
Tokens


We get a lot of complaints about problems caused by persistent tokens, so this 
would be great to see in K. Given the amount of work required to get it done, 
which includes taking care of some other issues, like getting revocation events 
working and refactoring the token code (things which could have been 
progressing all along...), and considering how long it takes to get changes 
merged, it seems unlikely that this will make it, but I've been planning all 
along to prioritize these reviews if that helps.
- Brant

On Fri, Feb 13, 2015 at 1:47 PM, Lance Bragstad 
mailto: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.

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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Brad Topol]

I am a vote of Yes for the Authenticated Encryption (AE) Token 
specification receiving a Spec Freeze exception.   This approach has 
tremendous potential to significantly improve Keystone and POC code 
already exists. I feel there is enough runway that it is worth trying to 
move forward with this spec in this release cycle.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Lance Bragstad 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   02/13/2015 02:52 PM
Subject:[openstack-dev] [keystone] SPFE: Authenticated Encryption 
(AE)Tokens



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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Brant Knudson]

We get a lot of complaints about problems caused by persistent tokens, so
this would be great to see in K. Given the amount of work required to get
it done, which includes taking care of some other issues, like getting
revocation events working and refactoring the token code (things which
could have been progressing all along...), and considering how long it
takes to get changes merged, it seems unlikely that this will make it, but
I've been planning all along to prioritize these reviews if that helps.

- Brant


On Fri, Feb 13, 2015 at 1:47 PM, Lance Bragstad  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Lance Bragstad]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev