Usage Guidelines

If you configure this command, all aggressive mode requests to the device and all aggressive mode requests made by the device are blocked, regardless of the ISAKMP authentication type (preshared keys or Rivest, Shamir, and Adelman [RSA] signatures).

If a request is made by or to the device for aggressive mode, the following syslog notification is sent:

Unable to initiate or respond to Aggressive Mode while disabled

Note	This command will prevent Easy Virtual Private Network (Easy VPN) clients from connecting if they are using preshared keys because Easy VPN clients (hardware and software) use aggressive mode.

Usage Guidelines

While specifying the proxy server, the proxy IP address and port number are separated with a colon. The proxy exception list is a semicolon-delimited string of IP addresses.

After enabling this command, you may specify the following subcommand:

• proxy --Configures proxy parameters for your Easy VPN remote device (see the proxy command for more information about this command and the acceptable parameters).

Usage Guidelines

Use the crypto isakmp client configuration group command to specify group policy information that needs to be defined or changed. You may wish to change the group policy on your router if you decide to connect to the client using a group ID that does not match the group-name argument.

After enabling this command, which puts you in Internet Security Association Key Management Protocol (ISAKMP) group configuration mode, you can specify characteristics for the group policy using the following commands:

• access-restrict--Ties a particular Virtual Private Network (VPN) group to a specific interface for access to the Cisco IOS gateway and the services it protects.

• acl --Configures split tunneling.

• auto-update client --Configures auto upgrade.

• backup-gateway --Configures a server to “push down” a list of backup gateways to the client. These gateways are tried in order in the case of a failure of the previous gateway. The gateways may be specified using IP addresses or host names.

• banner --Specifies a mode configuration banner.

• browser-proxy --Applies a browser-proxy map to a group.

• configuration url --Specifies on a server the URL an Easy VPN remote device must use to get a configuration in a Mode Configuration Exchange.

• configuration version --Specifies on a server the version a Cisco Easy VPN remote device must use to get a particular configuration in a Mode Configuration Exchange.

• crypto aaa attribute list --Defines a AAA attribute list of per-user attributes on a local Easy VPN server.

• dhcp giadd r--Configures an IP address on the Easy VPN server for the Dynamic Host Configuration Protocol (DHCP) to use. The DHCP server uses the giaddr keyword to determine the scope for the client IP address assignment. If the giaddr keyword is not configured, the Easy VPN server must be configured with a loopback interface to communicate with the DHCP server, and the IP address on the loopback interface determines the scope for the client IP address assignment.

• dhcp server --Configures multiple DHCP server entries.

• dhcp timeout --Controls the wait time before the next DHCP server on the list is tried.

• dns --Specifies the primary and secondary Domain Name Service (DNS) servers for the group.

• domain --Specifies group domain membership.

• firewall are-u-there-- Adds the Firewall-Are-U-There attribute to the server group if your PC is running the Black Ice or Zone Alarm personal firewalls.

• firewall policy --Specifies the CPP firewall policy push name for the crypto ISAKMP client configuration group on a local AAA server.

• group-lock--Use if preshared key authentication is used with Internet Key Exchange (IKE). Allows you to enter your extended authentication (Xauth) username. The group delimiter is compared against the group identifier sent during IKE aggressive mode.

• include-local-lan --Configures the Include-Local-LAN attribute to allow a nonsplit-tunneling connection to access the local subnetwork at the same time as the client.

• key --Specifies the IKE preshared key when defining group policy information for Mode Configuration push.

• max-logins --Limits the number of simultaneous logins for users in a specific user group.

• max-users --Limits the number of connections to a specific server group.

• netmask --Subnet mask to be used by the client for local connectivity.

• pfs --Configures a server to notify the client of the central-site policy regarding whether PFS is required for any IPsec SA. Because the client device does not have a user interface option to enable or disable PFS negotiation, the server will notify the client device of the central site policy via this parameter. The Diffie-Hellman (D-H) group that is proposed for PFS will be the same that was negotiated in Phase 1 of the IKE negotiation.

• pool --Refers to the IP local pool address used to allocate internal IP addresses to clients.

• save-password --Saves your Xauth password locally on your PC.

