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:nkin...@redhat.com] 
Sent: Thursday, June 12, 2014 4:41 PM
To: openstack-dev@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:nkin...@redhat.com]
> Sent: Thursday, June 12, 2014 3:32 PM
> To: openstack-dev@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to