Configuration Reference

IPSec policies specify the actions or transformations that will be applied to IP packets. An IPSec policy includes an IP packet filter and a transform (action) list. When IP packets are initially sent or received, HP-UX IPSec uses the IP packet filters to select an IPSec policy. It then takes the action specified in the transform list.

The configuration reference describes each configurable element of an IPSec policy in detail. For detailed procedures on configuring an IPSec policy, see Chapter 3 “Configuring HP-UX IPSec ”.

Below is the Create IPSec Policy screen.

The main components of an IPSec policy are described in the following sections.

Name

A unique identifier for the policy.

There is one reserved IPSec policy name: default. IPSec uses the default policy for any IP packets that do not match the filters of any other IPSec policy in the database. The default policy is pre-created for you and you cannot delete it. However, you can modify the IPSec Transform List for the default policy from Pass to Discard or vice-versa.

Exclusive

Use this flag to configure SAs to be shared (host-based keying) or exclusive (session-based keying). The default is host-based keying. Check Exclusive to select session-based keying.

You can select session-based keying (check Exclusive ) only if the transform list does not contain Discard or Pass as the transform policy.

You must use session-based keying if the transform for the policy is not Pass or Discard and the remote prefix length indicates a subnet (value of less than 32 for IPv4 or value of less than 128 for IPv6) or if the remote IP address is a wildcard (*). In this case, Exclusive is selected and unmodifiable (checkbox is grayed out).




	NOTE: If IPSec is configured with a transform that is not `Pass` or `Discard`, and the remote IP address is a subnet, then IPSec automatically selects the `Exclusive` flag. The checkbox is selected and unmodifiable (grayed out).

Host-based keying allows multiple connections, or sessions, between two systems to share the same two SAs created by HP-UX IPSec. With host-based keying, all IP packets that use the same IPSec policy between the same host pair (the source IP address and destination IP address are the same) will share the same IPSec/QM SA pair.

With session-based keying, a different pair of IPSec/QM SAs are used per connection or session. All the packets with the same source IP address, destination IP address, network protocol, source port, and destination port will share the same IPSec/QM SA pair. Session-based keying incurs more overhead but allows for a more secure or private connection.

Policy Type

IPSec policies can be placed in a Hashed List or an Ordered List.

To place a policy in the Hashed List, the policy filter must have at least one IP address (local or remote) or port (local or remote) specification that is hashable. A hashable specification has a single, non-expandable value.

How HP-UX IPSec Selects Policies

When HP-UX IPSec searches for an IPSec policy to use for an IP packet, it first searches the Hashed List for the policy with the IP packet filter that best matches the packet. The best match is the filter that matches the packet and has the largest number of hashable fields (up to 4) that match the packet. If multiple filters have the same number of hashable fields that match the packet, HP-UX IPSec selects the first of these policies according to the order in the configuration file.

If HP-UX IPSec finds no match in the Hashed List, it then sequentially searches the Ordered List for the first policy with an IP packet filter that matches the packet. If no match is found in the Ordered List, HP-UX IPSec uses the default IPSec policy




	NOTE: To change the order of the policies in the `Ordered List` on the `Create IPSec Policy` screen, select the policy you want to move, then click the up or down arrow on the right-hand side of the screen.

The advantage of a Hashed List search is that it takes less time to find a policy that matches an IP packet than searching sequentially through an Ordered List. The advantage of an Ordered List search is that the IPSec Administrator controls the order in which the policies are searched.

The IPSec policy database can contain hashed policies, ordered policies, or a combination of hashed and ordered policies.

Filters

The combination of the Protocol, Local IP Address, Local Prefix Length, Local Port, Remote IP Address, Remote Prefix Length, and Remote Port fields define an IP packet filter. HP-UX IPSec uses this filter to select the IPSec policy to use for an IP packet.

You will have the choice of configuring your policy automatically based on a service type such as telnet or configuring it manually. When you configure a policy based on service type, the service field in ipsec_mgr automatically displays a list of possible services. After choosing a service, you must also choose either an inbound or outbound direction. Once you choose a service, the Protocol, Local Port, Remote Port, From Local to Remote, and From Remote to Local fields are filled in automatically with the appropriate values for the service.

