Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Samuel, Yes, it's more friendly to extract this information on behalf of the user, but does occasionally break use cases we've seen. It should be possible, when there is hostname overlap, for the user to specify which certificate to use. It sounds like the Radware solution uses certificate ordering to resolve this conflict. stunnel requires the user to specify which certs should be used with which hostnames, and I think balks if you try to repeat a hostname. So in stunnel's case, conflict resolution happens through user configuration. So in both cases, the user specifies some way to do conflict resolution. There's not a reason we couldn't do it the Radware way for stunnel. The algorithm would be: 1. Order configured certificates based on the 'order' attribute. 2. One by one in sequence, extract CN and Subject Alternative Names from the certificates. 3. If a conflict arises, do not allow certs later in the sequence to supersede / override hostnames set earlier in the sequence. However, I'm not sure it's possible to do the opposite (ie. stunnel way) for Radware and get exactly similar behavior. People should be aware that we are potentially catering to one vendor's needs here by adopting the above conflict resolution / certificate hostname extraction model. In any case, it is probably still very handy to show the list of hostnames for which each certificate is valid to the user (ie. in UI's or whatever). What do people think? Stephen On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici samu...@radware.com wrote: Hi Stephen, The difference is whether the user get to specify hostnames or whether this get concluded from the certificate. I agree, that it might be more friendly if we have an immutable hostname field that get cached in lbaas but being read from the certificate and not managed by the end user. -Sam. *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Thursday, June 19, 2014 1:44 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit So... what I'm hearing here is that we might want to support both a 'hostname' and 'order' attribute. Though exact behavior from vendor to vendor when there is name overlap is not likely to be consistent. Note that while we have seen that corner case, it is unusual... so I'm not against having slightly different behavior when there's name overlap from vendor to vendor. Stephen On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici samu...@radware.com wrote: Hi Stephen, Radware Alteon extract the hostname information and the alt subjectAltName from the certificate information. It then do: 1. Find if there is exact match with the name in the https handshake and the ones extracted from the certificate, if there are more than a single match, the 1st one in the order will be used 2. If no match was found than try to use the regexp hostname to match, if you have multiple matches, the 1st one will be used 3. If no match was found than try to use subjectAltName to match. If you have multiple matches, the 1st one will be used 4. If no match than use default certificate -Sam. *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Thursday, June 19, 2014 12:03 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Evg, I do not think stunnel supports an ordered list without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems like it's important to support its behavioral model. It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously, these can overlap, and it's not always reliable to rely on this data from the certs themselves. So, while I have nothing against having an ordered certificate list, stunnel won't use the order here, and stunnel will likely have unexpected behavior if hostnames are duplicated. Would it work for Radware to simply order the (unique) hostnames alphabetically, and put any wildcard certificates at the end of the list? Also, while I'm loathe to ask for details on a proprietary system: How does Radware do SNI *without* hostnames? Isn't that entirely the point of SNI? Client sends a hostname, and server responds with the certificate that applies to that hostname? Thanks, Stephen On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk evge...@radware.com wrote: Hi Stephen, Regarding your comment related to SNI list management and behavior in the RST document: I understand the need to explicitly specify specific certificates for specific hostnames. However we need to deliver lowest common denominator for this feature which every vendor
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Samuel, So at the LBaaS hackathon, Dustin, Carlos and I discussed order vs. hostname and we came to the conclusion that we'd be OK with order on the SNI list / SNI Policy, so long as we also make note that individual back-ends may choose to implement this as a hostname hash lookup, based on hostnames embedded in the cert as the CN or x509v3 Subject Alternative Names. In this case, then, we should specifically not make 'hostname' an attribute of the SNI list / SNI policy object because this information will be extracted by the driver / back-end implementation. I think, though, we all still agree that supporting cipher selection criteria is probably beyond the scope of what we think we can reasonably offer in Juno. Back-ends should plan on using sane defaults for the first release, eh. If you're in agreement with the above, could y'all update the spec, and we'll remove our '-1's? https://review.openstack.org/#/c/98640/ Thanks, Stephen On Thu, Jun 19, 2014 at 6:23 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Samuel, Yes, it's more friendly to extract this information on behalf of the user, but does occasionally break use cases we've seen. It should be possible, when there is hostname overlap, for the user to specify which certificate to use. It sounds like the Radware solution uses certificate ordering to resolve this conflict. stunnel requires the user to specify which certs should be used with which hostnames, and I think balks if you try to repeat a hostname. So in stunnel's case, conflict resolution happens through user configuration. So in both cases, the user specifies some way to do conflict resolution. There's not a reason we couldn't do it the Radware way for stunnel. The algorithm would be: 1. Order configured certificates based on the 'order' attribute. 2. One by one in sequence, extract CN and Subject Alternative Names from the certificates. 3. If a conflict arises, do not allow certs later in the sequence to supersede / override hostnames set earlier in the sequence. However, I'm not sure it's possible to do the opposite (ie. stunnel way) for Radware and get exactly similar behavior. People should be aware that we are potentially catering to one vendor's needs here by adopting the above conflict resolution / certificate hostname extraction model. In any case, it is probably still very handy to show the list of hostnames for which each certificate is valid to the user (ie. in UI's or whatever). What do people think? Stephen On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici samu...@radware.com wrote: Hi Stephen, The difference is whether the user get to specify hostnames or whether this get concluded from the certificate. I agree, that it might be more friendly if we have an immutable hostname field that get cached in lbaas but being read from the certificate and not managed by the end user. -Sam. *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Thursday, June 19, 2014 1:44 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit So... what I'm hearing here is that we might want to support both a 'hostname' and 'order' attribute. Though exact behavior from vendor to vendor when there is name overlap is not likely to be consistent. Note that while we have seen that corner case, it is unusual... so I'm not against having slightly different behavior when there's name overlap from vendor to vendor. Stephen On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici samu...@radware.com wrote: Hi Stephen, Radware Alteon extract the hostname information and the alt subjectAltName from the certificate information. It then do: 1. Find if there is exact match with the name in the https handshake and the ones extracted from the certificate, if there are more than a single match, the 1st one in the order will be used 2. If no match was found than try to use the regexp hostname to match, if you have multiple matches, the 1st one will be used 3. If no match was found than try to use subjectAltName to match. If you have multiple matches, the 1st one will be used 4. If no match than use default certificate -Sam. *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Thursday, June 19, 2014 12:03 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Evg, I do not think stunnel supports an ordered list without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems like it's important to support its behavioral model. It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Stephen, Regarding your comment related to SNI list management and behavior in the RST document: I understand the need to explicitly specify specific certificates for specific hostnames. However we need to deliver lowest common denominator for this feature which every vendor is able to support In this case, specifying hostname for certificate will not be supported by Radware. The original proposal with ordered certificates list may be the lowest common denominator for all vendors and we should find out if this is the case. If not, managing a simple none-ordered list will probably be the lowest common denominator. With the proposed flavors framework considered, extra SNI management capabilities may be represented for providers but meanwhile we should agree on proposal that can be implemented by all vendors. What are your thought on this? Regarding the SNIPolicy, I agree and will change the document accordingly. Thanks, Evg -Original Message- From: Evgeny Fedoruk Sent: Sunday, June 15, 2014 1:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, The document was updated and ready for next review round. Main things that were changed: 1. Comments were addressed 2. No back-end re-encryption supported 3. Intermediate certificates chain supported *Opened question: Should chain be stored in same TLS container of the certificate? Please review Regards, Evgeny -Original Message- From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Wednesday, June 11, 2014 10:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use Barbican on the back end to store the secret under the LBaaS tenant. If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting and force-deleting Barbican, so I don’t think you really gain anything from all the complexity you’re proposing to add to Barbican. -Douglas M. On 6/11/14, 12:57 PM, Doug Wiegley do...@a10networks.com wrote: There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Evg, I do not think stunnel supports an ordered list without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems like it's important to support its behavioral model. It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously, these can overlap, and it's not always reliable to rely on this data from the certs themselves. So, while I have nothing against having an ordered certificate list, stunnel won't use the order here, and stunnel will likely have unexpected behavior if hostnames are duplicated. Would it work for Radware to simply order the (unique) hostnames alphabetically, and put any wildcard certificates at the end of the list? Also, while I'm loathe to ask for details on a proprietary system: How does Radware do SNI *without* hostnames? Isn't that entirely the point of SNI? Client sends a hostname, and server responds with the certificate that applies to that hostname? Thanks, Stephen On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk evge...@radware.com wrote: Hi Stephen, Regarding your comment related to SNI list management and behavior in the RST document: I understand the need to explicitly specify specific certificates for specific hostnames. However we need to deliver lowest common denominator for this feature which every vendor is able to support In this case, specifying hostname for certificate will not be supported by Radware. The original proposal with ordered certificates list may be the lowest common denominator for all vendors and we should find out if this is the case. If not, managing a simple none-ordered list will probably be the lowest common denominator. With the proposed flavors framework considered, extra SNI management capabilities may be represented for providers but meanwhile we should agree on proposal that can be implemented by all vendors. What are your thought on this? Regarding the SNIPolicy, I agree and will change the document accordingly. Thanks, Evg -Original Message- From: Evgeny Fedoruk Sent: Sunday, June 15, 2014 1:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, The document was updated and ready for next review round. Main things that were changed: 1. Comments were addressed 2. No back-end re-encryption supported 3. Intermediate certificates chain supported *Opened question: Should chain be stored in same TLS container of the certificate? Please review Regards, Evgeny -Original Message- From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Wednesday, June 11, 2014 10:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use Barbican on the back end to store the secret under the LBaaS tenant. If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting and force-deleting Barbican, so I don’t think you really gain anything from all the complexity you’re proposing to add to Barbican. -Douglas M. On 6/11/14, 12:57 PM, Doug Wiegley do...@a10networks.com wrote: There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Stephen, Radware Alteon extract the hostname information and the alt subjectAltName from the certificate information. It then do: 1. Find if there is exact match with the name in the https handshake and the ones extracted from the certificate, if there are more than a single match, the 1st one in the order will be used 2. If no match was found than try to use the regexp hostname to match, if you have multiple matches, the 1st one will be used 3. If no match was found than try to use subjectAltName to match. If you have multiple matches, the 1st one will be used 4. If no match than use default certificate -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, June 19, 2014 12:03 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Evg, I do not think stunnel supports an ordered list without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems like it's important to support its behavioral model. It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously, these can overlap, and it's not always reliable to rely on this data from the certs themselves. So, while I have nothing against having an ordered certificate list, stunnel won't use the order here, and stunnel will likely have unexpected behavior if hostnames are duplicated. Would it work for Radware to simply order the (unique) hostnames alphabetically, and put any wildcard certificates at the end of the list? Also, while I'm loathe to ask for details on a proprietary system: How does Radware do SNI *without* hostnames? Isn't that entirely the point of SNI? Client sends a hostname, and server responds with the certificate that applies to that hostname? Thanks, Stephen On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com wrote: Hi Stephen, Regarding your comment related to SNI list management and behavior in the RST document: I understand the need to explicitly specify specific certificates for specific hostnames. However we need to deliver lowest common denominator for this feature which every vendor is able to support In this case, specifying hostname for certificate will not be supported by Radware. The original proposal with ordered certificates list may be the lowest common denominator for all vendors and we should find out if this is the case. If not, managing a simple none-ordered list will probably be the lowest common denominator. With the proposed flavors framework considered, extra SNI management capabilities may be represented for providers but meanwhile we should agree on proposal that can be implemented by all vendors. What are your thought on this? Regarding the SNIPolicy, I agree and will change the document accordingly. Thanks, Evg -Original Message- From: Evgeny Fedoruk Sent: Sunday, June 15, 2014 1:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, The document was updated and ready for next review round. Main things that were changed: 1. Comments were addressed 2. No back-end re-encryption supported 3. Intermediate certificates chain supported *Opened question: Should chain be stored in same TLS container of the certificate? Please review Regards, Evgeny -Original Message- From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com] Sent: Wednesday, June 11, 2014 10:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use Barbican on the back end to store the secret under the LBaaS tenant. If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting and force-deleting Barbican, so I don’t think you really gain anything from all
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
So... what I'm hearing here is that we might want to support both a 'hostname' and 'order' attribute. Though exact behavior from vendor to vendor when there is name overlap is not likely to be consistent. Note that while we have seen that corner case, it is unusual... so I'm not against having slightly different behavior when there's name overlap from vendor to vendor. Stephen On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici samu...@radware.com wrote: Hi Stephen, Radware Alteon extract the hostname information and the alt subjectAltName from the certificate information. It then do: 1. Find if there is exact match with the name in the https handshake and the ones extracted from the certificate, if there are more than a single match, the 1st one in the order will be used 2. If no match was found than try to use the regexp hostname to match, if you have multiple matches, the 1st one will be used 3. If no match was found than try to use subjectAltName to match. If you have multiple matches, the 1st one will be used 4. If no match than use default certificate -Sam. *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Thursday, June 19, 2014 12:03 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Evg, I do not think stunnel supports an ordered list without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems like it's important to support its behavioral model. It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously, these can overlap, and it's not always reliable to rely on this data from the certs themselves. So, while I have nothing against having an ordered certificate list, stunnel won't use the order here, and stunnel will likely have unexpected behavior if hostnames are duplicated. Would it work for Radware to simply order the (unique) hostnames alphabetically, and put any wildcard certificates at the end of the list? Also, while I'm loathe to ask for details on a proprietary system: How does Radware do SNI *without* hostnames? Isn't that entirely the point of SNI? Client sends a hostname, and server responds with the certificate that applies to that hostname? Thanks, Stephen On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk evge...@radware.com wrote: Hi Stephen, Regarding your comment related to SNI list management and behavior in the RST document: I understand the need to explicitly specify specific certificates for specific hostnames. However we need to deliver lowest common denominator for this feature which every vendor is able to support In this case, specifying hostname for certificate will not be supported by Radware. The original proposal with ordered certificates list may be the lowest common denominator for all vendors and we should find out if this is the case. If not, managing a simple none-ordered list will probably be the lowest common denominator. With the proposed flavors framework considered, extra SNI management capabilities may be represented for providers but meanwhile we should agree on proposal that can be implemented by all vendors. What are your thought on this? Regarding the SNIPolicy, I agree and will change the document accordingly. Thanks, Evg -Original Message- From: Evgeny Fedoruk Sent: Sunday, June 15, 2014 1:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, The document was updated and ready for next review round. Main things that were changed: 1. Comments were addressed 2. No back-end re-encryption supported 3. Intermediate certificates chain supported *Opened question: Should chain be stored in same TLS container of the certificate? Please review Regards, Evgeny -Original Message- From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Wednesday, June 11, 2014 10:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi All, The document was updated and ready for next review round. Main things that were changed: 1. Comments were addressed 2. No back-end re-encryption supported 3. Intermediate certificates chain supported *Opened question: Should chain be stored in same TLS container of the certificate? Please review Regards, Evgeny -Original Message- From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Wednesday, June 11, 2014 10:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use Barbican on the back end to store the secret under the LBaaS tenant. If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting and force-deleting Barbican, so I don’t think you really gain anything from all the complexity you’re proposing to add to Barbican. -Douglas M. On 6/11/14, 12:57 PM, Doug Wiegley do...@a10networks.com wrote: There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Doug, Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround for your use case. Our recommendation was that there are two options for dealing with Secrets being deleted from under you: If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use Barbican on the back end to store the secret under the LBaaS tenant. If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting and force-deleting Barbican, so I don’t think you really gain anything from all the complexity you’re proposing to add to Barbican. -Douglas M. On 6/11/14, 12:57 PM, Doug Wiegley do...@a10networks.com wrote: There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will register itself in meta-data while retrieving container, how that registration will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit (https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, A Spec. RST document for LBaaS TLS support was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny ___ 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
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will register itself in meta-data while retrieving container, how that registration will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit (https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, A Spec. RST document for LBaaS TLS support was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will register itself in meta-data while retrieving container, how that registration will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit (https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will register itself
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
From an LBaaS view we have two use cases we access the certs: 1) When a new LB is build, an LB is changed, etc. -- we throw an error if the certificate is missing, broken, etc, 2) When we want to failover -- we use the last good certificate from a safe place (aka local copy, barbican copy, etc.) Establishing a safe place outside Barbican has its drawbacks, e.g. a user's cert is compromised and he rather wants failover, etc. to fail then run any longer with the compromised cert -- So and that is a question back to Barbican. Can the normal delete just be a flag, e.g. deleted but still preserves the certificate and LBaaS can decide if they throw an error or utilize the deleted cert. And then we have an rm -f which nukes it and has side effects... German -Original Message- From: Doug Wiegley [mailto:do...@a10networks.com] Sent: Wednesday, June 11, 2014 10:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, Clark, Robert Graham robert.cl...@hp.com wrote: Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement. -Original Message- From: Eichberger, German Sent: 11 June 2014 17:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Sorry, I am late to the party. Holding the shadow copy in the backend is a fine solution. Also, if containers are immutable can they be deleted at all? Can we make a requirement that a user can't delete a container in Barbican? German -Original Message- From: Eichberger, German Sent: Wednesday, June 11, 2014 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi, I think the previous solution is easier for a user to understand. The referenced container got tampered/deleted we throw an error - but keep existing load balancers intact. With the shadow container we get additional complexity and the user might be confused where the values are coming from. German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Tuesday, June 10, 2014 12:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: * The end user can delete a container and leave a dangling reference in LBaaS. * It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. * In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit's etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will register itself in meta-data while retrieving container, how that registration will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit (https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, A Spec. RST document for LBaaS TLS support was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny ___ 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 support RST document on Gerrit
Ok but we still need input from Stephen Balukoff and Jorge to see how this will integrate with the API being proposed. I'm not sure if they were intending to use the attributes your discussing as well as which object was going to contain them. On Jun 10, 2014, at 6:13 AM, Evgeny Fedoruk evge...@radware.com wrote: Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit’s etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will “register” itself in meta-data while retrieving container, how that “registration” will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit (https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, A Spec. RST document for LBaaS TLS support was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny ___ 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 support RST document on Gerrit
I responded in the other thread just now, but I did want to say: The problem with a dangling reference is this might mean that the associated Listener breaks at some random time after the barbican container goes away. While this is intuitive and expected behavior if it happens shortly after the barbican container disappears, I think it would be very unexpected if it happens weeks or months after the barbican container goes away (and would probably result in a troubleshooting nightmare). Having had to deal with many of these in the course of my career, I really dislike ticking time bombs like this, so I'm starting to be convinced that the approach Adam Harwell recommended in the other thread (ie. keep shadow copies of containers) is probably the most graceful way to handle dangling references, even if it does mean that when a user deletes a container, it isn't really gone yet. So! If we're not going to tie into an eventing or notification system which would cause a Listener to break immediately after a connected barbican container is deleted, then I think Adam's approach is the next best alternative. Also: Samuel: I agree that it would be great to be able to add meta-data so that the user can be made easily aware of which of their barbican containers are in use by LBaaS listeners. Stephen On Tue, Jun 10, 2014 at 12:17 PM, Carlos Garza carlos.ga...@rackspace.com wrote: See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas. He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be used. On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com wrote: To elaborate on the case where containers get deleted while LBaaS still references it. We think that the following approach will do: · The end user can delete a container and leave a “dangling” reference in LBaaS. · It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information. · In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container. Regards, -Sam. From: Evgeny Fedoruk Sent: Tuesday, June 10, 2014 2:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit’s etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will “register” itself in meta-data while retrieving container, how that “registration” will be removed when VIP listener stops using the certificate? Please comment on these points and review the document on gerrit ( https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. Thank you! Evgeny From: Evgeny Fedoruk Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document
Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi Evgeny, Comments inline. On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk evge...@radware.com wrote: Hi All, Carlos, Vivek, German, thanks for reviewing the RST doc. There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc. Other issues will be commented on the document itself. 1. Support/No support in JUNO Referring to summit’s etherpad https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, a. SNI certificates list was decided to be supported. Was decision made not to support it? Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. SNI support is a show stopper for us if it's not there. We have too many production services which rely on SNI working for us not to have this feature going forward. I'm not sure I understand what you're proposing when you say Single certificate with multiple domains can only partly address the need for SNI, still, different applications on back-end will need different certificates. In order to fully support SNI, you simply need to be able to specify alternate certificate/key(s) to use indexed by the hostname with which the non-default certificate(s) correspond. And honestly, if you're going to implement TLS termination support at all, then adding SNI is a pretty trivial next step. b. Back-end re-encryption was decided to be supported. Was decision made not to support it? So, some operators have said they need this eventually, but I think the plan was to hold off on both re-encryption and any kind of client certificate authentication in this release cycle. I could be remembering the discussion on this incorrectly, though, so others should feel free to correct me on this. c. With front-end client authentication and back-end server authentication not supported, Should certificate chains be supported? Certificate chains are a different beast entirely. What I mean by that is: Any given front-end (ie. server) certificate issued by an authoritative CA today may need intermediate certificates supplied for most browsers to trust the issued certificate implicitly. (Most do, in my experience.) Therefore, in order to effectively do TLS offload at all, we need to be able to supply an intermediate CA chain which will be supplied with the server cert when a client connects to the service. If you're talking about the CA bundle or chain which will be used to verify client certificates when we offer that feature... then no, we don't need that until we offer the feature. 2. Barbican TLS containers a. TLS containers are immutable. b. TLS container is allowed to be deleted, always. i. Even when it is used by LBaaS VIP listener (or other service). ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener iii. If every VIP listener will “register” itself in meta-data while retrieving container, how that “registration” will be removed when VIP listener stops using the certificate? So, there's other discussion of these points in previous replies in this thread, but to summarize: * There are multiple strategies for handling barbican container deletion, and I favor the one suggested by Adam of creating shadow versions of any referenced containers. I specifically do not like the one which allows for dangling references, as this could mean the associated listener breaks weeks or months after the barbican container was deleted (assuming no eventing system is used, which it sounds like people are against.) * Meta data on container is a good idea, IMO. Perhaps we might consider simply leaving generic meta-data which is essentially a note to the barbican system, or any GUI referencing the cert to check with the LBaaS service to see which listeners are using the cert? This wouldn't need to be cleaned up, because if the container actually isn't in use by LBaaS anymore, then LBaaS would simply respond that nothing is using the cert anymore. Please comment on these points and review the document on gerrit ( https://review.openstack.org/#/c/98640) I will update the document with decisions on above topics. I shall try to make sure I have time to review the document later today or tomorrow. 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] [Neutron][LBaaS] TLS support RST document on Gerrit
Hi All, A Spec. RST document for LBaaS TLS support was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