• split-dns --Specifies a list of domain names that must be tunneled or resolved to the private network.

• wins --Specifies the primary and secondary Windows Internet Naming Service (WINS) servers for the group.

Output for the crypto isakmp client configuration group command (using the key subcommand) will show that the preshared key is either encrypted or unencrypted. An output example for an unencrypted preshared key would be as follows:

crypto isakmp client configuration group key test

An output example for a type 6 encrypted preshared key would be as follows:

crypto isakmp client configuration group

 key 6 JK_JHZPeJV_XFZTKCQFYAAB

Session Monitoring and Limiting for Easy VPN Clients

It is possible to mimic the functionality provided by some RADIUS servers for limiting the number of connections to a specific server group and also for limiting the number of simultaneous logins for users in that group.

To limit the number of connections to a specific server group, use the max-users subcommand. To limit the number of simultaneous logins for users in the server group, use the max-logins subcommand.

The following example shows the RADIUS attribute-value (AV) pairs for the maximum users and maximum logins parameters:

ipsec:max-users=1000
ipsec:max-logins=1

The max-users and max-logins commands can be enabled together or individually to control the usage of resources by any groups or individuals.

If you use a RADIUS server, such as a CiscoSecure access control server (ACS), it is recommended that you enable this session control on the RADIUS server if the functionality is provided. In this way, usage can be controlled across a number of servers by one central repository. When enabling this feature on the router itself, only connections to groups on that specific device are monitored, and load-sharing scenarios are not accurately accounted for.

Usage Guidelines

The table below lists firewall types that may be used for the firewall-type argument.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

If you have neither manually configured ISAKMP policies with the crypto isakmp policy command nor issued the no crypto isakmp default policy command, IPsec will use the default ISAKMP policies to negotiate IKE proposals. There are eight default ISAKMP default policies supported (see the table below). The default ISAKMP policies define the following policy set parameters:

• The priority, 65507-65514, where 65507 is the highest priority and 65514 is the lowest priority.

• The authentication method, Rivest, Shamir, and Adelman (RSA) or preshared keys (PSK).

• The encryption method, Advanced Encryption Standard (AES) or Triple Data Encryption Standard (3DES).

• The hash function, Secure Hash Algorithm (SHA-1) or Message-Digest algorithm 5 (MD5).

• The Diffie-Hellman (DH) group specification DH2 or DH5.

  • DH2 specifies the 768-bit Diffie-Hellman group.
  • DH5 specifies the 1536-bit Diffie-Hellman group.

Usage Guidelines

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

If you disable IKE, you will have to make these concessions at the 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 chapter “Configuring IPSec Network Security” in the Cisco IOS Security Configuration Guide .)

• The IPSec SAs of the peers 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.

Note	Effective with Cisco IOS Release 12.3(2)T, a device is prevented from responding to Internet Security Association and Key Management Protocol (ISAKMP) by default unless there is a crypto map applied to an interface or if Easy VPN is configured.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Do not configure IKE fragmentation on a Cisco IOS router with Cisco Easy VPN Client versions 5.01 through 5.03. Versions earlier than version 5.01 and version 5.04 or a later release should be all right.

Note	The crypto isakmp fragmentation command is only applicable when the IOS Router is acting as an Easy VPN server and the remote peer is a Cisco IPsec VPN client.

Usage Guidelines

Use this command to specify an ISAKMP identity either by IP address, DN or host name. An ISAKMP identity is set whenever you specify preshared keys or RSA signature authentication.

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

The dn keyword should be used if the DN of a router certificate is to be specified and chosen as the ISAKMP identity during IKE processing. The dn keyword is used only for certificate-based authentication.

The hostname keyword should be used if more than one interface on the peer 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 host name.

Usage Guidelines

This command allows you to configure your router so that when an invalid security parameter index error (shown as “Invalid SPI”) occurs, an IKE SA is initiated. The “IKE” module, which serves as a checkpoint in the IPSec session, recognizes the “Invalid SPI” situation. The IKE module then sends an “Invalid Error” message to the packet-receiving peer so that synchronization of the security association databases (SADBs) of the two peers can be attempted. As soon as the SADBs are resynchronized, packets are no longer dropped.

