Internet Key Exchange Security Protocol

Description

The Internet Key Exchange (IKE) protocol is a key management protocol standard which 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.)

Benefits

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

Specifically, IKE provides these benefits:

• Eliminates the need to manually specify all the IPSec security parameters in the crypto maps at both peers.

• Allows you to specify a lifetime for the IPSec security association.

• Allows encryption keys to change during IPSec sessions.

• Allows IPSec to provide anti-replay services.

• Permits Certification Authority (CA) support for a manageable, scalable IPSec implementation.

• Allows dynamic authentication of peers.

Supported Standards

Cisco implements the following standards:

For more information on IPSec, see the "IPSec Network Security" feature documentation.

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.

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.

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.

• DES--The Data Encryption Standard (DES) is used to encrypt packet data. IKE implements the 56-bit DES-CBC with Explicit IV standard.

• Diffie-Hellman--A public-key cryptography protocol which allows two parties to establish a shared secret over an unsecure communications channel. Diffie-Hellman is used within IKE to establish session keys. 768-bit and 1024-bit Diffie-Hellman groups are supported.

• MD5 (HMAC variant)--MD5 (Message Digest 5) is a hash algorithm used to authenticate packet data. HMAC is a variant which provides an additional level of hashing.

• SHA (HMAC variant)--SHA (Secure Hash Algorithm) is a hash algorithm used to authenticate packet data. HMAC is a variant which provides an additional level of hashing.

• RSA signatures and RSA encrypted nonces--RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA signatures provides non-repudiation while RSA encrypted nonces provide repudiation.

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.

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.

Platforms

This feature is supported on these platforms:

Configuration Tasks

To configure IKE, perform the following tasks:

• Enable or Disable IKE

• Ensure Access Lists Are Compatible with IKE

• Create IKE Policies

• Manually Configure RSA Keys (Optional, depending on IKE parameters)

• Configure Pre-Shared Keys (Optional, depending on IKE parameters)

• Clear IKE Connections (Optional)

• Troubleshoot IKE (Optional)

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. Note that IKE must be enabled or disabled at all IPSec peers; you cannot have a mix of IKE-enabled and IKE-disabled peers within your IPSec network.

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

• You must manually specify all the IPSec security associations in the crypto maps at all peers. (Crypto map configuration is described in the "IPSec Network Security" feature documentation.)

• The peers' IPSec security associations will never time out for a given IPSec session.

• During IPSec sessions between the peers, the encryption keys will never change.

• Anti-replay services will not be available between the peers.

• Certification Authority (CA) support cannot be used.

To disable or enable IKE, perform one of the following tasks in global configuration mode:

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 "IPSec Network Security" feature documentation.

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?

• 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.

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.

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.

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?

• The encryption algorithm currently has only one option: 56-bit DES-CBC.

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

• The authentication method has three options: RSA signatures, RSA encrypted nonces, and pre-shared keys.

  • RSA signatures provides non-repudiation for the IKE negotiation (you can prove to a third party after the fact that you did indeed have an IKE negotiation with the remote peer).

  RSA signatures requires use of a Certification Authority (CA). Using a CA can dramatically improve the manageability and scalability of your IPSec network.
  

  • RSA encrypted nonces provides repudiation for the IKE negotiation (you cannot prove to a third party that you had an IKE negotiation with the remote peer). This is used to prevent a third party from knowing about your activity over the network.

  An IKE security association that is authenticated with RSA encrypted nonces is harder to crack than one authenticated with RSA signatures, though using the nonces vs. signatures can somewhat slow the negotiations.
  

  RSA encrypted nonces require that peers possess each other's public keys but do not use a Certification Authority. Instead, there are two ways for peers to get each others' public keys:
  

  1) During configuration you manually configure RSA keys (as described in the section "Manually Configure RSA Keys") or
  

  2) If your local peer has previously used RSA signatures during a successful IKE negotiation with a remote peer, your local peer already possesses the remote peer's public key. (The peers' public keys are exchanged during the RSA-signatures-based IKE negotiations.)
  

  • Pre-shared keys are clumsy to use if your secured network is large, and do not scale well with a growing network. However, they do not require use of a Certification Authority, as do RSA signatures.

• The Diffie-Hellman group identifier has two options: 768-bit or 1024-bit Diffie-Hellman.

1024-bit Diffie-Hellman is harder to crack, but requires more CPU time to execute.

• The security association's lifetime can be set to any value.

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, perform the following tasks starting in global configuration mode:

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.

• 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 Certification Authority (CA). (And, of course, the CA must be properly configured to issue the certificates.) Configure this certificate support as described in the "Certification Authority Interoperability" feature documentation.

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.

• RSA encrypted nonces method:

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:

• Either manually configure RSA keys as described in the section "Manually Configure RSA Keys," or

• Ensure that an IKE exchange using RSA signatures has already occurred between the peers. (The peers' public keys are exchanged during the RSA-signatures-based IKE negotiations.)

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.

• 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 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).

• Generate RSA Keys

• Set ISAKMP Identity

• Specify All the Other Peers' RSA Public Keys

Generate RSA Keys

To generate RSA keys, perform the following tasks starting in global configuration mode:

Set ISAKMP Identity

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

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 performing the following tasks starting in global configuration mode:

To view RSA public keys while or after you configure them, perform the following tasks in EXEC mode:

Configure Pre-Shared Keys

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

