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
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
is more often
used throughout the industry, it is used in this book as a synonym for both
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
precisely, an X.509v3 digital certificate). It also needs a
private key
also referred to as a secret key) that belongs to the certificate, because only the
possession of the private key
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
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
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.

Get DCE Replacement Strategies now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.