DCE Replacement Strategies

116 DCE Replacement Strategies

7.7 SSL implementation hints

Secure Sockets Layer (SSL) Version 3 and Transport Layer Security (TLS)

Version 1 are protocols that provide server authentication, client authentication

(optional), and protection by means of privacy and data integrity between two

communicating entities. Implementations of SSL and TLS are available on many

platforms including AIX, OS/390, OS/400, Linux, Windows 2000, and Solaris.

7.7.1 SSL and TLS overview

SSL is a Netscape proprietary protocol that has become a de facto standard.

TLS is an industry-standard protocol that is based on SSL and defined in IETF

RFC 2246, “TLS Protocol Version 1.0.” Both the SSL and TLS protocols use

standards defined in IETF RFC 2459, “Internet X.509 Public Key Infrastructure

Certificate and CRL Profile.” The two protocols have few differences and often

are referred to interchangeably.

Several products recommended in this book, including IBM WebSphere

Application Server, contain embedded SSL/TLS. Customers can use the

embedded SSL/TLS to replace the DCE authentication and protection services.

The use of SSL is recommended between systems that exchange sensitive data

and/or when strong authentication is required. The major differences between

SSL/TLS and the DCE authentication and protection services are:

 SSL/TLS operates at a transport level, whereas DCE authentication and

protection operates at a higher level.

 When using SSL/TLS, server authentication is required and client

authentication is optional. When using the DCE authentication service, client

authentication is required and server authentication is optional.

 When using SSL/TLS, all of the data transmitted over the connection must be

protected through encryption and integrity. When using DCE, the

authentication service can be used independently of the protection service so

authentication can be performed without data protection or with selected data

protection.

 SSL/TLS uses the public key infrastructure (PKI) protocol for authentication.

DCE uses the Kerberos protocol for authentication. (DCE has the option of

using PKI for initial authentication, but supports only the Kerberos protocol for

client and server authentication.)

The differences between SSL Version 3 and TLS Version 1 are only minor and

not important for the subject of this book. Because the term

SSL

is more often

used throughout the industry, it is used in this book as a synonym for both

protocols.

Chapter 7. Common replacement considerations 117

7.7.2 Uses of SSL

SSL is used for encryption (privacy) and authentication. SSL uses Public Key

Infrastructure (PKI) technology, namely X.509 digital certificates and digital

signatures, to authenticate a server or a client, and the process of authentication

is carried out by the SSL implementation (SSL libraries).

A server or a client that has to authenticate with SSL needs a

certificate

(more

precisely, an X.509v3 digital certificate). It also needs a

private key

(sometimes

also referred to as a secret key) that belongs to the certificate, because only the

possession of the private key

and

the certificate is evidence of authenticity.

7.7.3 Using SSL in the replacement scenarios

Most products mentioned in this book, including DCE, IBM Network

Authentication Service, IBM Directory Server, IBM Tivoli Access Manager, and

IBM WebSphere, support SSL for encryption and authentication when

communicating with other products. Specifically:

 IBM Directory Server supports SSL for the protection of the communication

with its clients.

 DCE, IBM Network Authentication Service, IBM Tivoli Access Manager, and

IBM WebSphere Application Server all support SSL when communicating

with IBM Directory Server.

 IBM WebSphere supports SSL for the CORBA application client to

authenticate to the CORBA application server.

 The HTTP Server, as part of IBM WebSphere, supports SSL for Web

browsers.

Although these products support SSL, and using SSL is recommended for

security reasons wherever feasible, for the sake of simplicity the scenarios in the

Note: In common language, the phrase “authentication with a certificate” is,

strictly speaking, incomplete and misleading. A certificate is, by definition, not

confidential and maybe copied easily. Thus, the possession of a certificate

cannot be proof of authenticity. Only the possession of the

private key

that

belongs to a certificate is considered proof of authenticity. In contrast to

certificates, private keys must not be shared and must be protected by all

means. When a subject authenticates to another subject using SSL and

certificates, a complex handshaking protocol takes place that includes digital

signatures using the private key. The private key, however, is never transmitted

over the network and hence this is strong authentication. The SSL handshake

protocol is transparent to the user or the application.