Полезная информация

cc/td/doc/product/software/ios120/12cgcr/secur_c
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring Internet  Key  Exchange Security Protocol

Configuring Internet  Key  Exchange Security Protocol

This chapter describes how to configure the Internet Key Exchange (IKE) protocol. IKE is a key management protocol standard that is used in conjunction with the IPSec standard. IPSec is an IP security feature that provides robust authentication and encryption of IP packets.

IPSec can be configured without IKE, but IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for the IPSec standard.

IKE is a hybrid protocol which implements the Oakley key exchange and Skeme key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.)

For a complete description of the IKE commands used in this chapter, refer to the "Internet Key Exchange Security Protocol Commands" chapter in the Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

IKE Overview

IKE automatically negotiates IPSec security associations (SAs) and enables IPSec secure communications without costly manual preconfiguration.

Specifically, IKE provides these benefits:

Supported Standards

Cisco implements the following standards:

For more information on IPSec, see the "Configuring IPSec Network Security" chapter.

Internet Key Exchange (IKE)---A hybrid protocol which implements Oakley and Skeme key exchanges inside the ISAKMP framework. While IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec security associations.

IKE is implemented per the latest version of the "The Internet Key Exchange," Internet Draft (draft-ietf-ipsec-isakmp-oakley-xx.txt).

ISAKMP---The Internet Security Association and Key Management Protocol. A protocol framework which defines payload formats, the mechanics of implementing a key exchange protocol, and the negotiation of a security association.

ISAKMP is implemented per the latest version of the "Internet Security Association and Key Management Protocol (ISAKMP)" Internet Draft (draft-ietf-ipsec-isakmp-xx.txt).

Oakley---A key exchange protocol which defines how to derive authenticated keying material.

Skeme---A key exchange protocol which defines how to derive authenticated keying material, with rapid key refreshment.

The component technologies implemented for use by IKE include:

Cipher Block Chaining (CBC) requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPSec packet.

IKE interoperates with the following standard:

X.509v3 certificates---Used with the IKE protocol when authentication requires public keys. This certificate support allows the protected network to scale by providing the equivalent of a digital ID card to each device. When two devices wish to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or to manually specify a shared key at each peer).

List of Terms

anti-replay---A security service in which the receiver can reject old or duplicate packets in order to protect itself against replay attacks. IPSec provides optional anti-replay services by use of a sequence number combined with the use of authentication.

data authentication---Includes two concepts:

Data authentication can refer either to integrity alone or to both of these concepts (although data origin authentication is dependent upon data integrity).

peer---In the context of this chapter, a peer refers to a router or other device that participates in IPSec and IKE.

perfect forward secrecy (PFS)---A cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not also compromised, because subsequent keys are not derived from previous keys.

repudiation---A quality that prevents a third party from being able to prove that a communication between two other parties ever took place. This is a desirable quality if you do not want your communications to be traceable. Non-repudiation is the opposite quality---a third party can prove that a communication between two other parties took place. Non-repudiation is desirable if you want to be able to trace your communications and prove that they occurred.

security association---A security association (SA) describes how two or more entities will utilize security services to communicate securely. For example, an IPSec SA defines the encryption algorithm (if used), the authentication algorithm, and the shared session key to be used during the IPSec connection.

Both IPSec and IKE require and use SAs to identify the parameters of their connections. IKE can negotiate and establish its own SA. The IPSec SA is established either by IKE or by manual user configuration.

IKE Configuration Task List

To configure IKE, perform the tasks in the following sections. The tasks in the first three sections are required; the remaining may be optional, depending on what parameters are configured.

For IKE configuration examples, refer to the "IKE Configuration Examples" section located at the end of this chapter.

Enable or Disable IKE

IKE is enabled by default. IKE does not have to be enabled for individual interfaces, but is enabled globally for all interfaces at the router.

If you do not want IKE to be used with your IPSec implementation, you can disable it at all IPSec peers.

If you disable IKE, you will have to make these concessions at the peers:

To disable or enable IKE, use one of the following commands in global configuration mode:
Command Purpose

no crypto isakmp enable

Disable IKE.

crypto isakmp enable

Enable IKE.

If you disable IKE, you can skip the rest of the tasks in this chapter and go directly to IPSec configuration as described in the "Configuring IPSec Network Security" chapter.

Ensure Access Lists Are Compatible with IKE

IKE negotiation uses UDP on port 500. Ensure that your access lists are configured so that UDP port 500 traffic is not blocked at interfaces used by IKE and IPSec. In some cases you might need to add a statement to your access lists to explicitly permit UDP port 500 traffic.

Create IKE Policies

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

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

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:
Parameter Accepted Values Keyword Default Value

encryption algorithm

56-bit DES-CBC

des

56-bit DES-CBC

hash algorithm

SHA-1 (HMAC variant)

MD5 (HMAC variant)

sha

md5

SHA-1

authentication method

RSA signatures

RSA encrypted nonces