If you are configuring manually, you must configure the Protocol, Local Port, Remote Port, From Local to Remote, and From Remote to Local fields manually.

HP-UX IPSec then checks the Transform List to determine what action to take.

By default, the transform is applied in both directions to:

Packets from the local address and port to the remote address and port
Packets from the remote address and port to the local address and port

You can restrict the IPSec policy so that the transform is only applied to packets in one direction using the option in the Apply to IP Datagrams area.




	CAUTION: Discarding or requiring ICMP messages (Internet Control Message Protocol messages, protocol value 1) to be encrypted or authenticated may cause connectivity problems. Be careful when configuring the default IPSec policy or IPSec policies that affect entire subnets because you may inadvertently cause ICMP messages to be discarded. You may also inadvertantly require ICMP messages being transmitted or received from a non-IPSec gateway or router to be authenticated or encrypted, which will cause ICMP packets to be discarded. See “HP-UX IPSec Product Requirements” for more information.

Filter Example

On node 192.168.1.1, you want to specify that all telnet traffic to and from the 192.0.0.0 subnet is encrypted using ESP-DES. In other words, you want to use DES encryption when a user on the local system telnets to a node on the 192.0.0.0 subnet and you also want to use DES encryption when a user on the 192.0.0.0 subnet telnets to the local node. To do so, you must create two IPSec policies.

The first policy specifies a filter for telnet requests from the local node to nodes on the 192.0.0.0 subnet:

Service:  telnet             Direction: Outbound
 
Local                        Remote
 
IP Address  192.168.1.1      IP Address    192.0.0.0
 
Prefix Length:       32      	Prefix Length:         8
 
Protocol:   TCP
 
Port:       *                Port:         23
 
  
 
Apply to IP Datagrams
 
X   From Local to Remote
 
X   From Remote to Local

The local port number is a * (wildcard) because the telnet clients will use any non-reserved TCP port.

The remote port number is 23 because telnet daemons (telnetd) receive incoming requests on TCP port 23.

For Direction, you specify both Local to Remote and From Remote to Local. This ensures that HP-UX IPSec encrypts telnet requests from the local client to the remote telnet daemon and replies from the remote telnet daemon to local telnet clients.

Specify ESP-DES for the HP-UX IPSec Transform.

The second IPSec policy specifies a filter for telnet requests from clients on the 192.0.0.0 subnet to the local node:

  Service:  telnet               Direction: Inbound
 
 
  Local                          Remote
 
  IP Address  192.168.1.1        IP Address 192.0.0.0
 
  Prefix Length:       32        Prefix Length:      8
 
  Protocol:  TCP
 
 
  Port:       23                 Port:      *
 
 
 
 Apply to IP Datagrams
 
  X  From Local to Remote
 
  X  From Remote to Local

In this filter, the local port number is 23 (the telnet port). The remote port is a * (Wildcard) because the remote telnet clients will use any non-reserved TCP port.

Specify ESP-DES for the HP-UX IPSec Transform.

Apply to IP Datagrams

By default, an IPSec policy applies to IP datagrams in both directions.

Packets from the local address and port to the remote address and port.
Packets from the remote address and port to the local address and port.

You can restrict the IPSec policy so that the transform is only applied to datagrams in one direction.

Transform List

A transform list, which defines the action HP-UX IPSec applies to packets using the IPSec policy:

Discard the packet
Let it pass with no alteration or
Apply authentication and/or encryption.

The transform list is used when negotiating IPSec Security Associations (SAs) with the remote system. Configure the transform list so that it will be accepted by the remote system during negotiations.The order of the entries in the transform list is significant. The first transform is the most preferable and the last transform is the least preferable. The GUI adds new transforms to the end of the list.Valid combinations:

A list that contains only Pass or Discard
A list that contains up to 2 AH transforms
A list that contains up to 8 ESP transforms
A list that contains one single AH&ESP (ESP nested inside of AH) transform

If you combine transformations to form a nested transform (AH&ESP), the lifetime values must all be set to the same value.

Creating Nested Transforms

To create nested transforms, you must first select at least two transforms from the Transform window. To do so, first select one AH transform, then press CTRL and select one ESP transform.

This will nest the two transforms and place the new transform on the Transform List screen.

Authentication Algorithms

