test

SunScreen 3.2 Administrator's Overview

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.