<div dir="ltr">Hi Adam,<div><br></div><div>The Fernet token and Project Kite looks very interesting, I think it might be helpful to work together to tackle the problem, shall we put this issue to the keystone design summit for further follow up discussion? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 3:30 PM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Encryption per se does not decrease token size, the best it can do is<br>
keep the token size the same size. So using Fernet tokens will not on<br>
its own alter the token size. Reducing the size must come from putting<br>
less information in the token. If the token recipient has to always go<br>
back to Keystone to get the token validated, then all the token needs to<br>
be is a large random number that Keystone can look up in its database to<br>
retrieve the user's permissions. In this case no encryption is needed at<br>
all.<br>
<br>
regards<br>
<br>
David<br>
<span class=""><br>
On 17/03/2015 06:51, joehuang wrote:<br>
> Hi, Adam,<br>
><br>
><br>
><br>
> Good to know Fernet token is on the way to reduce the token size and<br>
> token persistence issues.<br>
><br>
><br>
><br>
> It’s not reality to deploy KeyStone service ( including backend store )<br>
> in each site if the number, for example, is more than 10.  The reason is<br>
> that the stored data including data related to revocation need to be<br>
> replicated to all sites in synchronization manner. Otherwise, the API<br>
> server might attempt to use the token before it's able to be validated<br>
> in the target site.<br>
><br>
><br>
><br>
> When Fernet token is used in multisite scenario, each API request will<br>
> ask for token validation from KeyStone. The cloud will be out of service<br>
> if KeyStone stop working, therefore KeyStone service need to run in<br>
> several sites.<br>
><br>
><br>
><br>
> For reliability purpose, I suggest that the keystone client should<br>
> provide a fail-safe design: primary KeyStone server, the second KeyStone<br>
> server (or even the third KeySont server) . If the primary KeyStone<br>
> server is out of service, then the KeyStone client will try the second<br>
> KeyStone server. Different KeyStone client may be configured with<br>
> different primary KeyStone server and the second KeyStone server.<br>
><br>
><br>
><br>
> Best Regards<br>
><br>
> Chaoyi Huang ( Joe Huang )<br>
><br>
><br>
><br>
</span>> *From:*Adam Young [mailto:<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>]<br>
> *Sent:* Monday, March 16, 2015 10:52 PM<br>
> *To:* <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> *Subject:* Re: [openstack-dev] [opnfv-tech-discuss]<br>
<div><div class="h5">> [Keystone][Multisite] Huge token size<br>
><br>
><br>
><br>
> On 03/16/2015 05:33 AM, joehuang wrote:<br>
><br>
>     [Topic]: Huge token size<br>
><br>
><br>
><br>
>     Hello,<br>
><br>
><br>
><br>
>     As you may or may not be aware of, a requirement project proposal<br>
>     Multisite[1] was started in OPNFV in order to identify gaps in<br>
>     implementing OpenStack across multiple sites.<br>
><br>
><br>
><br>
>     Although the proposal has not been approved yet, we’ve started to<br>
>     run some experiments to try out different methods. One of the<br>
>     problem we identify in those experiments is that, when we want  to<br>
>     use a shared KeyStone for 101 Regions ( including ~500 endpoints ).<br>
>     The token size is huge (The token format is PKI), please see details<br>
>     in the attachments:<br>
><br>
><br>
><br>
>     token_catalog.txt, 162KB: catalog list included in the token<br>
><br>
>     token_pki.txt, 536KB: non-compressed token size<br>
><br>
>     token_pkiz.txt, 40KB: compressed token size<br>
><br>
><br>
><br>
>     I understand that KeyStone has a way like endpoint_filter to reduce<br>
>     the size of token, however this requires to manage many (hard to id<br>
>     the exact number) endpoints can be seen by a project, and the size<br>
>     is not easy to exactly controlled.<br>
><br>
><br>
><br>
>     Do you guys have any insights in how to reduce the token size if PKI<br>
>     token used? Is there any BP relates to this issue? Or should we fire<br>
>     one to tackle this?<br>
><br>
><br>
><br>
> Right now there is an effort for non-multisite to get a handle on the<br>
> problem.  The Fernet token format will make it possible for a token to<br>
> be ephemeral.  The scheme is this:<br>
><br>
> Encode the minimal amount of Data into the token possible.<br>
><br>
> Always validate the token on the Keystone server.<br>
><br>
> On the Keystone server, the token validation is performed by checking<br>
> the message HMAC, and then expanding out the data.<br>
><br>
> This concept is expandable to multi site in two ways.<br>
><br>
> For a completely trusted and symmetric multisite deployement, the<br>
> keystone servers can share keys.  The Kite project was<br>
> <a href="http://git.openstack.org/cgit/openstack/kite" target="_blank">http://git.openstack.org/cgit/openstack/kite</a> origianlly spun up to<br>
> manage this sort of symmetric key sharing, and is a natural extension.<br>
><br>
> If two keystone server need to sign for and validate separate serts of<br>
> data (future work)  the form of signing could be returned to Asymmetric<br>
> Crypto.  This would lead to a minimal tokne size of about 800 Bytes (I<br>
> haven't tested exactly).  It would mean that any service responsible for<br>
> validating tokens would need to fetch and cache the responses for things<br>
> like catalog and role assignments.<br>
><br>
> The epehemeral nature of the Fernet specification means that revocation<br>
> data needs to bepersisted separate from the token, so it is not 100%<br>
> ephemeral, but the amount of stored data should be (I estimate) two<br>
> orders of magnatude smaller, maybe three.  Password changes, project<br>
> deactivations,  and role revocations will still cause some traffic<br>
> there.  These will need to be synchronized across token validation servers.<br>
><br>
> Great topic for discussion in Vancouver.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> [1]<a href="https://wiki.opnfv.org/requirements_projects/multisite" target="_blank">https://wiki.opnfv.org/requirements_projects/multisite</a><br>
><br>
><br>
><br>
> Best Regards<br>
><br>
> Chaoyi Huang ( Joe Huang )<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
><br>
> OpenStack Development Mailing List (not for usage questions)<br>
><br>
</div></div>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe><br>
><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>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
><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>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Prooduct Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div>
</div>