SunScreen SKIP User's Guide, Release 1.5.1

Chapter 5 Usage Examples

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

All topologies require that

Keys be generated or installed.
Key IDs (and certificates) be exchanged between hosts.
On both hosts, ACL entries be configured with matching algorithms, key IDs, and protocol versions.
SKIP be enabled.

This chapter illustrates the following example topologies:

Setting Up an Encrypted Connection Between Two or More Hosts

The following figure 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

This figure 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 -x command. In this case, both system administrators should telephone one another and confirm the key ID.

Hosts that wish to communicate with each other must contain each other's addresses in their ACLs.

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

The following figure 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

Install a SunCA X.509 key of the same encryption strength.
Manually exchange certificates.
Use SKIP protocol Version 1.
Have an IP address or remote name.
Use the same algorithm 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 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 communicating with a SunScreen SPF-100. You must physically exchange the physical diskettes containing the public keys. 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.

You must configure both the host and the SunScreen SPF-100 ACLs 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 the 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

The following figure 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, must

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.
Exchange names or certificates.
Use the same version of the SKIP protocol.
Have an IP address or remote name.
Use the same algorithm that includes authentication, key encryption, and traffic encryption.
Enable SKIP.

A machine must also have a local identity. Hosts can have many identities, but you must choose one to use when communicating with 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. You should do this over the telephone or some other out of band media.

Type the encrypting gateway's information into the Add System box of skiptool. Then, set the Tunnel Address field of this box to be the IP address of the intermediate system. This action lets certificate discovery 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. You should set up the ACL in the host as shown in the following table.

Table 5-1 The ACL for the Host


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

You 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

The following figure 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

The following figure 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 host sends packets 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, you 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.