• First, set each peer's ISAKMP identity. Each peer's identity should be set to either its hostname or by its IP address. By default, a peer's identity is set to its IP address. Setting ISAKMP identities is described previously in the section "Set ISAKMP Identity."

• Next, specify the shared keys at each peer. Note that a given pre-shared key is shared between two peers. At a given peer you could specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.

To specify pre-shared keys at a peer, perform the following tasks in global configuration mode;

Clear IKE Connections

If you want, you can clear existing IKE connections.

To clear IKE connections, perform the following tasks in EXEC mode:

Troubleshoot IKE

To assist in IKE troubleshooting, perform the following tasks in EXEC mode:

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.

This example also creates a pre-shared key to be used with policy 20 with the remote peer whose IP address is 171.69.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 171.69.224.33

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.

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 11.3 command references.

The new debug command used with IKE is described in the "Debug Commands" section.

• address

• addressed-key

• authentication (IKE policy)

• clear crypto isakmp

• crypto isakmp enable

• crypto isakmp identity

• crypto isakmp key

• crypto isakmp policy

• crypto key generate rsa

• crypto key pubkey-chain rsa

• encryption (IKE policy)

• group (IKE policy)

• hash (IKE policy)

• key-string

• lifetime (IKE policy)

• named-key

• show crypto isakmp policy

• show crypto isakmp sa

• show crypto key mypubkey rsa

• show crypto key pubkey-chain rsa

address

To specify the IP address of the remote peer's RSA public key you will manually configure, use the address public key configuration command. This command should only be used when the router has a single interface that processes IPSec.

Syntax Description

Default

This command has no defaults.

Command Mode

Public key configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command in conjunction with the named-key command to specify which IPSec peer's RSA public key you will manually configure next.

Examples

This example manually specifies the RSA public keys of an IPSec peer.

myrouter(config)# crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# named-key otherpeer.companyx.com
myrouter(config-pubkey-key)# address 10.5.5.1
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 005C300D 06092A86 4886F70D 01010105
myrouter(config-pubkey)# 00034B00 30480241 00C5E23B 55D6AB22
myrouter(config-pubkey)# 04AEF1BA A54028A6 9ACC01C5 129D99E4
myrouter(config-pubkey)# 64CAB820 847EDAD9 DF0B4E4C 73A05DD2
myrouter(config-pubkey)# BD62A8A9 FA603DD2 E2A8A6F8 98F76E28
myrouter(config-pubkey)# D58AD221 B583D7A4 71020301 0001
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)# 

Related Commands

addressed-key
crypto key pubkey-chain rsa
key-string
show crypto key pubkey-chain rsa

addressed-key

To specify which peer's RSA public key you will manually configure, use the addressed-key public key chain configuration command.

Syntax Description

Default

If neither the encryption nor signature keywords are used, general purpose keys will be specified.

Command Mode

Public key chain configuration. Using this command puts you into public key configuration mode.

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command or the named-key command to specify which IPSec peer's RSA public key you will manually configure next.

Follow this command with the key-string command to specify the key.

If the IPSec remote peer generated general purpose RSA keys, do not use the encryption or signature keywords.

If the IPSec remote peer generated special usage keys, you must manually specify both keys: perform this command and the key-string command two times and use the encryption and signature keywords respectively.

Examples

This example manually specifies the RSA public keys of two IPSec peers. The peer at 10.5.5.1 uses general purpose keys, and the other peer uses special usage keys.

myrouter(config)# crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# named-key otherpeer.companyx.com
myrouter(config-pubkey-key)# address 10.5.5.1
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 005C300D 06092A86 4886F70D 01010105
myrouter(config-pubkey)# 00034B00 30480241 00C5E23B 55D6AB22
myrouter(config-pubkey)# 04AEF1BA A54028A6 9ACC01C5 129D99E4
myrouter(config-pubkey)# 64CAB820 847EDAD9 DF0B4E4C 73A05DD2
myrouter(config-pubkey)# BD62A8A9 FA603DD2 E2A8A6F8 98F76E28
myrouter(config-pubkey)# D58AD221 B583D7A4 71020301 0001
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# addressed-key 10.1.1.2 encryption
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 00302017 4A7D385B 1234EF29 335FC973
myrouter(config-pubkey)# 2DD50A37 C4F4B0FD 9DADE748 429618D5
myrouter(config-pubkey)# 18242BA3 2EDFBDD3 4296142A DDF7D3D8
myrouter(config-pubkey)# 08407685 2F2190A0 0B43F1BD 9A8A26DB
myrouter(config-pubkey)# 07953829 791FCDE9 A98420F0 6A82045B
myrouter(config-pubkey)# 90288A26 DBC64468 7789F76E EE21
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# addressed-key 10.1.1.2 signature
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 0738BC7A 2BC3E9F0 679B00FE 53987BCC
myrouter(config-pubkey)# 01030201 42DD06AF E228D24C 458AD228
myrouter(config-pubkey)# 58BB5DDD F4836401 2A2D7163 219F882E
myrouter(config-pubkey)# 64CE69D4 B583748A 241BED0F 6E7F2F16
myrouter(config-pubkey)# 0DE0986E DF02031F 4B0B0912 F68200C4
myrouter(config-pubkey)# C625C389 0BFF3321 A2598935 C1B1
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)#

Related Commands

crypto key pubkey-chain rsa
key-string
named-key
show crypto key pubkey-chain rsa

authentication (IKE policy)

To specify the authentication method within an IKE policy, use the authentication (IKE policy) ISAKMP policy configuration command. IKE policies define a set of parameters to be used during IKE negotiation. To reset the authentication method to the default value, use the no form of the command.

