Table of Contents

IKE Policies

Why Do You Need to Create These Policies?
What Parameters Do You Define in a Policy?
How Do IKE Peers Agree upon a Matching Policy?
Which Value Should You Select for Each Parameter?
Creating Policies
Additional Configuration Required for IKE Policies

IKE Pre-Shared (Authentication) Keys

About Internet Key Exchange (IKE)

IKE is a key management protocol standard that is used in conjunction with the IPSec standard.

IKE is a hybrid protocol, which implements the Oakley key exchange and Skeme key exchange inside the ISAKMP framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.) IKE automatically negotiates IPSec security associations and enables IPSec secure communications without manual preconfiguration.

Specifically, IKE provides these benefits:

• IKE Policies

• IKE Pre-Shared (Authentication) Keys

For the IKE configuration steps, see "Configuring IKE."

IKE Policies

You must create IKE policies at each peer. An IKE policy defines a combination of security parameters to be used during IKE negotiation.

To create an IKE policy, follow the guidelines provided in the following sections:

• Why Do You Need to Create These Policies?

• What Parameters Do You Define in a Policy?

• How Do IKE Peers Agree upon a Matching Policy?

• Which Value Should You Select for Each Parameter?

• Creating Policies

• Additional Configuration Required for IKE Policies

Why Do You Need to Create These Policies?

IKE negotiations must be protected, so each IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations.

After the two peers agree upon a policy, the security parameters of the policy are identified by a security association established at each peer, and these security associations apply to all subsequent IKE traffic during the negotiation.

You can create multiple, prioritized policies at each peer to ensure that at least one policy will match a remote peer's policy.

What Parameters Do You Define in a Policy?

There are five parameters to define in each IKE policy. These parameters apply to the IKE negotiations when the IKE security association is established. Table 3-1 provides the five IKE policy parameters and their accepted values.

Table 3-1: IKE Policy Parameters

Parameter	Accepted Values	Keyword	Default Value
encryption algorithm	56-bit DES-CBC 168-bit Triple DES	des 3des	56-bit DES-CBC
hash algorithm	SHA-1 (HMAC variant) MD5 (HMAC variant)	sha md5	SHA-1
authentication method	RSA signatures pre-shared keys	rsa-sig pre-share	RSA signatures
Diffie-Hellman group identifier	768-bit Diffie-Hellman or 1024-bit Diffie-Hellman	1 2	768-bit Diffie-Hellman
security association's lifetime	can specify any number of seconds	-	86,400 seconds (one day)

How Do IKE Peers Agree upon a Matching Policy?

When the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the other peer's received policies. The remote peer checks each of its policies in order of its priority (highest priority first) until a match is found.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer's policy specifies a lifetime less than or equal to the lifetime in the policy being compared. (If the lifetimes are not identical, the shorter lifetime—from the remote peer's policy—will be used.)

If no acceptable match is found, IKE refuses negotiation and IPSec will not be established.

If a match is found, IKE will complete negotiation, and IPSec security associations will be created.

Note   Depending on which authentication method is specified in a policy, additional configuration might be required (as described in the section "Additional Configuration Required for IKE Policies"). If a peer's policy does not have the required companion configuration, the peer will not submit the policy when attempting to find a matching policy with the remote peer.

Which Value Should You Select for Each Parameter?

You can select certain values for each parameter, per the IKE standard. But why chose one value over another?

If you are interoperating with a peer that supports only one of the values for a parameter, your choice is limited to the other peer's supported value. Aside from this, there is often a trade-off between security and performance, and many of these parameter values represent such a trade-off. You should evaluate the level of your network's security risks and your tolerance for these risks.

The following tips might help you select which value to specify for each parameter.

• The encryption algorithm has two options: 56-bit DES and 168-bit Triple DES.

• The hash algorithm has two options: SHA-1 and MD5.

  MD5 has a smaller digest and is considered to be slightly faster than SHA-1. There has been a demonstrated successful (but extremely difficult) attack against MD5; however, the HMAC variant used by IKE prevents this attack.

Creating Policies

You can create multiple IKE policies, each with a different combination of parameter values. For each policy that you create, you assign a unique priority (1 through 65,534, with 1 being the highest priority).

You can configure multiple policies on each peer—but at least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer. (The lifetime parameter does not necessarily have to be the same; see details in the section "How Do IKE Peers Agree upon a Matching Policy?".)

If you do not configure any policies, your PIX Firewall will use the default policy, which is always set to the lowest priority, and which contains each parameter's default value.

If you do not specify a value for a parameter, the default value is assigned.

Additional Configuration Required for IKE Policies

Depending on which authentication method you specify in your IKE policies, you need to do certain additional configuration before IKE and IPSec can successfully use the IKE policies.

Each authentication method requires additional companion configuration as follows:

• RSA signatures method

  If you specify RSA signatures as the authentication method in a policy, you must configure the peers to obtain certificates from a CA. (And, of course, the CA must be properly configured to issue the certificates.) Configure this certificate support as described in "Configuring CA."

  The certificates are used by each peer to securely exchange public keys. (RSA signatures require that each peer has the remote peer's public signature key.) When both peers have valid certificates, they will automatically exchange public keys with each other as part of any IKE negotiation in which RSA signatures are used.

• Pre-shared keys authentication method

  If you specify pre-shared keys as the authentication method in a policy, you must configure these pre-shared keys as described in "Configuring IKE Pre-Shared (Authentication) Keys Manually" within "Configuring IKE."

Note   If you enable the Extended Authentication (Xauth) and IKE Mode Config features for the VPN client peers, and you have security gateway and VPN client peers terminating IPSec on the same interface, configure to make exceptions to these features for each security gateway. See the sections "Configuring Extended Authentication" and "Configuring IKE Mode Config (Dynamic IP Address Assignment for VPN Client)" in "Advanced Configurations," for more information.

IKE Pre-Shared (Authentication) Keys

To configure pre-shared keys, perform one or both of the following tasks at each peer. See "Configuring IKE Pre-Shared (Authentication) Keys Manually" within "Configuring IKE," for the steps involved in configuring pre-shared keys.

• You will need to set each peer's ISAKMP identity, if its identity is to be set to hostname. Each peer's identity is set either to its host name or its IP address. When two peers use IKE to establish IPSec security associations, each peer sends its identity to its peer.

  By default, a peer's identity is its IP address. If appropriate, you could change the identity to be the peer's host name instead. As a general rule, set all peers' identities the same way—either all peers should use their IP addresses or all peers should use their host names. If some peers use their host names and some peers use their IP addresses to identify themselves to one another, IKE negotiations could fail if a peer's identity is not recognized and a DNS lookup is unable to resolve the identity.

Posted: Thu Aug 31 19:49:03 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.