[Nsi-wg] Setting up SSL/TLS

[John MacAuley]

Just a few more comments from a programming angle.  This TLS authentication is occurring in the grey area between the TCP/IP transport and application interface (for many of us the servlet interface in the container of our choice).  Your application will not see this TLS authentication, and since it is not being done by HTTP, getting the TLS security context in your servlet may be problematic depending on the environment you are using.

My current plan is to use the DN associated with the remote NSA's public certificate as negotiated during TLS setup.  This is located in the javax.servlet.request.X509Certificate attribute within the servlet HTTP request.  I can then check the discovered DN against provisioned values to identify the remote NSA and authorize as needed.

Remember, this is only securing the transport connection between the two servers and does not necessarily mean we have two authorized NSA communicating.  We will need to look at additional authentication mechanisms to handle this.

John

----- Original Message -----
> From: "Henrik Thostrup Jensen" <htj at nordu.net>
> To: "NSI Working Group" <nsi-wg at ogf.org>
> Sent: Thursday, November 24, 2011 7:13:07 AM
> Subject: [Nsi-wg] Setting up SSL/TLS
> 
> Hi
> 
> As promised just a short introduction to this.
> 
> Some terminology:
> 
> SSL: Secure Socket Layer
> TLS: Transport Layer Security (mostly a new a name for SSL)
> HTTPS: HTTP over SSL/TLS
> 
> Versions:
> SSLv2 is deprecated.
> SSLv3 and TLS 1.0 are quite similar, but not quite the same.
> TLS 1.1 and 1.2 still have very sporadic support.
> SSLv3 and TLS 1.0 is the common thing used today. Don't worry too
> much
> about the SSL/TLS name, it is protocol-negotiable along with ciphers,
> etc.
> and will most likely take care of itself.
> 
> To authenticate a certificate must be used. The typical setup in www
> is
> that only the service has a certificate, so the client can
> authenticate
> the service, but not the other way (this has be done via some other
> means
> then). For NSI, the client should also have a certificate such that
> both
> parties can be identified.
> 
> Getting a "real" certificate, i.e., one signed by a proper
> certificate
> authority (CA) can be a bit tricky. There are commercial providers
> (costs
> money), but often research institutions and NRENs can get them
> through
> Terena or through a grid CA (which would be part of IGTF - The
> International Grid Trust Federation). If this turns out to be
> difficult,
> one can make a self-signed certificate, but this is probably not what
> you
> want for production.
> 
> Regarding authorization, it is usually possible to make a setup where
> no
> checking is done on the CA or the identity of the certificate. This
> can be
> a good way to start, but again, not something suited for production.
> Usually one will have a set of trusted CAs, and a list of identifies
> which
> are authorized (possible with some policy on the side). In the Java
> world
> the CAs are traditionally kept in whats called keystore, but in many
> other
> systems, it is just a directory with the CA files.
> 
> How to setup and implement this, will vary greatly depending on your
> system, so I can't provide any details on this, but most HTTP servers
> support for it. Otherwise a proxy such as NginX can be used in front
> of
> the service. Similarly you will also have to support https on your
> client.
> In fact, this can be a good place to start as your client will then
> be
> able to make requests to https services. For now, I strongly suggest
> using
> a client which can do both http and https, in order to easy the
> transition.
> 
> Once you have acquired a certificate, please update this page
> http://code.google.com/p/ogf-nsi-project/wiki/Certificates.
> 
> Furthermore send the new endpoint of your service to master of the
> topology file (Jerry), so he can update the topology with the new
> endpoint.
> 
> I hope this gives some overview and pointers on how to start. It
> should
> not be that difficult.
> 
> 
>      Best regards, Henrik
> 
>   Henrik Thostrup Jensen <htj at ndgf.org>
>   NORDUnet / Nordic Data Grid Facility.
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>