Note	SPI recovery initiates a new IKE SA only for static peers.

Caution

Using this command to initiate an IKE SA to notify an IPSec peer of an “Invalid SPI” error can result in a denial-of-service (DoS) attack.

Usage Guidelines

Use the crypto isakmp keepalive command to enable the gateway to send DPD messages to the peer. DPD is a keepalives scheme that allows the router to query the liveliness of its Internet Key Exchange (IKE) peer.

Use the periodic keyword to configure your router so that DPD messages are “forced” at regular intervals. This forced approach results in earlier detection of dead peers than with the on-demand approach. If you do not configure the periodic option, the router defaults to the on-demand approach.

Note	When the crypto isakmp keepalive command is configured, the Cisco IOS software negotiates the use of Cisco IOS keepalives or DPD, depending on which protocol the peer supports.

Note	Cisco IOS VPN Client connections are not supported if you configure the crypto isakmp keepalive command with the periodic keyword on a Cisco IOS device.

Usage Guidelines

You must use this command to configure a key whenever you specify preshared keys in an Internet Key Exchange (IKE) policy; you must enable this command at both peers.

If an IKE policy includes preshared keys as the authentication method, these preshared 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 preshared keys at the peers. (The first task is accomplished using the crypto isakmp identity command.)

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

With the address keyword, you can also use the mask argument to indicate the remote peer ISAKMP identity will be established using the preshared key only. If the mask argument is used, preshared keys are no longer restricted between two users.

Note	If you specify mask, you must use a subnet address. (The subnet address 0.0.0.0 is not recommended because it encourages group preshared keys, which allow all peers to have the same group key, thereby reducing the security of your user authentication.)

When using IKE main mode, preshared keys are indexed by IP address only because the identity payload has not yet been received. This means that the hostname keyword in the identity statement is not used to look up a preshared key and will be used only when sending and processing the identity payloads later in the main mode exchange. The identity keyword can be used when preshared keys are used with IKE aggressive mode, and keys may be indexed by identity types other than IP address as the identity payload is received in the first IKE aggressive mode packet.

If crypto isakmp identity hostname is configured as identity, the preshared key must be configured with the peer’s IP address for the process to work when using IKE in main mode.

Use the no-xauth keyword to prevent the router from prompting the peer for Xauth information (username and password). This keyword disables Xauth for static IPSec peers. The no-xauth keyword should be enabled when configuring the preshared key for router-to-router IPSec--not VPN-client-to-Cisco-IOS IPSec.

Output for the crypto isakmp key command will show that the preshared key is either encrypted or unencrypted. An output example for an unencrypted preshared key would be as follows:

crypto isakmp key test123 address 10.1.0.1

An output example for a type 6 encrypted preshared key would be as follows:

crypto isakmp key 6 RHZE[JACMUI\bcbTdELISAAB address 10.1.0.1

Usage Guidelines

The crypto isakmp nat keepalive command allows users to keep the dynamic NAT mapping alive during a connection between two peers. A NAT keepalive packet is sent by the peer that is behind the NAT device if IPsec does not send or receive a packet within a specified time period. With CSCul35051, if both peers are behind their respective NAT devices, each peer sends NAT keepalive packets according to its configured interval.

If this command is enabled, users should ensure that the idle value is shorter than the NAT mapping expiration time.

Note	When the timer is modified, it is modified for every Internet Security Association Key Management Protocol (ISAKMP) security association (SA) when the keepalive for that SA is sent based on the existing timer.

Note	A 5-percent jitter mechanism value is applied to the timer to avoid SA rekey collisions. If there are many peer devices, and the timer is configured too low, then the device can experience high CPU usage.

Usage Guidelines

After enabling this command, you can use the set aggressive-mode client-endpoint and set aggressive-mode password commands to specify RADIUS tunnel attributes in the Internet Security Association and Key Management Protocol (ISAKMP) peer policy for IPSec peers.

Instead of keeping your preshared keys on the hub router, you can scale your preshared keys by storing and retrieving them from an AAA server. The preshared keys are stored in the AAA server as Internet Engineering Task Force (IETF) RADIUS tunnel attributes and are retrieved when a user tries to “speak” to the hub router. The hub router retrieves the preshared key from the AAA server and the spokes (the users) initiate aggressive mode to the hub by using the preshared key that is specified in the ISAKMP peer policy as a RADIUS tunnel attribute.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

IKE policies define a set of parameters to be used during the IKE negotiation. 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].)

