Open Stack

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.



Jarret