test

SunScreen 3.2 Administrator's Overview

Chapter 6 Encryption, Tunneling, and Virtual Private Networks

Encryption is the process by which a readable message is converted to an unreadable form to prevent unauthorized parties from reading it. Decryption is the process of converting an encrypted message back to its original (readable) format. This chapter includes discussions of the following:

Encryption and Decryption

An unencrypted message is called a plaintext message. An encrypted message is called a ciphertext message.

Digital encryption algorithms work by manipulating the content of a plaintext message mathematically, using an encryption algorithm and a digital key to produce a ciphertext version of the message. The sender and recipient can communicate securely if the sender and recipient are the only ones who know the key.

Encryption is important to SunScreen because it provides a mechanism for protecting the privacy of communications and authenticating the identities of the sender and receiver. Encryption technology enables you to authenticate systems and users. As a result, you can define rules that control access according to specific cryptographic identities rather than according to general IP addresses.

SunScreen uses either IPsec/IKE (Internet Protocol Security Architecture/Internet Key Exchange) or SKIP (SunScreen Simple Key Management for Internet Protocols) as the basis for its encryption technology. Both IKE and SKIP provide secure, encrypted communication between a remote Administration Station and a Screen and between a Screen and a remote host. SunScreen also provides for the use of tunneling and VPNs.

SunScreen incorporates cryptography at the network (IP) layer to provide privacy and authentication over insecure public networks such as the Internet. For full descriptions of SKIP, IPsec, and the Sun Certification-Authority-issued keys and certificates, see the SunScreen SKIP User's Guide, Release 1.5.1, "Overview of IPv6" in System Administration Guide, Volume 3, and "Overview of IPsec" in System Administration Guide, Volume 3.

You can use the skiptool GUI, IKE GUI, or the command line to set up an Adminstration Station to encrypt administration commands that travel from a remote Administration Station over a potentially insecure network to a Screen.

How SunScreen Uses Encryption

SunScreen uses a combination of public-key and shared-key cryptography to encrypt and decrypt packets. Any traffic that passes between any two systems or other SKIP devices can be encrypted. All administrative traffic between a Screen and a remote Administration Station is encrypted.

Packet Examination

When the rules and policies determine that a specific packet should be encrypted, the encrypted packet is first checked to see if it is too large to forward. Encrypted packets can be larger than the original packet for the following reasons:

If the new packet is too large to send on and the original packet carries the "Don't Fragment" bit, then a message is sent back to the sender with a request for a smaller packet: "ICMP Fragmentation needed, but Don't-Fragment bit set." If the new packet is too large and fragmentation is allowed, the original packet is first fragmented and then encrypted. The other end of the encryption tunnel can then decrypt each fragment independently.

The encryption routine builds a new IP packet to carry the original data. It uses the original source and destination addresses, or if tunneling is specified, the tunnel source and destination addresses.

After a new packet is created, the original packet is encrypted using the encryption mechanism specified (such as DES, RC2, or RC4) and a randomly generated traffic key. The traffic key is then encrypted using the encryption mechanism specified (DES or RC2) and a key-encrypting key from the SKIP key manager. The new IP header, SKIP header, and encrypted data are concatenated to form the new IP packet that is sent on to the destination addresses.

Note -

Because of a limitation in SunScreen SKIP 1.5.1 for Solaris, the RC2 encryption algorithm is not available when running Solaris 7 and Solaris 8 in 64-bit mode.

When an encrypted packet is received, it is passed to the decryptor. By examining the SKIP header, the decryptor determines the correct decryption mechanisms for both the encrypted traffic key (DES or RC2) and the encrypted data (DES, RC2, or RC4). It retrieves the traffic-encrypting key from the key manager and decrypts the traffic key that in turn decrypts the original IP packet.

Finally, the decrypted packet is sent through the rules or policies to determine the action for the packet (for example, whether the decrypted packet should be passed or dropped).

Note -

See "Using IKE With SunScreen" for the IKE case.

Tunneling

SunScreen can use encryption in a feature called tunneling that is used to hide actual source and destination addresses. With tunneling you can substitute other addresses for the addresses on the packet header. When the Screen tunnels a packet, it replaces the packet's source address with the tunnel address of the From Encryptor and replaces the packet's destination address with the (optional) tunnel address of the To Encryptor. When the Screen decrypts a packet, the original addresses are restored.

Organizations typically have offices in more than one location. The tunneling feature enables the different offices to use public networks as a secure private network without needing dedicated lines and with no changes to user applications.

When a tunnel, or virtual private network (VPN), is set up between two locations, all data packets traveling from one location to the other are encrypted and encapsulated inside other packets before they are sent over the public internetwork. Encrypting the packets guarantees that their contents remain private; anyone capturing packets to snoop on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are extracted, decrypted, and forwarded to their intended destination.

