SSL|TLS - The Secure Sockets Layer and Transport Layer Security
I2A2 uses SSL|TLS to conduct private conversations between client system applications and I2A2 servers, including the I2A2 LDAP
protocol converter and the DBM net daemon servants.
A full description of the Secure Socket Layer (SSL) protocol is beyond the scope of this documentation. Consult the SSL Documentation at NetScape, where the protocol was designed.
A recent metomophasis of SSL via an Internet RFC (2246) is called TLS, for Transport Layer Security. In many cases SSL and TLS function identically, but TLS should be considered the most recent and correct instantiation of SSL. The rest of this discussion of TLS|SSL will use the simpler and more well known name SSL.
SSL is based on Public Key Infrastructure (PKI) certificates.
A full description of PKI certificates, usually X.509 certificates, is also beyond the scope of this document. Consult this IETF reference for more information. (IETF stands for Internet Engineering Task Force.)
Public and Private Keys
A basic description of a PKI certificate is that it is a pair of keys, one public and the other private. What has been encrypted
with the public key may only be decrypted with the private one. The private key is less used for encrypting than for signing;
what it signs can be validated with the public key.
The private key is always held in strict confidence and guarded with symmetric encryption controlled by a pass phrase. The private key is never distributed, even when being used to establish a secure exchange. Instead, it is used to decrypt messages that have been encrypted with the public key, sign those messages, and return them for establishing proof that the private key is known.
The public key can be freely distributed.
There are elaborate mechanisms for establishing the trustworthiness of certificates. The
Netscape SSL documentation explains them.
In I2A2's case, the ultimate source of trust is the Purdue Public Certificate. Any client system application that intends to communicate with I2A2 over an SSL connection must have it.
The Purdue public certificate is in the I2A2 Apache Web Server Package. It can also be found here.
SSL Types -- Client-side and Server-side - There are two types of SSL connections, server-side and client-side.
Server-side SSL is established by the server to which a client connects. The server presents a certificate to the client application. If it is acceptable, the channel between the two is encrypted. This is the fundamental SSL method. It provides the secure channel and it allows the client application to verify that it is talking to the intended server.
In I2A2's case, the I2A2 LDAP protocol converter and net daemon DBM servants will present a Purdue certificate that has a known PUID and known certificate serial number in it. (See DBM Certificate Definitions.)
The client application may also present a certificate to the server side. When this is done, the client establishes its identity to the server via the PKI methods provided by the exchange. Client-side SSL may be used with the I2A2 net daemon DBM servants, but is not used with the I2A2 LDAP protocol converter.
In I2A2's case, client-side SSL authentiction establishes a PUID to the net daemon for the client application. The client application must have a Purdue certificate. Contact I2A2 Administration for information on obtaining a Purdue certificate.
DBM Certificate Definitions - The header files contains these definitions related to I2A2 net daemon servant certificates.
PUIDNETD_PUID_OID -- X.509 object ID (OID) for a PUID inside a certificate
PUIDNETD_AUTHC_CSER -- the serial number of the certificate for the authenticator net daemon
PUIDNETD_AUTHC_PUID -- the PUID of the authenticator net daemon, found in its certificate
PUIDNETD_AUTHZ_CSER -- the serial number of the certificate for the authorizer net daemon
PUIDNETD_AUTHZ_PUID -- the PUID of the authorizer net daemon, found in its certificate
PUIDNETD_REFL_CSER -- the serial number of the certificate for the reflector net daemon
PUIDNETD_REFL_PUID -- the PUID of the reflector net daemon, found it its certificate
A client application should use the values associated with these symbols to establish the identity of its peer. The libpuidX external library has support for extracting and checking certificate PUIDs and serial numbers.
The Purdue Certificate OID
The PUID is enclosed in a certificate with a user-defined, standard exception called an "object". The object has an identifier,
an OID, used to extract the value of the object from the certificate. That's why there's a PUIDNETD_PUID_OID definition in
PUIDNETD_PUID_OID is used, for example, in the puid_getcertPUID() function of libpuidX to extract the PUID from a Purdue Certificate.
I2A2 Certificate Definitions
Because most LDAP clients that are used for connecting to the I2A2 LDAP protocol converter do not have provisions for checking
the PUID and serial number of the protocol converter's certificate, no standard I2A2 method can be provided for doing that.
If you have a client that can check the PUID and serial number in the I2A2 LDAP protocol converter, contact us for information on how to do that checking.
SSL clients often use an alternate server verification method, based on checking the server's host name against host names encoded in the server's certificate. The I2A2 LDAP protocol converter's certificate contains host names that can be used by suitable clients for verifying the certificate that way. Check your client to determine if it uses this method of checking the validity of an SSL server's certificate.
For the UNIX environment SSL support is usually provided by the OpenSSL library. Windows
application developers will find SSL support in the
I2A2 PUIDCL Client Access Library.
The OpenSSL library is included in the I2A2 Apache Web Server Package.
In summary the I2A2 client system application developer must keep these things in mind.
- SSL is required when communicating private information to I2A2 -- e.g., passwords for authentication.
- SSL requires some type of library support -- e.g., OpenSSL.
- SSL requires certificates -- the Purdue public certificate at a minimum.
- A client application should check the server's identity, if possible.
For a client application, those steps might include these procedures.
- Establish a TCP/IP connection with the desired net daemon's SSL port.
- Do SSL setup, including the identification of the locations of certificates.
- Open the SSL connection and examine the results of the opening and certificate verification.
- If possible, use the contents of the SSL server's certificate to verify the server's identity.
- Communicate with the net daemon via SSL input and output functions.
The I2A2 PUIDCL Client Access Library provides a high-level interface to do most of those procedures.