Syntax Description

Default

RSA signatures

Command Mode

ISAKMP policy configuration (config-isakmp)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify the authentication method to be used in an IKE policy.

If you specify RSA signatures, you must configure your peer routers to obtain certificates from a Certification Authority (CA).

If you specify RSA encrypted nonces, you must ensure that each peer has the other peer's RSA public keys. (See the crypto key pubkey-chain rsa, addressed-key, named-key, address, and key-string commands.)

If you specify pre-shared keys, you must also separately configure these pre-shared keys. (See the crypto isakmp identity and crypto isakmp key commands.)

Example

This example configures an IKE policy with pre-shared keys as the authentication method (and with all other parameters set to the defaults):

MyPeerRouter(config)# crypto isakmp policy 15
MyPeerRouter(config-isakmp)# authentication pre-share
MyPeerRouter(config-isakmp)# exit
MyPeerRouter(config)#

Related Commands

crypto isakmp key
crypto isakmp policy
crypto key generate rsa
encryption (IKE policy)
group (IKE policy)
hash (IKE policy)
lifetime (IKE policy)
show crypto isakmp policy

clear crypto isakmp

To clear active IKE connections, use the clear crypto isakmp global configuration command.

Syntax Description

Default

If the connection-id argument is not used, all existing IKE connections will be cleared when this command is issued.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to clear active IKE connections.

Example

This example clears an IKE connection between two peers connected by interfaces 172.21.114.123 and 172.21.114.67.

MyPeerRouter# show crypto isakmp sa
    dst           src          state        conn-id   slot
172.21.114.123 172.21.114.67  QM_IDLE           1       0
155.0.0.2      155.0.0.1      QM_IDLE           8       0
MyPeerRouter# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
MyPeerRouter(config)# clear crypto isakmp 1
MyPeerRouter(config)# exit
MyPeerRouter# show crypto isakmp sa
    dst           src          state        conn-id   slot
155.0.0.2      155.0.0.1      QM_IDLE           8       0
MyPeerRouter#

Related Commands

show crypto isakmp sa

crypto isakmp enable

To globally enable IKE at your peer router, use the crypto isakmp enable global configuration command. To disable IKE at the peer, use the no form of the command

Syntax Description

This command has no arguments or keywords.

Default

IKE is enabled.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

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 in your IPSec implementation, you can disable IKE at all your IPSec peers. If you disable IKE at one peer you must disable it at all your IPSec peers.

• You must manually specify all the IPSec security associations (SAs) in the crypto maps at the peers. (Crypto map configuration is described in the "IPSec Network Security" feature documentation.)

• The peers' IPSec SAs will never time out for a given IPSec session.

• During IPSec sessions between the peers, the encryption keys will never change.

• Anti-replay services will not be available between the peers.

• Certification Authority (CA) support cannot be used.

Example

This example disables IKE at one peer. (The same command should be issued at all remote peers.)

no crypto isakmp enable

crypto isakmp identity

To define the identity the router uses when participating in the IKE protocol, use the crypto isakmp identity global configuration command. Set an ISAKMP identity whenever you specify pre-shared keys. To reset the ISAKMP identity to the default value (address), use the no form of the command.

Syntax Description

Default

The IP address is used for the ISAKMP identity.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify an ISAKMP identity either by IP address or by hostname.

The address keyword is typically used when there is only one interface (and therefore only one IP address) that will be used by the peer for IKE negotiations, and the IP address is known.

The hostname keyword should be used if there is more than one interface on the peer that might be used for IKE negotiations, or if the interface's IP address is unknown (such as with dynamically-assigned IP addresses).

As a general rule, you should set all peers' identities in the same way, either by IP address or by hostname.

Examples

The following example uses pre-shared keys at two peers and sets both their ISAKMP identities to IP address.

crypto isakmp identity address
crypto isakmp key sharedkeystring address 198.168.1.33

crypto isakmp identity address
crypto isakmp key sharedkeystring address 10.0.0.1

crypto isakmp identity hostname
crypto isakmp key sharedkeystring hostname RemoteRouter.companyx.com
ip host RemoteRouter.companyx.com 198.168.0.1

crypto isakmp identity hostname
crypto isakmp key sharedkeystring hostname LocalRouter.companyx.com
ip host LocalRouter.companyx.com 10.0.0.1 10.0.0.2

Related Commands

authentication (IKE policy)
crypto isakmp key

crypto isakmp key

To configure a pre-shared authentication key, use the crypto isakmp key global configuration command. You must configure this key whenever you specify pre-shared keys in an IKE policy. To delete a pre-shared authentication key, use the no form of the command.

Syntax Description

Default

There is no default pre-shared authentication key.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to configure pre-shared authentication keys. You must perform this command at both peers.

If an IKE policy includes pre-shared keys as the authentication method, these pre-shared keys must be configured at both peers--otherwise the policy cannot be used (the policy will not be submitted for matching by the IKE process). The crypto isakmp key command is the second task required to configure the pre-shared keys at the peers. (The first task is accomplished with the crypto isakmp identity command.)

Use the address keyword if the remote peer previously set its ISAKMP identity with its IP address.

Use the hostname keyword if the remote peer previously set its ISAKMP identity with its hostname.

With the hostname keyword, you might also need to map the remote peer's hostname to all IP addresses of the remote peer interfaces that could be used during the IKE negotiation. (This is done with the ip host command which is not documented in this chapter.) You need to map hostname to IP address except when this mapping is already done in a DNS server.

