Define the IKE Phase 1 Policy

The importance of IKE Phase 1 is that it provides the negotiation to create a secure channel through which the Phase 2 negotiation can take place. You must consider several items when determining the IKE Phase 1 policies. Following is a list of each item with its specific purpose:

• Select a key distribution method This item is usually determined by the expected size of the network. For networks that only require a few VPN peers, you can manually distribute the keys (configure each peer manually). For large networks, it is recommended to use a certificate authority (CA) server. This method allows for significant growth because a trusted CA identifies each IPsec peer. If you are not manually distributing the keys, you need to implement the ISAKMP to support the method of key distribution you have selected.

• Select an authentication method There are several ways to configure the routers to authenticate themselves during Phase 1 of the IKE negotiation when establishing the SA. The configuration to be used is usually determined by the number of VPNs connected to the router and how dynamic the network environment will be. Three different configuration types are used:

- Preshared keys If your organization only requires VPN connectivity with few locations, you might want to use a static configuration on the router. This static configuration is referred to as preshared keys because the keys are manually configured on both peers. Preshared keys are alphanumeric keys (similar to passwords) configured on each router and must match exactly for the routers to negotiate the connection. Management of multiple VPN connections using preshared keys can become cumbersome as the number of connections grows.

- RSA signatures RSA is a public key cryptography system using digital certificates authenticated by RSA signatures.

- RSA-encrypted nonces An RSA nonce is a random value generated by the peer that is encrypted using RSA encryption. This method requires you to configure the RSA public key and designate the peer. This method is more secure because a different nonce is created with every negotiation.

• Identify the ISAKMP peer The ISAKMP peer is the router at the other end of the VPN connection that is functioning as the termination point. It is the device that you negotiate with to create the VPN tunnel. The IPsec peer is identified either by IP address or host name.

• Select the ISAKMP policies for the connection It is important that the ISAKMP policies for both peers match. If the configurations differ on each peer, they cannot negotiate the VPN connection. You can configure multiple policies on each router, however, because each router will search for a matching policy. The following items must be determined when selecting the ISAKMP policies:

- Message-encryption algorithm Cisco IOS VPN routers support two encryption algorithms:

Data Encryption Standard (DES) DES is a 56-bit symmetric encryption algorithm. It uses a 64-bit block of plain text and converts it into cipher text of the same size, encrypting it with a secret key. The key length is also 64 bits, but 8 bits are used for parity, leaving the effective key length at 56 bits. Although still widely used, DES is a somewhat outdated algorithm and should not be used if your data is highly sensitive. It is commonly used for VPN connections to locations outside the United States that cannot purchase higher levels of encryption because of U.S. technology export policies.

Triple Data Encryption Standard (3DES) 3DES is a 168-bit symmetric encryption algorithm. 3DES just applies three different phases of DES, effectively tripling the key length to 168 bits. The data is encrypted using three stages of DES using a different 56-bit key for each stage.

- Message-integrity (hash) algorithm The hash algorithm converts message input into a fixed-length output called the message digest . The message digest is then put into a digital signature algorithm, and the output becomes a digital signature for the message. Because the message digest is usually much smaller than the actual message, it is more efficient to sign the digest rather than the message itself. Keyed-Hashing for Message Authentication (HMAC) is a variant that provides an additional layer of security by performing additional cryptographic keying and a secret key for calculation and verification of the message authentication values. HMAC is a variant that can be added to the supported hash algorithms. Cisco IOS VPN routers support two hash algorithms:

Secure Hash Algorithm 1 (SHA-1) The output of SHA-1 is 160 bit. Because the output is larger than MD5, SHA-1 is considered to be more secure; however, it requires more CPU cycles to process.

Message Digest 5 (MD5) The output of MD5 is 128 bit. MD5 is slightly faster to process because of its smaller message digest.

- Peer-authentication method This is the method that each peer uses to authenticate itself to the other peer. The three methods are explained in the previous section (preshared keys, RSA signatures, and RSA-encrypted nonces).

- Diffie-Hellman key exchange Diffie-Hellman is a public key cryptography protocol used between two IPsec peers to derive a shared secret over an unsecured channel without transmitting it to each other. There are seven Diffie-Hellman groups with varying key lengths. This chapter focuses on the first two Diffie-Hellman groups because they are currently the most commonly used on VPN enabled routers: group 1 is 768 bits, and group 2 is 1024 bits.

- IKE SA lifetime The SA lifetime is the time that each system waits before initiating another key exchange. This allows the systems to constantly renegotiate the connection, greatly reducing any chance of an unauthorized listener being able to decrypt the connection.

Table 19-2 lists the IKE policy parameters that can be used when determining the IKE Phase 1 policies.

Encryption algorithm DES

3DES, AES, AES-192, AES-265

Hash algorithm


Authentication method


RSA signature

RSA-encrypted nonce

Diffie-Hellman key exchange

Group 1

Group 2

Group 5

SA lifetime

86,400 seconds

<86,400 seconds

0 0

Post a comment