test

SunScreen SKIP User's Guide, Release 1.1

Relating SKIP to Data Encryption Concepts

Once installed, any two (or more) systems running SKIP have the ability to encrypt all traffic between or among them transparently.

SunScreen SKIP Services

SunScreen SKIP provides networks with four security services:

  1. Access Control to protect corporate network and data resources from unauthorized use.

  2. Encryption and Decryption to ensure the confidentiality of information sent over the network.

  3. Authentication to ensure the integrity of the information transferred from one group to another within a the network.

  4. Key and Certificate Management to provide efficient, cost-effective administration of the basic building blocks of a security policy.

Access Control List (ACL) Using SunScreen SKIP

The ACL feature allows you to limit and control who uses your host systems and applications through your network. Each entity--host, network, or nomadic system, with which you communicate over your network when using SKIP--must be identified and authenticated so that access to your system is controlled. Clear-text hosts are not authenticated. Once communication is established, data can be exchanged in the clear, integrity protected, or encrypted.

SunScreen SKIP can provide mobile remote (nomadic) users with access through the ability to separate an entity from its physical address by means of a key identifier (key ID).

SunScreen SKIP's ACL is based on the requesting system's IP address, if this is fixed and known, or on the key ID, if the SKIP user is nomadic (that is, does not have a fixed address).

When a system tries to connect to a host running SunScreen SKIP, the order of processing for the host is as follows:

  1. Search for an entry specifying a remote host by IP address. If the entry exists and it meets the established criteria, the host allows traffic from the remote host; otherwise, it continues to the next search action. If the entry exists, but does not meet the established criteria (in case of incoming traffic), the connection (packet) is refused.

  2. Search for a network entry that matches the remote entry. If the entry exists and it meets the established criteria, the host allows traffic from the remote host; otherwise, it continues to the next search action.

  3. If an entry for a host or network is not found, search for a nomadic ACL entry containing the sender's key identifier in the SKIP protocol header. If the entry is found and the packet is authenticated, the host stores the sender's IP address until it is replaced with a new value. If it exists and meets these criteria, the host allows traffic from the remote host; otherwise, the host continues to the next search action.

  4. Finally, if no match can be found, a catchall ACL entry (named "default") will be used if it is present.

Note -

These rules may be used to prevent a host or network from obtaining access to the system.

Here is an example of how ACL works. Suppose there are two network nodes A and B that wish to communicate securely using DES-to-DES encryption. The three cases that can occur are

Figure B-1 Example of Case One--Access Control

Graphic

  1. Nodes A and B (Figure B-1) may be on a network where their IP addresses are known and can be identified as specific host entries in their ACLs.

    Figure B-2 Example of Case Two--Access Control

    Graphic

  2. Node B may be a router (Figure B-2) that has a list of IP addresses, one of which is the host, with which Node A wishes to communicate with as part of a network ACL.

    Figure B-3 Example of Case Three--Access Control

    Graphic

  3. Node A may be nomadic. Node A will find the sender's key identifier in the SKIP protocol header when it searches for an ACL entry. The packet is authenticated and the sender's IP address is stored until the nomadic entity tries to communicate with the host node again.

The ACL searches through these cases to authenticate the nodes. Node B can have the same options as Node A.

In Case One, or the host ACL, the ACL search for each node finds that they are to use DES/DES to communicate and that they have each other's IP addresses and certificates.

In Case Two, or network ACL, Node B is a router; Node A has the same information as before, but instead of the IP address of 1.2.3.5, it has the router's network address list (1.2.3.*) so it can communicate with any of the nodes in that list.

The main difference is that Node A does not have the certificates of the list of individual hosts on Node B's network, it just has Node B's certificate. So, the whole set of addresses behind Node B is protected; data are encrypted up to Node B and then are sent in the clear behind Node B to the individual hosts on Node B's network.

In Case Three, or the nomadic ACL, a nomadic ACL entry containing the sender's key identifier in the SKIP protocol header is found. The router has an address of "*" for the nomadic system. The entry is found and the packet is authenticated, it stores the sender's IP address until the nomadic entity tries to communicate with the host node again.

Transport and Tunnel Modes

Each IP packet can be encrypted or authenticated in two ways:

  1. Transport Mode--Only the data part of the IP packet can be encrypted.

  2. Tunnel Mode--The whole IP packet is protected.

Topology Hiding

SKIP supports topology hiding through the use of a tunnel address. The tunnel address field contains the IP address of the host that serves as the intermediary between any or all hosts or systems on a network whose topology is to remain hidden from the rest of the world. The source host is not hidden; only the destination address can be hidden (that is, replaced with a tunnel address that the user specified). To hide the topology, the remote system must be configured using Tunnel Mode and the same router must be used for the tunnel destination as the original destination.

