Open Stack

Hi Adam,

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?

On Tue, Mar 17, 2015 at 3:30 PM, David Chadwick <d.w.chadwick at kent.ac.uk>
wrote:

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



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/fdf6c2ad/attachment.html>