In addition to protecting the privacy of network traffic, tunneling also lets a site conceal the details of its network topology from intruders or eavesdroppers. Because the original packets are encrypted, the source and destination addresses in their IP headers cannot be read. When the encrypted packets are encapsulated in other packets, the new IP headers identify the addresses of the Screens that protect the locations, not the hosts that originated the packets. Consequently, the network topology behind the Screens is never exposed.

The figure below illustrates how tunneling affects the outside IP header of a packet traveling from Host A to Host B. Note that the encrypted packet containing the original data Host A sent to Host B is the same whether or not tunneling is used. Note also that the addresses in the figure are not meant to be valid IP addresses; they have been simplified for illustrative purposes.

Figure 6-1 Effect of Tunneling on Contents of IP Headers

Graphic

If you do not use a VPN (a tunnel) to transfer data between the two locations, the source and destination addresses on the outer IP header are the same as the source and destination addresses on the inner (encrypted) IP header: 1.1.1.10 and 2.2.2.10, respectively. Someone intercepting this packet cannot read its contents, but can determine that hosts with IP addresses 1.1.1.10 and 2.2.2.10 reside behind the Screens protecting the two locations.

If you use a VPN to transfer data between the two locations, the Screen protecting Host A substitutes the IP address of its external interface (1.1.1.1) for the IP address of host A (1.1.1.10) in the Source Address field of the external IP header. Similarly, it substitutes the external IP address of the Screen at the other end of the tunnel (2.2.2.1) for the IP address of Host B in the Destination field. The local Screen then sends the packet through the insecure public network to the remote Screen.

When the remote Screen receives the packet, it strips off the encapsulation and decrypts the original packet from Host A. The remote Screen then reads the destination address from the original IP header of the decrypted packet and forwards the packet to Host B.

Because the IP addresses behind the Screen are never exposed to hosts on the external Internet, the two locations do not need to assign externally valid IP addresses to hosts behind the Screens. As long as hosts behind the Screens do not need to communicate with hosts on the Internet, the two locations can use a shared IP address space, as shown in Figure 6-2.

Figure 6-2 Geographically Dispersed Network

Graphic

Using IKE With SunScreen

This section describes the IKE syntax and options as well as providing command line examples of policy rules that use IKE. You can find detailed administration GUI and command line instructions for using IKE in the SunScreen 3.2 Administration Guide. Additionally, the SunScreen 3.2 Configuration Examples manual has examples of using IKE for encryption.

IKE usage within SunScreen had three components: the IKE negotiation, the authentication header (AH), and the encryption header (ESP). Either the AH or ESP option can be omitted, but authentication, which is available from both AH and ESP, must be included. Possible combinations are:

Note -

Unlike SKIP syntax, the IPsec and IKE parameter lists use parentheses to contain them.

Possible values for authalgN are:

Possible values for encralgN are:

The NULL algorithm is generally used for testing because it exercises nearly all the normal code paths but does not obscure the data. That means what is inside can be easily seen. In general, unless a non-NULL encryption algorithm (like DES-CBC or 3DES-CBC) is applied, the data will not be obscured.

The AH and ESP options control the cryptographic means that are used to protect the DATA portions of network traffic. They are functional equivalents of the DATA and MAC algorithms used in SKIP.

The IKE option performs the functional equivalent of the rest of the options in SKIP, including the KEY algorithm and the naming of the certified cryptographic data to be used for configuring and securing the traffic.

IKE Options

IKE options have the form:

IKE(encralg2, authalg3, oakleygroup, PRE-SHARED, presharedkey)

or

IKE(encralg2, authalg3, oakleygroup, authmethod, srcidentity, dstidentity)

Note -

The above syntax is that used in policy rules. In the contexts of AccessRemote, Screen, and VPNgateway objects, the syntax does not allow the PRE-SHARED formulation, the srcidentity is the local Screen's identity, and there is no dstidentity value.

For IKE, the parameters given determine the mechanisms to be used to validate signed security items, and the algorithms and parameters to be used to negotiate keys and other interactions which precede the actual transmission of data. (In IKE parlance, this is called the "phase 1" negotiation; "phase 2" is the use of the negotiated key to secure the client data.)

The lists for encralg2 and authalg3 are the same as for AH and ESP (see the third component listed for IKE usage within SunScreen).

The oakleygroup parameter represents a Diffie-Hellman Group. That parameter controls the type of cryptographic mathematics to be used in key generation. These are given as single-digit numbers. SunScreen supports:

The authmethod determines how the certified key items (for example, certificates) are to be validated. The current values are:

IKE Certificates

SINGLE IKE certificates contain a matching pattern, or even a portion of a matching pattern, that is evaluated as needed by the IKE software. IKE certificates have a variety of naming methodologies, among them DNS names of hosts, mailbox names of users (which contain DNS names), IP addresses (both V4 and V6), and X.500 composite names.