pre-shared keys

rsa-sig

rsa-encr

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 lifetime1

can specify any number of seconds

-

86400 seconds (one day)

1For information about this lifetime and how it is used, see the command description for the lifetime (IKE policy) command.

These parameters apply to the IKE negotiations when the IKE security association is established.

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 device that supports only one of the values for a parameter, your choice is limited to the other device'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. Then the following tips might help you select which value to specify for each parameter.

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.
1024-bit Diffie-Hellman is harder to crack, but requires more CPU time to execute.
As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPSec security associations can be set up more quickly. For more information about this parameter and how it is used, see the command description for the lifetime (IKE policy) command.

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 10,000, 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 router will use the default policy, which is always set to the lowest priority, and which contains each parameter's default value.

To configure a policy, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto isakmp policy priority

Identify the policy to create. (Each policy is uniquely identified by the priority number you assign.)

(This command puts you into the config-isakmp command mode.)

2 . 

encryption des

Specify the encryption algorithm.

3 . 

hash {sha | md5}

Specify the hash algorithm.

4 . 

authentication {rsa-sig | rsa-encr | pre-share}

Specify the authentication method.

5 . 

group {1 | 2}

Specify the Diffie-Hellman group identifier.

6 . 

lifetime seconds

Specify the security association's lifetime.

7 . 

exit

Exit the config-isakmp command mode.

8 . 

show crypto isakmp policy

(Optional) View all existing IKE policies.

(Use this command in EXEC mode.)

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


Note The default policy and the default values for configured policies do not show up in the configuration when you issue a show running command. Instead,
to see the default policy and any default values within configured policies, use the show crypto isakmp policy command.)

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:

