Table Of Contents

Configuring the IKE Policy for IPSec Tunnel Security

IKE Overview

Setting the IKE Policy

Configuring the IKE Policy for IPSec Tunnel Security

---

This chapter describes how to configure the Internet Key Exchange (IKE) policy for IPSec tunnels. These security parameters are global to the concentrator and are not associated with a particular interface.

IKE Overview

IKE ensures the authenticated exchange of secure keys to allow the negotiation of IPSec tunnels over an insecure Internet connection. An IKE session between two peers consists of an encryption algorithm, an authentication algorithm, and a key-exchange method (a protection suite). The IKE initiator proposes one or more protection suites, and if the responder accepts one of these proposals, IKE Phase 1 negotiation proceeds.

IKE consists of two phases:

•Phase 1 sets up an authenticated secure connection that can be used for Phase 2 negotiations.

This connection is identified by an IKE security association (SA).

Phase 1 consists of four main tasks:

–Identify the peers.

–Authenticate the peers to each other.

–Negotiate Phase 2 parameters: encryption, authentication, and key-exchange method.

–Exchange keys and tie the keys to the peers.

An IKE SA can support many Phase 2 negotiations.

•Phase 2 negotiates the IPSec SAs.

To set Phase 2 negotiation parameters, see the "Configuring a VPN Group for the VPN 5000 Client" section or "Configuring VPN LAN-to-LAN Tunnels."

Setting the IKE Policy

To configure tunnel authentication, follow these steps:

---

Step 1 Access the IKE Policy section using the command line or by editing a text file:

•Command line—Enter the following command:

configure IKE Policy

•Text file—Create the following header:

[ IKE Policy ]

Step 2 Enter the following keyword in the IKE Policy section:

Keyword

Purpose

Protection = {MD5_DES_G1 | MD5_3DES_G1 | MD5_DES_G2 | MD5_3DES_G2 | SHA_DES_G1 | SHA_3DES_G1 | SHA_DES_G2 | SHA_3DES_G2}

Multi-keyword: You can enter this command multiple times within this section, in which case the concentrator proposes each of the specified protection suites in order until the tunnel peer accepts the options for the negotiation. Specifies the protection suite for the IKE negotiation. The authentication and encryption algorithms of this protection typically match the Phase 2 transform for VPN groups and LAN-to-LAN tunnels. You might use multiple protection suites if you have a mix of client versions (for example, Windows and Macintosh) or LAN-to-LAN tunnel partners. If offering multiple protections, you usually do not offer DES and 3DES, because the added security of 3DES is only secure if it is required of all logins. The first piece of each option is the authentication algorithm to be used for the negotiation: •MD5—Message-digest 5 hash algorithm. •SHA—Secure Hash Algorithm, which is considered to be more secure than MD5. The second piece is the encryption algorithm: •DES (Data Encryption Standard)—Uses a 56-bit key to scramble the data. •3DES (Triple DES)—Uses three different keys and three applications of the DES algorithm to scramble the data. 3DES is subject to restrictions by U.S. encryption export laws, and might not be available in concentrators or clients shipped outside the United States. The third piece is the Diffie-Hellman group to be used for key exchange: •G1 (Group 1)—Uses a 768-bit algorithm. •G2 (Group 2)—Uses a 1024-bit algorithm and is more secure than Group 1. Note VPN 5000 clients that do not use certificates for authentication only support the G1 key exchange.

---

See the following sample text configuration:

[ IKE Policy ]

Transform = SHA_3DES_G2