IKE certificate groups are also dissimilar from SKIP groups. In IKE, a certificate group is defined in a manner similar to that of SunScreen address objects (with some restrictions). The IKE certificate group is really just a mechanism for expressing composite names (complex patterns).

The restrictions on IKE certificate groups relate to the context in which their exclusion lists can be used. Only a top-most IKE certificate group can use exclusions; all other groups can only contain inclusions. This restriction helps avoid various bizarre naming situations that might otherwise arise.

Pre-Shared Option

The PRE-SHARED option is a degenerate key certification mechanism. This option indicates that a manual key has been defined out-of-band between the peer systems, and that key requires no further validation. It differs from purely manual keying in that only the IKE negotiation uses the manual key; IKE still negotiates and changes the keys used for data protection.

The srcidentity and dstidentity certificates refer to Certificate objects. Certificate objects so used can be either SINGLE IKE or groups of other IKE Certificate objects.

Note -

You cannot intermix IKE and SKIP certificate objects within a certificate group.

Certificate Options

srcidentity refers to the certificate(s) to be associated with and representing the source addresses with respect to the data protected by the policy rule in question.

dstidentity refers to the certificate(s) to be associated with and representing the destination addresses with respect to the data protected by the policy rule in question.

srcidentity and dstidentity must both be verifiable using the authmethod given.

IKE Policy Rules

Besides the IKE options given above, IKE policy rules can also specify a SOURCE_SCREEN and a DESTINATION_SCREEN clause. These clauses each take the name of a Screen object, and anchor the usage of a rule to particular Screens upon which to perform the specified IKE processing.

Like SKIP, IKE policy rules can also use the SOURCE_TUNNEL and DESTINATION_TUNNEL options; as in SKIP, these specify a (possibly fictitious) IP address (object) to be used as the tunnel identity at one or both ends of an encrypted tunnel.

In addition, IKE policy rules can use TRANSPORT mode, which does not tunnel the data (wrap a new IP header outside an inner one), but rather secures the data portion of an IP datagram, using and leaving exposed the original source and destination IP addresses.

IKE Policy Rule Syntax

Command line syntax for various IKE policy rules is shown below. Note that the backslash (\) at the end of a line indicates that the line continues on the next line. Do not include any Returns, Enters, or backslashes when typing rules.

Defining a VPN

A VPN is a group of Screens that transfer encrypted data among themselves. A VPN simulates a private network using a public network, with IP-level encryption providing privacy.

Note -

A VPN object in SunScreen--called a "VPN" in this document--is not a virtual private network as generally defined in the firewall industry. It is a mechanism for implementing SunScreen's version of a VPN.

After a VPN has been defined, you can refer to it when adding rules to your security policy. This means you can define your security policy with fewer rules. The system automatically generates the multiple rules that the VPN defines.

In defining a VPN:

When defining a VPN gateway object, which is a list of Screens, specify the following information:

Note -

See ssadm-rule(1m) for information about VPNs using IPsec/IKE.

The site shown in Figure 6-3 has ten Screens. One of the systems protected by each Screen is a mail server. Assume that your security policy allows the exchange of encrypted mail between all these mail servers and you want to define rules to allow SMTP between all of the mail servers.

Figure 6-3 Sample Ten-Network Site

Graphic

Without a VPN, you must define nine rules on each Screen for each mail server to send mail encrypted to the other nine mail servers. Because you have ten mail servers, you must define a total of 90 rules. If, instead you defined a VPN, you only need a single rule: one that allows the mail servers to send mail to the other mail servers using the VPN. Because you have ten Screens in the VPN, you must define ten VPN gateway entries.

Looking at this example in detail, the figure below shows the configuration. In this example, the name for the VPN is "ourVPN." The Screens are labeled Screen1 through Screen10. The mail servers behind them are labeled mail1 through mail10 and are part of network1 through network10.

Once you have defined the VPN objects, as shown in the figure below, you can use the VPN in any rule. Select VPN as the action for the data between the sender and the SMTP server, and specify the name of the VPN.

Figure 6-4 VPN Tab with VPN Entries

Graphic

Adding a VPN Rule

Assuming an address group named MailServers containing all the mail servers exchanging encrypted mail, define the rule in the Rule Definition dialog box shown in the figure below.

Figure 6-5 Completed Rule Definition Dialog Box for the VPN Rule

Graphic

The VPN rule appears on the Packet Filtering tab of the Policy Rules page. The more restrictive a rule is, the earlier it should be ordered in the list of rules because the rules take effect in order. The more restrictive VPN rule comes before the more general rule and so will take effect earlier.

Figure 6-6 VPN Rule

Graphic

There is no limit to the number of VPNs to which a Screen can belong. For example, you can define two VPNs--one for encryption at 1024 bits, and one for encryption at 4096 bits. A single Screen can belong to both of those VPNs: one entry specifying the 1024-bit certificate, and the other specifying the 4096-bit certificate.

VPN Limitations

Currently, the VPN object has the following limitation: