 |
 |
  |
|
|
Implementing Web Site Client Authentication Using Digital IDsSM and the Netscape Enterprise Server 2.0
Summary
SummaryThis 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.
Introduction
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.
Client Authentication and SSLAs 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 Overview
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 access that are best implemented using Digital IDs.
SSL Process
SSL uses a series of client/server handshakes to enable
a secure session. The two major phases of the SSL protocol are:
(1) establish private communications and (2) perform client authentication.
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:
Client HelloThis 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.
Server Hello
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.
Client Master Key
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. Client Finish
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. Server Verify
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. Request Certificate
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.
Client certificate
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.
Server Finish
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. Enabling SSL at the Server
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. Activating SSL for your server
After you install your server Digital ID, you activate SSL for
your Enterprise server:
Once SSL is enabled on your server, you can configure your overall
SSL preferences, and specify different strengths of encryption
for different parts of your server. Client Authentication using Digital IDsAfter SSL is enabled on the server, the process for accepting Digital IDs follows easily. Two likely implementation options are to:
Using Digital IDs as a User Name/Password proxy
Sites today control access to specific users by creating
a list of authorized persons along with a password. Implementing
this access control list (ACL) on an Enterprise 2.0 Server with
Digital IDs is accomplished in the following steps:
Creating a user group
Once you have created a group, you can add a user to it. Creating users and assigning them to a group
Once users and groups are created, set the access control for your server. Restricting access control for part of your server
Enable access by certificates
How the Digital ID works as a user name/password proxy
When an existing registered user with a new client certificate
accesses your site, they enter their user name and password. This
is done only once-the first time the site requests the
certificate. Their client certificate is then mapped to their
existing user name. From then on, each time the certificate is
presented, the ACL is automatically accessed and their user privileges
derived. This process works for new or existing registrants, as
well as automatic or manual enrollment. Users never need to remember
their password, and sites do not have to worry about any transition
problems.
Figure 1 illustrates a simple Registration Flow Chart. 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 during registration or site access: Existing user, with certificateThis method was described in How the Digital ID works as a user name/password proxy above. Existing user, no certificateIn 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. New user, no certificateWith 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. New user, with certificate
Again, the site would use its existing registration process.
After either the automatic or manual entry of the user name/password
into the ACL, the user is instructed to enter their log-in ID.
They present a valid certificate, input their new user name/password,
the certificate is matched to the new ACL 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 and
implementing the built-in Netscape API functions as listed in
Appendix A.
Figure 2 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
an ACL 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.
Appendix A provides information on how to modify particular server files to derive the certificate content. By running the certificate through a VeriSign certificate reading tool, sites can easily obtain the certificate contents. Conclusion
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.
The Netscape Enterprise Server provides a flexible
tool for implementing client authentication using VeriSign Digital
IDs.
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,
or send E-mail to clientauth@verisign.com. Appendix A: Reading Certificate ContentSummary
Two new customer-accessible Service Application Functions (SAFs)
were added to the client authentication code. These allow customers
using the NSAPI and CGI to add directives to the server's obj.conf
file so that they can get the requesting client certificate from
their own NSAPI modules or CGI programs while processing a request.
In the Enterprise 2.0 release there will be no support
for controlling these through "admin server" configuration
forms. Customers that need this functionality can only get it
by manually editing their obj.conf
files to include these directives.
Usage:
PathCheck fn="get-client-cert" dorequest={"0"|"1"} [method=<shexp>]
where dorequest is assigned "0" or "1" and
method
is a shell expression (pattern).
Description:
Gets the authenticated client certificate from the
SSL3 session.
If it is not already present on the session, and
the value of dorequest
is not "0", then redo the SSL3 handshake and get it.
When the client is a Navigator, this request triggers a dialog
that allows the client to select a certificate to present.
If the method parameter is given it should be a valid
shell expression. The function will only do anything for those
requests in which the HTTP method matches this pattern. If the
method parameter is absent, the function is applied to all requests.
Using this function allows site administrators to
"trap" when a client application does not have a certificate
present. You can then display a page indicating that the user
needs to enroll for a Digital ID before accessing the site further.
This works for client applications such as Navigator 2.0 as well
as certificate-enabled browsers such as Navigator 3.0.
Return Values:
If a certificate is obtained from the client and
verified successfully by the server, the ASCII base64 encoding
of the DER-encoded X.509 certificate is placed in the parameter
auth-cert
in the Requestvars
parameter block, and the function returns
REQ_PROCEED,
allowing the request to proceed.
If the client's certificate is not obtained and verified,
the function returns REQ_ABORTED
and sets the protocol status to 403
FORBIDDEN, causing the request to fail
and the client to be given the FORBIDDEN
status.
Note: if dorequest
is absent the default value is "0"
Example: # Get the client cert from the session, request one if there is not # already one associated with the session. Fail the request if the # client does not present a valid one. Do this on HTTP GET or POST # requests.
PathCheck fn="get-client-cert"
dorequest="1" method="(GET|POST)"
Usage: PathCheck fn="cert2user" userdb=<authdbpath> makefrombasic={"0"|"1"}
require={"0"|"1"}
method=<shexp> where: makefrombasic is "0" or "1" require is "0" or "1" userdb is the path to the authentication database to use
method
is a shell expression (pattern).
Description:
Map the authenticated client certificate from the
SSL3 session, to a user name using the certificate-to-user mappings
in userdb.
If a client certificate is not already present on
the session, this directive fails (see RETURN VALUES).
If makefrombasic
is present and is not "0", then the directive will
use basic (password) authentication to authenticate the
user and then create a new certificate-to-user mapping in the
specified userdb
if a mapping for the certificate to a user does not exist.
If the method parameter is given it should be a valid
shell expression. The function will only do anything for those
requests in which the HTTP method matches this pattern. If the
method parameter is absent, the function is applied to all requests.
Return Values: If a certificate is successfully mapped to a user name, the values of auth-type, auth-user, and authdb are set in the Requestvars parameter block by the function as follows: auth-type to ssl auth-user to the user name from the user database
authdb
to the database that was used
If the certificate cannot be mapped successfully
to a user name, and the value of require
is present and is "0" the function returns REQ_NOACTION,
allowing the request to proceed, otherwise it returns REQ_ABORTED
and sets the protocol status to 403
FORBIDDEN, causing the request to fail
and the client to be given the FORBIDDEN
status. Note: if makefrombasic is absent, the default value is "0"
if require
is absent, the default value is "1"
Example: # Map the client cert to a user using this userdb. If a mapping is notR # present, fail the request. Do this mapping only for POST requests. PathCheck fn="cert2user" userdb="/usr/ns-home/authdb/default" require="1" method="POST"
CGI Support/Environment
Variables
An environment variable CLIENT_CERT
was added to the environment in which CGI programs are executed.
This environment variable is set from the value of auth-cert
in the Requestvars
if it is present at the time that the send-cgi
directive is executed.
Establishing this value is accomplished using the
Service Application Functions get-client-cert
(and optionally cert2user).
Example: <Object name="cgi"> # # Due to these PathCheck directives, the CGI programs will be executed # only for clients that present certificates on request and for which # the certificate is mapped to a user in the given database. The values # of the following environment variables will be set: # AUTH_TYPE "ssl" # CLIENT_CERT the client's certificate # (base64 encoded DER X.509 certificate # REMOTE_USER the user name to which the cert was mapped. # If only the certificate is desired, the cert2user mapping can be # eliminated. # PathCheck fn="get-client-cert" dorequest="1" PathCheck fn="cert2user" userdb="/usr/people/server/ns-home/authdb/default" require="1" ObjectType fn="force-type" type="magnus-internal/cgi" Service fn="send-cgi"
</Object>
|
|