Public-Key Cryptography and Diffie-Hellman Certificates

Public-Private Keys

Cryptography takes the original message, and produces an encoded version by using a special piece of information known to the sender and receiver. The original message is called the plaintext, the special information is called the key, and the resulting message is called the ciphertext. Cryptosystems work by taking the digital representation of the plaintext and manipulating it mathematically under the control of the digital key to produce the ciphertext.

Public-key cryptography was invented by Whitfield Diffie and Martin Hellman. It takes a message encrypted in one shared secret and decrypts it in another. The keys are mathematically related in such a way that a knowledge of one key does not make it possible to figure out the other key. This permits the one key, the public key, to be made widely known, while the corresponding private key is known only to a single user. The two keys together are called a key pair.

The Diffie-Hellman key produces shared secret keys directly from private and public components that are not in themselves keys. The advantage of a public-key system is that the secret components do not have to be shared to exchange information securely. The private portion is never given out to anyone, and it cannot feasibly be calculated from the public portion.

Certificates

To know that the key pair being used in the transaction is actually the key pair for that user, a special sort of signed record is used called a certificate. A certificate contains information identifying the user: distinguished name, public key, and expiration date; for example, digitally signed by a trusted network entity called a certification authority (CA).

Certification Authority

The CA's public key is known to every user of the network. This permits anyone wishing to authenticate a certificate to follow the same procedure for authenticating a message. The CA's public key is available in certificate format so that it, too, can be verified. The major commercial application for CAs is to authenticate businesses and the employees of those businesses. SunCA and SunCAglobal are Sun Microsystems' certification authority in the Internet Commerce Group (ICG).

Unsigned Diffie-Hellman (UDH) Keys

Unsigned Diffie-Hellman (UDH) keys derive their certificate name from the hash of the public key. By communicating the hash over the telephone or some other trusted method of communication with another party, user's can securely communicate without requiring the infrastructure of a CA. How their certificate name is derived and how this is placed in the SKIP packet are shown in Figure B-4.

Figure B-4 Unsigned Diffie-Hellman Keys

Graphic

The advantages of UDH pairs of public and private keys over signed certificates are as follows:

An example of this last point might be as follows: Two users call each other on the telephone and exchange public keys using the recognition of each other's voice as the authentication mechanism. Because these are hashes of public keys, it does not matter if anyone overhears the conversation.

The disadvantage of UDH keys is that the names must be communicated out of band, such as over the telephone by PGP.

SKIP must be able to name or identify a given key. It does this by using a name or identifier drawn from a namespace identifier (NSID). It also must be able to figure out which certificate name to use when communicating with a remote system. This information can be derived from its IP address or explicitly stated in the protocol via NSID/key ID.

If NSID is set to 0, the IP address is used for key lookup. By default, the NSID is set at 0 and a key ID is not sent; however, with the key ID feature activated, key names are no longer tied to IP addresses. This means that regardless of their physical location on the network or on the Internet, various people have the ability to communicate with each other and corporate using encryption.

The Namespace Identifiers (NSID)

SunScreen SKIP provides users with the ability to separate the identity of an entity from its physical address. This means that each person (sender or receiver) participating in a transfer of encrypted data over a computer network can be identified by a namespace identifier/key identifier (NSID/key ID) pair.

NSIDs are a part of SKIP; these identifiers are used to identify the keys being used. The NSIDs supported by SunScreen SKIP are

The first two are nearly identical in that they both use signed X.509 keys, with one very important difference. SKIP packets that use NSID 1 include the key ID in the packet. SKIP packets that use NSID 0 figure out which key to use.

With SunCA keys, for example, it is necessary to put the key identifier into the SKIP header because the IP address may not correspond to the identifier in the certificate. If there is a SunCA key identifier of "0a000101" for a certificate, it becomes "10.0.1.1" in IP address terminology.

Further, if your IP address is "192.12.10.49," then you would have to include your key identifier in the SKIP header because it does not equal your IP address. But with NSID 0, which also uses X.509 certificates, it is guaranteed that the key identifier is the IP address; therefore, the key identifier does not have to be sent.

Using NSID 0 results in a small gain in efficiency by not having to send the key identifier. This is what is meant by "No Key ID present" in the NSID 0 bullet above. This approach reduces the amount of packet expansion because of SKIP.

Traffic Encryption

Traffic is encrypted using conventional symmetric key cryptography, such as RC2, RC4, DES, and the like. The user installs SunScreen SKIP, which has the algorithm packages that are required. Traffic encryption keys are changed based on the volume of data and the length of time a key is used.

