Open Stack

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?

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