Example

The remote peer "RemoteRouter" specifies an ISAKMP identity by address:

crypto isakmp identity address

The local peer "LocalRouter" also specifies an ISAKMP identity, but by hostname:

crypto isakmp identity hostname

Now, the pre-shared key must be specified at each peer.

crypto isakmp key sharedkeystring address 198.168.1.33

crypto isakmp key sharedkeystring hostname LocalRouter.domain.com

ip host LocalRouter.domain.com 10.0.0.1 10.0.0.2

Related Commands

authentication (IKE policy)
crypto isakmp identity
ip host

crypto isakmp policy

To define an IKE policy, use the crypto isakmp policy global configuration command. IKE policies define a set of parameters to be used during the IKE negotiation. To delete an IKE policy, use the no form of the command.

Syntax Description

Default

There is a default policy which is always the lowest priority. This default policy contains default values for the encryption, hash, authentication, Diffie-Hellman group, and lifetime parameters. (The parameter defaults are listed below in the Usage Guidelines section.)

When you create an IKE policy, if you do not specify a value for a particular parameter, the default for that parameter will be used.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify the parameters to be used during an IKE negotiation. (These parameters are used to create the IKE security association [SA].)

When you enter this command, you are put into the ISAKMP policy configuration (config-isakmp) command mode. While in the ISAKMP policy configuration command mode, the following commands are available to specify the parameters in the policy:

• encryption (IKE policy); default = 56-bit DES-CBC

• hash (IKE policy); default = SHA-1

• authentication (IKE policy); default = RSA signatures

• group (IKE policy); default = 768-bit Diffie-Hellman

• lifetime (IKE policy); default = 86400 seconds (one day)

If you do not specify one of these commands for a policy, the default value will be used for that parameter.

To exit the config-isakmp command mode, type exit.

You can configure multiple IKE policies on each peer participating in IPSec. When the IKE negotiation begins, it tries to find a common policy configured on both peers, starting with the highest priority policies as specified on the remote peer.

Example

The following example configures two policies for the peer:

crypto isakmp policy 15
 hash md5
 authentication rsa-sig
 group 2
 lifetime 5000
crypto isakmp policy 20
 authentication pre-share
 lifetime 10000

MyPeerRouter# show crypto isakmp policy
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

Related Commands

authentication (IKE policy)
encryption (IKE policy)
group (IKE policy)
hash (IKE policy)
lifetime (IKE policy)
show crypto isakmp policy

crypto key generate rsa

To generate RSA key pairs, use the crypto key generate rsa global configuration command.

Syntax Description

Default

RSA key pairs do not exist. If the usage-keys keyword is not used, general purpose keys will be generated.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to generate RSA key pairs for your Cisco device (such as a router).

RSA keys are generated in pairs--one public RSA key and one private RSA key.

Special Usage Keys

General Purpose Keys

Modulus Length

When you generate RSA keys, you will be prompted to enter a modulus length. A longer modulus could offer stronger security, but takes longer to generate (see Table 1 for sample times) and takes longer to use. Below 512 is normally not recommended. (In certain situations, the shorter modulus may not function properly with IKE, so Cisco recommends using a minimum modulus of 1024.)

Examples

This example generates special usage RSA keys.

myrouter(config)# crypto key generate rsa usage-keys
The name for the keys will be: myrouter.companyx.com
Choose the size of the key modulus in the range of 360 to 2048 for your Signature Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus[512]? <return>
Generating RSA keys.... [OK].
Choose the size of the key modulus in the range of 360 to 2048 for your Encryption Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus[512]? <return>
Generating RSA keys.... [OK].
myrouter(config)#

This example generates general purpose RSA keys. (Note, you cannot generate both special usage and general purpose keys; you can only generate one or the other.)

myrouter(config)# crypto key generate rsa
The name for the keys will be: myrouter.companyx.com
Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus[512]? <return>
Generating RSA keys.... [OK].
myrouter(config)#

Related Commands

show crypto key mypubkey rsa

crypto key pubkey-chain rsa

To enter public key configuration mode (so you can manually specify other devices' RSA public keys), use the crypto key pubkey-chain rsa global configuration command.

Syntax Description

This command has no arguments or keywords.

Default

This command has no defaults.

Command Mode

Global configuration. Using this command puts you into public key chain configuration mode.

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to enter public key chain configuration mode. Use this command when you need to manually specify other IPSec peers' RSA public keys. You need to specify other peers' keys when you configure RSA encrypted nonces as the authentication method in an IKE policy at your peer router.

Examples

This example manually specifies the RSA public keys of two other IPSec peers. The remote peers use their IP address as their identity.

myrouter(config)# crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# addressed-key 10.5.5.1
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 00302017 4A7D385B 1234EF29 335FC973
myrouter(config-pubkey)# 2DD50A37 C4F4B0FD 9DADE748 429618D5
myrouter(config-pubkey)# 18242BA3 2EDFBDD3 4296142A DDF7D3D8
myrouter(config-pubkey)# 08407685 2F2190A0 0B43F1BD 9A8A26DB
myrouter(config-pubkey)# 07953829 791FCDE9 A98420F0 6A82045B
myrouter(config-pubkey)# 90288A26 DBC64468 7789F76E EE21
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# addressed-key 10.1.1.2
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 0738BC7A 2BC3E9F0 679B00FE 53987BCC
myrouter(config-pubkey)# 01030201 42DD06AF E228D24C 458AD228
myrouter(config-pubkey)# 58BB5DDD F4836401 2A2D7163 219F882E
myrouter(config-pubkey)# 64CE69D4 B583748A 241BED0F 6E7F2F16
myrouter(config-pubkey)# 0DE0986E DF02031F 4B0B0912 F68200C4
myrouter(config-pubkey)# C625C389 0BFF3321 A2598935 C1B1
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)#