This command invokes the Internet Security Association Key Management Protocol (ISAKMP) policy configuration (config-isakmp) command mode. While in the ISAKMP policy configuration command mode, some of the commands for which you can specify parameters are as follows:

• authentication ; default = RSA signatures

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

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

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

• lifetime (IKE policy) ; def ault = 86,400 seconds (one day)

If you do not specify any given parameter, 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.

Usage Guidelines

Defining an ISAKMP Profile

An ISAKMP profile can be viewed as a repository of Phase 1 and Phase 1.5 commands for a set of peers. The Phase 1 configuration includes commands to configure such things as keepalive, identity matching, and the authorization list. The Phase 1.5 configuration includes commands to configure such things as extended authentication (Xauth) and mode configuration.

The peers are mapped to an ISAKMP profile when their identities are matched (as given in the identification [ID] payload of the Internet Key Exchange [IKE]) against the identities defined in the ISAKMP profile. To uniquely map to an ISAKMP profile, no two ISAKMP profiles should match the same identity. If the peer identity is matched in two ISAKMP profiles, the configuration is invalid. Also, there must be at least one match identity command defined in the ISAKMP profile for it to be complete.

After enabling this command and entering ISAKMP profile configuration mode, you can configure the following commands:

• accounting --Enables authentication, authorization, and accounting (AAA) accounting.

• ca trust-point --Specifies certificate authorities.

• client --Specifies client configuration settings.

• default --Lists subcommands for the crypto isakmp profile command.

• description --Specifies a description of this profile.

• initiate mode --Initiates a mode.

• isakmp authorization --ISAKMP authorization parameters.

• keepalive --Sets a keepalive interval.

• keyring --Specifies a keyring.

• local-address --Specifies the interface to use as the local address of this ISAKMP profile.

• match --Matches the values of the peer.

• qos-group --Applies a quality of service (QoS) policy class map for this profile.

• self-identity --Specifies the identity.

• virtual-template --Specifies the virtual template for the dynamic interface.

• vrf --Specifies the Virtual Private Network routing and forwarding (VRF) instance to which the profile is related.

Auditing IPSec User Sessions

Use this command to audit multiple user sessions that are terminating on the IPSec gateway.

Note

The crypto isakmp profile command and the crypto map (global IPSec) command are mutually exclusive. If a profile is present (the crypto isakmp profile command has been used), with no accounting configured but with the global command present (the crypto isakmp profile command without the accounting keyword), accounting will occur using the attributes in the global command.

Dynamic Virtual Tunnel Interfaces

Support for dynamic virtual tunnel interfaces allows for the virtual profile to be mapped into a specified virtual template.

VRF-Aware IPsec

You must include the VRF in the local-address command when using the local address with VRF in the ISAKMP profile and keyring.

Usage Guidelines

Use the crypto key decrypt rsa command to store the decrypted private key in NvRAM the next time NvRAM is written (which is immediately if the write keyword is issed).

Usage Guidelines

The private key is encrypted (protected) via the specified passphrase. After the key is protected, it may continue to be used by the router; that is Internet Key Exchange (IKE) tunnels and encrypted key export attempts should continue to work because the key remains “unlocked.”

To lock the key, which can be used to disable the router, issue the crypto key lock rsa privileged EXEC command. (When you lock the encrypted key, all functions which use the locked key are disabled.)

Usage Guidelines

IPsec and public key infrastructure (PKI) both support the ability to generate, export, and import EC (ECDSA-256 and ECDSA-384) key pairs. The crypto key export ec command lets you export EC key pairs to PEM-formatted files. Then, you can import the PEM files back into a Cisco IOS router or other PKI applications.

Note	Before you export an EC key pair to a PEM file, ensure that the EC key pair is exportable. To generate an exportable EC key pair, use the crypto key generate ec keysize command and specify the exportable keyword.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

