Providing robust security services is chief among the challenges faced by information systems teams that are building full-service intranets 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:

Security challenges and solutions

Typical security challenges

Cryptographic technology

Secure Sockets Layer (SSL)

Security features in Netscape products

Netscape Navigator

Netscape SuiteSpot

Future directions for Netscape products

Deploying Netscape products for secure communications and collaboration

Building versus outsourcing a certificate infrastructure

Safeguarding real-time communications

Enabling single-user login

Deploying secure email

Summary

Scaling to the public Internet

Futures

THE CHALLENGES
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:

• How do I authenticate users to make sure they are who they claim to be? Standard Web protocols such as TCP/IP and HTTP make impersonating a person or an organization relatively simple. For example, if Alice connects to http://www.well-known-retailer.com, how does she know that site is actually operated by the well-known retailer?

• How can I perform authentication without sending usernames and passwords across the network in the clear?

• How can I provide single-user login services to avoid costly username and account maintenance for all the servers (Web, proxy, directory, mail, news, and so on) across the enterprise? Can I provide single-user login without compromising security or incurring high administrative costs?

• How can I ensure that these services not only work on my intranet but also scale to the Internet? In other words, how can I avoid managing a separate security scheme for inside my firewall and a completely different scheme for outside the firewall?

• How can I protect the privacy of my communications, both those in real time (such as the data flowing between a Web client and a Web server) and those with store-and-forward applications such as email?

• How can I can ensure that messages have not been tampered with between the sender and the recipient?

• How can I safeguard confidential documents to ensure that only authorized individuals have access to them?

THE CRYPTOGRAPHIC SOLUTION
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:

• Encryption transforms data into some unreadable form to ensure privacy. Internet communication is like sending postcards in that anyone who is interested can read a particular message; encryption offers the digital equivalent of a sealed envelope.

• Decryption is the reverse of encryption; it transforms encrypted data back into the original, intelligible form.

• Authentication identifies an entity such as an individual, a machine on the network, or an organization.

• Digital signatures bind a document to the possessor of a particular key and are the digital equivalent of paper signatures.
• Signature verification is the inverse of a digital signature; it verifies that a particular signature is valid.

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:

1. Alice generates a random number (key) that will be used for actually encrypting her message to Bob.

2. Alice encrypts the random number with Bob's public key.

3. Bob decrypts the random number with his private key. Now Bob has a secret shared with only Alice that they can use to encrypt and decrypt messages to each other.

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.

Public-Key Certificates
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.

HOW DOES CRYPTOGRAPHY HELP?
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.

SSL provides three fundamental security services, all of which use public-key techniques:

Service	Underlying Technology	Protection Against
Message privacy	Encryption	Eavesdroppers
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:

1. The client and server exchange X.509 certificates to prove their identity. This exchange may optionally include an entire certificate chain, up to some root certificate. Certificates are verified by checking validity dates and verifying that the certificate bears the signature of a trusted certificate authority.

2. The client randomly generates a set of keys that will be used for encryption and calculating MACs. The keys are encrypted using the server's public key and securely communicated to the server. Separate keys are used for client to server and server to client communications for a total of four keys.

3. A message encryption algorithm (for encryption) and hash function (for integrity) are negotiated. In Netscape's SSL implementation, the client presents a list of all the algorithms it supports, and the server selects the strongest cipher available. Server administrators may turn particular ciphers on and off.

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:

• Fewer handshake messages for faster handshakes

• Support for more key-exchange and encryption algorithms (for example, Diffie-Hellman, Fortezza)

• Support for hardware tokens in the form of Fortezza cards. This is the first step toward more general support for cryptography-capable smart cards.