Related Commands

address
addressed-key
key-string
named-key
show crypto key pubkey-chain rsa

encryption (IKE policy)

To specify the encryption algorithm within an IKE policy, use the encryption (IKE policy) ISAKMP policy configuration command. IKE policies define a set of parameters to be used during IKE negotiation. To reset the encryption algorithm to the default value, use the no form of the command.

Syntax Description

Default

The 56-bit DES-CBC encryption algorithm.

Command Mode

ISAKMP policy configuration (config-isakmp)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify the encryption algorithm to be used in an IKE policy.

Example

This example configures an IKE policy with the 56-bit DES encryption algorithm (and with all other parameters set to the defaults):

MyPeerRouter(config)# crypto isakmp policy 15
MyPeerRouter(config-isakmp)# encryption des
MyPeerRouter(config-isakmp)# exit
MyPeerRouter(config)#

Related Commands

authentication (IKE policy)
crypto isakmp policy
group (IKE policy)
hash (IKE policy)
lifetime (IKE policy)
show crypto isakmp policy

group (IKE policy)

To specify the Diffie-Hellman group identifier within an IKE policy, use the group (IKE policy) ISAKMP policy configuration command. IKE policies define a set of parameters to be used during IKE negotiation. To reset the Diffie-Hellman group identifier to the default value, use the no form of the command.

Syntax Description

Default

768-bit Diffie-Hellman (group 1)

Command Mode

ISAKMP policy configuration (config-isakmp)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify the Diffie-Hellman group to be used in an IKE policy.

Example

This example configures an IKE policy with the 1024-bit Diffie-Hellman group (and with all other parameters set to the defaults):

MyPeerRouter(config)# crypto isakmp policy 15
MyPeerRouter(config-isakmp)# group 2
MyPeerRouter(config-isakmp)# exit
MyPeerRouter(config)#

Related Commands

authentication (IKE policy)
crypto isakmp policy
encryption (IKE policy)
hash (IKE policy)
lifetime (IKE policy)
show crypto isakmp policy

hash (IKE policy)

To specify the hash algorithm within an IKE policy, use the hash (IKE policy) ISAKMP policy configuration command. IKE policies define a set of parameters to be used during IKE negotiation. To reset the hash algorithm to the default SHA-1 hash algorithm, use the no form of the command.

Syntax Description

Default

The SHA-1 hash algorithm.

Command Mode

ISAKMP policy configuration (config-isakmp)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify the hash algorithm to be used in an IKE policy.

Example

This example configures an IKE policy with the MD5 hash algorithm (and with all other parameters set to the defaults):

MyPeerRouter(config)# crypto isakmp policy 15
MyPeerRouter(config-isakmp)# hash md5
MyPeerRouter(config-isakmp)# exit
MyPeerRouter(config)#

Related Commands

authentication (IKE policy)
crypto isakmp policy
encryption (IKE policy)
group (IKE policy)
lifetime (IKE policy)
show crypto isakmp policy

key-string

To manually specify a remote peer's RSA public key, use the key-string public key configuration command.

Syntax Description

Default

This command has no defaults.

Command Mode

Public key configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to manually specify the RSA public key of an IPSec peer. Before using this command you must identify the remote peer using either the addressed-key or named-key command.

If possible, to avoid mistakes, you should cut and paste the key data (instead of attempting to type in the data).

Examples

This example manually specifies the RSA public keys of an IPSec peer.

myrouter(config)# crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# named-key otherpeer.companyx.com
myrouter(config-pubkey-key)# address 10.5.5.1
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 005C300D 06092A86 4886F70D 01010105
myrouter(config-pubkey)# 00034B00 30480241 00C5E23B 55D6AB22
myrouter(config-pubkey)# 04AEF1BA A54028A6 9ACC01C5 129D99E4
myrouter(config-pubkey)# 64CAB820 847EDAD9 DF0B4E4C 73A05DD2
myrouter(config-pubkey)# BD62A8A9 FA603DD2 E2A8A6F8 98F76E28
myrouter(config-pubkey)# D58AD221 B583D7A4 71020301 0001
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)#

Related Commands

addressed-key
crypto key pubkey-chain rsa
named-key
show crypto key pubkey-chain rsa

lifetime (IKE policy)

To specify the lifetime of an IKE security association (SA), use the lifetime (IKE policy) ISAKMP policy configuration command. To reset the SA lifetime to the default value, use the no form of the command.

Syntax Description

Default

86400 seconds (one day)

Command Mode

ISAKMP policy configuration (config-isakmp)

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command to specify how long an IKE SA lives before expiring.

When IKE begins negotiations, the first thing it does is agree upon the security parameters for its own session. The agreed-upon parameters are then referenced by an SA at each peer. The SA is retained by each peer until the SA's lifetime expires. Before an SA expires, it can be reused by subsequent IKE negotiations, which can save time when setting up new IPSec SAs. New SAs are negotiated before current SAs expire.

So, to save setup time for IPSec, configure a longer IKE SA lifetime. However, the shorter the lifetime (up to a point), the more secure the IKE negotiation is likely to be.

