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@nordu.net> To: "NSI Working Group" <nsi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg