Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
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 [samu...@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 APIsupport 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.ga...@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 sbaluk...@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@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
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.ga...@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 sbaluk...@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@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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
This very good news. Please point to the code review in gerrit. -Sam. -Original Message- From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Saturday, May 24, 2014 12:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication All, Susanne and I had a demonstration of life code by HP's Barbican team today for certificate storage. The code is submitted for review in the Barbican project. Barbican will be able to store all the certificate parts (cert, key, pwd) in a secure container. We will follow up with more details next week -- So in short all we need to store in LBaaS is the container-id. The rest will come from Barbican and the user will interact straight with Barbican to upload/manage his certificates, keys, pwd... This functionality/use case also is considered in the Marketplace / Murano project -- making the need for a central certificate storage in OpenStack a bit more pressing. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Friday, May 23, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com wrote: Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too many customers complained. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Were anticipating referring the keys via a barbican key id which will be named later. Therefore your design should never depend on having access to a private key and But we need access enough to transport the key to the back end implementation though. should permit having the private key stored in some type of secure key storage. A secure repository for the private key is already a requirement that we are attempting to meat with barbican. -- John ___ 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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Several OSSG members have expressed an interest in reviewing this functionality too. -Rob On 28/05/2014 11:35, Samuel Bercovici samu...@radware.com wrote: This very good news. Please point to the code review in gerrit. -Sam. -Original Message- From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Saturday, May 24, 2014 12:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication All, Susanne and I had a demonstration of life code by HP's Barbican team today for certificate storage. The code is submitted for review in the Barbican project. Barbican will be able to store all the certificate parts (cert, key, pwd) in a secure container. We will follow up with more details next week -- So in short all we need to store in LBaaS is the container-id. The rest will come from Barbican and the user will interact straight with Barbican to upload/manage his certificates, keys, pwd... This functionality/use case also is considered in the Marketplace / Murano project -- making the need for a central certificate storage in OpenStack a bit more pressing. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Friday, May 23, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com wrote: Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too many customers complained. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Were anticipating referring the keys via a barbican key id which will be named later. Therefore your design should never depend on having access to a private key and But we need access enough to transport the key to the back end implementation though. should permit having the private key stored in some type of secure key storage. A secure repository for the private key is already a requirement that we are attempting to meat with barbican. -- John ___ 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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
On May 27, 2014, at 9:13 PM, Stephen Balukoff sbaluk...@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@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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Hi y'all! On Fri, May 23, 2014 at 1:24 PM, Carlos Garza carlos.ga...@rackspace.comwrote: Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. 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. 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. Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Therefore your design should never depend on having access to a private key and should permit having the private key stored in some type of secure key storage. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com wrote: Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too many customers complained. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Were anticipating referring the keys via a barbican key id which will be named later. Therefore your design should never depend on having access to a private key and But we need access enough to transport the key to the back end implementation though. should permit having the private key stored in some type of secure key storage. A secure repository for the private key is already a requirement that we are attempting to meat with barbican. -- John ___ 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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
All, Susanne and I had a demonstration of life code by HP's Barbican team today for certificate storage. The code is submitted for review in the Barbican project. Barbican will be able to store all the certificate parts (cert, key, pwd) in a secure container. We will follow up with more details next week -- So in short all we need to store in LBaaS is the container-id. The rest will come from Barbican and the user will interact straight with Barbican to upload/manage his certificates, keys, pwd... This functionality/use case also is considered in the Marketplace / Murano project -- making the need for a central certificate storage in OpenStack a bit more pressing. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Friday, May 23, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com wrote: Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too many customers complained. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Were anticipating referring the keys via a barbican key id which will be named later. Therefore your design should never depend on having access to a private key and But we need access enough to transport the key to the back end implementation though. should permit having the private key stored in some type of secure key storage. A secure repository for the private key is already a requirement that we are attempting to meat with barbican. -- John ___ 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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
This is good news, thanks for sharing German! Kyle On Fri, May 23, 2014 at 4:54 PM, Eichberger, German german.eichber...@hp.com wrote: All, Susanne and I had a demonstration of life code by HP's Barbican team today for certificate storage. The code is submitted for review in the Barbican project. Barbican will be able to store all the certificate parts (cert, key, pwd) in a secure container. We will follow up with more details next week -- So in short all we need to store in LBaaS is the container-id. The rest will come from Barbican and the user will interact straight with Barbican to upload/manage his certificates, keys, pwd... This functionality/use case also is considered in the Marketplace / Murano project -- making the need for a central certificate storage in OpenStack a bit more pressing. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Friday, May 23, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Right so are you advocating that the front end API never return a private key back to the user once regardless if the key was generated on the back end or sent in to the API from the user? We kind of are already are implying that they can refer to the key via a private key id. On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com wrote: Using standard formats such as PEM and PKCS12 (most people don't use PKCS8 directly) is a good approach. We had to deal with PKCS8 manually in our CLB1.0 offering at rackspace. Too many customers complained. Be mindful that some cryptographic services do not provide *any* direct access to private keys (makes sense, right?). Private keys are shielded in some hardened container and the only way to refer to the private key is via some form of name association. Were anticipating referring the keys via a barbican key id which will be named later. Therefore your design should never depend on having access to a private key and But we need access enough to transport the key to the back end implementation though. should permit having the private key stored in some type of secure key storage. A secure repository for the private key is already a requirement that we are attempting to meat with barbican. -- John ___ 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
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Hi Sam, I totally agree - this will definitely reduce our scope and increase the chance of getting this in. I am still (being influenced by Unix methodology) thinking that we should explore service chaining more for that. As I said earlier, re-encryption feels more like a VPN type thing than a load balancer. Hence, I can imagine a very degenerated VPN service which re-encrypts things with SSL. But, admittedly, I am looking at that as a software engineer and not a network engineer :) German From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Thursday, May 22, 2014 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Hi Everone, I would like to defer addressing client authentication and back-end-server authentication for a 2nd phase - after Juno. This means that from looking on https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the SSL/TLS Termination capabilities, not addressing 2.2 and 3. I think that this would reduce the effort of storing certificates information to the actual ones used for the termination. We will leave the discussion on storing the required trusted certificates and CA chains for later. Any objections? Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
+1 I agree. Lets focus on client SSL Termination at LB for Juno release. Thanks, Vivek From: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 22, 2014 at 12:53 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Hi Sam, I totally agree – this will definitely reduce our scope and increase the chance of getting this in. I am still (being influenced by Unix methodology) thinking that we should explore service chaining more for that. As I said earlier, re-encryption feels more like a VPN type thing than a load balancer. Hence, I can imagine a very degenerated VPN service which re-encrypts things with SSL. But, admittedly, I am looking at that as a software engineer and not a network engineer :) German From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Thursday, May 22, 2014 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication Hi Everone, I would like to defer addressing client authentication and back-end-server authentication for a 2nd phase – after Juno. This means that from looking on https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the “SSL/TLS Termination capabilities”, not addressing 2.2 and 3. I think that this would reduce the “effort” of storing certificates information to the actual ones used for the termination. We will leave the discussion on storing the required trusted certificates and CA chains for later. Any objections? Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
