Chapter 5 Usage Examples

This chapter describes sample topologies for systems and networks using SunScreen SKIP.

All topologies require that

1. Keys be generated or installed.

2. Key IDs (and certificates) be exchanged between hosts.

3. On both hosts, ACL entries be configured with matching algorithms, key IDs, and protocol versions.

4. SKIP be enabled.

The topologies explained here are the following:

1. Setting up an encrypted connection between two hosts.

2. Setting up an encrypted connection between a host and a SunScreen SPF-100.

3. Setting up an encrypted connection from a host to an encrypting gateway, SunScreen EFS, or SunScreen SPF-200.

4. Setting up a host as a nomadic encrypting gateway.

5. Using tunnel addresses.

Setting Up an Encrypted Connection Between Two or More Hosts

Figure 5-1 depicts the configuration in which a host has an encrypted connection to another host. This is the simplest case.

Figure 5-1 Communicating with a Host

Figure 5-1 is an example of host-to-host communication using UDH keys and SKIP.

All the hosts must:

• Share the same key types, such as UDH, SunCA X.509, or the like, and of the same encryption strength. If X.509 certificates and keys are used, the certificates and keys for both hosts must be from the same vendor.

• Exchange certificates.

• Have the same algorithm to use that includes authentication, key encryption, and traffic encryption.

• Enable SKIP.

A machine must also have a local identity. Hosts can have many identities, but the user must choose one with which to communicate to the other host. This local identity consists of the local key type (NSID) and the local key name.

The hosts must exchange key IDs. The safest method of exchanging UDH key IDs is to have each user run skiptool, then call each other on the telephone and type the other's UDH key ID in the Remote Key ID field in the Add window.

UDH key IDs can be exchanged and added to the ACL of each using the skiplocal export command. In this case, both system administrators should telephone one another and confirm the key ID.

The address of each host with which a host wants to communicate must be in its ACL.

Setting Up an Encrypted Connection Between a Host and a SunScreen SPF-100

Figure 5-2 depicts the configuration of an encrypted connection between a host and a SunScreen SPF-100.

Figure 5-2 Communicating with a SunScreen SPF-100

In this case, both the host and the SunScreen SPF-100 must

1. Install a SunCA X.509 key of the same encryption strength.

2. Manually exchange certificates.

3. Use SKIP protocol Version 1.

4. Have an IP address or remote name.

5. Use the same algorithm that includes authentication, key encryption, and traffic encryption.

6. Enable SKIP.

A machine must also have a local identity. Hosts can have many identities, but the user must choose one with which to communicate to the remote host. This local identity consists of the local key type and the local key name.

X.509 certificates and keys must be used when speaking to a SunScreen SPF-100. The physical diskettes containing the public keys must be physically exchanged.

The only method of exchanging key IDs is to have each user run skiptool, then call each other on the telephone and type the other's key ID in the Remote Key ID field in the Add window.

The ACL for both the host and the SunScreen SPF-100 must be configured with each other's address. The host must also include the addresses of any networks and hosts attached to the SunScreen SPF-100 in its ACL. The SunScreen SPF-100 does not really use ACL: It uses packet filtering rules. These rule must be set to "match" the ACL on the host running SunScreen SKIP.

Setting Up an Encrypted Connection From a Host to an Encrypting Gateway, or SunScreen EFS

Figure 5-3 depicts the configuration in which a host is communicating with an encrypting gateway.

Figure 5-3 Communicating with an Encrypting Gateway

In this case, both the host and the encrypting gateway, whether it be a gateway, or a SunScreen EFS must

1. Have the same key type, such as UDH, SunCA X.509, or the like, and of the same encryption strength. If X.509 certificates and keys are used, the certificates and keys for both hosts must be from the same vendor.

2. Exchange names or certificates.

3. Use the same version of the SKIP protocol.

4. Have an IP address or remote name.

5. Use the same algorithm that includes authentication, key encryption, and traffic encryption.

6. Enable SKIP.

A machine must also have a local identity. Hosts can have many identities, but the user must choose one with which to communicate to the remote host. This local identity consists of the local key type and the local key name.

Both machines install or generate their keys and exchange namespace/key ID information. This should be done over the telephone or some other media.

The user should type the encrypting gateway's information into the Add System box of skiptool. The user should also set the Tunnel Address field of this box to be the IP address of the intermediate system. This enables certificate discovery to ask the correct host for its certificate.

For example: You are contacting a gateway that has three networks attached to it (networks 199.190.177, 199.190.176, and 199.190.176) and these networks are to remain hidden. It also has a local host attached to it. The ACL in the host should be set up as in Table 5-1.

Table 5-1

Host	Algorithm	Tunnel Address	Remote Key
199.190.177.*	V2 DES/DES	Gateway	Gateway's
199.190.176.*	V2 DES/DES	Gateway	Gateway's
199.190.176.*	V2 DES/DES	Gateway	Gateway's
Local host	V2 DES/DES	Gateway	Gateway's
Default	V2 DES/DES	Gateway	Gateway's

The user can configure a default so that everything is sent to the gateway where it will be decrypted and sent to the proper recipient in the clear. The recipients of the packets will not be aware of any encryption. The gateway will handle all the encryption and decryption of packets from and to everything behind it.

Setting Up a Nomadic Encrypting Gateway

Figure 5-4 depicts the configuration in which a host is communicating with an encrypting gateway that receives packets from an encrypting nomadic system.

Figure 5-4 Setting Up a Nomadic Host and a Gateway

A nomadic encrypting gateway is an encrypting gateway that encrypts and decrypts packets from hosts whose IP address is not known ahead of time (for instance, hosts who receive the IP address dynamically). This is the same as configuring a host-to-host configuration except that the ACL does not have a specific address for the nomadic system. The address in the ACL is * and gets the temporary address from the nomadic system when it contacts the host. The host can only contact the nomadic system when it knows its address. Every time the nomadic system moves and then reconnects with the host, it will have a new address.

Using Tunnel Addresses

Figure 5-5 depicts the configuration in which a host is communicating with a hidden system through a tunnel address to an encrypting gateway. The hidden system also uses a tunnel address from the encrypting gateway to the host.

Figure 5-5 Using Tunnel Addresses

In tunneling, the packets are sent from the host to the gateway. The packets are encrypted such that the gateway decrypts them and sends them to their final destination in the clear.

When setting up tunneling, the user must add the address for the gateway into the host's ACL because there is no way that the host can discover the gateway's certificate.