IKE Phase 1: Management Connection

This book focuses on setting up IPSec connections that use only ISAKMP/IKE. The combination of these two protocols provides the framework for building IPSec connections, including the sharing of keying information for algorithms and functions.

The Internet Security Association and Key Management Protocol (ISAKMP), defined in RFC 2408, defines the message format, the mechanics of a key-exchange protocol, and the negotiation process to build an SA for IPSec. However, ISAKMP does not define how keys should be managed or how they are shared between the two IPSec peers. IKE is used to solve these two problems.

Internet Key Exchange (IKE), defined in RFC 2409, negotiates security protocols and the exchange of keying information to build an SA to a remote IPSec peer. IKE is a hybrid protocol, combining ISAKMP and the Oakley and Skeme key exchange methods. IKE completes the ISAKMP protocol, filling in what ISAKMP does not define or do. Oakley and Skeme have five defined key groups. Of these groups, Cisco routers supports three groups. Group 1 uses a 768-bit key, group 2 uses a 1024-bit key, and group 5 uses a 1536-bit key for keying information. For the actual key creation, IKE uses Diffie-Hellman (DH) to create the public/private key combination that will allow the creation of an SA between two IPSec peers. DH is used to share information securely between the two peers before any management connection in IKE Phase 1 is built.

One optional solution is to not use ISAKMP/IKE to build IPSec connections. If you choose this route, you need to configure manually everything that ISAKMP/IKE does dynamically; however, this is beyond the scope of this book.

Enabling ISAKMP/IKE

On a Cisco router that has IPSec as a component of the Cisco IOS, ISAKMP/IKE is enabled by default. If your router is not using IPSec, I recommend that you disable it with the following command:

Router(config)#  no crypto isakmp enable

You easily can re-enable it by removing the no parameter from this command.

Defining IKE Phase 1 Policies

To move data between two devices, three connections are built between the two IPSec peers:

• One bidirectional IKE Phase 1 connection? I commonly refer to this as the management connection. The peers use this connection to negotiate policy information for the data connections that will be built in IKE Phase 2.

• Two unidirectional IKE Phase 2 connections? I commonly refer to these as the data connections. To move data between two peers, two unidirectional connections are built: from peer A to peer B, and from peer B to peer A. These connections protect the actual user's data, such as a Telnet, e-mail, or FTP traffic.

Policy Commands

To build an IKE Phase 1 management connection, you must specify policies that will define how this connection is to be protected. If all peers have the same capabilities, you need only one policy that will be applied to all peers. However, if you have two peers with different capabilities (for example, one supports 3DES encryption and the other supports DES), you must create two separate policies.

You define these items in your IKE Phase 1 policies:

• The type of authentication (authentication command)

• The encryption algorithm (encryption command)

• The DH group number (group command)

• The hash function (hash command)

• The lifetime for the management SA that is being negotiated (lifetime command)

Creating a Policy

To create an IKE Phase 1 policy, use the following command:

Router(config)# crypto isakmp policy priority_#

Router(config-isakmp)#

The crypto isakmp policy command creates an IKE Phase 1 policy, where the priority_# parameter specifies the policy number: It binds together the policy statements for this policy. This number can range from 1 to 10,000. The lower the number is, the higher the policy priority is. This number plays an important role in determining which policy should be used between two peers. When determining which policy to use, both IPSec peers share their list of IKE Phase 1 policies with the other. These policies then are compared from highest to lowest priority (where 1 is the highest-priority policy, if configured). The first policy that the peer accepts is the one used for the current management session. If no policy is found to match between the two peers, a management connection is not built and, therefore, no data connections are built.

Specifying Policy Parameters

You probably noticed in the last coding example that the crypto isakmp policy command takes you into a subconfiguration mode, where you enter your specific IKE Phase 1 policies. The priority_# of this command groups the policy statements, similar to what a number or name does for an ACL. Here are the policy commands that you can define for your IKE Phase 1 management connection:

Router(config)#  crypto isakmp policy priority_#

Router(config-isakmp)# authentication {rsa-sig | rsa-encr | pre-share}

Router(config-isakmp)# encryption {des | 3des | aes | aes 192 | aes 256}

Router(config-isakmp)# hash {md5 | sha}

Router(config-isakmp)# group {1 | 2 | 5}

Router(config-isakmp)# lifetime #_of_seconds

The authentication command specifies the type of authentication to use when validating the identity of the remote IPSec peer. There are three choices. rsa-sig specifies that certificates and a Certificate Authority (CA) are used for authentication (this is the default method). rsa-encr specifies that RSA encrypted nonces are used. pre-share specifies that a single preshared key is used. RSA signatures are the most secure and scalable, but this is also the slowest method and the most difficult to set up initially. If you specify rsa-encr, you need to generate your own public and private key combination, as well as give your public key to the remote peer and manually configure the remote peer's public key on your router. Configuring preshared keys is the simplest method; however, because it uses only a single key for authentication, it should be used only for a small number of L2L connections. The configuration of these authentication methods is discussed later in the "IKE Phase 1 Peer Authentication" section.

The encryption algorithm used to encrypt the information for the management connection is configured using the encryption command. DES uses a 56-bit key, and 3DES uses a 168-bit key. Depending on the type, AES uses either a 128-, 192-, or 256-bit key. The default encryption algorithm, if not specified, is des, which is the weakest form of encryption; AES is the strongest.

Hashing functions are used to verify that packets are not altered by a device between the two peers. Hashing functions create an integrity checksum value that the remote end uses to validate that the packet contents have not been tampered with. Two hashing functions are supported: MD5 (128-bit signature) and SHA (160-bit signature). The signature created by these functions is the ICV value. SHA is more secure, but MD5 is quicker in its computation. The default is SHA if you omit the hash command from your policy configuration.

Cisco IOS routers support three DH key groups: 1, 2, and 5. Group 1 keys are 768 bits in length, group 2 keys are 1024 bits, and group 5 keys are 1536 bits. The default is group 1 if you do not configure the group command. Also, the default lifetime of the management connection is 86,400 seconds (1 day); you can change this value with the lifetime command. By default, when making a connection to a remote peer, the peer that has the lowest time value is used.

Policy Verification

To view your IKE Phase 1 policies, use the show crypto isakmp policy command, as shown in Example 19-1.

Example 19-1. Using the show crypto isakmp policy Command

Router# show crypto isakmp policy

Protection suite priority 1

  encryption algorithm:   DES - Data Encryption Standard (56 bit keys)

  hash algorithm: Message Digest 5

  authentication method:  preshared Key

  Diffie-Hellman Group:   #2 (1024 bit)

  lifetime:       86400 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

In Example 19-1, the highest-ranking policy (the priority is 1). The encryption algorithm is DES, the default; the hash function is MD5; the authentication method is preshared keys; the DH group is 2; and the lifetime is 1 day. Note that the router has a default ISAKMP policy that is preconfigured on the router; this is shown at the bottom of the output of Example 19-1.