The crypto key export rsa pem command allows RSA key pairs to be exported in PEM-formatted files. The PEM files can then be imported back into a Cisco IOS router or other public key infrastructure (PKI) applications.

Note	Before an RSA key pair is exported in a PEM file, ensure that the RSA key pair is exportable. To generate an exportable RSA key pair, issue the crypto key generate rsa command and specify the exportable keyword.

Usage Guidelines

Use this command to generate EC key pairs for your Cisco device (such as a router). IPsec and public key infrastructure (PKI) both support the ability to generate, export, and import EC (ECDSA-256 and ECDSA-384) key pairs.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

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.

If your router already has RSA keys when you issue this command, you will be warned and prompted to replace the existing keys with new keys.

Note

Before issuing this command, ensure that your router has a hostname and IP domain name configured (with the hostname and ip domain-name commands). You will be unable to complete the crypto key generate rsa command without a hostname and IP domain name. (This situation is not true when you generate only a named key pair.)

Note

Secure Shell (SSH) may generate an additional RSA key pair if you generate a key pair on a router having no RSA keys. The additional key pair is used only by SSH and will have a name such as {router_FQDN }.server. For example, if a router name is “router1.cisco.com,” the key name is “router1.cisco.com.server.”

This command is not saved in the router configuration; however, the RSA keys generated by this command are saved in the private configuration in NVRAM (which is never displayed to the user or backed up to another device) the next time the configuration is written to NVRAM.

Note	If the configuration is not saved to NVRAM, the generated keys are lost on the next reload of the router.

There are two mutually exclusive types of RSA key pairs: special-usage keys and general-purpose keys. When you generate RSA key pairs, you will be prompted to select either special-usage keys or general-purpose keys.

Special-Usage Keys

If you generate special-usage keys, two pairs of RSA keys will be generated. One pair will be used with any Internet Key Exchange (IKE) policy that specifies RSA signatures as the authentication method, and the other pair will be used with any IKE policy that specifies RSA encrypted keys as the authentication method.

A CA is used only with IKE policies specifying RSA signatures, not with IKE policies specifying RSA-encrypted nonces. (However, you could specify more than one IKE policy and have RSA signatures specified in one policy and RSA-encrypted nonces in another policy.)

If you plan to have both types of RSA authentication methods in your IKE policies, you may prefer to generate special-usage keys. With special-usage keys, each key is not unnecessarily exposed. (Without special-usage keys, one key is used for both authentication methods, increasing the exposure of that key.)

General-Purpose Keys

If you generate general-purpose keys, only one pair of RSA keys will be generated. This pair will be used with IKE policies specifying either RSA signatures or RSA encrypted keys. Therefore, a general-purpose key pair might get used more frequently than a special-usage key pair.

Named Key Pairs

If you generate a named key pair using the key-label argument, you must also specify the usage-keys keyword or the general-keys keyword. Named key pairs allow you to have multiple RSA key pairs, enabling the Cisco IOS software to maintain a different key pair for each identity certificate.

Modulus Length

When you generate RSA keys, you will be prompted to enter a modulus length. The longer the modulus, the stronger the security. However a longer modules takes longer to generate (see the table below for sample times) and takes longer to use.

Cisco IOS software does not support a modulus greater than 4096 bits. A length of less than 512 bits is normally not recommended. In certain situations, the shorter modulus may not function properly with IKE, so we recommend using a minimum modulus of 2048 bits.

Note

As of Cisco IOS Release 12.4(11)T, peer public RSA key modulus values up to 4096 bits are automatically supported. The largest private RSA key modulus is 4096 bits. Therefore, the largest RSA private key a router may generate or import is 4096 bits. However, RFC 2409 restricts the private key size to 2048 bits or less for RSA encryption. The recommended modulus for a CA is 2048 bits; the recommended modulus for a client is 2048 bits.

Additional limitations may apply when RSA keys are generated by cryptographic hardware. For example, when RSA keys are generated by the Cisco VPN Services Port Adapter (VSPA), the RSA key modulus must be a minimum of 384 bits and must be a multiple of 64.

Specifying a Storage Location for RSA Keys

When you issue the crypto key generate rsa command with the storage devicename : keyword and argument, the RSA keys will be stored on the specified device. This location will supersede any crypto key storage command settings.