These algorithms are used to provide the authentication value used in an IPSec Authentication Header (AH).

The AH provides data integrity, system-level authentication, and can provide anti-replay protection.

AH-MD5

Hashed Message Authentication Code (HMAC) using RSAs Message Digest-5. (128 bit message digest encrypted with a 128 bit key.)

AH-SHA1

HMAC using the Secure Hash Algorithm-l. (160 bit digest encrypted with 160 bit key.)

Encryption Algorithms

These algorithms are used to encrypt the IP payload for an IPSec Encapsulating Security Payload (ESP). The ESP provides confidentiality (encryption).

In addition, there are authenticated ESP algorithms, which include an encryption algorithm and an authentication algorithm. The authentication algorithm is used to compute an Integrity Check Value (ICV) to authenticate the ESP header and IP data. The ICV does not authenticate the original IP header unless tunnelling is used.

ESP-DES

ESP using Data Encryption Standard Cipher Block Chaining (CBC) Mode encryption, with a 56 bit key.




	NOTE: DES has been cracked (data encoded using DES has been decoded by a third party).

ESP-DES-HMAC-MD5

Authenticated ESP using DES-CBC encryption and HMAC-MD5 to generate an Integrity Check Value (ICV) for authentication.

ESP-DES-HMAC-SHA1

Authenticated ESP using DES-CBC encryption and HMAC-SHA1 to generate with an ICV.

ESP-3DES

ESP using triple DES-CBC encryption (three encryption iterations, each with a different 56-bit key).

ESP-3DES-HMAC-MD5

Authenticated ESP using 3DES-CBC encryption and HMAC-MD5 to generate an ICV.

ESP-3DES-HMAC-SHA1

Authenticated ESP using 3DES-CBC encryption and HMAC-SHA1 to generate an ICV.

ESP-AES128

Authenticated ESP using AES128 encryption.




	NOTE: AES provides the most secure encryption, with the system performance comparable to or better than DES and 3DES.

ESP-AES128-HMAC-MD5

Authenticated ESP using AES128 encryption and HMAC-MD5 to generate an ICV.

ESP-AES128-HMAC-SHA1

Authenticated ESP using AES128 encryption and HMAC-SHA1 to generate an ICV.

ESP-NULL-HMAC-MD5

ESP header and trailer, but nothing is encrypted. An ICV is generated using HMAC-MD5.

ESP-NULL-HMAC-SHA1

ESP header and trailer, but nothing is encrypted. An ICV is generated using HMAC-SHA1.




	NOTE: If you are configuring an HP-UX IPSec system to interoperate with a Linux FreeSwan system, you can use 3DES encryption or AES encryption with the appropriate FreeSwan crypto algorithm patch. Linux FreeSwan does not support DES encryption.

Transform Lifetime Values

You can edit the preferred lifetimes associated with the transform you selected if the specified algorithm in the transform list is used. The actual lifetimes used depends on negotiations with the remote system.

If the local system initiates the IPSec negotiations, the ISAKMP daemon will send the preferred lifetime to the remote system. The remote system may process this value in any manner according to the IPSec protocol specification.

If the remote system initiates the IPSec negotiations, the ISAKMP daemon will accept the lifetime sent by the remote system, within the range specified by the IPSec protocol.

The lifetime values will be linked to the system-wide lifetime values configured for this transform algorithm, if you check Use System Values on the Edit Transform Lifetimes screen. Any changes to the system-wide lifetime values for this transform algorithm will affect all the IPSec policies referencing this transform.

Nested AH and ESP Transforms

You can create a nested AH and ESP transform by using CTRL + click to select both an authentication (AH) transform and an encryption (ESP) transform and clicking Add.

For example, you can create the combination HMAC-MD5 & DES-CBC. With this combination, HP-UX IPSec will use DES-CBC to build an ESP with the IP data encrypted. HP-UX IPSec will then nest this within an AH transform, using HMAC-MD5 to authenticate the ESP and the entire IP packet, including the immutable fields of the original IP header.

This differs from a DES-CBC-HMAC-MD5 transform, which is an authenticated ESP transform which only adds an IP header. The DES-CBC-HMAC-MD5 transform authenticates only the ESP header and IP data, and does not authenticate the original IP header unless tunnelling is used.