There is a tool with a GUI to control how often you want the traffic encryption keys changed. As shipped, the default is to change traffic keys after every 512K bytes of data or after being used for 30 seconds; traffic keys are deleted after being unused for 30 seconds. You can change these values to meet the security needs of your site. This tool is discussed in detail in Chapter 3.

It is important to change the traffic encryption keys frequently enough so that cracking a key will leave little data, and yet not so frequently so that reconfiguring the keys incurs excessive overhead.

Authentication of SKIP Packets

Authentication is used to guarantee the integrity of SKIP packets. In this process, AH authentication protects the integrity of the packets and the mutual authentication of the sender and the receiver.

AH stands for Authentication Header. This header has been defined for the authentication of IP packets by the IPSEC working group of the ETIF. Packet authentication is performed with a keyed hash function to create a MAC that guarantees the integrity of the packet. When the sender transmits a packet, it calculates a hash of the IP packet along with a key and includes it in the packet. When the packet is received, the receiver calculates the hash over the IP packet and the key as well. If the value that the receiver calculates is the same as the one that the sender included in the packet, the packet has been authenticated. If someone modified the packet in transmission, the value that the receiver calculates will not match the one that the sender calculated and the packet fails authentication and is discarded.

Key and Certificate Management with SKIP

Keys and certificates are handled by the key manager. Details of the implementation are presented above. Local-key (that is, your own key) information is managed using the skiplocal command, CA information is managed using the skipca command, and peer certificate information is managed by the skipdb command.

The algorithms used by SKIP are

As stated earlier, certificates are the digital documents that testify to the binding of a public key to an individual (or other entity) to prevent someone else from impersonating you. For two hosts that are running a security package to communicate, they must exchange certificates or public keys. Common methods of exchange for these items are

  1. Certificate Discovery Protocol (CDP)--Hosts running SKIP request each other's certificates through a clear channel. A host can also ask a certificate server for a certificate.

  2. Manual Exchange--This procedure is manual in that the certificate and possibly the key are provided by the certifying agency on physical media: tape, diskette or CD-ROM. They must be loaded into the system by the user through the command line provided by the vendor.

SKIP supports the common methods of certificate and key exchange. By default, the key manager asks the host with which it is trying to communicate for its certificate or public key.

It is useful to allow a system to have more than one pair of public-private keys. For example, keys of different sizes may be required because of U.S. export controls or local laws or regulations when communicating with subsidiaries in other countries.

To meet these requirements, SunScreen SKIP implementation allows a system to possess as many pairs of keys as required. Similarly, the SunScreen SKIP can also be configured with the details of several CAs so that certificates signed by different CAs can be checked for authenticity.

For more information on configuring certificate-fetching protocols and certificate management, see the man pages for skipd, skipdb, and skipca.

Certificate Discovery Protocol (CDP)

Certificate Discovery Protocol (CDP) greatly simplifies the management of secure communications because it eliminates the manual exchange of certificates. CDP can be used to exchange X.509 or UDH certificates.

What Are the Operation Requirements of CDP?

To work, the hosts on both sides of a communication must support CDP and both users must agree to use it.

Caution - Caution -

SunScreen SPF-100 does not support certificate discovery, you cannot use it to communicate between a machine that is running SunScreen SKIP and a SunScreen SPF-100.

If both hosts can use CDP and both users agree to it, then the users merely exchange certificate identifiers and allow CDP to do the work instead of exchanging their public keys. This is a simpler solution than manually exchanging certificates.

As an example, if for X.509 certificates, your certificate number is "0a000100" and another user's public certificate number or master key identifier is "0a000102," you can exchange these numbers and enter them into your respective ACL when you set up your ACL with the other user's host for access.

You can do the same for UDH certificates, namely, by exchanging hash values.

Then, when communication between the two is attempted, even though your SunScreen SKIP program does not have the peer's certificate in its certificate database, your host can request that the certificate be sent automatically from the other host and can put it into its certificate database since it knows the certificate's master key ID.

How Do You Configure CDP?

The only configuration required is to enter the host with which you wish to communicate into your ACL, along with its certificate number or master key ID. If the two hosts attempt to communicate, the fact that there is no corresponding certificate for the key ID in the certificate database automatically activates CDP. If you are communicating to hosts through an encrypting gateway, you must configure the encrypting gateway's IP address as the tunnel address. This alerts SunScreen SKIP to query the gateway for its certificate.

There is a skip.conf file that stores configuration data. You can set its values through the skip_conf command.

More information on the skip_conf command can be found in the man pages.

How Long Are Certificates Cached?

Once the certificates have been transferred and entered into the certificate database of the hosts of the users that wish to communicate, they are cached until they expire or until they are replaced.