Note that when your local peer initiates an IKE negotiation between itself and a remote peer, an IKE policy can be selected only if the lifetime of the remote peer's policy is shorter than or equal to the lifetime of the local peer's policy. Then, if the lifetimes are not equal, the shorter lifetime will be selected. To restate this behavior: If the two peer's policies' lifetimes are not the same, the initiating peer's lifetime must be longer and the responding peer's lifetime must be shorter, and the shorter lifetime will be used.

Example

This example configures an IKE policy with a security association lifetime of 600 seconds (10 minutes) and with all other parameters set to the defaults:

MyPeerRouter(config)# crypto isakmp policy 15
MyPeerRouter(config-isakmp)# lifetime 600
MyPeerRouter(config-isakmp)# exit
MyPeerRouter(config)#

Related Commands

authentication (IKE policy)
crypto isakmp policy
encryption (IKE policy)
group (IKE policy)
hash (IKE policy)
show crypto isakmp policy

named-key

To specify which peer's RSA public key you will manually configure, use the named-key public key chain configuration command. This command should only be used when the router has a single interface that processes IPSec.

Syntax Description

Default

If neither the encryption nor signature keywords are used, general purpose keys will be specified.

Command Mode

Public key chain configuration. Using this command puts you into public key configuration mode.

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Use this command or the addressed-key command to specify which IPSec peer's RSA public key you will manually configure next.

Follow this command with the key-string command to specify the key.

If you use the named-key command you also need to use the address public key configuration command to specify the IP address of the peer.

If the IPSec remote peer generated general purpose RSA keys, do not use the encryption or signature keywords.

If the IPSec remote peer generated special usage keys, you must manually specify both keys: perform this command and the key-string command two times and use the encryption and signature keywords respectively.

Examples

This example manually specifies the RSA public keys of two IPSec peers. The peer at 10.5.5.1 uses general purpose keys, and the other peer uses special purpose keys.

myrouter(config)# crypto key pubkey-chain rsa
myrouter(config-pubkey-chain)# named-key otherpeer.companyx.com
myrouter(config-pubkey-key)# address 10.5.5.1
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 005C300D 06092A86 4886F70D 01010105
myrouter(config-pubkey)# 00034B00 30480241 00C5E23B 55D6AB22
myrouter(config-pubkey)# 04AEF1BA A54028A6 9ACC01C5 129D99E4
myrouter(config-pubkey)# 64CAB820 847EDAD9 DF0B4E4C 73A05DD2
myrouter(config-pubkey)# BD62A8A9 FA603DD2 E2A8A6F8 98F76E28
myrouter(config-pubkey)# D58AD221 B583D7A4 71020301 0001
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# addressed-key 10.1.1.2 encryption
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 00302017 4A7D385B 1234EF29 335FC973
myrouter(config-pubkey)# 2DD50A37 C4F4B0FD 9DADE748 429618D5
myrouter(config-pubkey)# 18242BA3 2EDFBDD3 4296142A DDF7D3D8
myrouter(config-pubkey)# 08407685 2F2190A0 0B43F1BD 9A8A26DB
myrouter(config-pubkey)# 07953829 791FCDE9 A98420F0 6A82045B
myrouter(config-pubkey)# 90288A26 DBC64468 7789F76E EE21
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# addressed-key 10.1.1.2 signature
myrouter(config-pubkey-key)# key-string
myrouter(config-pubkey)# 0738BC7A 2BC3E9F0 679B00FE 098533AB
myrouter(config-pubkey)# 01030201 42DD06AF E228D24C 458AD228
myrouter(config-pubkey)# 58BB5DDD F4836401 2A2D7163 219F882E
myrouter(config-pubkey)# 64CE69D4 B583748A 241BED0F 6E7F2F16
myrouter(config-pubkey)# 0DE0986E DF02031F 4B0B0912 F68200C4
myrouter(config-pubkey)# C625C389 0BFF3321 A2598935 C1B1
myrouter(config-pubkey)# quit
myrouter(config-pubkey-key)# exit
myrouter(config-pubkey-chain)# exit
myrouter(config)#

Related Commands

address
addressed-key
crypto key pubkey-chain rsa
key-string
show crypto key pubkey-chain rsa

show crypto isakmp policy

To view the parameters for each IKE policy, use the show crypto isakmp policy EXEC command.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Sample Display

The following is sample output from the show crypto isakmp policy command, after two IKE policies have been configured (with priorities 15 and 20 respectively):

MyPeerRouter# show crypto isakmp policy
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

Related Commands

authentication (IKE policy)
crypto isakmp policy
encryption (IKE policy)
group (IKE policy)
hash (IKE policy)
lifetime (IKE policy)

show crypto isakmp sa

To view all current IKE security associations (SAs) at a peer, use the show crypto isakmp sa EXEC command.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.3 T.

Sample Display

The following is sample output from the show crypto isakmp sa command, after IKE negotiations have successfully completed between two peers:

MyPeerRouter# show crypto isakmp sa
    dst           src          state        conn-id   slot
172.21.114.123 172.21.114.67  QM_IDLE           1       0
155.0.0.2      155.0.0.1      QM_IDLE           8       0

Table 2 through Table 4 show the various states that may be displayed in the output of the show crypto isakmp sa command. When an ISAKMP SA exists, it will most likely be in its quiescent state (OAK_QM_IDLE). For long exchanges, some of the OAK_MM_xxx states may be observed.