Comparative Key Lengths

Below is a table showing the key lengths of AH and ESP algorithms. In general, the longer the key length, the more secure the encryption algorithm will be. The encryption algorithms (DES, 3DES, AES) with longer key lengths, however, are also slower.

Table D-1 Title not available (Comparative Key Lengths)

Algorithm	Key Length
ESP-DES	56
ESP-3DES	168 (3 x 56)
ESP-AES	128
AH-MD5	128
AH-SHA1	160

3DES (Triple-DES) uses three independent 56-bit keys. The data is encrypted in three stages: it is encrypted using key1, decrypted using key2, and encrypted again using key3.

AES with HP-UX IPSec supports 128-bit keys. AES encryption is stronger than that of 3DES. In addition, processing speed is faster with AES, comparable to or better than that of DES encryption.

HMAC-SHA1 generates a 160-bit message digest and uses a 160-bit shared secret key to encrypt the digest.

HMAC-MD5 generates a 128-bit message digest and uses a 128-bit shared secret key to encrypt the digest.

ISAKMP Policy Name

This is the name of the ISAKMP policy to use with this IPSec policy. If an IPSec policy’s Transform List specifies any authentication or encryption, HP-UX IPSec must establish an IPSec/QM SA with the remote system to negotiate the parameters for the authentication or encryption, including encryption key information. These negotiations require a secure channel, which is provided by an ISAKMP/MM SA. If there is no active ISAKMP/MM SA with the remote system, HP-UX IPSec will establish a new one according to the ISAKMP policy specified in the IPSec policy.

Do not specify an ISAKMP policy if the transform list contains Discard or Pass (there is no encryption or authentication).

In an ISAKMP policy, you define the parameters for the ISAKMP/MM SA. The ISAKMP SA uses the Diffie-Hellman method to create a secure channel from publicly-exchanged information. HP-UX IPSec then uses this secure channel to negotiate IPSec/QM SAs. In the ISAKMP policy, you define Diffie-Hellman parameters, how you will perform the ISAKMP/Oakley primary authentication (preshared key, certificate-based RSA digital signature), and what type of authentication and encryption to use for the ISAKMP/Oakley dialogue.




	NOTE: The same ISAKMP policy must be used if multiple IPSec policies reference the same remote IP address.

Certificate ID Types and Values

You may need to create an ID if you are using certificate-based authentication (RSA signatures) for ISAKMP.

If you are configuring an HP-to-HP connection using certificates, you do not need to create certificate IDs. Both HP hosts must have single IP addresses and the IP address of the machine must match the IP address of the certificate on that host.

If you are configuring an HP-to-other connection using certificates, you must configure a certificate ID for the “other” host’s certificate.

Certificate ID Types

IPv4 Address

The IP address of the system the certificate is associated with, as it is recorded in the certificate file.

FQDN

The Fully Qualified Domain Name (FQDN) of the subject of the certificate, as recorded in the certificate file.

User-FQDN

The User-Fully Qualified Domain Name (User-FQDN) of the subject of the certificate, as recorded in the certificate file.

Subject DN

The Subject distinguishedName (Subject DN) of the subject of the certificate, as recorded in the certificate file.

Certificate ID Values

IPv4 Address

The IP address of the system the certificate is associated with, as it is recorded in the certificate file. This address must be in standard dot notation.

FQDN

The Fully Qualified Domain Name (FQDN), also known as the Domain Name Server (DNS), of the subject of the certificate, as recorded in the certificate file. The FQDN must be in ASCII format. For example, myhost.hp.com.

User-FQDN

The User-Fully Qualified Domain Name (User-FQDN) of the subject of the certificate, as recorded in the certificate file. The User-FQDN must be in SMTP mail address format. For example: user@hp.com.

Subject DN

The Subject distinguishedName (Subject DN) consists of the following values:

commonName: The commonName of the Subject DN is printable string format. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

organization: The organization of the Subject DN, for example Hewlett-Packard. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

country: The two-character ISO 3166-1 code for the country listed in the Subject DN, for example US for United States of America. This field is required. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.

organizationalUnit: The organizationalUnit for the Subject DN, for example Marketing. This field is optional. Commas are not accepted as part of this value. The size of this value must not exceed 64 bytes.