If you specify RSA signatures as the authentication method in a policy, you must configure the peers to obtain certificates from a Certification Authority (CA). (And, of course, the CA must be properly configured to issue the certificates.) Configure this certificate support as described in the "Configuring Certification Authority Interoperability" chapter.
The certificates are used by each peer to securely exchange public keys. (RSA signatures requires 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.
If you specify RSA encrypted nonces as the authentication method in a policy, you need to ensure that each peer has the other peers' public keys.
Unlike RSA signatures, the RSA encrypted nonces method does not use certificates to exchange public keys. Instead, you ensure that each peer has the others' public keys as follows:
To make this happen, specify two policies: a higher-priority policy with RSA encrypted nonces, and a lower-priority policy with RSA signatures. When IKE negotiations occur, RSA signatures will be used the first time because the peers do not yet have each others' public keys. Then, future IKE negotiations will be able to use RSA encrypted nonces because the public keys will have been exchanged.
Of course, this alternative requires that you have Certification Authority support configured.
If you specify pre-shared keys as the authentication method in a policy, you must configure these pre-shared keys as described in the section "Configure Pre-Shared Keys."

If RSA encryption is configured and signature mode is negotiated, the peer will request both signature and encryption keys. Basically, the router will request as many keys as the configuration will support. If RSA encryption is not configured, it will just request a signature key.

Manually Configure RSA Keys

Manually configure RSA keys when you specify RSA encrypted nonces as the authentication method in an IKE policy and you are not using a Certification Authority (CA).

To manually configure RSA keys, perform these tasks at each IPSec peer that uses RSA encrypted nonces in an IKE policy:

Generate RSA Keys

To generate RSA keys, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto key generate rsa [usage-keys]

Generate RSA keys.

2 . 

show crypto key mypubkey rsa

View the generated RSA public key (in EXEC mode).

Remember to repeat these tasks at each peer (without CA support) that uses RSA encrypted nonces in an IKE policy.

Set ISAKMP Identity

You should set the ISAKMP identity for each peer that uses pre-shared keys in an IKE policy.

When two peers use IKE to establish IPSec security associations, each peer sends its identity to the remote peer. Each peer sends either its host name or its IP address, depending on how you have the router's ISAKMP identity set.

By default, a peer's ISAKMP identity is the peer's 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 address, or all peers should use their host name. If some peers use their host name and some peers use their IP address to identify themselves to each other, IKE negotiations could fail if a remote peer's identity is not recognized and a DNS lookup is unable to resolve the identity.

To set a peer's ISAKMP identity, use the following commands in global configuration mode:
Step Command Purpose

1 . 

crypto isakmp identity {address | hostname}

At the local peer: Specify the peer's ISAKMP identity by IP address or by host name.1

2 . 

ip host hostname address1 [address2...address8]

At all remote peers: If the local peer's ISAKMP identity was specified using a host name, map the peer's host name to its IP address(es) at all the remote peers. (This step might be unnecessary if the host name/address is already mapped in a DNS server.)

1See the crypto isakmp identity command description for guidelines for when to use the IP address vs. the host name.

Remember to repeat these tasks at each peer that uses pre-shared keys in an IKE policy.

Specify All the Other Peers' RSA Public Keys

At each peer, specify all the other peers' RSA public keys by using the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto key pubkey-chain rsa

Enter public key configuration mode.

2 . 

named-key key-name [encryption | signature]

or

addressed-key key-address [encryption | signature]

Indicate which remote peer's RSA public key you are going to specify.

If the remote peer uses its host name as its ISAKMP identity, use the named-key command and specify the remote peer's fully qualified domain name (such as somerouter.domain.com) as the key-name.

If the remote peer uses its IP address as its ISAKMP identity, use the addressed-key command and specify the remote peer's IP address as the key-address.

3 . 

address ip-address

If you used a fully qualified domain name to name the remote peer in step 2 (using the named-key command), you can optionally specify the remote peer's IP address.

4 . 

key-string

key-string

quit

Specify the remote peer's RSA public key. This is the key viewed by the remote peer's administrator previously when he generated his router's RSA keys.

5 . 

Repeat Steps 2 through 4 to specify the RSA public keys of all the other IPSec peers that use RSA encrypted nonces in an IKE policy.

6 . 

exit

Return to global configuration mode.

Remember to repeat these tasks at each peer that uses RSA encrypted nonces in an IKE policy.

To view RSA public keys while or after you configure them, use the following command in EXEC mode:
Command Purpose

show crypto key pubkey-chain rsa {name key-name | address key-address}

View a list of all the RSA public keys stored on your router, or view details of a particular RSA public key stored on your router.

Configure Pre-Shared Keys

To configure pre-shared keys, perform these tasks at each peer that uses pre-shared keys in an IKE policy:

To specify pre-shared keys at a peer, use the following commands in global configuration mode;
Step Command Purpose

1 . 

crypto isakmp key keystring address peer-address

or

crypto isakmp key keystring hostname peer-hostname

At the local peer: Specify the shared key to be used with a particular remote peer.

If the remote peer specified their ISAKMP identity with an address, use the address keyword in this step; otherwise use the hostname keyword in this step.

2 . 

crypto isakmp key keystring address peer-address

or

crypto isakmp key keystring hostname peer-hostname

At the remote peer: Specify the shared key to be used with the local peer. This is the same key you just specified at the local peer.

If the local peer specified their ISAKMP identity with an address, use the address keyword in this step; otherwise use the hostname keyword in this step.

3 . 

Repeat the previous two steps for each remote peer.

Remember to repeat these tasks at each peer that uses pre-shared keys in an IKE policy.

Clear IKE Connections

If you want, you can clear existing IKE connections.

To clear IKE connections, use the following commands in EXEC mode:
Step Command Purpose

1 . 

show crypto isakmp sa

View existing IKE connections; note the connection identifiers for connections you wish to clear.

2 . 

clear crypto isakmp [connection-id]

Clear IKE connections.

Troubleshoot IKE

To assist in IKE troubleshooting, use the following commands in EXEC mode:
Command Purpose

show crypto isakmp policy

View the parameters for each configured IKE policy.

show crypto isakmp sa

View all current IKE security associations.

debug crypto isakmp

Display debug messages about IKE events.

What to Do Next

After IKE configuration is complete, you can configure IPSec. IPSec configuration is described in the "Configuring IPSec Network Security" chapter.

IKE Configuration Examples

This example creates two IKE policies, with policy 15 as the highest priority, policy 20 as the next priority and the existing default priority as the lowest priority. it also creates a pre-shared key to be used with policy 20 with the remote peer whose IP address is 192.168.224.33.

crypto isakmp policy 15
  encryption des
  hash md5
  authentication rsa-sig
  group 2
  lifetime 5000
crypto isakmp policy 20
  authentication pre-share
  lifetime 10000
crypto isakmp key 1234567890 address 192.168.224.33

In the above example, the encryption des of policy 15 would not appear in the written configuration because this is the default value for the encryption algorithm parameter.

If the show crypto isakmp policy command is issued with this configuration, the output would be as follows:

Protection suite priority 15
	encryption algorithm:	DES - Data Encryption Standard (56 bit keys)
	hash algorithm:	Message Digest 5
	authentication method:	Rivest-Shamir-Adleman Signature
	Diffie-Hellman group:	#2 (1024 bit)
	lifetime:	5000 seconds, no volume limit
Protection suite priority 20
	encryption algorithm:	DES - Data Encryption Standard (56 bit keys)
	hash algorithm:	Secure Hash Standard
	authentication method:	Pre-Shared Key
	Diffie-Hellman group:	#1 (768 bit)
	lifetime:	10000 seconds, no volume limit
Default protection suite
	encryption algorithm:	DES - Data Encryption Standard (56 bit keys)
	hash algorithm:	Secure Hash Standard
	authentication method:	Rivest-Shamir-Adleman Signature
	Diffie-Hellman group:	#1 (768 bit)
	lifetime:	86400 seconds, no volume limit

Note that although the output shows "no volume limit" for the lifetimes, you can currently only configure a time lifetime (such as 86400 seconds); volume limit lifetimes are not configurable.


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.