• An improvement to the client certificate request protocol that allows a server to specify a list of certificate authorities that it trusts to issue client certificates. Navigator returns a certificate signed by one of those certificate authorities. If it does not have such a certificate, the handshake fails. This frees the user from having to choose a certificate for each connection.

  ---

  HOW NETSCAPE PRODUCTS USE PUBLIC-KEY TECHNOLOGY

  NETSCAPE NAVIGATOR
  Netscape Navigator has incorporated SSL technology from release 1.1. Navigator's implementation of the SSL protocol enables Navigator to do the following:
  1. Encrypt communication using an encryption algorithm negotiated with the server during the SSL handshake
  2. Perform message integrity checks on communication delivered from the server
  3. Verify the server's identity on the basis of the public-key certificate presented by the server during the SSL handshake
  Each release of Navigator has added new public-key capabilities, summarized in the following tables.

  Navigator 2.0

  Feature	Description	Benefit
  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 application/x-x509-ca-cert	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.

  Navigator 3.0

  Feature	Description	Benefit
  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 application/x-x509-user-cert. Certificates are stored in the local file system. No encryption is necessary because certificates contain public information.	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.

  
  

  Future Directions for Netscape Navigator
  Future releases of Navigator will support features such as the following:

  • Secure email using S/MIME, which requires X.509 certificates. This open secure mail standard, spearheaded by RSA, enables Navigator to exchange secure email with any S/MIME capable client. In general, no changes to existing Internet mail servers that support POP3, SMTP, or IMAP4 are necessary. Click here for more information about the S/MIME standard.

  • Smart cards and other hardware tokens. These devices range from simple "stored value" cards that can be used for simple digital cash transactions to full-featured devices that generate key pairs, manage certificates, and implement full cryptographic suites.

  • Certificates and key pair migration. Users will want to move their key pairs and corresponding certificates between machines (for example, between their home and office machines) using floppy disks or other storage devices.

  • Improved checks for certificate status and certificate revocation lists. Netscape has defined a X.509v3 extension that lists URLs where client applications can check on certificate status, download certificate revocation lists, renew a certificate, and so on.

  NETSCAPE SUITESPOT
  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:

  • Communicate privately using an encryption algorithm negotiated with an SSL client such as Netscape Navigator. The traffic that is carried depends on the server. For example, Netscape Enterprise Server 2.0 carries Hyper Text Transfer Protocol (HTTP) data; Netscape News Server 2.0 carries Network News Transport Protocol (NNTP) data; and Netscape Mail Server 2.0 uses SSL to encrypt communication between Navigator and the Mail Administration Server, enabling administrators to manage the server securely from any network node.

  • Use a message digest function, also negotiated with the client during the SSL handshake, to perform messsage integrity checks on data coming from the client.

  • Authenticate itself to clients using a digital certificate (server authentication).

  The first Netscape server to support client authentication is Netscape Enterprise Server 2.0, which has the following unique features:

  • Allows administrators to map client certificates to entries in the access control database. In this scenario, users present a certificate rather than a username and password to gain access to access-controlled documents.

  • Presents certificates to server-side applications via NSAPI and as CGI environment variables.

  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:

  • No passwords flow across the network. Certificates are public information, so users may be authenticated without sending sensitive information such as a password over the network.

  • Improved user experience. Users do not have to remember separate username and password pairs for every Web server they visit. They simply log in to Navigator, and Navigator sends the necessary certificate to establish the user's identity.

  • Strong authentication.Certificates are a stronger form of authentication because they are based on what the user has (the certificate) as well as what the user knows (the password that protects the private key corresponding to the certificate).

  • Lower administration cost. Certificate-based authentication can lower the cost of server administration. Rather than managing separate access control lists (ACLs) at every server, servers may simply be configured to grant access to users who present certificates signed by an approved list of certificate authorities.

  NETSCAPE CERTIFICATE SERVER
  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:

  1. The client connects to a published URL such as http://certs.myorg.com/cert-request.html.
  2. The server delivers an HTML form that prompts the user for various kinds of information, which will be
     • Embedded in the certificate (such as the user's name)
     • Used for authentication purposes (something only the user will know, such as mother's maiden name)
     • Used for administrative purposes (such as a phone number)
  3. The HTML form also contains a special keyword called <keygen>. The <keygen> tag prompts Navigator to do the following:
     • Generate a public-private key pair.
     • Prompt the user to select a key length.
     • Prompt the user for a password to protect the private-key database.
     • Place the public portion of the key pair as a field in the HTML form data. (To protect against replay attacks in which someone steals a public key and attempts to get a spurious certificate generated for that public key, the public key is actually signed together with a random string challenge issued by the server as part of the tag.)
  4. The user submits the form data.
  5. A certificate issuer logs in to Netscape Certificate Server, presenting a client certificate as acredential, and uses the server's administrative tools to formulate a certificate based on the information in the posted form data.
  6. When satisfied with the user's identity, the certificate issuer issues a certificates and sends email alerting the user that the certificate is ready. The email contains the URL that the user may click on to receive the certificate.
  7. Users with Netscape Navigator (or another HTML-savvy email client) click the highlighted URL in the mail message to download the certificate.
  8. Navigator recognizes the certificate by a special MIME type (application/x-x509-user-cert) and prompts the user to type a nickname to identify the certificate in the certificate database.
  9. Users may confirm the installation of their certificate by choosing Security Preferences from the Options menu.
  Using Netscape Navigator 3.0 (beta 5 or later), users can test drive this feature at VeriSign and other sites on the Internet.

  Server certificates. Servers such as Netscape Enterprise Server or Netscape FastTrack Server request certificates using the server's administrative tools as follows:

  1. The server administrator logs in to the Server Manager and selects the Encryption button.
  2. Following the on-screen directions and using a supplied command-line utility, the administrator creates a key pair and types a password to protect the private-key file.
  3. The administrator clicks the Request Certificate button and fills in the requested information, including the server's distinguished name, the file containing the key pair, and the email address of the certificate authority (such as server-cert-request@myorg.com).
  4. The server software packages the information from step 3 and sends by email a standard certificate request formatted according to PKCS 10. (PKCS stands for Public Key Cryptography Standard and is a series of cryptographic standards published by RSA Laboratories.)
  5. The server administrator retrieves the email containing the certificate request and cuts and pastes the request into a form published by Netscape Certificate Server.
  6. When satisfied with the server's identity, the certificate issuer issues a certificate and sends the certificate back to the server administrator via email.

  Constraining Certificate Content
  Server administrators can constrain the content of certificates in a variety of ways:

  Constraint	Typical Values
  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

  Managing Certificates
  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:

  Query	Appropriate Server
  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

  
  

  ---

  DEPLOYING NETSCAPE PRODUCTS FOR SECURE COMMUNICATIONS AND COLLABORATION

  This final section describes typical deployment scenarios and examines the design trade-offs. The following scenarios are covered:

  • Building versus outsourcing a certificate infrastructure

  • Safeguarding communications over the internal web

  • Enabling single-user login across the enterprise

  • Enabling secure email

  BUILDING VERSUS OUTSOURCING A CERTIFICATE INFRASTRUCTURE
  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:

  1. Certificates are public information, so no sensitive information such as a password flows over the network.

  2. Users do not have to remember separate username and password pairs for every Web server they visit. They simply log in to Navigator, and Navigator sends the necessary certificate to establish their identity.

  3. Certificates are a stronger form of authentication because they are based on what the user has (the certificate) as well as what the user knows (the password that protects the private key corresponding to the certificate).

  4. Certificates may contain special data (in the form of X.509v3 extensions) that give hints as to how to customize the site for a particular user. For example, the certificate might contain attributes such as Native language=English or Account Number=1238X018 or Clearance=Top Secret. These attributes may control which language the Web server presents its documents in, what parts of the site a user may see, or some other customization.

  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:

  • Issues certificates to its employees (potentially multiple certificates per employee, depending on the environment). Corporations can use a variety of techniques to authenticate users, ranging from automated checks in an internal database to calling employees and having them give some secret information (such as their mother's maiden name) to asking employees to present their employee badge in person.

  • Issues certificates to its various Web, mail, news, catalog, directory, and proxy servers to enable SSL's authentication, encryption, and message integrity services.

  • Manages a directory containing certificates so that employees can send and receive encrypted email.

  • Manages and distributes user, group, and access control lists in a directory server.

  • Configures servers to update user, group, access control, and certificate data (including certificate revocation lists) from central directory or certificate servers.

  Companies that want to build a certificate infrastructure have two choices for managing it:

  1. Purchase a certificate server such as Netscape Certificate Server from a vendor to create and manage their own certificate infrastructure. For most environments that require centralized directory management, a directory server such as Netscape Directory Server would also be required.

  2. Outsource certificate management to an external vendor, such as VeriSign, GTE, AT&T, BBN, or KeyWitness, that offers certificate management services. Some certificate vendors also offer online directory services for getting up-to-date certificate information.

  Following are the trade-offs between these solutions:

  	Buy a Product	Use a Service
  Pros	Allows a company to tightly control its certificate management policies. Permits more experimentation with certificate content. Allows a company to fine-tune its certificate policy to match its overall security policy.	Leverages the expertise of a professional service provider. Creates an opportunity for expertise transfer so that over time a company learns to manage its own infrastructure. Leverages the provider's understanding of the technical, legal, and business issues associated with certificate use.
  Cons	Roll-out schedule may be longer than with an expert service provider.	Potentially provides less flexibility in managing certificates. May create two directory standards, one for managing internal users, groups, and ACLs, and a separate directory for certificate information. Typically involves per-certificate costs.

  SAFEGUARDING COMMUNICATIONS OVER THE INTERNAL WEB
  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:

  • A scheme for authenticating users that provides protection against impostors - preferably a scheme that does not involve broadcasting usernames and passwords in the clear

  • A message encryption service to protect against eavesdroppers with IP packet sniffers

  • A message integrity service to protect against vandals who can insert valid TCP/IP packets into a TCP stream

  • A way of controlling access to entire servers or individual directories and documents to protect sensitive documents from unauthorized access

  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.

  The access control requirement may be satisfied with a server (such as Netscape FastTrack Server, Netscape News Server, and so on) capable of managing access control lists that limit access to particular servers, directories, discussion groups, files, or other server resources. Netscape servers allow you to define access control lists in terms of users, passwords, groups, and privileges. These ACLs may then be applied to particular resources such as a directory or discussion group. For example, a directory may be marked as read-only for all users except members of the Engineering group, who are granted read and write access.

  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.

  ENABLING SINGLE-USER LOGIN ACROSS THE ENTERPRISE
  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:

  1. When a new employee joins the company, she or he is issued a corporate client certificate.

  2. Server administrators configure the various servers around the enterprise to accept the corporate-issued certificate as a form of authentication.

  3. Over time, the marketing server becomes an increasingly sensitive repository of product plans, schedules, and other confidential documents. Because of the sensitive nature of these documents, the marketing department decides to establish its own certificate authority as a subordinate to the corporate CA.

  4. Employees that join the marketing department are now issued certificates issued by the marketing CA. When marketing employees receive their certificates, they actually receive a chain of certificates that contain their own client certificate, the marketing CA's certificate, and finally the corporate CA certificate. The entire chain is presented to servers during the SSL handshake.

  5. Administrators now configure the marketing server to give read-write access only to employees presenting a client certificate signed by the marketing CA. Employees that present a certificate signed by the corporate CA are given read-only access.

  6. This process can be repeated for any number of subordinate CAs and for multiple levels of subordinate CAs (for example, the marketing organization could establish subordinate CAs for client product marketing and server product marketing). Navigator's certificate "wallet" becomes populated with a variety of certificates that are appropriate for different servers. During the SSL handshake, the server demands a certificate signed by a particular CA, and Navigator automatically (without user intervention) presents the appropriate certificate.

  Smart Cards
  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:

  • Increased security. Key pairs are generated by a hardware device (which typically has a better random number generator than a software-based pseudo-random number generator). Because the keys never leave the card, they are impervious to some of the attacks that may be directed against key pairs sitting in a file system.

  • Improved performance. Some sophisticated smarts cards contain hardware-based encryption chips that can provide better throughput than software-based implementations.

  • Users can use any available workstation. Given an enterprise-wide deployment of smart cards and readers, users can use any workstation running Navigator. They "log in" by sliding in their smart card to the reader and presenting whatever information the card needs to authenticate its user. Software-based solutions require the users to migrate their key pairs and certificates between machines, typically using a floppy disk for storage.

  ENABLING SECURE EMAIL
  Four components are needed for secure electronic mail services across the enterprise:

  1. A secure email client. Future releases of Netscape Navigator will implement S/MIME for encrypted and signed email messages. S/MIME requires X.509 certificates, so Navigator can leverage its certificate management capabilities to deliver a world-class secure email client solution.

  2. A secure email server. Depending on the standard used for secure email, the changes required in the mail server range from none to substantial. Because the S/MIME standard builds on existing Internet standards for email, no changes are required to IMAP4, POP3, or SMTP-based email servers such as Netscape Mail Server.

  3. A certificate server. Users need each other's certificates in order to send secure email. For example, Alice requires Bob's public key if she wants to send an encrypted message to him because the certificate binds Bob's identity to his public key. A way of creating and managing certificates - for example, with Netscape Certificate Server - is required to deploy a secure email solution.

  4. A directory server. The final component of a secure email solution is a directory server, which provides a scalable way of distributing user, certificate, and group information throughout an enterprise. If Alice wants to send Bob secure email, the best way to get his certificate is to look it up in a directory server. Netscape Navigator will be able to look up usernames and their corresponding certificates by using the LDAP protocol to communicate with Netscape Directory Server. Users will also be able to store frequently used entries in Navigator's local address book.

  ---

  SUMMARY

  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 PUBLIC INTERNET
  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:

  • The same X.509 certificate technology that authenticates users to internal servers can also authenticate users to external services such as news feeds, stock quotes, and others on the public Internet.
  • The same security protocol, SSL, can be used to encrypt and provide message integrity services, inside and outside the firewall for remote banking and other electronic commerce applications.
  • The same secure messages standard, S/MIME, enables secure interoffice email as well as secure intercompany email with global partners, customers, press, and analysts.

  FROM SECURE EMAIL TO ELECTRONIC COMMERCE
  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.

  ---

  Corporate Sales: 415/937-2555; Personal Sales: 415/937-3777
  If you have any questions, please visit Customer Service.

  Copyright © 1996 Netscape Communications Corporation