Open Stack

Hi All!

It would be great if we could discuss the TLS extension proposal during our next LBaaS IRC meeting
I will then put it as a spec on gerrit.
Please, see the document at https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
and reply with your feedback

Thank you!
Evgeny

From: Evgeny Fedoruk
Sent: Friday, May 30, 2014 2:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Hi,

WIKI page was updated https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
It includes our last comments.
In highlights:

·         TLS instead of SSL

·         Storing certificates and keys in Barbican’s certificate containers

·         VIP listener TLS settings scenarios

·         No client authentication on front-end or back-end server authentication on back-end in first phase

Please review and comment

Thanks,
Evgeny

From: Evgeny Fedoruk
Sent: Tuesday, May 27, 2014 6:10 PM
To: Carlos Garza; Samuel Bercovici
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Hi Carlos,

I am working to update the wiki (https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL ) to include all the information bellow and the discussions from the summit.
I think that I will be done by tomorrow and will want initial feedback on ML before I create the blue print for this.

The key changes are:

1.       All APIs start with TLS

2.       Remove the client authentication and backend server authentication

3.       Merging the “old” proposal with Stephen’s proposal

4.       Assuming the X509+key can be referenced as a single ID available from Barbican

Thanks,
Evgeny



From: Carlos Garza [mailto:carlos.garza at rackspace.com]
Sent: Friday, May 23, 2014 6:39 AM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List (not for usage questions); Evgeny Fedoruk
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Clearing up Certificate, public Key Confusion.
Observe the diagram certs_and_keys.png or the dot file that generated it.
[cid:image001.png at 01CF7AA6.0DED0270]


You will notice that private keys contain the public keys inside them.
Most people think of asymmetric in terms of key pairs but in reality the
public key contains a few attributes of the private key.  In Java bouncy
castle PrivateKeys are a subclass of Public key. In OpenSSL's C library
the same structure is used for both private and public with the exception
that the private attributes are nulled out when using the RSA structure
in a public context.


    The point is that if you have the private key then you also have the
public key for free.


    X509 certificates were meant to be a generic way of signing public
keys. By generic I mean to say that the SubjectPublicKeyInfo structure
has an Algorithm identifier that declares what type of public key is used.
In the example above the actual publicKey I'm showing how an
X509Certificate can use DSA RSA and Eliptic curves. If in the future a
new public key algorithm arrives it can be worked into X509 by assigning
a new publicKeyAlgorthm to it. So we should consider the case where users
may not be submitting an RSA x509 like were all used to.

    So with this in mind it should noted that there is no private part
of a certificate. Everything in it(the x509) is public. Notice their are no
links to the private key from the x509. Perhaps this confusion came from
the fact that certs and private keys are usually installed together and
that this may have led to the confusion by interchanging the words vert
with public key since they may previously have known that every private_key
has an associated public_key. IE encrypt with the public key and decrypt with
the private key. Just keep in mind that in any future documents we
must be careful not to interchange the two words.
                                                                         V
    I would advocate we accept only Pem Encoded Certificates as it seems
pretty standard enough and it fits in a string . Be they their native
encodings such as PKCS1 or what ever RFC defined their encoding or the
more generic PKCS8.  PKCS8 is flexible in that it can be used to store
different types of keys. Keep in mind that pkcs8 also allows for private
keys to be encrypted so any menthols that attempt to decode pkcs8 should
have an optional password field.

                                                                          ^

   In many cases the user of a service has a requirement that the private
key be generated on the decrypting machine(In this case our virtual
loadbalancer) and that the private key never leave this machine so we
should consider having the ability for our lbaas service (or Barbican) generate
the private key and return a CSR(pkcs10) for key back to the user for
signing. After signing this into an X509 the user will pass this
certificate back into our api and associate it with a key. In this
scenario even the user doesn't have access to their own key. Well unless
they query the API to fetch it out I suppose. :(
What are your thoughts on this. I know barbican aspires to be capable of
this I will talk with them tomorrow and see how far along they are.

Is any one going to start the blue print? If not does any one mind if I take a shot?



On May 22, 2014, at 1:44 PM, Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>
 wrote:

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140601/6f048c18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 84474 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140601/6f048c18/attachment-0001.png>