IPSec VPN peers must exchange some form of authentication keys in order to have a trust relationship. IKE is a standardized way to manage and exchange keys for IPSec. Although IPSec can be used without IKE, IKE provides a flexible and scalable means of managing keys.
IKE is based on RFC 2409.
The Internet Security Association and Key Management Protocol (ISAKMP) provides the mechanism of key exchange. It is used by both IKE and IPSec and is based on RFC 2408.
As soon as IKE negotiations are successful between two peers, IKE creates a security association (SA) to the remote peer. SAs are unidirectional; two SAs actually exist between two peers.
Preshared secret keys can be configured between VPN peers. This process is simple to set up but difficult to maintain for a large number of peers.
A Certification Authority (CA) can be used to authenticate VPN peers on a more flexible, larger scale. The CA is a trusted source of digital certificates, each of which must be "signed" by the CA itself.
IKE is compatible with these CAs: Baltimore unicert, Entrust VPN connector, Microsoft Windows 2000, Netscape CMS, and VeriSign onsite.
IKE operates in two phases: phase 1, where keys are exchanged and an SA is established, and phase 2, where keys and SAs are established for IPSec. Information exchanged during both phases is secured, and the identities of the peers are usually hidden from view on the network.
IKE supports multiple policies, such that the router searches through a list of policies to find one that matches the capabilities of a negotiating peer.
IKE mode can be used to provide a VPN peer with a protected IP address and other network parameters during IKE negotiation. This is useful when the remote clients have dynamic IP addresses from their ISPs or corporate networks and you can't preconfigure the remote peer host names or addresses.
NOTE
IKE uses UDP port 500 for negotiations. Be sure port 500 is not blocked.
(Optional) Enable or disable IKE:
(global) crypto isakmp enable
-OR-
(global) no crypto isakmp enable
IKE is enabled by default on all interfaces. To disable IKE, use the no form of this command. If IKE is disabled, many IPSec features will become static.
Create an IKE policy.
Define the policy:
(global) crypto isakmp policy priority
The policy is given a unique arbitrary priority number (1 to 10000, where 1 is the lowest). IKE is organized into policies that are matched in sequential order ( lowest to highest).
(Optional) Define the encryption algorithm:
(isakmp) encryption { des 3des }
The encryption mode can be 56-bit DES-CBC ( des, the default) or 168-bit 3DES ( 3des ).
(Optional) Define the hash algorithm:
(isakmp) hash { sha md5 }
The hash algorithm can be sha (an HMAC variant of SHA-1, the default) or md5 (an HMAC variant of MD5). MD5 has a smaller digest but is slightly slower.
(Optional) Define the authentication method:
(isakmp) authentication { rsa-sig rsa-encr pre-share }
The authentication method can be rsa-sig (RSA signatures; requires the use of a CA and offers nonrepudiation; the default), rsa-encr (RSA encryption; a CA is not required; offers repudiation ), or pre-share (keys are preshared through manual configuration). For the RSA methods , public keys must be shared between peers either by manual configuration of RSA keys or by previous use of RSA signatures.
(Optional) Define the Diffie-Hellman group identifier:
(isakmp) group { 1 2 }
The group can be 1 (768-bit Diffie-Hellman, the default) or 2 (1024-bit Diffie-Hellman). Group 2 is harder to crack but is more CPU- intensive .
(Optional) Define the lifetime for security associations:
(isakmp) lifetime seconds
The SA lifetime is set to seconds (60 to 86400; the default is 86400 seconds, or 1 day).
("rsa-sig" method) Use a Certification Authority (CA).
Make sure the router has a host name and domain name :
(global) hostname hostname (global) ip domain-name domain
The router must have a fully qualified domain name, formed by the host name and IP domain name. This is used to generate RSA keys and is assigned to the certificates used by the router.
Generate RSA keys:
(global) crypto key generate rsa
By default, a pair of general-purpose keys is generated for use with IKE. When prompted, enter the modulus length (1024 or 2048 bits). The larger modulus produces a more secure key but takes many times longer to generate. The RSA keys are stored in the private configuration in NVRAM and are not displayed. To see the public RSA key, use the show crypto key mypubkey rsa command.
Use the CA that issued certificates to the IPSec peer.
Set the host name of the CA:
(global) crypto ca identity name
An arbitrary name is given to the CA definition.
Set the URL used to reach the CA:
(ca-identity) enrollment url url
To enroll with the CA, the URL given by url is used. The URL should be of the form http://ca-domain-name:port/cgi-bin-location. The port can be given, as well as any optional path to a nonstandard cgi-bin script location.
(Optional) Use RA mode:
(ca-identity) enrollment mode ra (ca-identity) query url url
Use a Registration Authority (RA) for enrollment if one is provided by the CA. The URL used to reach the LDAP server can also be given as url.
(Optional) Set the enrollment retry parameters:
(ca-identity) enrollment retry period minutes (ca-identity) enrollment retry count number
The router sends a request for a certificate and then waits for minutes (1 to 60; the default is 1) before retrying . Requests are retried for number times (1 to 100; the default is 0 for an infinite number).
(Optional) Make the Certificate Revocation List (CRL) optional:
(ca-identity) crl optional
Normally, a router downloads a CRL with a new certificate. If the certificate appears in the CRL, it is not accepted. However, the CRL can be optional so that certificates are accepted even if a CRL cannot be obtained.
(Optional) Use a trusted root CA.
Identify the trusted root CA:
(global) crypto ca trusted-root name
The trusted root is associated with an arbitrary name. The local router can be enrolled with the trusted root without having to enroll with the same CA that issued a certificate to the far end of an IPSec connection.
(Optional) Request a CRL from the trusted root:
(ca-root) crl query url
The CRL is requested via the URL.
Define the enrollment method:
(ca-root) root { CEP url TFTP server file PROXY url }
The router can enroll with the trusted root through the following methods: Simple Certificate Enrollment Protocol ( CEP ), TFTP, or HTTP proxy server ( PROXY ). For TFTP, the server IP address or host name and the file filename must be given.
Authenticate the CA:
(global) crypto ca authenticate name
The router must obtain the self-signed certificate for the CA name. During this process, the CA's public RSA key is also retrieved. The CA certificate is placed in the router configuration automatically after it is received.
Enroll the router with the CA:
(global) crypto ca enroll name
The router requests a signed certificate for itself from the CA name. You enter a challenge password (up to 80 characters ) during this process, which will be used if you ever need to have the certificate revoked by the CA. The router's serial number can optionally be included in the certificate if the CA requires it (this isn't required by IKE or IPSec). Don't choose to have the router's IP address included in the certificate, however.
NOTE
The enrollment and certificate request process can take considerable time, especially if the CA grants certificates through a manual process. The router returns to a configuration prompt, making it seem as though the process is complete. However, the enrollment process is running in the background while waiting for the certificate to be returned. A message is posted to the console as soon as the certificate arrives. You can also use show crypto ca certificates to view all the router's certificates.
("rsa-encr" method) Manually configure the RSA keys (no CA is used).
Generate the RSA keys:
(global) crypto key generate rsa
By default, a pair of general-purpose keys is generated for use with IKE. When prompted, enter the modulus length (1024 or 2048 bits). The larger modulus produces a more secure key but takes much longer to generate. The RSA keys are stored in the private configuration in NVRAM and are not displayed. To see the public RSA key, use the show crypto key mypubkey rsa command.
Specify the ISAKMP identity of this peer:
(global) crypto isakmp identity { address hostname }
The router is identified to its peers either by the IP address of the interface used to communicate with a remote peer or by its hostname.
Specify RSA public keys for all other peers.
Configure the public key chain:
(global) crypto key pubkey-chain rsa
Identify the key by name or address:
(pubkey-chain) named-key key-name [ encryption signature ]
-OR-
(pubkey-chain) addressed-key key-name [ encryption signature ]
The key ( key-name ) from the remote peer can be identified as the fully qualified domain name ( named-key ) or as the IP address ( addressed-key ). Use the encryption keyword if the remote peer has a special-purpose key for encryption, or signature if it has a special-purpose key for signatures. If the remote peer is using general-purpose RSA keys, don't use either keyword.
(Optional) Manually configure a remote peer's IP address:
(pubkey-key) address ip-address
Identify a remote peer's IP address only if its host name can't be resolved or if it has only one interface configured for IPSec.
Specify the remote peer's public key:
(pubkey-key) key-string key-string
The RSA public key is key-string (hexadecimal format). This string is very long and can take several lines of typing to enter. You can press the Enter key at the end of a line and continue entering values after the next "pubkey" command-line prompt. It is usually more accurate to copy and paste the key string from another terminal emulator that has displayed the remote peer's public key. At the end of the key string, use the quit keyword to end key entry.
("Preshare" method) Configure preshared keys.
Enter the preshared key:
(global) crypto isakmp key key-string { address hostname } { peer-address peer-hostname }
The preshared key is entered as key-string (up to 128 alphanumeric characters) on both the local router and the remote peer. The key string must be identical on both peers. The key is associated with the remote peer, either by its address peer-address (if the ISAKMP identity was set to address in Step 4b) or by its hostname peer-hostname (if the ISAKMP identity was set to hostname ).
NOTE
It is good practice to use a unique preshared key between every pair of IPSec peers. When entering the preshared key into the router configurations, use an out-of- band channel (telephone, fax, modem dialup, and so forth) so that the secret key is not revealed as cleartext on the network.
(Optional) Use IKE Mode.
Define a pool of "internal" or protected IP addresses to hand out:
(global) ip local pool pool-name start-address end-address
An address pool named pool-name (a text string) is created, containing a range of IP addresses from start-address to end-address. These addresses should belong to an unused subnet on the protected side of the VPN tunnel. A remote peer then receives an internal network address for its tunnel endpoint.
Enable IKE mode negotiation:
(global) crypto isakmp client configuration address-pool local pool-name
IKE uses the address pool named pool-name (a text string) to assign tunnel endpoint addresses to peers. IKE mode can be started by the local router (also called gateway-initiated ) or by the remote client peer ( client-initiated ).
IKE is configured on the router named hq-router in domain mydomain.com. Two ISAKMP policies are defined. The first policy to be matched against required 3DES encryption and the use of a CA (rsa-sig) to authenticate a peer. The second policy requires DES encryption and can use preshared keys to authenticate a peer.
The CA is defined with a URL and is called mydomain. Before you use the CA for IKE, the CA must be authenticated (the CA sends a self-signed certificate to the router). Then the router must be enrolled with the CA (the CA sends a certificate for the router itself).
Finally, a preshared key is defined for a peer at address 192.168.219.1.
(For clarity, this example contains only the IKE portion of the configuration. This same configuration is built upon in Section 13-10, where the remaining IPSec commands are added.)
hostname hq-router ip domain-name mydomain.com ip name-server 4.2.2.1 ip name-server 4.2.2.2 crypto isakmp policy 10 encryption 3des authentication rsa-sig crypto isakmp policy 20 encryption des authentication pre-share lifetime 900
NOTE
At this point, the crypto key generate rsa command should be run from the EXEC- level prompt.
crypto ca identity mydomain enrollment url http://ca.mydomain.com:80 crl optional
NOTE
At this point, the crypto ca authenticate mydomain command should be run from the EXEC-level prompt. This requests the CA's self-signed certificate. As soon as the CA sends it, the certificate is added to the configuration as something like this:
crypto ca certificate chain mydomain certificate ca 01 308201E5 ... quit
After that, the crypto ca enroll mydomain command can be run from the EXEC-level prompt. This requests a certificate from the CA for the local router. As soon as the CA approves and returns the certificate, it too is added to the configuration as something like this:
certificate 08 308201B2 ... quit
crypto isakmp key secretvpn1 address 192.168.219.1