|
![]() |
Implementing Web Site Client
Authentication Using Digital IDs
Summary This paper is designed to help system administrators implement VeriSign Digital IDs to control user access to their web servers. Compared to traditional password control, Digital IDs provide a web site enhanced security, a better user experience, increased return on investment, and enhanced marketing capabilities. If you are not familiar with Digital IDs or need more information on the benefits of using Digital IDs instead of passwords for client authentication, see the VeriSign white paper Web Site Client Authentication Using Digital IDs at http:// digitalid.verisign.com/info_ctr.htm. This document is not intended to replace your existing server
documentation;
it is to be used in conjunction with the documentation to assist in implementing
client authentication.
Organizations that use the low cost Internet to market services or products have recognized the need to control access to their web site to verified customers. To date, this web site control has been primarily through a traditional user name and password implementation. Indeed, most web servers include mechanisms to easily create these user name/password lists. However, even though these user name/password lists are easy to set up, organizations who use the "out of the box" implementations are limited to marketing only low value products or services due to the ease in which hackers can intercept password information. Those sites that resort to coding a more complex password implementation in order to thwart information theft often find a cumbersome user experience which only reduces--not eliminates--the risk of password theft. Digital IDs (digital certificates) give web sites the only control mechanism available today that implements easily, provides enhanced security over passwords, and enables a better user experience. Digital IDs have been available for several years, encrypting the transaction stream between server and client (browser) software via a technology called the Secure Sockets Layer (SSL). Whereas the previous SSL version (SSL 2.0) provided only for server authentication (only the server needed a Digital ID), the current version (SSL 3.0) provides for client authentication, with both a web site and a client using Digital IDs to provide mutual authentication and support transaction non-repudiation. There are several steps required to fully implement client authentication on a web server:
When a user accesses your site, their certificate is automatically mapped
to their name in the ACL, providing seamless site access with no need to
enter their user name and password.
As previously mentioned, the SSL technology provides two functions: encrypting the information flow between client and server and forming the basis for mutual client/server authentication. SSL was developed by Netscape in 1994, and is currently in its third revision. It is supported by the popular client applications (Netscape Navigator, Microsoft Internet Explorer), most server applications (Netscape, Microsoft, Apache, Oracle, NSCA, and many others), and Certification Authorities (CAs) such as VeriSign. The SSL infrastructure is widely used throughout the Internet. SSL relies on the concept of a secure channel. This channel guarantees confidentiality in that all messages that pass over it are optionally encrypted. SSL does not encrypt any information stored on either the client or server. SSL integrates security beneath application protocols such as HTTP, NNTP, and Telnet. SSL provides a security "handshake" to initiate a TCP/IP connection, resulting in the client and server agreeing to the security level used, and fulfilling any Digital ID authentication requirements for the connection. From this point on, if message encryption is active (the default state), SSL encrypts and decrypts the byte stream of the application protocol being used. This means that all the information in both the HTTP request and the HTTP response is fully encrypted, including the URL the client is requesting, any submitted form contents, any HTTP access authorization information, and all the data returned from the server to the client. Because HTTP+SSL (or "https") and HTTP are different protocols and typically reside on different ports (443 and 80, respectively), the same system can run secure and insecure HTTP servers simultaneously. This means you can provide some information to all users using no security, and other information to some users with security. For example, a "storefront" and merchandise catalog could be insecure, while ordering and payment forms could be secure. SSL uses public key cryptography to exchange a session key between the client and server. This session key is uniquely generated for each client/server connection and is used to encrypt the HTTP transaction (both request and response). Public-key cryptography is used only for mutual verification and to encrypt the session key; SSL uses symmetric key encryption (which operates significantly faster than Public-key cryptography) to encrypt the session. Each transaction uses a different session key, so even the theft of one key (however remote) does not result in multiple session eavesdropping. New web client applications embed CA keys from VeriSign. These embedded keys enable client applications to verify server legitimacy by inspecting both the server identity and the CA identity that issued the server's certificate. SSL requires a server to have a Secure Server Digital ID issued by a trusted Certificate Authority such as VeriSign. This SSL client/server verification process occurs transparently. Adding any security layer to a transaction will slow server processes somewhat, and SSL is no exception. The overhead, however, is light, and the benefits where security is needed greatly outweigh the risks. And SSL provides myriad advantages for online commerce and network raccess that are best implemented using Digital IDs. SSL uses a series of client/server handshakes to enable a secure session. The two major phases of the SSL protocol are:
The major SSL protocols are described below. While the process may seem lengthy and complicated, it is completely transparent to the user and is established immediately at the initial client/server connection. The graphics use the following legend:
This first step occurs when the client application tries to connect to a secure page. The application first sends a random challenge string to the server, then chooses-on behalf of the user-which suite of encryption protocols to use (based on those installed in the application). The client application must choose a session key exchange (server authentication) algorithm (such as DES), a private key encryption algorithm (such as RC2 or RC4), and a message integrity (hashing) algorithm (such as MD5) to use during the secure transaction. There are many other algorithms which could be used.
The server asserts its identity by returning its secure server certificate plus an acknowledgment that it can support the set of algorithms chosen by the client. It also generates a random connection identifier to be used throughout the communications phase.
The client application verifies the server certificate by comparing the signature of the certification authority (CA) in the server's certificate to the public key of the CA embedded in the client application. If the client does not have a CA key, or the client CA certificate does not match the server CA, the user receives a message warning that this server contains a certificate not known by the client application. The user is given the opportunity to cancel the session, always trust the new CA certificate, or trust the CA certificate only for the current session.
After verifying the server, the client generates a master session key. This master session key is used as the seed to generate the client and server communications keys. Two symmetric key-pair sets are used: one for incoming communications and one for out going communications. Because the single master key was used as the seed, the server write-key equals the client read-key, and the server read-key equals the client write key. It is important that the master session key is generated by the client-not the server-thus providing another security layer to the user. Finally, the client encrypts the session key with the server public key (contained in the server certificate) and sends it to the server. The client ends its part of the private communications phase by encrypting the server connection identifier using the server-write (client-read) key. The client then waits to receive the Server Finish message to prove that the secure channel is complete. The server decrypts the master session key using the server private key and uses the session key to create the corresponding server key pairs. The server then returns the initial client challenge phrase, encrypted with the server-write key. This is confirmation of server authenticity, as only the master session key could have created the key used to encrypt the client challenge message.
At this point the server is authenticated, the communications protocols are set, and the client authentication phase begins. Assuming the web site is configured to accept client certificates, the server now requests that the client present a valid client Digital ID, and sends the client a new challenge phrase, encrypted using the server-write key.
If the client does not have a certificate, the client responds with an error message. Otherwise, the client decrypts the server challenge phrase (using the client-read key) and forms a response phrase consisting of an MD5 hash of the server challenge phrase plus the server certificate. This response phrase, plus the client certificate, is digitally signed with the client's private key and then returned to the server.
The server verifies the client authenticity in two ways: first by verifying that the client certificate is issued by a trusted CA by checking the certificate signature against its internal list of trusted CA roots, and second by rehashing the server challenge phrase plus the server certificate and matching this hash with the client response phrase hash.
Finally, the server ends its phase two role by sending the client a unique
session identifier number encrypted with the server-write (client-read)
key. This unique session-id is used throughout the remainder of the session,
eliminating the need for future handshaking, which could slow server
performance.
Operating a secure site is widely regarded as an essential feature for organizations providing services or merchandise on the Internet. This is because without any security-in this case SSL-the user name, password, personal information, or credit card data typically used to enable site access or purchase products are sent in the clear and can be easily intercepted. By enabling SSL, the login name, password, and any transaction data are encrypted. Additionally, using a client Digital ID in conjunction with SSL instead of passwords further increases the site security. An essential requirement for SSL is a secure server certificate. This certificate authenticates your site to any client that accesses the server and provides the mechanism for the client to initiate the secure session. (See Client Authentication and SSL above.) While client-side Digital IDs are not necessary to establish an SSL-protected channel, server-side certificates are required. The process for obtaining a secure server certificate is:
The procedure for generating the server key pair is detailed in the server documentation. Requesting a VeriSign secure server certificate is a three-step process:
Once you have received the secure sever Digital ID, install it according
to your server documentation.
Advanced Implementations of Digital IDs as User Name/Password Proxy The previous example set up a standard user name/password database and mapped certificates to each name. This method required manual input for each user authorized to use the server. The example also assumed the user already had their own Digital ID. We now enhance the example, adding cases for when the user does not yet have a certificate or is a first time site visitor:
There are four different methods for incorporating certificate content with your ACL (or other user information database) during registration or site access: Existing User, With Certificate This method was described in How the Digital ID works as a user name/password proxy above. In this method, the site would encourage certificate upgrade by offering enhanced services available to certificate holders. The user would be redirected to the VeriSign Digital ID center to obtain their certificate. After receiving their certificate, they could be directed back to the exact spot they left. Afterwards, when the certificate is presented, it is mapped to the existing user name as previously described. With this method, sites use their normal registration process, either manual or automatic. During the automatic registration, users would deflect to the VeriSign Digital ID center. If the registration is manual, there would be a link from the site home page to the VeriSign Digital ID center. After the user receives their certificate, they enter the site, present their certificate, enter their new user name/password, and have the certificate automatically mapped to their new ACL entry. Again, the site would use its existing registration process, whether by ACL or another database. After either the automatic or manual entry of the user information and password, the user is instructed to enter their log-in ID. They present a valid certificate, input their new user ID and password, the certificate is matched to the new access entry, and access is granted. It is possible to verify when a user without a certificate comes to the web site, and present the user a page indicating the need for them to obtain a Digital ID. This is done by changing the default error page (error code 401-Unauthorized) presented when a certificate is required but the client does not have one. Figure 1 illustrates an enhanced Web Site Registration Flow Chart. Reading Certificate Content to Provide Personalized Options Another benefit to implementing Digital IDs is that of providing personalized user services. Using certificates with password protection is easy to implement and solves a site's need for access control. In addition, a Digital ID also gives sites an easy method for obtaining user information, and the ability to provide customized services through reading the certificate contents. For example, a site may contain personal information such as found in a white pages directory and need confirmation that the individual listed is the only one able to modify the data. Or a site may wish to greet users by name and provide that user customized content. The VeriSign Certificate Reader is used to extract fields from client
Digital IDs presented to a web server. The Certificate Reader is provided
in two separate implementations. The preferred implementation is a plug-in
server application function (SAF) that is loaded at startup when properly
specified in the server's magnus.conf file, and accessed during a client
session when properly specified in the server's obj.conf file. This
implementation
is recommended for most sites because it offers considerably simpler
installation
and allows future upgrades to be accomplished by simply replacing the SAF
with a new version.
The Internet holds the promise of dramatically changing how organizations market and sell products and services. The low access cost coupled with world-wide presence provides a revolutionary new channel for commerce. But the very openness which makes the Internet so revolutionary is also what makes it risky: a majority of messages transmitted over the Internet are accessible to hackers. Hackers can easily trace user passwords and obtain information they are not authorized to have. Fear from new users of having their credit card information stolen through interception or the faking of an entire web site has prevented a faster adoption of Internet commerce. In order to mitigate the risks associated with doing business on the public Internet, organizations who market services or sell products must first determine how they can restrict-either in part or completely-site access to appropriate customers. To date, the most popular method available for controlling web site access is through user name and password. But the lack of security inherent with passwords forces organizations to make a choice between an easily implemented process but one limited to low value information or inexpensive products, and attempting to provide higher value services but requiring a cumbersome implementation and risk through use. Founded in 1995, VeriSign's mission is providing trust for secure Electronic Commerce through our Digital Authentication services and products. VeriSign works with its investors and partners to continue opening the digital marketplace to all consumers and organizations that serve them. To learn more about how your organization can make its mark on this
new commercial landscape, contact VeriSign at (650) 961-7500, visit our
web site at http:// www.verisign.com.
|
|