Netscape Communications Corporation
Taher Elgamal, Chief Scientist
Jeff Treuhaft, Director of Security Products
Frank Chen, Product Manager, Security
Providing robust security services is chief among the challenges faced by information systems teams that are building full-service intranetsttaduxydxvatqxyfdq or connecting to the public Internet. IS teams want to provide such services as single-user login, message privacy, and access control for safeguarding confidential documents. These services need to be provided in a cross-platform (Windows, Macintosh, Unix, etc.) and application independent (Web server, Web client, mail server, news servers, directory server, proxy server, etc.) way.
Fortunately, industry-standard solutions to these challenges are emerging. Cryptography plays a pivotal role in these standard solutions. This technology white paper discusses the motivations, protocols, and Netscape product offerings for deploying cryptographic technology throughout the enterprise and over the public Internet.
This paper covers the following topics:
There are many challenges in building a full-service intranet that provides safe communications and collaboration. As the exponential growth of the public Internet demonstrates, TCP/IP solves many problems in a remarkably scalable way. However, TCP/IP was not designed to offer secure communication services.
Because TCP/IP was not designed with security in mind, we must bring additional technology and policies to bear to solve typical security problems such as the following:
Cryptography is a surprisingly general technology that provides the foundation for each of the security challenges listed above. The next sections describe how public-key technology works and explains its role in industry-standard protocols such as SSL and S/MIME.
What Is Cryptography?
Cryptography comprises a family of technologies that include the following:
All of these technologies make use of sophisticated mathematical techniques. For more information on cryptography, please see RSA's Frequently Asked Questions.
Symmetric-Key and Public-Key Cryptography
Symmetric-key or secret-key cryptography uses the same key to encrypt and decrypt messages. This is a familiar real-world phenomenon: We use the same key to unlock and lock our car doors, for instance. The problem with symmetric-key cryptography is having the sender and receiver agree on a secret key without anyone else finding out. How can they do this? Over the phone, on a floppy disk, using a courier? All of these are cumbersome, slow, and error-prone techniques. In addition, the number of Keys tends to be much larger than the number of nodes; that is, people may have multiple keys they use for different purposes.
Public-key cryptography was invented in 1976 by Whitfield Diffie and Martin Hellman to solve precisely this problem. With public-key cryptography, each person gets a pair of keys, a public key and a private key. Each person's public key is published, while the private key is kept secret. When Alice wants to send Bob a secure message, she encrypts it using Bob's public key. When Bob gets the message, he decrypts it using his private key. The sender and receiver no longer have to share secret information before they can communicate securely.
In practice, both symmetric-key and public-key techniques are used in popular security protocols such as SSL and S/MIME because symmetric-key algorithms tend to be much faster than public-key algorithms. Let's visit Alice and Bob again. They want to communicate securely, but they also want to communicate quickly. Here's what they do:
In reality, most security protocols are much more complicated than this, but the three-step process above gives you an idea of the fundamentals. SSL is an excellent example of a security protocol that uses these techniques to safeguard communications. See our description of how SSL uses symmetric-key and public-key encryption.
Digital certificates, also called digital IDs, digital passports, or public-key certificates, are defined by an ITU standard called X.509. A certificate is the digital equivalent of an employee badge, passport, or driver's license.
The certificate and corresponding private key identify you to someone who needs proof of your identity. If you are pulled over by the highway patrol, you need to show your driver's license to prove that you are legally licensed to drive a car. If you want to get into a secure workplace, you might have to show a badge to prove that you are an employee of the company. If you want to make a credit card purchase, you typically have to show a credit card and demonstrate that you can produce a signature like the one on the back of your card. All of these forms of identification allow you to establish your identity with someone.
Over a network, a certificate serves the same role as a driver's license, employee badge, or credit card: It establishes your identity. Servers may be configured to grant access only to people with particular certificates; similarly, clients may be configured to trust servers that present certain certificates.
What's in a Certificate? An X.509 certificate is typically a small file that contains the information shown in the following table.
|Subject's distinguished name (DN)||A name uniquely identifying the owner of the certificate||C=US, O=Netscape Communications, OU=Technology, CN=Marc Andreessen|
|Issuer's distinguished name (DN)||A name uniquely identifying the certificate authority that signed the certificate||C=US, O=VeriSign, CN=VeriSign Class 1 root|
|Subject's public key||The owner's public key||512-bit RSA key|
|Issuer's signature||The certificate authority's digital signature from which the certificate derives its authenticity||RSA encryption with MD5 hash (signature itself is not human readable)|
|Validity period||Dates between which the certificate is valid||Not before
Wed, Nov 9, 1995, 15:54:17
Fri, Dec 31, 1997, 15:54:17
|Serial number||A unique number generated by the certificate authority for administrative purposes||02:41:00:00:01|
With this overview of public-key technology in mind, let us review the challenges described at the beginning of this paper and see how public-key technology embodied in industry-standard protocols such as SSL and S/MIME offers solutions for those challenges.
|Requirement||Public-Key Technology||Example of Typical Use|
|Authentication of users without username and password in the clear||Digital certificates (X.509)||SSL handshake includes exchange of client and server certificates and corresponding signatures.|
|Single-user login||Digital certificates (X.509)||Servers may be configured to demand digital certificates rather than username/password pairs.|
|Scalability to the Internet||Standards-based encryption and message digest algorithms (for example, RSA, DES) negotiated using industry-standard protocols (for example, SSL)||Unlike most proprietary security systems, SSL works both inside and outside the firewall.|
|Message privacy (real-time as well as store-and-forward applications)||Public-key encryption and RSA decryption (for example, RSA). Often used in conjunction with symmetric-key technology (for example, RC2, RC4, and DES) for higher performance.||SSL protects the session key used to encrypt and decrypt a data stream with public-key encryption. S/MIME uses a similar technique for encrypting and signing email messages in a store-and-forward paradigm.||Message integrity||Message authentication codes calculated using message digest algorithms (MD5, SHA1)||SSL calculates message authentication codes (MACs) using a message digest algorithm and a key negotiated during the SSL handshake.||Protection of confidential documents from unauthorized access||Digital certificates (X.509) and signatures||Binds users listed in access control lists (ACLs) to certificates or requires that users present a particular certificate (for example, signed by the Netscape Marketing Certificate Authority) for access.|
SSL provides three fundamental security services, all of which use public-key techniques:
|Service||Underlying Technology||Protection Against|
|Message integrity||Message authentication codes (keyed hash functions)||Vandals|
|Mutual authentication||X.509 certificates||Impostors|
Message privacy. Message privacy is achieved through a combination of public-key and symmetric key encryption, as described above. All traffic between an SSL server and SSL client is encrypted using a key and an encryption algorithm negotiated during the SSL handshake described below. Encryption thwarts eavesdroppers who can capture a TCP/IP session using devices such as IP packet sniffers. Even though packet sniffers can still capture the traffic between a server and client, the encryption makes it impractical for them to actually read the message.
Message integrity. The message integrity service ensures that SSL session traffic does not change en route to its final destination. If the Internet is going to be a viable platform for electronic commerce, we must ensure that vandals do not tamper with message contents as they travel between clients and servers. SSL uses a combination of a shared secret and special mathematical functions called hash functions to provide the message integrity service.
Mutual authentication. Mutual authentication is the process whereby the server convinces the client of its identity and (optionally) the client convinces the server of its identity. These identities are coded in the form of public-key certificates, and the certificates are exchanged during the SSL handshake.
To demonstrate that the entity presenting the certificate is the legitimate certificate owner (rather than some impostor), SSL requires that the certificate presenter must digitally sign data exchanged during the handshake. The exchanged handshake data includes the entire certificate. The entities sign protocol data (which includes their certificates) to prove they are the legitimate owner of the certificate. This prevents someone from masquerading as you by presenting your certificate. The certificate itself does not authenticate; the combination of the certificate and the correct private key does.
What Happens During the SSL Handshake
SSL is designed to make its security services as transparent as possible to the end user. Typically, users click a link or a button on a page that connects to an SSL-capable server. A typical SSL-capable Web server accepts SSL connection requests on a different port (port 443 by default) than standard HTTP requests (port 80 by default).
When the client connects to this port, it initiates a handshake that establishes the SSL session. After the handshake finishes, communication is encrypted and message integrity checks are performed until the SSL session expires. SSL creates a session during which the handshake needs to happen only once. Performing an SSL handshake for every HTTP connection would result in poor performance.
The following high-level events take place during an SSL handshake:
SSL 2 Versus SSL 3
The first generations of Netscape products (including, for example, Netscape Navigator 2.0, Netscape Commerce Server 1.0, and Netscape News Server 1.0) implement SSL version 2.
The current generation of Netscape products (including Netscape Navigator 3.0 and the Netscape SuiteSpot server products) implement version 3 of the SSL protocol. The SSL 3 protocol incorporates feedback on SSL 2 from a wide variety of companies. The basic services SSL provides - message integrity, message privacy, and mutual authentication - are the same in both versions 2 and 3 of the protocol. However, SSL 3 boasts a number of protocol enhancements such as the following:
|Can view and edit the list of trusted Certificate Authorities (CAs)||Users select Security Preferences from the Options menu to view and remove trusted CAs. New CAs may be added over HTTP by identifying the certificate with the MIME type
||Users gain more control over which servers they trust by controlling the list of trusted certificate authorities. System administrators may configure a version of Navigator with the company-approved list of CAs before they distribute Navigator.|
|Accepts site certificates.||Users connect to a server that presents a certificate signed by an unrecognized certificate authority. Users may still choose to trust this site certificate.||Users enjoy more flexibility because they can choose to trust a server directly (similar to the way Pretty Good Privacy, a popular secure email solution, works).|
|Checks that certificates match their host's domain name.||Navigator checks that the server certificate's common name matches the URL. A warning appears if the names do not match. The user can choose to communicate with the suspicious server regardless.||This capability closes a potential man-in-the-middle attack where an impostor presents a stolen certificate.|
|Generates and manages multiple key pairs.||A special HTML tag called <keygen> causes Navigator to generate a key pair, prompt the user for a password to protect the private key, and deliver the public key as part of the HTML form data.||Enables Navigator to perform public-key operations (such as digital signatures) with its own key pair.|
|Manages multiple client-side certificates.||Manages a local database of client certificates delivered over HTTP using the MIME type
||Enables Navigator to perform strong authentication via SSL, laying the foundation for single-user login which (1) simplifies the end user's experience and (2) lowers the cost of maintaining servers.|
|Presents certificates during the SSL handshake.||Navigator's implementation of the SSL 3 protocol enables servers to ask for a certificate signed by a particular CA. Navigator searches its local database to present the necessary certificate.||Simplifies the user interface. The previous version of the SSL protocol required the user to select from a certificate from the certificate database rather than automatically finding the certificate the server needs.|
|Allows users to toggle whether SSL documents should be cached.||Users select Network Preferences from the Option menu to toggle caching of SSL documents.||Caching SSL documents improves performance; not caching SSL documents may be required for more secure environments.|
|Allows users fine-grained control over SSL 2 and SSL 3.||Users select Security Preferences to toggle SSL 2 and SSL 3 on or off. Users may also toggle particular encryption algorithms on or off.||Gives users fine-grained control over Navigator's encryption capabilities.|
The complete Netscape SuiteSpot server family implements (or will implement) SSL 3, although the exact use of SSL varies from server to server. All servers are capable of the following:
The first Netscape server to support client authentication is Netscape Enterprise Server 2.0, which has the following unique features:
All SuiteSpot Servers will eventually support client authentication. Client authentication based on certificates has the following advantages over authentication based on username and password combinations, IP addresses, or DNS names:
Netscape Certificate Server is part of the Netscape SuiteSpot family of server products and is a robust solution for creating and managing certificates. It is highly integrated with Netscape's entire product line and enables administrators to issue, revoke, renew, and otherwise manage industry-standard X.509 (version 1 or 3) public-key certificates. Because Certificate Server manages industry-standard X.509 certificates, other X.509-compliant applications can use these certificates.
Organizations can use Netscape Certificate Server together with Netscape Navigator, Netscape SuiteSpot, and Netscape Commercial Applications to manage a certificate infrastructure that enables each of the security solutions described earlier.
Requesting and Installing Certificates
Netscape Certificate Server handles certificate requests from client software such as Netscape Navigator as well as server software such as Netscape FastTrack Server or Netscape Enterprise Server. The format of the certificate signing request is slightly different for clients and servers.
Client certificates. Clients such as Netscape Navigator request certificates using HTML and HTTP as follows:
application/x-x509-user-cert) and prompts the user to type a nickname to identify the certificate in the certificate database.
Server certificates. Servers such as Netscape Enterprise Server or Netscape FastTrack Server request certificates using the server's administrative tools as follows:
Constraining Certificate Content
Server administrators can constrain the content of certificates in a variety of ways:
|Must the key be an RSA public key?||Yes/No|
|Valid exponents in an RSA public key||3, 17, 65537|
|Minimum key length||512 bits|
|Maximum key length||1024 bits|
|Subject name must begin with||C=US, O=Netscape|
|Minimum validity period||1 month|
|Maximum validity period||2 years|
Netscape Certificate Server manages an internal repository of certificate data in a bundled Informix relational database.
The database contains the life history of a certificate, including such information as date and time of issuance, who issued it, when it was revoked, and so on. Administrators can query the database using a variety of standard queries that are part of the Certificate Server administrative interface.
Clients may also query Certificate Server to check a certificate's status, to get a certificate, and to download the latest certificate revocation list (CRL). All of these queries are submitted to a well-known URL, with requests and responses being conducted over HTTP.
Netscape Certificate Server publishes certificate information over the Lightweight Directory Access Protocol (LDAP) to LDAP servers such as Netscape Directory Server. (See An Internet Approach to Directories from Netscape for more information on LDAP and related Netscape products.)
In general, if a client has a certificate and wants to check the certificate's status, it queries Certificate Server. If a client needs a certificate, it queries Directory Server. The following table summarizes the situations in which queries to Certificate Server or Directory Server are more appropriate:
|I have an email address and need a certificate.||Directory|
|I need a CRL quickly and realize it may lag the most up-to-date CRL by some period of time.||Directory|
|I need to check a certificate's status.||Certificate|
|I need the latest CRL.||Certificate|
This final section describes typical deployment scenarios and examines the design trade-offs. The following scenarios are covered:
X.509 certificates may be used on an intranet or over the Internet. However, certificates may serve very different purposes when used inside or outside a corporation. The next two sections explore certificate use on the public Internet and then on the intranet.
Public Server Certificates
Your company may want to install a server certificate that attests to your public server's identity. For example, Netscape wants to convince people who connect to its site that https://www.netscape.com is actually operated by Netscape Communications Corporation rather than some impostor. In this case, an external certificate authority (CA) is the right choice.
Why? Because Netscape must convince that external CA that it is indeed Netscape by performing whatever due diligence the CA requires. For example, a CA might require that Netscape send a letter from its board of directors, submit a copy of its articles of incorporation, or allow credit or other third-party checks to be performed.
Only after it is satisfied that Netscape is indeed Netscape, will the CA issue a server certificate that Netscape may install on its public server. The essential service that a CA provides is authentication: the CA must take some pains to verify your identity before issuing you a certificate.
The more lax a CA is, the less useful a certificate issued by that CA is. This public authentication service is crucial for thwarting Internet impostors. Without this service, there is no reliable way of knowing whether servers are actually operated by who they claim to be. Is www.well-known-retailer.com really operated by that well-known retailer? Is www.well-known-bank.com?
Netscape Certificate Server and similar products available from other vendors are not designed to issue certificates used in this fashion. Purchasing Certificate Server to issue certificates for this purpose would defeat the trust in the public-key certificate model. Users would no longer enjoy the trust embodied in a reputable certificate authority that takes careful steps to verify an entity's identity before it issues a certificate.
Public Client Certificates
Another example of using certificates over the Internet is issuing client certificates to customers or partners. Client certificates have several advantages over traditional usernames and passwords:
For these reasons, a company may want to issue certificates to all its customers. In this case, the company may either build its own infrastructure or rely on an external service provider. The criteria for making this decisions are similar to the ones shown in the table above.
Certificates Inside the Organization
Inside an organization, certificates are typically used to provide services such as secure email, single-user login, strong authentication, and access control. To provide these services, a company takes the following steps:
Companies that want to build a certificate infrastructure have two choices for managing it:
Following are the trade-offs between these solutions:
|Buy a Product||Use a Service|
Providing a safe environment for Web client and server communication over a public network protocol like TCP/IP using a public file transfer protocol like HTTP typically requires the following:
The first three requirements are satisfied by deploying SSL-capable servers and clients throughout the enterprise. Most implementations of SSL-capable servers use two different ports: one port (typically 80) for insecure communications using HTTP and a separate port for secure communications using HTTP over SSL. Typically, Servers such as Netscape FastTrack Server and Netscape Enterprise Server have SSL turned on or off. A single-server instance cannot serve both insecure and secure documents.
However, system administrations can install multiple instances of the server on the same machine. One instance would handle insecure communication and the other instance, secure communication. Although these instances can serve documents out of the same directories, this is not recommended: Document content, not the capabilities of the client application, should dictate whether security services such as encryption are necessary.
In high security environments, documents requiring delivery over SSL are stored on different machines altogether. Of course, increased security precautions should be taken to safeguard the physical security of these secure servers. The best encryption in the world cannot protect you from vandals approaching to an unattended terminal or finding passwords taped to monitors.
Netscape Enterprise Server introduces a way of tying certificates and ACLs together so that users are authenticated with certificates presented during the SSL handshake (rather than by traditional methods such as IP address, DNS name, or username and password). As mentioned earlier, this client authentication feature has several benefits over traditional authentication methods and will be rolled into all Netscape SuiteSpot products over time.
LOGIN ACROSS THE
Single-user login has immediate benefits for both the end user and the administrator. End users enjoy the convenience of remembering a single password for logging in to Navigator. Administrators see simplified maintenance of the various servers (Web, proxy, news, mail, directory, etc.) requiring user authentication. Together, these benefits add up to lower costs of ownership.
Deploying a single-user login scheme requires two components: a universal client and a suite of servers that use X.509 certificates for authentication. With Netscape Navigator and Netscape SuiteSpot server products, authentication occurs during the SSL handshake. Following is an overview of the process:
Currently, this SSL-based authentication protocol is completely software based. The key pair is stored in the local file system and protected with a password. The certificates are also stored in the file system, typically in the clear because most certificates contain only public information. However, there are exceptions when Secure Electronic Transactions (SET) certificates contain private information, such as an encoded version of the cardholder's personal account number. Encryption and decryption is carried out in software.
Although this software-based scheme may be deployed today (beginning with Netscape Navigator 2.0 and Netscape Enterprise 2.0) and requires no additional hardware, a hardware-based mechanism has many benefits. A hardware-based solution may come in the form of smart cards, credit card devices that can generate and store key pairs and certificates. Advanced versions of these smart cards can even perform their own hardware-assisted encryption and decryption for a performance improvements over software. Netscape is working on integrating smart card support across its product line so that users can use their smart cards in a simple manner with any available computer running Netscape Navigator.
The benefits of hardware-based security are as follows:
Cryptography is a surprisingly general technology that provides the foundation for a wide variety of security challenges. When cryptographic technology is embedded in industry-standard protocols such as SSL and S/MIME, it offers valuable security services such as message encryption, message integrity, digital signatures, and strong authentication. Netscape provides a full range of products that implement industry-standard protocols, allowing corporations to build open networks for secure communications and collaboration.
SCALING TO THE
One of the chief benefits of using open protocols such as SSL and S/MIME is that systems scale from the intranet to the Internet. Although proprietary systems such as Lotus Notes, Microsoft Exchange, and Novell GroupWise offer integrated security and directory services for communications and collaboration, they do so in a way that does not scale to the Internet. The result is a jumble of gateways and other translation services that force rich, proprietary data into a lowest common denominator, such as a 7-bit ASCII text transported over SMTP in the clear.
When open standards such as SSL and S/MIME are adopted, the same systems, administrators, trainers, support personnel, and applications may be used for secure, robust communications throughout the intranet and over the public Internet as well. There is no loss of fidelity in email messages, no fumbling with different attachment mechanisms, no loss of security services. For example:
Public-key technology is also gaining broad market acceptance as the primary means of safeguarding electronic transactions. Public-key technology figures prominently in a large collection of protocols and payment technologies, including Secure Electronic Transactions (SET), the credit card transaction protocol, Electronic Data Interchange (EDI) applications, electronic cash, and micropayment technology.
Building on public-key technology is much more than an investment in a particular protocol or a single vendor's product. It is an investment in a general-purpose technology that is rapidly becoming a foundation for the many applications of secure communications over the Internet, including ubiquitous electronic commerce.
Copyright © 1996 Netscape Communications Corporation