Defining the relationship between innovation

When you deploy Tivoli Identity Manager into a production environment, we strongly recommend that all communication between Tivoli Identity Manager components, depicted in Figure 3-1 on page 80, is secured. The Secure Sockets Layer (SSL) protocol is used to secure communication in the Tivoli Identity Manager environment, because it provides endpoint authentication and communications privacy over the network using cryptography.

In a typical use case where a browser connects to a Web server application, only the server is authenticated while the client remains unauthenticated. In this case, the server provides a set of symmetric keys for encryption that are only valid while the particular session between the browser and the server is active.

Mutually authenticated SSL sessions, as used between the Tivoli Identity Manager components, require the use of public key cryptography between the participants. Encryption of data is provided using the public-key cryptography algorithm, also known as asymmetric key cryptography.

Public key cryptography allows users to communicate securely using a pair of cryptographic keys, designated as public key and private key, which are related mathematically.⁶ The private key is kept secret, whereas the public key can be widely distributed. A sender encrypts a message using the public key of the recipient who can decrypt the message using the private key. Thus, participants

Note: For the latest information about specific levels and required fix packs for OS and middleware components, always refer to IBM Tivoli Identity Manager Version 5.0: Product overview, Release Notes section.

6 For more details about public key cryptography refer to:

http://en.wikipedia.org/wiki/Public_key

in a mutually authenticated SSL communication have to exchange the public key before they can encrypt any information.

Also, public-key cryptography is built on trust. The recipient of a public key needs to have confidence that the key really belongs to the sender and not to a

fraudulent party. Digital certificates provide that confidence. A digital certificate serves two purposes:

򐂰 it establishes the owner’s identity.

򐂰 It makes the owner’s public key available.

A digital certificate is issued by a trusted authority—a certificate authority (CA)—and is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced.

The digital certificate contains specific pieces of information about the identity of the certificate owner and about the certificate authority, including:

򐂰 The owner’s distinguished name

򐂰 The owner’s public key

򐂰 The date the digital certificate was issued

򐂰 The date the digital certificate expires

򐂰 The issuer’s distinguished name

򐂰 The issuer’s digital signature

You can use self-signed certificates to test an SSL configuration before you create and install a signed certificate issued by a certificate authority. A self-signed certificate contains a public key, information about the owner of the certificate, and the owner’s signature. It has an associated private key, but it does not verify the origin of the certificate through a third-party certificate authority.

A self-signed certificate serves as both a CA certificate and a certificate. You use a key management utility to generate a self-signed certificate and private key, and then you extract the self-signed certificate and add it to a truststore of the communicating application to serve as the CA certificate. Note that you do not include the private key in the file when you extract a self-signed certificate.

The Tivoli Identity Manager Server takes advantage of the WebSphere

Application Server SSL keystore and SSL truststore for the SSL communication with adapters:

򐂰 The SSL keystore is a key database file designated as a keystore that contains the SSL certificate.

򐂰 The SSL truststore is a key database file designated as a truststore that contains the list of signer certificates (CA certificates) that define which certificates the SSL protocol trusts.

Chapter 3. Installation 85 In the other words, only a certificate issued by one of these listed trusted signers is accepted.

Note that the keystore and truststore can be the same physical file but this practice usually is not the best security practice.

If enabling SSL communication between the Tivoli Identity Manager Server and an adapter, the configuration of Tivoli Identity Manager Server does not require any specific parameters. The only setup that is required on the Tivoli Identity Manager Server side is to configure the keystore and truststore properly in WebSphere Application Server.

If the Tivoli Identity Manager Server has to communicate to the directory server using LDAP over SSL, in addition to creating appropriate keystore and truststore in WebSphere Application Server, you need to update the Tivoli Identity Manager properties file (called enRoleLDAPConnection.properties) with the following parameters:

java.naming.provider.url=<ldap host>:<ldap port>

java.naming.security.protocol=ssl

For instructions about how to enable SSL on the directory server, use the applicable directory server documentation or the documentation about security that is available in the IBM Tivoli Identity Manager Information Center:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=

/com.ibm.itim.doc/welcome.htm

We discuss how to enable SSL for the adapter in 3.4, “Adapter installation and configuration” on page 93.

3.2.1 Certificate and key formats

Certificates and keys are stored in files with the following formats:

򐂰 .pem format

A privacy-enhanced mail (.pem) format file begins and ends with the following lines:

---BEGIN ---END

CERTIFICATE---A .pem file format supports multiple digital certificates, including a certificate chain. If your organization uses certificate chaining, you can use this format to create CA certificates.

򐂰 .arm format

An .arm file contains a base-64 encoded ASCII representation of a certificate, including its public key, but not its private key. An .arm file format is generated and used by the IBM Key Management utility. You can specify this format to extract a self-signed certificate from the machine on which the self-signed certificate was generated to the machine that will use the self-signed certificate as the CA certificate.

򐂰 .der format

A .der file contains binary data. A .der file can be used only for a single certificate, unlike a .pem file, which can contain multiple certificates. You can specify this format to extract a self-signed certificate from the machine on which the self-signed certificate was generated to the machine that will use the self-signed certificate as the CA certificate.

򐂰 .pfx format (PKCS12)

A PKCS12 file is a portable file that contains a certificate (CA-issued certificate or self-signed certificate) and a corresponding private key. This format enables you to transfer the contents of a keystore to a separate machine. For example, you can create and install a certificate and private key using the IBM Key Management utility, export the certificate and key to a PKCS12 file, and then import the file into another keystore. This format is also useful for converting from one type of SSL implementation to a different one.

However, as this format contains a private key it is considered a non-secure way for managing certificates and it is not a recommended approach for the certificate management.

3.2.2 SSL handshake

The two nodes that participate in SSL communication exchange signed digital certificates in the authentication phase also known as an SSL handshake. The following steps describe typical SSL handshake communication:

1. The client sends a client “hello” message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.

2. The server responds with a server “hello” message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number.⁷

7 Note that the client and the server must support at least one common cipher suite, or the handshake fails. The server generally chooses the strongest common cipher suite.

Chapter 3. Installation 87 3. The server sends its digital certificate (for example, the server uses X.509 V3

digital certificates with SSL). If the server uses SSL V3 and if the server application (for example, the Web server) requires a digital certificate for client authentication, the server sends a “digital certificate request” message. In the

“digital certificate request” message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.

4. The server sends a server “hello done” message and waits for a client response.

5. Upon receipt of the server “hello done” message, the client verifies the validity of the server’s digital certificate and checks that the server’s “hello”

parameters are acceptable. If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a “no digital certificate” alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory. The negotiation that requires the client to provide a certificate to the server is called two-way SSL, or mutual SSL.

6. The client sends a “client key exchange” message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server. If the client sent a digital certificate to the server, the client sends a “digital certificate verify” message signed with the client’s private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.

7. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then, the client sends a “change cipher spec” message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the “finished” message) is the first message encrypted with this cipher method and keys.

8. The server responds with a “change cipher spec” and a “finished” message of its own.

9. The SSL handshake ends, and encrypted application data can be sent.

Note: An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.