Open Stack

Hello Samuel,

The team is working on adding transport key support to Barbican per this blueprint: https://blueprints.launchpad.net/barbican/+spec/add-wrapping-key-to-barbican-server

We would like to add convenience methods to the Python barbican client to support this key wrapping behavior. 

________________________________________
From: Samuel Bercovici [SamuelB at Radware.com]
Sent: Thursday, May 29, 2014 7:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API    support for     authentication

+1 to Carlos.

In addition, there should be possible for LBaaS (It might only be just the LBaaS drivers) to get the information including the private key back so that the backend can use it.
This means that a "trusted" communication channel between the driver and Barbican needs to be established so that such information will be passed.
I am waiting for the "code review" in barbican to check that such capabilities will be available.

Regards,
        -Sam.



-----Original Message-----
From: Carlos Garza [mailto:carlos.garza at rackspace.com]
Sent: Wednesday, May 28, 2014 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication


On May 27, 2014, at 9:13 PM, Stephen Balukoff <sbalukoff at bluebox.net>
 wrote:

> Hi y'all!
>
> I would advocate that if the user asks the front-end API for the private key information (ie. "GET" request), what they get back is the key's modulus and nothing else. This should work to verify whether a given key matches a given cert, and doesn't break security requirements for those who are never allowed to actually touch private key data. And if a user added the key themselves through the front-end API, I think it's safe to assume the responsibility for keeping a copy of the key they can access lies with the user.

    I'm thinking at this point all user interaction with their cert and key be handled by barbican directly instead of through our API. It seems like we've punted everything but the IDs to barbican. Returning the modulus is still RSA centric though.


>
> Having said this, of course anything which spins up virtual appliances, or configures physical appliances is going to need access to the actual private key. So any back-end API(s) will probably need to have different behavior here.
>
> One thing I do want to point out is that with the 'transient' nature of back-end guests / virtual servers, it's probably going to be important to store the private key data in something non-volatile, like barbican's store. While it may be a good idea to add a feature that generates a private key and certificate signing request via our API someday for certain organizations' security requirements, one should never have the only store for this private key be a single virtual server. This is also going to be important if a certificate + key combination gets re-used in another listener in some way, or when horizontal scaling features get added.

    I don't think our API needs to handle the CSRs it looks like barbican aspires to do this so our API really is pretty insulated.

>
> Thanks,
> Stephen
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> _______________________________________________
> 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