Open Stack

On Thu, 2014-06-12 at 23:22 +0000, Tiwari, Arvind wrote:
> Thanks Nathan for your response.  
> 
> Still not very convinced for two separate service.
> 
> Keystone authentication is not a mandatory requirement for Barbican, as per design it can work without Keystone authentication. Rest (temporary session key generation, long-term keys ...) are feature gap which can be easily developed in barbican. 
> 
> If Barbican has to store long term keys on behalf of Kite users than IMO it is good to merge these two services. We can develop separate plug-in to achieve KDC (or Kite plug-in). One can have two separate barbican deployments one of KDC another for KMS (or may be only one with enhanced barbican API). 
> 
> Thoughts?

I think you're looking at the wrong part of the stack here. Barbican is
a user facing component, kite is looking at securing messages between
services that are sent over a message bus. They will need to be deployed
and configured in a completely different manner. The users in this case
are host machines.

I don't think that session key generation is a 'gap' in barbican's
features, I think it's very correctly outside of scope. Key generation
such as this is done in a very specific format for a very specific use
case, and includes a lot of metadata that has no application outside of
kite.

Kite or a KDC plugin, would still need to manage a whole lot of state
around services and which services can talk to which other services.
This is very much outside barbican's scope. 

The only thing that is really common between the two projects is safely
storing encrypted keys, and even then a fundamental purpose of barbican
is being able to retrieve the keys, which kite should never do. So we
would then need to start putting things into barbican to mark these keys
as special...

This was discussed at the summit (you were in that room) that when
appropriate we should look at having an option for kite to use barbican
for it's long term key storage and look to extract the secure key
storage component from barbican (or kite) into a library that can be
shared between the two components if feasible.

In summary, yes they both store keys but the plugin you suggest will end
up with the same API surface area as barbican itself, involve a lot of
service management that is way outside of barbican's scope, will need to
scale for a different reason, will need to be discovered by a different
class of user and have different requirements on 'privacy' on keys.

Why would we want to deal with all that if you would still need another
barbican deployment?


Jamie

> Arvind
> 
> 
> -----Original Message-----
> From: Nathan Kinder [mailto:nkinder at redhat.com] 
> Sent: Thursday, June 12, 2014 4:41 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Message level security plans. [barbican]
> 
> 
> 
> On 06/12/2014 03:16 PM, Tiwari, Arvind wrote:
> > Some thoughts out of the context of this email thread.
> > 
> > As per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs?
> 
> That's not a true statement.  This was also something that was discussed at the Atlanta Summit in the Kite session with the Barbican development team, and agreement was reached that they are different use-cases and feature sets that should remain separate.
> 
> To (over) simplify, Barbican allows OpenStack users (or services) identified by Keystone tokens to archive and later retrieve keys.  In contrast, Kite is generating and issuing temporary session keys to communicating parties that are using the message queue in the underlying OpenStack infrastructure.  These parties are not identified by Keystone.
>  These session keys are also not archived by a service.  Kite generates them, issues them in the form of a ticket, and forgets them immediately.
>  You never want to be able to retrieve a key after a ticket is issued.
> In addition, the key generation is not purely random as I've outlined in my blog post (see the details around how HKDF is used if you're interested).
> 
> There are areas for integration between Kite and Barbican.  The most obvious would be to utilize Baribican to store the long-term keys used to authenticate the communicating party.
> 
> Thanks,
> -NGK
> 
> > 
> > Thoughts?
> > 
> > Arvind
> > 
> > -----Original Message-----
> > From: Nathan Kinder [mailto:nkinder at redhat.com]
> > Sent: Thursday, June 12, 2014 3:32 PM
> > To: openstack-dev at lists.openstack.org
> > Cc: Jamie Lennox
> > Subject: Re: [openstack-dev] Message level security plans.
> > 
> > Hi Tim,
> > 
> > Jamie Lennox (cc'd) has been the main developer working on Kite.  I'm 
> > sure he would appreciate you getting involved in reviews [1] and any 
> > other development help you're willing to contribute.  Patches have 
> > slowly been landing in the kite repo. [2]
> > 
> > For others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine:
> > 
> >   https://blog-nkinder.rhcloud.com/?p=62
> > 
> > Thanks,
> > -NGK
> > 
> > [1] 
> > https://review.openstack.org/#/q/status:open+project:stackforge/kite,n
> > ,z [2] https://github.com/stackforge/kite
> > 
> > 
> > On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:
> >> Hello OpenStack folks,
> >>
> >> First please allow me to introduce myself, my name is Tim Kelsey and I'm a security developer working at HP. I am very interested in projects like Kite and the work that's being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what's being worked on or planned in blueprints.
> >>
> >> Many Thanks,
> >>
> >> --
> >> Tim Kelsey
> >> Cloud Security Engineer
> >> HP Helion
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev