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.
PKI Certificates
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.
Certificate Trust
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.h.
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.
SSL Support
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.
SSL Summary
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.