|
|
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.
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 automatically negotiates IPSec security associations (SAs) and enables IPSec secure communications without costly manual preconfiguration.
Specifically, IKE provides these benefits:
Cisco implements the following standards:
IKE is implemented per the latest version of the "The Internet Key Exchange," Internet Draft (draft-ietf-ipsec-isakmp-oakley-xx.txt).
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.
The component technologies implemented for use by IKE include:
IKE interoperates with the following standard:
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.
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.
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.
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 |
|---|---|
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.
To create an IKE policy, follow the guidelines in these sections:
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.
There are five parameters to define in each IKE policy:
| Parameter | Accepted Values | Keyword | Default Value |
|---|---|---|---|
56-bit DES-CBC | des | 56-bit DES-CBC | |
SHA-1 (HMAC variant) MD5 (HMAC variant) | sha md5 | SHA-1 | |
RSA signatures RSA encrypted nonces pre-shared keys | rsa-sig rsa-encr pre-share | RSA signatures | |
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.
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.
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.
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 | ||
|---|---|---|---|---|
| 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.) | ||
| encryption des | Specify the encryption algorithm. | ||
| Specify the hash algorithm. | |||
| Specify the authentication method. | |||
| ||||
| ||||
| exit | Exit the config-isakmp command mode. | ||
| (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.
Each authentication method requires additional companion configuration as follows:
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.
To manually configure RSA keys, perform these tasks at each IPSec peer that uses RSA encrypted nonces in an IKE policy:
To generate RSA keys, use the following commands starting in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto key generate rsa [usage-keys] | Generate RSA keys. | ||
| 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.
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 | ||
|---|---|---|---|---|
| At the local peer: Specify the peer's ISAKMP identity by IP address or by host name.1 | |||
| 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ||||
| 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. | ||
| 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. | ||
|
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. | ||
|
| 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. | ||
| exit |
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. |
To specify pre-shared keys at a peer, use the following commands in global configuration mode;
Remember to repeat these tasks at each peer that uses pre-shared keys in an IKE policy.
If you want, you can clear existing IKE connections.
To clear IKE connections, use the following commands in EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| View existing IKE connections; note the connection identifiers for connections you wish to clear. | |||
| Clear IKE connections. |
To assist in IKE troubleshooting, use the following commands in EXEC mode:
| Command | Purpose |
|---|---|
Display debug messages about IKE events. |
After IKE configuration is complete, you can configure IPSec. IPSec configuration is described in the "Configuring IPSec Network Security" chapter.
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.
|
|