test

SunScreen 3.2 Administrator's Overview

IPsec/IKE

IPsec is the name of the IETF standard system for Internet Protocol security. Specified in RFCs 2401, 2402, 2406, and 2409, among others, IPsec provides network-layer security for IP packets, and therefore, for any protocol that is based on IP. IPsec provides approximately the same functionality as SKIP. Both were developed from the same ideas and technology, but IPsec has been adopted as an IETF standard and is supported by a growing variety of software and equipment vendors. IPsec security can include:

When a packet is sent using IPsec, it contains security information in addition to the normal payload and IP headers. If confidentiality is desired, the normal payload and some of the headers are encrypted using a cryptographic key, and can only be decrypted by a recipient with the correct key. If authentication and integrity protection are desired, a message authentication code (MAC) is computed by the sender using a cryptographic key and can be verified by a recipient with the correct key.

The security information in an IPsec packet is carried in one or both of the special headers that form the IPsec protocols: AH and ESP. AH is an authentication header inserted between a packet's IP header and its transport layer payload. AH does not modify the payload; it merely adds an integrity check value so that a recipient can confirm the authenticity of the payload. ESP (encapsulating security payload), on the other hand, does modify the payload by encrypting it, making it unreadable until a recipient decrypts it using the correct key.

A variety of encryption and authentication algorithms can be used, but both the sender and receiver must use the same algorithms and keys. Multiple "flows" of packets using different algorithms or keys can exist simultaneously between a pair of systems. Each flow of packets using a particular algorithm and key is identified by a security parameters index, or SPI, which is included in the IPsec headers for the receiver's use. The association of an algorithm, a key, and an SPI with a packet flow is called a security association (SA). Each system using IPsec has a security association database that helps control the processing of incoming and outgoing IPsec packets. A security association is unidirectional, so it is typical to have a pair of SAs, one in each direction, for bidirectional protocols such as TCP.

The specific algorithm and key used by each SA can be configured into both systems manually, or can be determined by an automatic process called the Internet Key Exchange (IKE). To configure an SA manually, each administrator of two communicating systems enters the SPI, algorithm, and key identically on each system. To use IKE, the administrator enters the algorithm to be used; IKE automatically chooses keys and changes the keys periodically to minimize the risk of massive data compromise in the event that a key is stolen or "cracked." Another difference between manual keying and using IKE is that IKE chooses parameters and sets up SAs for both directions of traffic, while the manually configured SAs have to be explicitly set up in each direction.

Internet Key Exchange (IKE)

IKE defines a two-phased protocol to establish IPsec SAs for the communication peers. In Phase I, an authenticated, ephemeral Diffie-Hellman exchange allows the peers to authenticate each other, and provides a secure communication channel (an IKE security association) for later use. The IKE SA created in Phase I is then used in Phase II to establish the IPsec SAs used in the ESP and AH security protocols. Multiple Phase II exchanges can be performed under a protection of a single Phase I IKE SA.

One of the following authentication methods must be chosen for the two IKE peers to authenticate each other:

IKE supports the use of X.509 public key certificates for authentication. SunScreen maintains a certificate database for the local system's certificates and for certificates of IKE peers with which the system may communicate. Certificates can be generated on a SunScreen system itself--self-signed, and manually distributed and verified--or can be generated and signed by a certificate authority, the signature validated automatically using the certificate authority's public certificate. An alternative to certificates is the use of a pre-shared key by both peers to authenticate each other, but this method has some security disadvantages.

Other security parameters that must be chosen for Phase I include an encryption algorithm (SunScreen supports DES and Triple-DES), an authentication algorithm (SunScreen supports MD5 and SHA-1), and an Oakley Group (SunScreen supports groups 1, 2, and 5).

Note -

RSA-ENCRYPTION cannot use certificate payload. This precludes interoperating with Win2K using this authmethod. Since Win2K does not support this authmethod, this is not a significant problem. The following two conditions must be met for RSA-ENCRYPTION:

SunScreen IPsec Configuration

SunScreen's IPsec module uses the same cryptographic (encryption and authentication) modules as the Solaris IPsec implementation. The IPsec encryption and authentication algorithms must be installed and configured in the Solaris kernel in order to be used by SunScreen. SunScreen and Solaris support DES and Triple-DES for encryption and MD5 and SHA-1 for authentication. You may need to install the optional software packages SUNWcryr and/or SUNWcryrx to make these algorithms available.

Configuration of IPsec and IKE in SunScreen is done through parameters to the rules. Please refer to ssadm-edit(1m) and rule(4sunscreen). Commands are provided for certificate generation and certificate database maintenance; see the man pages for ssadm-certlocal(1m) and ssadm-certdb(1m).