<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 15, 2015 at 12:03 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">On February 14, 2015 at 9:53:14 PM, Adam Young (<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>) wrote:</div> <blockquote type="cite"><span><div bgcolor="#FFFFFF" text="#000000"><div></div><div>
<div>On 02/13/2015 04:19 PM, Morgan
Fainberg wrote:<br></div>
<blockquote type="cite">
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
On February 13, 2015 at 11:51:10 AM, Lance Bragstad
(<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>) wrote:</div>
<div>
<blockquote type="cite" style="color:rgb(0,0,0);font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div dir="ltr"><span>Hello all, </span>
<div><span><br></span></div>
<div><span><br></span></div>
<div><span>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]. </span></div>
<div><span><br></span></div>
<div><span>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. </span></div>
<div><span><br></span></div>
<div><span>Feel free to leave your comments on the AE Token
spec. </span></div>
<div><span><br></span></div>
<div><span>Thanks! </span></div>
<div><span><br></span></div>
<div><span>Lance</span></div>
<div><span><br></span></div>
<div><span>[1] <a href="https://review.openstack.org/#/c/130050/" target="_blank">https://review.openstack.org/#/c/130050/</a></span></div>
<div><span>[2] <a href="https://etherpad.openstack.org/p/kilo-keystone-authorization" target="_blank">https://etherpad.openstack.org/p/kilo-keystone-authorization</a></span></div>
<div><span>[3] <a href="https://review.openstack.org/#/c/145317/" target="_blank">https://review.openstack.org/#/c/145317/</a></span></div>
<div><span>[4] <a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/" target="_blank">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</a></span></div>
</div>
<span>__________________________________________________________________________<span> </span><br>
OpenStack Development Mailing List (not for usage
questions)<span> </span><br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><span> </span><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span> </span></span></div>
</div>
</blockquote>
</div>
<p><br></p>
<p>I am for granting this exception as long as it’s clear that the
following is clear/true:</p>
<p>* All current use-cases for tokens (including federation) will
be supported by the new token provider.</p>
<p>* 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.</p>
</blockquote>
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.<br>
<br>
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.<br>
<br></div></div></span></blockquote><div><br></div></span><div>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).</div><span class=""><br><blockquote type="cite"><span><div bgcolor="#FFFFFF" text="#000000"><div>
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.<br>
<br></div></div></span></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>—Morgan</div><div><br></div><div><br></div></font></span></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>