[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

System Management Guide: Communications and Networks

Configuring IKE Tunnels

Internet Key Exchange (IKE) tunnels have more complex policy parameters. In most cases, you must use the Web-based System Manager interface to configure IKE tunnels. The Basic Configuration wizard provides an easy way to define an IKE tunnel with preshared keys. For more advanced options, see Advanced IKE Tunnel Configuration.

Basic Configuration Wizard

The basic configuration wizard is an easy way to define an IKE tunnel through Web-based System Manager using preshared keys or certificates as the authentication method. It adds new key management and data management IKE tunnels to the IP Security subsystem, allows you to input minimal data and choose some options, and makes use of common default values for such parameters as tunnel lifetime. The basic configuration wizard can also be used on the remote endpoint to quickly set up a corresponding IKE tunnel end point.

Once a tunnel is defined using the wizard, the tunnel definition appears in the Web-based System Manager IKE tunnels list and can be activated or modified.

When using the basic configuration wizard, keep the following in mind:

Use the following procedure to configure a new tunnel using the wizard:

  1. Open Web-based System Manager using the wsm command.
  2. Select the Network plug-in.
  3. Select Virtual Private Networks (IP Security).
  4. From the Console area, choose the Overview and Tasks folder.
  5. Select Configure a Basic Tunnel Configuration wizard.
  6. Click on Next on the Step 1 Introduction panel then follow the steps to configure an IKE tunnel. There are six configuration dialogs.

    Online help is available if you need it.

Advanced IKE Tunnel Configuration

Creating IKE tunnels differs from creating manual tunnels because the setting of security policy is a separate process from defining tunnel endpoints. In IKE, there is a two-step negotiation process, called phases, and each phase can have separate security policies.

When the Internet Key negotiation starts, it must set up a secure channel for the negotiations. This is known as the key management phase or phase 1. During this phase, each party uses preshared keys or digital certificates to authenticate the other and pass ID information. This phase sets up a security association during which the two parties determine how they plan to communicate securely and then which protections are to be used to communicate during the second phase. The result of this phase is an IKE or phase 1 tunnel.

The second phase is known as the data management phase or phase 2 and uses the IKE tunnel to create the IP Sec security associations for AH and ESP that actually protect traffic. The second phase also determines the data that will be using the IP Security tunnel. For example, it can specify:

Figure 4-4. IKE Tunnel Setup Process. This illustration shows the two-step, two-phase process for setting up an IKE tunnel. A description of this process can be found in the document text.

Artwork for comma46

In many cases, the endpoints of the key management (IKE) tunnel will be the same as the endpoints of the data management (IP Security) tunnel. The IKE tunnel endpoints are the IDs of the machines carrying out the negotiation. The IP Security tunnel endpoints describe the type of traffic that will use the IP Security tunnel. For simple host-to-host tunnels, in which all traffic between two tunnels is protected with the same tunnel, the phase 1 and phase 2 tunnel endpoints are the same. When negotiating parties are two gateways, the IKE tunnel endpoints are the two gateways, and the IP Security tunnel endpoints are the machines or subnets (behind the gateways) or the range of addresses (behind the gateways) of the tunnel users.

Key Management Parameters and Policy

The following parameters are set during phase 1 (the key management phase) of an IKE tunnel configuration:

Key Management
(Phase 1) Tunnel
The name of this IKE tunnel. For each tunnel, the endpoints of the negotiation must be specified. These are the two machines that plan to send and validate IKE messages. The name of the tunnel may describe the tunnel endpoints such as VPN Boston or VPN Acme.
Host Identity Type The ID type that will be used in the IKE exchange. The ID type and value must match the value for the preshared key to ensure that proper key lookup is performed. If a separate ID is used to search a preshared key value, the host ID is the key's ID and its type is KEY_ID. The KEY_ID type is useful if a single host has more than one preshared key value
Host Identity The value of the host ID represented as an IP address, a fully qualified domain name (FQDN), or a user at the fully qualified domain name (user@FQDN). For example:

IP Address The IP address of the remote host. This value is required when the host ID type is KEY_ID or whenever the host ID type cannot be resolved to an IP address. For example, if the user name cannot be resolved with a local nameserver, the IP address for the remote side must be entered.

You can customize key management policy by specifying the parameters to be used during IKE negotiation. For example, there are key management policies for preshared key or signature mode authentication. For Phase 1, the user must determine certain key management security properties with which to carry out the exchange. These properties are fully described in the help available with Web-based System Manager and in the documentation for the ike command.

Data Management Parameters and Policy

The data management proposal parameters are set during phase 2 of an IKE tunnel configuration. They are the same IP Security parameters used in manual tunnels and describe the type of protection to be used for protecting data traffic in the tunnel. You can start more than one phase 2 tunnel under the same phase 1 tunnel.

The following endpoint ID types describe the type of data that is to use the IP Security Data tunnel:

Host, Subnet, or Range Describes whether the data traffic traveling in the tunnel will be for a particular host, subnet, or address range.
Host/Subnet ID Contains the host or subnet identity of the local and remote systems passing traffic over this tunnel. Determines the IDs sent in the phase 2 negotiation and the filter rules that will be built if the negotiation is successful.
Subnet mask Describes all IP addresses within the subnet (for example, host and mask
Starting IP Address Range Provides the starting IP address for the range of addresses that will be using the tunnel (for example, of to
Ending IP Address Range Provides the ending IP address for the range of addresses that will be using the tunnel (for example, of to
Port Describes data using a specific port number (for example, 21 or 23)
Protocol Describes data being transported with a specific protocol (for example, TCP or UDP). Determines the protocol sent in the phase 2 negotiation and the filter rules that will be built if the negotiation is successful. The protocol for the local endpoint must match the protocol for the remote end point.

The data management parameters are fully described in the help available with Web-based System Manager and in the documentation for the ike command.

Setting up, Key Management

IKE tunnels are configured using the Web-based System Manager tool. Use the following procedure to add an IKE tunnel:

  1. Open Web-based System Manager using the wsm command.
  2. Select the Network plug-in.
  3. Select Virtual Private Networks (IP Security).
  4. From the Console area, choose the Overview and Tasks folder.
  5. Start IP Security. This action loads the IP Security kernel extensions and starts the isakmpd, tmd, and cpsd daemons.

    A tunnel is created by defining the key management and data management endpoints and their associated security transforms and proposals.

    The same key management tunnel can be used to protect multiple data management negotiations and key refreshes, as long as they take place between the same two endpoints, for example between two gateways.

  6. To define the key management tunnel endpoints, click on Internet Key Exchange (IKE) Tunnels from the Identification tab.
  7. Enter information to describe the identities of the systems taking part in the negotiations. In most cases, IP addresses are used, and a policy compatible with the remote side must be created.

    On the Transforms tab, use matching transforms on both sides, or contact the administrator on the remote end to define a matching transform. A transform containing several choices can be created to allow flexibility when proposing or matching on a transform.

  8. If using preshared keys for authentication, enter the preshared key under the key tab. This value must match on both the remote and local machines.
  9. Create a transform to be associated with this tunnel using the Add button on the Transforms tab.

    To enable digital certificates and signature mode support, choose an authentication method of RSA Signature or RSA Signature with CRL Checking.

    For more information about digital certificates, see Digital Certificate Configuration.

Setting up, Data Management

To set up data management tunnel endpoints and proposals and to complete IKE tunnel setup, launch the Web-based System Manager tool, as described in Setting up, Key Management. A data management tunnel is created by selecting a key management tunnel and defining any unique options. Most data management options can remain as defined by the default.

However, you must specify endpoint types (such as IP address, subnet, or IP address range) under the Endpoints tab. You can select a port number and protocol or accept the default.

On the Proposals panel, you can create a new proposal by selecting the Add button or simply click on OK to create a proposal. If there are multiple proposals, you can use the Move Up or Move Down buttons to change the search order.

Group Support

Beginning with AIX 5.1, IP security supports grouping IKE IDs in a tunnel definition to associate multiple IDs with a single security policy without having to create separate tunnel definitions. Grouping is especially useful when setting up connections to several remote hosts, because you can avoid setting up or managing multiple tunnel definitions. Also, if changes must be made to a security policy, you do not need to change multiple tunnel definitions.

A group is composed of a group name and a list of IKE IDs and ID types. The IDs can all be the same type or a mix of IPv4 addresses, IPv6 addresses, FQDN, user@FQDN, and X500 DN types. During a Security Association negotiation, the IDs in a group are searched linearly for the first match.

A group must be defined before using that group name in tunnel definition. Use the ikedb command to define groups. This command accepts XML text as input to create a group definition in the IKE databases. The group's size is limited to 1 Kbyte.

A group name can be used in both key management tunnel and data management tunnel definitions, but can be used only as a remote ID.

Activating a Tunnel

Activate the tunnel using the Web-based System Manager tool (see Setting up, Key Management) or from the command line using the ike command. Online help is available for the Web-based System Manager tool. The following instructions describe how to activate a tunnel from the command line.

  1. To start a tunnel negotiation (activate a tunnel) or to allow the incoming system to act as a responder (depending on the role that is specified), use the ike command with a tunnel number, as shown in the following example:

    ike cmd=activate numlist=1

    You can also use remote id or IP addresses, as shown in the following examples:

    ike cmd=activate remid=
    ike cmd=activate ipaddr=,

    Since it may take several seconds for the commands to complete, the command returns after the negotiation is started.

  2. To ensure the command was successful, use the following command to display the tunnel status.

    ike cmd=list

    The output looks similar to the following:

    Phase 1 Tunnel ID       [1]
    Phase 2 Tunnel ID       [1]

    This command shows the phase 1 and phase 2 tunnels that are currently active. To do a verbose listing of the tunnel, use the verbose option, as shown in the following example:

    ike cmd=list verbose
    Phase 1 Tunnel ID       1
    Local ID Type:          Fully_Qualified_Domain_Name
    Local ID:               bee.austin.ibm.com
    Remote ID Type:         Fully_Qualified_Domain_Name
    Remote ID:              ipsec.austin.ibm.com
    Mode:                   Aggressive
    Security Policy:        BOTH_AGGR_3DES_MD5
    Role:                   Initiator
    Encryption Alg:         3DES-CBC
    Auth Alg:               Preshared Key
    Hash Alg:               MD5
    Key Lifetime:           28800 Seconds
    Key Lifesize:           0 Kbytes
    Key Rem Lifetime:       28737 Seconds
    Key Rem Lifesize:       0 Kbytes
    Key Refresh Overlap:    5%
    Tunnel Lifetime:        2592000 Seconds
    Tunnel Lifesize:        0 Kbytes
    Tun Rem Lifetime:       2591937 Seconds
    Status:                 Active
    Phase 2 Tunnel ID       1
    Local ID Type:          IPv4_Address
    Local ID:     
    Local Subnet Mask:      N/A
    Local Port:             any
    Local Protocol:         all
    Remote ID Type:         IPv4_Address
    Remote ID:    
    Remote Subnet Mask:     N/A
    Remote Port:            any
    Remote Portocol:        all
    Mode:                   Oakley_quick
    Security Policy:        ESP_3DES_MD5_SHA_TUNNEL_NO_PFS
    Role:                   Initiator
    Encryption Alg:         ESP_3DES
    AH Transform:           N/A
    Auth Alg:               HMAC-MD5
    PFS:                    No
    SA Lifetime:            600 Seconds
    SA Lifesize:            0 Kbytes
    SA Rem Lifetime:        562 Seconds
    SA Rem Lifesize:        0 Kbytes
    Key Refresh Overlap:    15%
    Tunnel Lifetime:        2592000 Seconds
    Tunnel Lifesize:        0 Kbytes
    Tun Rem Lifetime:       2591962 Seconds
    Assoc P1 Tunnel:        0
    Encap Mode:             ESP_tunnel
    Status:                 Active

    Activating the IKE tunnel causes filter rules for the new tunnel to be inserted into the dynamic filter table. These entries can be viewed using the lsfilt command with the -d option for dynamic filter rules:

    1 permit no udp eq 4001 eq 4001 both both no all
      packets 0 all
    2 *** Dynamic filter placement rule *** no
    0 permit yes all any 0 any 0 both both no all
      packets 0 all
    *** Dynamic table ***
    0 permit no udp eq 500 eq 500 local both no all
      packets 0
    0 permit no ah any 0 any 0 both inbound no all
      packets 0
    0 permit no esp any 0 any 0 both inbound no all
      packets 0
    1 permit no all any 0 any
      0 both outbound yes all packets 1
    1 permit no all any 0 any
      0 both inbound yes all packets 1

    This example shows a machine that has one IKE tunnel and no other tunnels. The dynamic filter rule (rule #2 in this example of the static table) can be moved by the user to control placement relative to all other user-defined rules. The rules in the dynamic table are constructed automatically as tunnels are negotiated and corresponding rules are inserted into the filter table. These rules can be displayed, but not edited.

  3. To turn on logging of the dynamic filter rules, set the logging option for rule #2 to yes, as shown in the following example:

    chfilt -v 4 -n 2 -l y

    For more details on logging of IKE traffic, see the section on Logging Facilities.

  4. To deactivate the tunnel, use the remove option, as shown in the following example:

    ike cmd=remove numlist=1

Command Interface to IKE Tunnel Creation

The ikedb command, available in AIX 5.1 and later, allows a user to create IKE tunnels using an XML interface. The ikedb command can also be used for IKE data retrievals (useful for database backups), updates, deletes, and imports. An example XML file can be found in /usr/samples/ipsec. See the ikedb command description in the AIX 5L Version 5.1 Commands Reference for syntax details.

You can view the tunnel definitions using either the ikedb command with the -g flag or the Web-based System Manager. To activate the tunnel, use either the ike cmd=activate command or the Web-based System Manager.

AIX IKE and Linux affinity

To configure an AIX IKE tunnel using Linux configuration files (AIX 5.1 and later), use the ikedb command with the -c flag (conversion option), which lets you use the /etc/ipsec.conf and /etc/ipsec.secrets Linux configuration files as IKE tunnel definitions. The ikedb command parses the Linux configuration files, creates an XML file, and optionally adds the XML tunnel definitions to the IKE database. You can then view the tunnel definitions by using either the ikedb -g command or the Web-based System Manager.

Examples of IKE Tunnel Configurations

There are typical scenarios that describe the type of situations most customers encounter when trying to set up tunnels. They can be described as the branch office, business partner, and remote access cases.

In the branch office case, the customer has two trusted networks that they want to connect together--the engineering group of one location to the engineering group of another. In this example, there are gateways that connect and all the traffic passing between the gateways use the same tunnel. The traffic at either end of the tunnel is decapsulated and passes in the clear within the company intranet.

In the first phase of the IKE negotiation, the IKE security association is created between the two gateways. The traffic that passes in the IP Security tunnel is the traffic between the two subnets, and the subnet IDs are used in the phase 2 negotiation. After the security policy and tunnel parameters are entered for the tunnel, a tunnel number is created. To start the tunnel, use the ike command.

In the business partner scenario, the networks are not trusted, and the network administrator may want to restrict access to a smaller number of hosts behind the security gateway. In this case, the tunnel between the hosts carries traffic protected by IP Security for use between two particular hosts. The protocol of the phase 2 tunnel is AH or ESP. This host-to-host tunnel is secured within a gateway-to-gateway tunnel.

In the remote access case, the tunnels are setup on demand and a high level of security is applied. The IP addresses may not be meaningful, therefore, fully qualified domain names or user@ fully qualified domain names are preferred. Optionally, you can use KEYID to relate a key to a host ID.

Digital Certificate Configuration

Digital certificates bind an identity to a public key, through which you can verify the sender or the recipient of an encrypted transfer. Beginning with AIX 4.3.3, IP Security uses digital certificates to enable public-key cryptography, also known as asymmetric cryptography, which encrypts data using a private key known only to the user and decrypts it using an associated public (shared) key from a given public-private key pair. Key pairs are long strings of data that act as keys to a user's encryption scheme.

In public-key cryptography, the public key is given to anyone with whom the user wants to communicate. The sender digitally signs all secure communications with the corresponding private key for their assigned key pair. The recipient uses the public key to verify the sender's signature. If the message is successfully decrypted with the public key, the receiver can verify that the sender was authenticated.

Public-key cryptography relies on trusted, third parties, known as a certification authorities (CAs), to issue reliable digital certificates. The recipient specifies which issuing organizations or authorities are deemed trusted. A certificate is issued for a specific amount of time; when its expiration date has passed, it must be replaced.

AIX 4.3.3 and later versions provide the IBM Key Manager tool, which manages digital certificates. The following sections provide conceptual information about the certificates themselves. Management tasks for these certificates are described in Using the IBM Key Manager Tool.

Format of Digital Certificates

The digital certificate contains specific pieces of information about the identity of the certificate owner and about the certification authority. See the following figure for an illustration of a digital certificate. The following list further describes the contents:

Figure 4-5. Contents of a Digital Certificate. This illustration shows the four entities of a digital certificate. From the top they are, Owner's Distinguished Name, Owners Public Key, Issuer's (CA) Distinguished Name, and Issuer's Signature.

Artwork for digcert

Owner's Distinguished Name
Combination of the owner's common name and context (position) in the directory tree. In the following figure of a simple directory tree, for example, Prasad is the owner's common name and the context is country=US, organization=IBM, lower organization=SERV; therefore, the distinguished name is:

Figure 4-6. Example of Deriving Distinguished Name from Directory Tree. This illustration is a directory tree with O=IBM at the top level and branching to two entities on the second level. Level two contains OU=AIX and OU=Acctg on separate branches; each has a branch leading to a single entity on the last level.. The last level contains CN=Prasad and CN=Peltier respectively.

Artwork for simpdirtree


Owner's Public Key
Used by the recipients to decrypt data.

Subject Alternate Name
Can be an identifier such as an IP address, e-mail address, fully qualified domain name, etc.

Issue Date
Date the digital certificate was issued.

Expiration Date
Date the digital certificate expires.

Issuer's Distinguished Name
Distinguished name of the Certification Authority.

Issuer's Digital Signature
Digital signature used to validate a certificate.

Security Considerations for Digital Certificates

A digital certificate alone cannot prove identity. The digital certificate only allows you to verify the identity of the digital certificate owner by providing the public key that is needed to check the owner's digital signature. You can safely send your public key to another because your data cannot be decrypted without of the other part of the key pair, your private key. Therefore, the owner must protect the private key that belongs to the public key in the digital certificate. All communications of the owner of a digital certificate can be deciphered if the private key is known. Without the private key, a digital certificate cannot be misused.

Certification Authorities and Trust Hierarchies

A digital certificate is only as trustworthy as the certification authority (CA) that issued it. As part of this trust, the policies under which certificates are issued should be understood. Each organization or user must determine which certification authorities can be accepted as trustworthy.

Certification Authority organizations such as Verisign, Entrust, or Thawte can issue digital certificates. The IBM Key Manager tool also allows organizations to create self-signed certificates, which can be useful for testing or in environments with a small number of users or machines.

As a user of a security service, you need to know its public key to obtain and validate any digital certificates. Also, simply receiving a digital certificate does not assure its authenticity. To verify its authenticity, you need the public key of the certification authority that issued that digital certificate. If you do not already hold an assured copy of the CA's public key, then you might need an additional digital certificate to obtain the CA's public key.

Certificate Revocation Lists (CRLs)

A digital certificate is expected to be used for its entire validity period. If needed, however, a certificate can be invalidated before its actual date of expiration. Invalidating the certificate may be necessary, for example, if an employee leaves the company or if the certificate's private key has been compromised. To invalidate a certificate, you must notify the appropriate Certificate Authority (CA) of the circumstances. When a CA revokes a certificate, it adds the invalid certificate serial number to a Certificate Revocation List (CRL).

CRLs are signed data structures that are issued periodically and made available in a public repository. CRLs can be retrieved from HTTP or LDAP servers. Each CRL contains a current timestamp and a nextUpdate timestamp. Each revoked certificate in the list is identified by its certificate serial number.

When configuring an IKE tunnel and using digital certificates as your authentication method, you can confirm the certificate has not been revoked by selecting RSA Signature with CRL Checking. If CRL Checking is enabled, the list is located and checked during the negotiation process to establish the key management tunnel.

Note: To use this feature of IP Security, your system must be configured to use a SOCKS server (version 4 for HTTP servers), an LDAP server, or both. If you know which SOCKS or LDAP server you are using to obtain CRLs, you can make the necessary configuration selections by choosing CRL Configuration from the Digital Certificates menu within the Web-based System Manager.

Uses for Digital Certificates in Internet Applications

Internet applications that use public-key cryptography systems must use digital certificates to obtain the public keys. There are many applications that use public-key cryptography, including the following ones:

Virtual Private Networks (VPN)
Virtual Private Networks, also called secure tunnels, can be set up between systems such as firewalls to enable protected connections between secure networks over unsecured communication links. All traffic destined to these networks is encrypted between the participating systems.

The protocols used in tunneling follow the IP Security and IKE standards, which allow for a secure, encrypted connection between a remote client (for example, an employee working from home) and a secure host or network.

Secure Sockets Layer (SSL)
SSL is a protocol that provides privacy and integrity for communications. It is used by Web servers for secure connections between Web servers and Web browsers, by the Lightweight Directory Access Protocol (LDAP) for secure connections between LDAP clients and LDAP servers, and by Host-on-Demand V.2 for connections between the client and the host system. SSL uses digital certificates for key exchange, server authentication, and, optionally, client authentication.

Secure Electronic Mail
Many electronic mail systems, using standards such as PEM or S/MIME for secure electronic mail, use digital certificates for digital signatures and for the exchange of keys to encrypt and decrypt mail messages.

Digital Certificates and Certificate Requests

Simplified, a signed digital certificate contains fields for the owner's distinguished name, the owner's public key, the CA's distinguished name and the CA's signature. A self-signed digital certificate contains its owner's distinguished name, public key, and signature.

A certificate request must be created and sent to a CA to request a digital certificate. The certificate request contains fields for the requestor's distinguished name, public key, and signature. The CA verifies the requestor's signature with the public key in the digital certificate to ensure that:

The CA is also responsible for verifying to some level the identity of the requestor. Requirements for this verification can range from very little proof to absolute assurance of the owner's identity.

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]