Open Stack

On Wed, 2013-05-08 at 20:38 +0000, Jarret Raim wrote:
> On 5/8/13 12:08 PM, "Simo Sorce" <simo at redhat.com> wrote:
> 
> >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.
> 
> I think the value is in all the work that Keystone is not planning on
> doing. For example:
> 
> * Secure storage including key encryption keys and access control
> * Auditing & logging of key storage, accesses, etc.
> * Common Criteria & FIPS certifications (capable anyway - up to the
> provider)
> * Use of HSMs and other encryption products for secure storage and
> generation
> * Mitigation for entropy exhaustion
> 
> There are more, but the goal of Barbican is to implement all the things we
> need for secure key management so that all the other systems don't have
> too. Keystone is, of course, welcome to do so, I'm just saying that we'll
> be solving those problems so there might not be a need to do it twice.
> 
> As to the two request issue, I would assume any implementation would cache
> the keys for message security for some period of time or at least the uri
> to the key in barbican so it would only need to make the double request
> infrequently. If worse comes to worse, we could have keystone make a
> request to barbican to get the key and return it to the user to obviate
> the need for the second request. I don't believe that's as clean and it
> does make the transaction less secure (loss of auditing, more systems with
> access to the key, etc), but it would be doable.
> 
> >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.
> 
> Barbican is designed to rely on consumers to associate keys to their
> objects. E.g. We don't store what Cinder volume a key belongs to, Cinder
> stores the barbican URI in the volume metadata. I agree that Keystone owns
> the linking and the key itself, just suggesting the storage (and possibly
> the creation) logic doesn't need to be duplicated.
> 
> 
> >I rather keep the hole thing simple and in one place.
> 
> I think that's what I'm suggesting, I'm just suggesting that the best
> place for key storage and generation is in the system that is designed to
> perform those operations rather than a system designed to manage
> identities. 
> 
> Depending on what you need and when, Keystone might be the best option in
> the short-term. I'm just saying we are going to have to solve these issues
> in Barbican and you might be able to take advantage of that work. I'd be
> happy to talk about exactly what you need if you are interested and we can
> aim at delivering those features.

I think we should definitely look at the similarities in the long term,
but I say it is a post-Havana perspective. Once we understand better the
limits and requirements and we know what is the performance profile of
the key distribution server and barbican for this type of operations.

The other reason not to rush towards barbican is that there is still a
chance operational issues will push the solution to morph from shared
key to public-key type or even a mix of the two. So it is better to keep
the whole thing in one place until we discovered all the issues and
tweak the scheme to our needs. Coordinating more projects is a burden
that would make the whole problem much harder to crack at this stage.

Simo.

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