Table 2: States in Main Mode Exchange
State
Explanation
  OAK_MM_NO_STATE
 The ISAKMP SA has been created but nothing else has happened yet. It is "larval" at this stage--there is no state.
  OAK_MM_SA_SETUP
 The peers have agreed on parameters for the ISAKMP SA.
  OAK_MM_KEY_EXCH
 The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The ISAKMP SA remains unauthenticated.
  OAK_MM_KEY_AUTH
 The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to OAK_QM_IDLE and a Quick Mode exchange begins. 
 


Table 3: States in Aggressive Mode Exchange
State
Explanation
  OAK_AG_NO_STATE
 The ISAKMP SA has been created but nothing else has happened yet. It is "larval" at this stage--there is no state.
  OAK_AG_INIT_EXCH
 The peers have done the first exchange in Aggressive Mode but the SA is not authenticated.
  OAK_AG_AUTH
 The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to OAK_QM_IDLE and a Quick Mode exchange begins.



Table 4: States in Quick Mode Exchange
 State
Explanation
  OAK_QM_IDLE
 The ISAKMP SA is idle. It remains authenticated with its peer and may be used for subsequent Quick Mode exchanges. It is in a quiescent state.

 Related Commands
 crypto isakmp policy
lifetime (IKE policy)

 show crypto key mypubkey rsa
 To view your router's RSA public key(s), use the show crypto key mypubkey rsa EXEC command.

show crypto key mypubkey rsa



 Syntax Description
 There are no arguments or keywords with this command.

 Command Mode
 EXEC

 Usage Guidelines
 This command first appeared in Cisco IOS Release 11.3 T.
 This command displays your router's RSA public key(s).

 Sample Display
 The following is sample output from the show crypto key mypubkey rsa command. Special usage RSA keys were previously generated for this router using the crypto key generate rsa command:
% Key pair was generated at: 06:07:49 UTC Jan 13 1996
Key name: myrouter.companyx.com
 Usage: Signature Key
 Key Data:
  005C300D 06092A86 4886F70D 01010105 00034B00 30480241 00C5E23B 55D6AB22 
  04AEF1BA A54028A6 9ACC01C5 129D99E4 64CAB820 847EDAD9 DF0B4E4C 73A05DD2 
  BD62A8A9 FA603DD2 E2A8A6F8 98F76E28 D58AD221 B583D7A4 71020301 0001
% Key pair was generated at: 06:07:50 UTC Jan 13 1996
Key name: myrouter.companyx.com
 Usage: Encryption Key
 Key Data:
  00302017 4A7D385B 1234EF29 335FC973 2DD50A37 C4F4B0FD 9DADE748 429618D5
  18242BA3 2EDFBDD3 4296142A DDF7D3D8 08407685 2F2190A0 0B43F1BD 9A8A26DB
  07953829 791FCDE9 A98420F0 6A82045B 90288A26 DBC64468 7789F76E EE21


 Related Commands
 crypto key generate rsa

 show crypto key pubkey-chain rsa
 To view peers' RSA public keys stored on your router, use the show crypto key pubkey-chain rsa EXEC command.

show crypto key pubkey-chain rsa [name key-name | address key-address]



 Syntax Description
 name key-name
 (Optional) Specify the name of a particular public key to view.
 address key-address
 (Optional) Specify the address of a particular public key to view.

 Default
 If no keywords are used, this command displays a list of all RSA public keys stored on your router.

 Command Mode
 EXEC

 Usage Guidelines
 This command first appeared in Cisco IOS Release 11.3 T.
 This command shows RSA public keys stored on your router. This includes peers' RSA public keys manually configured at your router and keys received by your router via other means (such as by a certificate, if CA support is configured).
 If a router reboots, any public key derived by certificates will be lost. This is because the router will ask for certificates again, at which time the public key will be derived again. 
 Use the name or address keywords to display details about a particular RSA public key stored on your router.

 Sample Display
 The following is sample output from the show crypto key pubkey-chain rsa command:

Codes: M - Manually Configured, C - Extracted from certificate
Code  Usage        IP-address     Name
M     Signature    10.0.0.l       myrouter.companyx.com
M     Encryption   10.0.0.1       myrouter.companyx.com
C     Signature    172.16.0.1     routerA.companyx.com
C     Encryption   172.16.0.1     routerA.companyx.com
C     General      192.168.10.3   routerB.comanyx.com

 This sample shows manually configured special usage RSA public keys for the peer "somerouter." This sample also shows three keys obtained from peers' certificates: special usage keys for peer "routerA" and a general purpose key for peer "routerB".
 Certificate support is used in the above example; if certificate support was not in use, none of the peers' keys would show "C" in the code column, but would all have to be manually configured.
 The following is sample output when you issue the command show crypto key pubkey rsa name somerouter.companyx.com:
Key name: somerouter.companyx.com
Key address: 10.0.0.1
 Usage: Signature Key
 Source: Manual
 Data:
  305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00C5E23B 55D6AB22 
  04AEF1BA A54028A6 9ACC01C5 129D99E4 64CAB820 847EDAD9 DF0B4E4C 73A05DD2 
  BD62A8A9 FA603DD2 E2A8A6F8 98F76E28 D58AD221 B583D7A4 71020301 0001
