Commerce Server/400 White Paper

Secure AS/400 Transactions Over Intranets and the Public Internet

July 1996

The following is an I/NET partial reprint of Netscape Communications Corporation's White Paper on Internet Security by Taher Elgamal, Chief Scientist, Jeff Treuhaft, Director of Security Products, Frank Chen, Product Manager, Security.

In it, I/NET hopes to describe how Commerce Server/400 uses Secure Sockets Layer (SSL) to provide secured Intranet/Internet transactions. While this document references secured e-mail transactions, I/NET only provides SSL for web serving at this time.

INTRODUCTION

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 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 CHALLENGES AND SOLUTIONS

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.

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.

Field	Description	Examples
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 Not after 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

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.

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.

SECURE SOCKETS LAYER
Secure Sockets Layer (SSL) is an industry-standard protocol that makes substantial use of public-key technology. SSL is widely deployed on the intranet as well as over the public Internet in the form of SSL-capable servers and clients from leading vendors including Netscape, Microsoft, IBM, Spyglass, and Open Market as well as public-domain products such as Apache-SSL. All Netscape products - clients, servers, and applications - incorporate SSL to provide advanced security services. The features in each product are described in detail below.

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.

We at I/NET hope this document helps you understand SSL and its relationship to Commerce Server/400. We hope you understand the value of security in your communications for general business as well as online commerce.

Please forward any questions or concerns that you might have to I/NET Support.

Copyright © 1996 I/NET
Copyright © 1996 Netscape Communications Corporation