Open Stack

On Wed, 2013-05-08 at 15:55 +0000, Jarret Raim wrote:
> On 5/7/13 3:31 PM, "Simo Sorce" <simo at redhat.com> wrote:
> 
> 
> >New blueprint:
> >https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
> >
> >This is the server part needed to implement Message Security for Havana.
> 
> I agree that Keystone should own the assignment of keys to accounts for
> use in authentication and the /kds endpoint seems fine to me, but I would
> suggest that instead of keystone returning the keying material directly,
> it just return a URI to the barbican API.

> When we talked about key management at the design summit, it seemed like
> Keystone didn't want to take on a lot of the secure storage (common
> criteria, fips) stuff or the logging & auditing requirements for a key
> management solution. If Keystone uses Barbican as its backend store for
> keys (while still owning the lifecycle of those keys and the mapping of
> those to services) that seems to make the most sense?
> 
> 
> 
> Thoughts?

We already have too many moving parts in this project, and bouncing one
request to another server just adds latency (keys are sourced at the
time you need to send a message) and I do not see what is the benefit of
splitting storage this way.
Currently the only thing I store is a key, and the KDS does key
derivation and returns a ticket containing a session key. It's all it
does.
As a second step it will also start doing some simple ACL to handle
temporary group keys. But those keys are created on the spot and need no
long term storage.

I rather keep the hole thing simple and in one place.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York