Specifying a Device for RSA Key Generation

As of Cisco IOS Release 12.4(11)T and later releases, you may specify the device where RSA keys are generated. Devices supported include NVRAM, local disks, and USB tokens. If your router has a USB token configured and available, the USB token can be used as cryptographic device in addition to a storage device. Using a USB token as a cryptographic device allows RSA operations such as key generation, signing, and authentication of credentials to be performed on the token. The private key never leaves the USB token and is not exportable. The public key is exportable.

RSA keys may be generated on a configured and available USB token, by the use of the on devicename : keyword and argument. Keys that reside on a USB token are saved to persistent token storage when they are generated. The number of keys that can be generated on a USB token is limited by the space available. If you attempt to generate keys on a USB token and it is full you will receive the following message:

% Error in generating keys:no available resources 

Key deletion will remove the keys stored on the token from persistent storage immediately. (Keys that do not reside on a token are saved to or deleted from nontoken storage locations when the copy or similar command is issued.)

For information on configuring a USB token, see “ Storing PKI Credentials ” chapter in the Cisco IOS Security Configuration Guide, Release 12.4T. For information on using on-token RSA credentials, see the “ Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment ” chapter in the Cisco IOS Security Configuration Guide , Release 12.4T.

Specifying RSA Key Redundancy Generation on a Device

You can specify redundancy for existing keys only if they are exportable.

Usage Guidelines

IPsec and public key infrastructure (PKI) both support the ability to generate, export, and import EC (ECDSA-256 and ECDSA-384) key pairs. The crypto key import ec command lets you import EC key pairs into PEM-formatted files. The files can be previously exported from another Cisco IOS router or generated by other PKI applications.

You can specify a device from which to import EC key pairs. Devices supported include NVRAM and local disks.

If the device on which the EC key pair is to be imported does not have enough space for this key, then a message appears stating that the importation of the key pair has failed.

To delete EC key pairs from a device, use the crypto key zeroize ec command.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

The crypto key import rsa pem command allows RSA key pairs to be imported into PEM-formatted files. The files can be previously exported from another Cisco IOS router or generated by other public key infrastructure (PKI) applications.

As of Cisco IOS Release 12.4(11)T and later releases, the device can be specified for where RSA keys are generated. Devices supported include NVRAM, local disks and USB tokens. If the router has a USB token configured and available, the USB token can be used as cryptographic device in addition to a storage device. Using a USB token as a cryptographic device allows RSA operations such as key generation, signing and authentication of credentials to be performed on the token. The private key never leaves the USB token and is not exportable. The public key is exportable.

RSA keys may be imported to a configured and available USB token by using the on devicename : keyword and argument. Keys that reside on a USB token, or on-token keys, are saved to persistent token storage when they are imported. Key deletion removes the on-token keys from persistent storage immediately. (Keys that do not reside on a token are saved to or deleted from nontoken storage locations when the write memory or similar command is issued.)

If the device, on which the RSA key is to be imported, does not have enough space for this key, then a message appears saying that the importation of the key has failed.

For information on configuring a USB token, see “ Storing PKI Credentials ” module. For information on using on-token RSA credentials, see “ Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment” module.

Usage Guidelines

When the crypto key lock rsa command is issued, the unencrypted copy of the key is deleted. Because the private key is not available, all RSA operations will fail.

This command affects only the “run-time” access to the key; that is, it does not affect the key that is stored in NVRAM.

Usage Guidelines

When an existing RSA key pair is generated in Cisco IOS, stored on a USB token, and used for an enrollment, it may be necessary to move those existing RSA key pairs to an alternate location for permanent storage.

Generating the key on the router and moving it to the token requires less than a minute. Generating a key on the token using the on keyword could require 5 to 10 minutes and is dependent on hardware key generation routines available on the USB token.

Using the crypto key move rsa command allows the storage location of a newly generated key to be changed if the storage keyword or on keyword was not specified when the key was first generated and the key has not yet been written out to a storage location. You can always move an exportable key.

Note	If you make the key nonexportable by issuing the non-exportable keyword, the key cannot be made exportable again. Also, once you specify the on keyword with the target device, either to move an existing key or during key generation, the command cannot be undone.

