<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/13/2015 04:19 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote cite="mid:etPan.54de6a53.1190cde7.173@nullptr.local"
type="cite">
<style>body{font-family:Helvetica,Arial;font-size:13px}</style>
<div id="bloop_customfont"
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
moz-do-not-send="true" href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>)
wrote:</div>
<div>
<blockquote type="cite" class="clean_bq" 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; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><span>
<div>
<div>
<div dir="ltr">Hello all,
<div><br>
</div>
<div><br>
</div>
<div>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]. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Feel free to leave your comments on the AE Token
spec. </div>
<div><br>
</div>
<div>Thanks! </div>
<div><br>
</div>
<div>Lance</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/130050/">https://review.openstack.org/#/c/130050/</a></div>
<div>[2] <a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/kilo-keystone-authorization">https://etherpad.openstack.org/p/kilo-keystone-authorization</a></div>
<div>[3] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/145317/">https://review.openstack.org/#/c/145317/</a></div>
<div>[4] <a moz-do-not-send="true"
href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</a></div>
</div>
__________________________________________________________________________<span
class="Apple-converted-space"> </span><br>
OpenStack Development Mailing List (not for usage
questions)<span class="Apple-converted-space"> </span><br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><span
class="Apple-converted-space"> </span><br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span
class="Apple-converted-space"> </span></div>
</div>
</span></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>
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>
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.<br>
<br>
I think with those two adjustments, AE tokens should be able to
progress.<br>
<br>
<br>
<blockquote cite="mid:etPan.54de6a53.1190cde7.173@nullptr.local"
type="cite">
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<p>TL;DR, I am for the exception if the AE Tokens support 100% of
the current use-cases of tokens (UUID or PKI) today.</p>
<p><br>
</p>
<p>—Morgan</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>