22.12.2012 Views

Front cover - IBM Redbooks

Front cover - IBM Redbooks

Front cover - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

7.3 X.509 certificates<br />

294 Lotus Security Handbook<br />

Client authentication using X.509 certificates provides for two-way authentication<br />

between a browser user and a server using both SSL and an LDAP directory for<br />

user authentication. Multiple applications that share this same LDAP directory<br />

can use the same certificate authentication. This is not the same as using a<br />

server certificate for server authentication by a client, where the client simply<br />

needs to trust the root CA that issued the server’s certificate. We are focusing on<br />

client authentication performed by a server.<br />

Typically, the client X.509 certificate is password protected, so in this case the<br />

use of X.509 certificates is considered a two-factor authentication method:<br />

something you have (the certificate on the workstation), and something you know<br />

(the password). Because the certificates can also be verified and the revocation<br />

or expiration checked, X.509 certificates can be a very secure method of user<br />

authentication. However, making the X.509 certificate portable (or making it<br />

exportable) so it can be installed into other applications or workstations presents<br />

both logistical issues for the user as well as potential security vulnerabilities. It is<br />

worth mentioning that Internet Explorer stores client X.509 certificates in the<br />

Windows registry. Removing a certificate permanently from a workstation may<br />

require manually removing it from the registry. Smartcards are just beginning to<br />

gain momentum as a means to provide a portable yet secure way to store client<br />

certificates, although the lack of ubiquitous smart card readers on PCs is<br />

definitely hindering their widespread use.<br />

With client authentication, the LDAP client, specifically the browser installed on<br />

the user’s workstation, must have a digital certificate (based on the X.509<br />

standard). In other words, the X.509 certificate contains the user’s credentials<br />

and is passed to the different Web servers that require the same X.509<br />

authentication. The LDAP directory needs to have both the root certificate from<br />

the corresponding CA that issued the client’s certificate, and the client’s public<br />

SSL certificate (key) must be stored in their directory record. This digital<br />

certificate is used to authenticate the LDAP client (browser) to the LDAP<br />

directory being used for authentication. So in order to use X.509 certificates,<br />

there must be an Internet certificate (PKI) infrastructure implemented where<br />

users can obtain X.509 certificates that are trusted by the LDAP directory service<br />

(server) and the user’s public certificate (keys) are stored in the directory.<br />

In addition to SSL authentication of Web browser clients, the Simple<br />

Authentication and Security Layer (SASL) can be used to add X.509 certificate<br />

authentication support to connection-based protocols. A protocol includes a<br />

command for identifying and authenticating a user to a server. It can optionally<br />

negotiate a security layer for subsequent protocol interactions. Specifically, there<br />

are at least seven different types of authentication supported by SASL, but the

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!