Usage Guidelines

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 Internet Key Exchange policy at your peer router.

Usage Guidelines

You may specify a default storage location, other than NVRAM, for newly created USB token RSA keys. The storage location specified by the crypto key generate rsa command for RSA keys will override the location specified by the crypto key storage command. The name of the designated device is followed by a colon (:).

Regardless of configuration settings, existing keys will be stored on the devices from where they were originally loaded.

Note	The USB token must be logged into the router for the RSA keys to be read or written.

Usage Guidelines

When a router with an encrypted RSA key (via the crypto key encrypt rsa command) initially boots up, the key does not exist in plain text and is therefore considered to be locked. Because the private key is not available, all RSA operations will fail. After you unlock the private key, RSA operations will function again.

This command affects only the “run-time” access to the key; that is, it does not affect the key that is stored in NVRAM.

Usage Guidelines

This command deletes all EC key pairs that were previously generated by your router unless you include the key-pair-label argument, which will delete only the specified EC key pair. If you issue this command, you must also perform two additional tasks for each trustpoint that is associated with the key pair that was deleted:

• Ask the certification authority (CA) administrator to revoke your router’s certificates at the CA; you must supply the challenge password you created when you originally obtained the router’s certificates using the crypto ca enroll command.

• Manually remove the router’s certificates from the configuration by removing the configured trustpoint (using the no crypto ca trustpoint name command .)

Note

This command cannot be undone (after you save your configuration), and after EC keys have been deleted, you cannot use certificates or the CA or participate in certificate exchanges with other IP security (IPsec) peers unless you reconfigure CA interoperability by regenerating EC keys, getting the CA’s certificate, and requesting your own certificate again.

This command is not saved to the configuration.

Usage Guidelines

This command is used is used to delete the peer router's public keys in order to help debug signature verification problems in IKEv1 and IKEv2. Keys are cached by default with the lifetime of the certificate revocation list (CRL) associated with the trustpoint.

Usage Guidelines

This command deletes all Rivest, Shamir, and Adelman (RSA) keys that were previously generated by your router unless you include the key-pair-label argument, which will delete only the specified RSA key pair. If you issue this command, you must also perform two additional tasks for each trustpoint that is associated with the key pair that was deleted:

• Ask the certification authority (CA) administrator to revoke your router’s certificates at the CA; you must supply the challenge password you created when you originally obtained the router’s certificates using the crypto ca enroll command.

• Manually remove the router’s certificates from the configuration by removing the configured trustpoint (using the no crypto ca trustpoint name command .)

Note

This command cannot be undone (after you save your configuration), and after RSA keys have been deleted, you cannot use certificates or the CA or participate in certificate exchanges with other IP Security (IPSec) peers unless you reconfigure CA interoperability by regenerating RSA keys, getting the CA’s certificate, and requesting your own certificate again.

This command is not saved to the configuration.

Usage Guidelines

A keyring is a repository of preshared and Rivest, Shamir, and Adelman (RSA) public keys. The keyring is used in the ISAKMP profile configuration mode. The ISAKMP profile successfully completes authentication of peers if the peer keys are defined in the keyring that is attached to this profile.

Usage Guidelines

Crypto logging messages allow users to receive notification for every crypto EZVPN group or session that is made on their device.

Usage Guidelines

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Use this command to create a new crypto map entry or profile. Use the crypto map ipv6 map-name seq-num command without any keyword to modify an existing IPv6 crypto map entry or profile. For IPv4 crypto maps, use the crypto map map-name seq-num command without any keyword to modify the existing crypto map entry or profile.

After a crypto map entry is created, you cannot change the parameters specified at the global configuration level because these parameters determine the configuration commands that are valid at the crypto map level. For example, after a map entry has been created using the ipsec-isakmp keyword, you cannot change it to the option specified by the ipsec-manual keyword; you must delete and reenter the map entry.

After you define crypto map entries, you can assign the crypto map set to interfaces using the crypto map (interface IPsec) command.

Crypto Map Functions

Crypto maps provide two functions: filtering and classifying the traffic to be protected and defining the policy to be applied to that traffic. The first affects the flow of traffic on an interface; the second affects the negotiation performed (via IKE) on behalf of that traffic.