Key name: somerouter.companyx.com
Key address: 10.0.0.1
 Usage: Encryption Key
 Source: Manual
 Data:
  00302017 4A7D385B 1234EF29 335FC973 2DD50A37 C4F4B0FD 9DADE748 429618D5
  18242BA3 2EDFBDD3 4296142A DDF7D3D8 08407685 2F2190A0 0B43F1BD 9A8A26DB
  07953829 791FCDE9 A98420F0 6A82045B 90288A26 DBC64468 7789F76E EE21

 Note that the Source field in the above example indicates "Manual," meaning that the keys were manually configured on your router, not received in the peer's certificate.
 The following is sample output when you issue the command show crypto key pubkey rsa address 192.168.10.3:
Key name: routerB.companyx.com
Key address: 192.168.10.3
 Usage: General Purpose Key
 Source: Certificate
 Data:
  0738BC7A 2BC3E9F0 679B00FE 53987BCC 01030201 42DD06AF E228D24C 458AD228
  58BB5DDD F4836401 2A2D7163 219F882E 64CE69D4 B583748A 241BED0F 6E7F2F16
  0DE0986E DF02031F 4B0B0912 F68200C4 C625C389 0BFF3321 A2598935 C1B1

 Note that the Source field in the above example indicates "Certificate," meaning that the keys were received by your router by way of the other router's certificate.
 

 Debug Commands
 The following debug command can assist with troubleshooting IKE configuration:

 debug crypto isakmp
 Use the debug crypto isakmp EXEC command to display messages about IKE events. The no form of this command disables debugging output.

[no] debug crypto isakmp



 Sample Display
 The following shows sample debug crypto isakmp output for an IKE peer that initiates an IKE negotiation.
 First, IKE negotiates its own security association (SA), checking for a matching IKE policy:
MyRouter# debug crypto isakmp
20:26:58: ISAKMP (8): beginning Main Mode exchange
20:26:58: ISAKMP (8): processing SA payload. message ID = 0
20:26:58: ISAKMP (8): Checking ISAKMP transform 1 against priority 10 policy
20:26:58: ISAKMP:      encryption DES-CBC
20:26:58: ISAKMP:      hash SHA
20:26:58: ISAKMP:      default group 1
20:26:58: ISAKMP:      auth pre-share
20:26:58: ISAKMP (8): atts are acceptable. Next payload is 0

 IKE has found a matching policy. Next, the IKE SA is used by each peer to authenticate the other peer:
20:26:58: ISAKMP (8): SA is doing pre-shared key authentication
20:26:59: ISAKMP (8): processing KE payload. message ID = 0
20:26:59: ISAKMP (8): processing NONCE payload. message ID = 0
20:26:59: ISAKMP (8): SKEYID state generated
20:26:59: ISAKMP (8): processing ID payload. message ID = 0
20:26:59: ISAKMP (8): processing HASH payload. message ID = 0
20:26:59: ISAKMP (8): SA has been authenticated

 Next, IKE negotiates to set up the IPSec SA by searching for a matching transform set:
20:26:59: ISAKMP (8): beginning Quick Mode exchange, M-ID of 767162845
20:26:59: ISAKMP (8): processing SA payload. message ID = 767162845
20:26:59: ISAKMP (8): Checking IPSec proposal 1
20:26:59: ISAKMP: transform 1, ESP_DES
20:26:59: ISAKMP:   attributes in transform:
20:26:59: ISAKMP:      encaps is 1
20:26:59: ISAKMP:      SA life type in seconds
20:26:59: ISAKMP:      SA life duration (basic) of 600
20:26:59: ISAKMP:      SA life type in kilobytes
20:26:59: ISAKMP:      SA life duration (VPI) of
  0x0 0x46 0x50 0x0 
20:26:59: ISAKMP:      authenticator is HMAC-MD5
20:26:59: ISAKMP (8): atts are acceptable.

 A matching IPSec transform set has been found at the two peers. Now the IPSec SA can be created (one SA is created for each direction):
20:26:59: ISAKMP (8): processing NONCE payload. message ID = 767162845
20:26:59: ISAKMP (8): processing ID payload. message ID = 767162845
20:26:59: ISAKMP (8): processing ID payload. message ID = 767162845
20:26:59: ISAKMP (8): Creating IPSec SAs
20:26:59:         inbound SA from 155.0.0.2       to 155.0.0.1       (proxy 155.0.0.2       to 155.0.0.1      )
20:26:59:         has spi 454886490 and conn_id 9 and flags 4
20:26:59:         lifetime of 600 seconds
20:26:59:         lifetime of 4608000 kilobytes
20:26:59:         outbound SA from 155.0.0.1       to 155.0.0.2       (proxy 155.0.0.1       to 155.0.0.2      )
20:26:59:         has spi 75506225 and conn_id 10 and flags 4
20:26:59:         lifetime of 600 seconds
20:26:59:         lifetime of 4608000 kilobytes


 Supported MIBs and RFCs
 No new or changed MIBs are supported by IKE.
 IKE implements/supports the following RFCs and Internet drafts:

"Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-09.txt, Maughan, D., Schertler, M., Schneider, M., and Turner, J.

"The Internet Key Exchange (IKE)," draft-ietf-ipsec-isakmp-oakley-08.txt, Harkins, D., and Carrel, D.

"The IP Security Domain of Interpretation," draft-ietf-ipsec-ipsec-doi-09.txt, Piper, D.

RFC 2104: "HMAC: Keyed-Hashing for Message Authentication," H. Krawczyk, M. Bellare, R. Canetti.



 What to Do Next 
 After IKE configuration is complete, you can configure IPSec. IPSec configuration is described in the "IPSec Network Security" feature documentation.