Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens
+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 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://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
On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt 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 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://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
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 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://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
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 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://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
On 2/16/15 11:48 AM, Lance Bragstad wrote: On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt s...@swiftstack.com 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 mailto:lbrags...@gmail.com mailto: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-request@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 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
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.fainb...@gmail.com 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. So, lets make the adjustment to avoid encrypting data and rely on the
Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens
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 os.lch...@gmail.com 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 steve...@ca.ibm.com 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 morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote on 02/13/2015 04:19:15 PM: From: Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com To: Lance Bragstad lbrags...@gmail.com mailto:lbrags...@gmail.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 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://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
Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens
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
On 02/13/2015 04:19 PM, Morgan Fainberg wrote: 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/ [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
Big +1 from me if we can land something solid. On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang guang@hp.com 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 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 __ 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
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 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 __ 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
++ 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 lbrags...@gmail.commailto: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:unsubscribehttp://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
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 lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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
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
++ 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 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 morgan.fainb...@gmail.com wrote on 02/13/2015 04:19:15 PM: From: Morgan Fainberg morgan.fainb...@gmail.com To: Lance Bragstad lbrags...@gmail.com, 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
It would be great to see this land in Kilo, I'll definitely be willing to review the code. Steve Morgan Fainberg morgan.fainb...@gmail.com wrote on 02/13/2015 04:19:15 PM: From: Morgan Fainberg morgan.fainb...@gmail.com To: Lance Bragstad lbrags...@gmail.com, 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