IPsec crypto maps define the following:

• What traffic should be protected

• To which IPsec peers the protected traffic can be forwarded--these are the peers with which an SA can be established

• Which transform sets are acceptable for use with the protected traffic

• How keys and SAs should be used or managed (or what the keys are, if IKE is not used)

Note	Crypto maps are not supported on tunnel interface and port-channel interface for Cisco ASR 1000 Series Aggregation Services Routers, Cisco Cloud Services Router 1000V Series, and Cisco 4000 Series Integrated Services Routers.

Multiple Crypto Map Entries with the Same Map Name Form a Crypto Map Set

A crypto map set is a collection of crypto map entries, each with a different seq-num argument but the same map-name argument. Therefore, for an interface, you could have certain traffic forwarded to one IPsec peer with specified security applied to that traffic and other traffic forwarded to the same or different IPsec peer with different IPsec security applied. To accomplish differential forwarding, you would create two crypto maps, each with the same map-name argument but different seq-num argument. Crypto profiles must have unique names within a crypto map set.

Note

If a deny statement (which specifies the conditions under which a packet cannot pass the access control list) in an access control list belongs to a crypto map in a crypto map set, the IPsec logic causes a jump to the next crypto map in the crypto map set, hoping for a better possible match. VPN Service Adapter (VSA) hardware has a restriction of 14 jumps.

Sequence Numbers

The number you assign to the seq-num argument should not be arbitrary. This number is used to rank multiple crypto map entries within a crypto map set. Within a crypto map set, a crypto map entry with a lower seq-num is evaluated before a map entry with a higher seq-num ; that is, the map entry with the lower number has a higher priority.

For example, assume that a crypto map set contains three crypto map entries: mymap 10, mymap 20, and mymap 30. The crypto map set named “mymap” is applied to serial interface 0. When traffic passes through serial interface 0, traffic is evaluated first for mymap 10. If the traffic matches any access list permit statement entry in the extended access list in mymap 10, the traffic will be processed according to the information defined in mymap 10 (which includes establishing IPsec SAs when necessary). If the traffic does not match the mymap 10 access list, the traffic will be evaluated for mymap 20, and then mymap 30, until the traffic matches a permit entry in a map entry. (If the traffic does not match a permit entry in any crypto map entry, it will be forwarded without any IPsec security.)

Dynamic Crypto Maps

Refer to the “Usage Guidelines” section of the crypto dynamic-map command for a discussion on dynamic crypto maps.

Crypto map entries that reference dynamic map sets should be the lowest priority map entries, allowing inbound SA negotiation requests to try to match the static maps first. If the request does not match any of the static maps, it will be evaluated against the dynamic map set.

If a crypto map entry references a dynamic crypto map set, make it the lowest priority map entry by giving it the highest seq-num value of all the map entries in a crypto map set.

Create dynamic crypto map entries using the crypto dynamic-map command. After you create a dynamic crypto map set, add the dynamic crypto map set to a static crypto map set with the crypto map (global IPsec) command using the dynamic keyword.

Note	IPv6 keywords are not supported on dynamic crypto maps.

TED

Tunnel Endpoint Discovery (TED) is an enhancement to the IPsec feature. Defining a dynamic crypto map allows you to dynamically determine an IPsec peer; however, only the receiving router has this ability. With TED, the initiating router can dynamically determine an IPsec peer for secure IPsec communications.

Dynamic TED helps to simplify the IPsec configuration on individual routers within a large network. Each node has a simple configuration that defines the local network that the router is protecting and the IPsec transforms that are required.

Note	TED helps only in discovering peers; otherwise, TED does not function any differently from normal IPsec. Thus, TED does not improve the scalability of IPsec (in terms of performance or the number of peers or tunnels).

Crypto Map Profiles

Crypto map profiles are created using the profile profile-name keyword and argument combination. Crypto map profiles are used as configuration templates for dynamically creating crypto maps on demand for use with the L2TP Security feature. The relevant SAs in the crypto map profile will be cloned and used to protect IP traffic on the L2TP tunnel.

Note	The set peer and match address commands are ignored by crypto profiles and should not be configured in the crypto map definition.