IKE and ISAKMP

Internet Key Exchange and the Internet Security Association and Key Management Protocol were designed to allow crypto endpoints to dynamically exchange keys and negotiate security associations. Unlike the examples that we've discussed that use manual SAs, IKE SAs can be established on the fly and torn down at a time period negotiated. As we had discussed before, IPsec specifies two SAs. The type of SA is the IPsec SA, which we reviewed in fair detail in examples 2-1 through 2-9. The second one, which we have yet to discuss in great detail, is the IKE SA. It is over this SA, the one that IKE establishes, that IPsec can now dynamically establish and tear down its SA between crypto endpoints.

IKE and ISAKMP Terminology and Background

ISAKMP was originally defined as a framework implementing two critical services to growing IPsec environments, which are dynamic establishment of security associations and dynamic exchange of cryptographic keys over a secure channel. As such, ISAKMP defines procedures for:

• Crypto endpoint authentication procedures

• IPsec SA negotiation, maintenance, and timeout

• Cryptographic key generation and exchange techniques (Diffie-Hellman)

• Threat mitigation (antireplay, DoS mitigation techniques)

However, ISAKMP is a framework for delivering these servicesit does not define the protocol for them. As such, ISAKMP is designed to be key-exchange independent, and supports a number of key exchange protocols. In the IPsec world, we are concerned with one of these key exchange protocolsIKE.

The protocol used for key exchange and SA negotiation in IPsec today, IKE, uses the framework outlined in ISAKMP to deliver upon authentication, SA negotiation, key generation and exchange, and native threat mitigation services. IKE represents a number of key exchange and SA negotiation protocols (Oakley and SKEME) that have been combined to fit within the ISAKMP framework. Oakley is a key exchange and management protocol that allows for the exchange of multiple keys and their corresponding services. SKEME supplies anonymity and nonrepudiation using its own key exchange method. IKE combines the strengths of Oakley and SKEME in a comprehensive protocol for establishing a secure channel over which to establish IPsec SAs.

As IKE is the ISAKMP protocol for IPsec, we will be discussing Oakley and SKEME only insofar as their relevance to IKE. In-depth coverage of Oakley and SKEME is outside of the scope of this work.

IKE SA Negotiation and Maintenance

The concept of an IPsec SA lifetime does not exist when using manual keys. The security parameters that comprise an IPsec SA are all manually defined. This is not the case with IKE/ISAKMP. IKE dynamically creates IPsec SAs upon the transmittal of traffic matching the IPsec policy. This is done by exchanging a series of messages over UDP port 500. IKE allows the crypto endpoints to negotiate a lifetime for each SA. This enables network administrators to use their SADB more efficiently through establishing security associations only when needed and automatically tearing down stale SAs at the end of their agreed-upon lifetime. Example 2-10 illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE.

Example 2-10. Charlie Specifies a Lifetime for His IPsec SAs, Negotiated with James During IKE

Charlie# Charlie#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Charlie(config)#crypto isakmp policy 10 Charlie(config)#lifetime ?   <60-86400>  lifetime in seconds

IPsec Diffie-Hellman Shared Secret Key Generation Using IKE

As we've discussed already in our overview of cryptographic components, IPsec uses symmetric key encryption. This requires the use of a shared secret key to exist on both crypto endpoints. We've seen examples of how one can preplace the session key on each endpoint to establish IPsec SAs. However, this approach presents a number of problems affecting the administrative overhead, performance, and security of an IPsec VPN:

• Session keys for every SA (inbound and outbound at each crypto endpoint) for every IPsec tunnel. This presents greatly increased administrative overhead, especially if crypto session keys are to be changed regularly for security purposes.

• IPsec SAs will never time out. If IPsec SAs are not in use for extended periods of time, they cannot time out and reinitiate upon matching policy traffic. As a result, manual session key configuration requires that the crypto endpoints maintain all of the SAs configured in the SADB, as opposed to just those in use with IKE.

• Session keys never change, unless they are manually altered. The more frequently one changes the session keys, the less likely they are to be compromised.

• Manual keying negates antireplay techniques between crypto peers.

• There is no CA support for manual session keys.

As we've discussed, IKE exists, at least in part, as an alternative that is designed to increase scalability in IPsec VPN designs. Because keys are no longer manually configured in IKE, they must be dynamically created. IKE uses the Diffie-Hellman algorithm to dynamically create session keys exchanged over IKE. Diffie-Hellman is configured as part of the ISAKMP policy. The default MODP is 768 bits in length, denoted by group 1. Administrators have the option to choose between 3 different MODP for Diffie-Hellman secret key generation, as illustrated in Example 2-11.

Example 2-11. ISAKMP Policy Diffie-Hellman Configuration (Charlie Selects DH MODP 2)

Charlie# Charlie#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Charlie(config)#crypto isakmp policy 10 Charlie(config-isakmp)#group ?   1  Diffie-Hellman group 1   2  Diffie-Hellman group 2   5  Diffie-Hellman group 5 Charlie(config-isakmp)#group 2 Charlie(config-isakmp)#end Charlie#

Note

Diffie-Hellman group 5 was created for ciphers requiring larger keys, such as AES. It is supported only in IOS releases later than 12.2. Like RSA keys, larger Diffie-Hellman MODPs ensure a stronger Diffie-Hellman secret key. However, as Diffie-Hellman MODP values get larger, they become more computationally expensive.

Consider once more the exchange between James and Charlie listed in Figure 2-22. Both want to exchange secure keys across the network but need an automated method to do so. As such, instead of manually configuring a shared secret key such as "abcd1234abcd1234," or some other password that could be compromised when being transported across the untrusted media between them, James and Charlie derive shared secret keys together using the Diffie-Hellman algorithm.

Figure 2-22. James and Charlie Derive Shared Secret Keys Using Diffie-Hellman

The following order of operations outlines the exchange that James and Charlie will execute when deriving shared secret keys using Diffie-Hellman, as illustrated in Figure 2-22:

1.	Charlie and James derive two large, random numbers P and Q, and exchange them with one another. Usually, this is done in a master-slave relationship, where one party will derive the two numbers to be used in the DH exchange and forward them over to its peer. In this case, Charlie derives the numbers and exchanges them with his peer, James.
2.	James selects a large random number, A, which he keeps private. He uses this number to calculate the value of A*, which is defined by the equation A* = (Q ^ A) mod (P). Once he has finished his calculation, James shares the value of A* with Charlie.
3.	Charlie selects a large random number B, which he keeps private. He uses this number to calculate the value of B*, which is defined by the equation B* = (Q ^ B) mod (P). Charlie then shares this value with James.
4.	James and Charlie derive their shared, secret (Diffie-Hellman) keys from the values of B* and A*, respectively. Charlie uses the equation DHS = (A* ^ Q) mod P and James uses the equation DHS = (B* ^ Q) mod P to derive the shared key, commonly referred to as a Diffie-Hellman Secret Key.
5.	Now that James and Charlie have a shared secret key, they can choose one of many effective symmetric key encryption algorithms to use. Examples of such symmetric encryption transforms include DES, 3DES, and AES, which will be explored later in this chapter.

In the example used above, small numbers are used for illustration purposes only. In reality, the effectiveness of the Diffie-Hellman algorithm depends largely on the size of the values selected for P, Q, A, and B mentioned above. As with RSA encryption, P and Q must be large, randomly selected prime numbers. A and B can be any large, randomly selected numbersthey do not have to be prime.

A Diffie-Hellman derived keypair presents two mathematical tasks to would-be attackers who wish to compromise the shared secret key's confidentiality. First, an attacker must be able to derive A from seeing Q ^ A. This would require the computation of a discrete algorithm. The second strength is similar to one of RSA's key strengthsthe attacker must be able to factor two large prime numbers. Hence, Diffie-Hellman values for P and Q share the same requirement as an RSA key modulusit must be large and random. Diffie-Hellman does not typically specify a modulus size directly. Instead, the modulus of a Diffie-Hellman key is referred to as the Diffie-Hellman group. There are four different Diffie-Hellman Groups that yield a DHS that is approximately equal to a 7080-bit symmetric key in strength.

Note

Existing Diffie-Hellman groups have traditionally accommodated commercially available symmetric cryptographic exchanges such as DES and 3DES. But, because the AES transform supports up to 256-bit encryption, stronger symmetric keys are required. Hence, demand has been sparked for a fifth Diffie-Hellman group. RFC 3526 describes the development of DH group 5 in more detail.

Unless attackers can leap the mathematical hurdles described above, the DH secret key can be shared between the peers confidentially without an attacker being able to determine its value. IKE provides for additional confidentiality in the exchange of security parameters by encrypting the communication sessions over IKE. The encryption cipher to be used for encrypting the IKE channel is configured in Example 2-12, using the Diffie-Hellman shared secret as the symmetric encryption key on each peer.

Example 2-12. James Configures IPsec and IKE Encryption Ciphers.

James# James#configure terminal Enter configuration commands, one per line. End with CNTL/Z. James(config)#crypto isakmp policy 10 James(config-isakmp)# encryption 3DES James(config-isakmp) end James#

Tip

The Diffie-Hellman keys used for encrypting IKE can also be used as the shared session key for the cipher specified in the IPsec transform. For stronger security, another new Diffie-Hellman key can be created over IKE for use with IPsec transform ciphers.

IKE Authentication Services

In an IPsec VPN using ISAKMP, IKE will be the channel over which security parameters are exchanged for IPsec SA negotiation. As such, it is absolutely critical that IKE SAs are established securely. To do this, IKE offers a number of robust authentication mechanisms to ensure that crypto endpoints are not exchanging information with would-be attackers instead of valid endpoints. Cisco IPsec VPN crypto endpoints support all of IKE's supported authentication protocols, which include:

• Pre-Shared Keys

• RSA Encryption (Encrypted Nonces)

• RSA Signatures (X.509 certificate basedrequires X.509 CA)

Pre-Shared Keys

For smaller networks on which keys can be manually defined, IKE preshared keys (PSKs) can be used. PSKs are manually defined in the IKE policy of each crypto endpoint. Once crypto and ISAKMP policies are attached to active crypto interfaces, IKE attempts to exchange PSKs with the appropriate crypto peer, or IPsec tunnel endpoint.

Note

A defined, static PSK may specify a single peer to share a key with. Alternately, a range of peers can be specified for a single key using wildcard subnet masks in the ISAKMP key definition. A single IKE PSK defined for use with multiple peers using wildcard subnet masks is typically referred to as a wildcard preshared key.

To guarantee authenticity of this message exchange, IKE appends a message digest to the key through a user-defined hash algorithm (MD5 or SHA-1). Example 2-13 shows the required IKE configurations on James and Charlie.

Example 2-13. IKE Configurations for James and Charlie Using PSKs

Charlie# Charlie#configure terminal *Mar  6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console Enter configuration commands, one per line.  End with CNTL/Z. Charlie(config)#crypto isakmp key unctarheels address 10.1.1.1 Charlie(config)#crypto isakmp policy 10 Charlie(config-isakmp)# encryption 3des Charlie(config-isakmp)# authentication pre-share Charlie(config-isakmp)# group 2 Charlie(config-isakmp)# lifetime 50000 Charlie(config-isakmp)#end Charlie#configure terminal Enter configuration commands, one per line.  End with CNTL/Z. Charlie(config)#crypto map IPSECMAP-3 10 IPsec-isakmp % NOTE: This new crypto map will remain disabled until a peer         and a valid access list have been configured. Charlie(config-crypto-map)#set peer 10.1.1.1 Charlie(config-crypto-map)#set transform-set IPSECVPN-2 Charlie(config-crypto-map)#match address 101 Charlie(config-crypto-map)#end Charlie# James(config)#crypto isakmp policy 10 James(config-isakmp)# encryption 3des James(config-isakmp)# authentication pre-share James(config-isakmp)# group 2 James(config-isakmp)# lifetime 50000 James(config-isakmp)#exit James(config)#crypto isakmp key unctarheels address 10.1.1.2 James(config)#crypto map IPSECMAP-3 10 IPsec-isakmp % NOTE: This new crypto map will remain disabled until a peer         and a valid access list have been configured. James(config-crypto-map)#match address 101 James(config-crypto-map)#set transform James(config-crypto-map)#set transform-set IPSECVPN-2 James(config-crypto-map)#set peer 10.1.1.2 James(config-crypto-map)#end

While pre-shared keys are effective in smaller, trusted environments, the obvious pitfalls associated with manual keying exist. Somebody could verbally compromise the key, or the key could be a simple key that is easily guessed (administrator's home town, favorite baseball team, birthday, and so on). Because all peers share the same wildcard PSK, that key must be changed on all peers using that key, which can lead to increased administrative overhead. As such, wildcard PSKs have inherent security flaws primarily related to inability to effectively manage the eviction of a once-trusted IPsec peer in the group and are generally not recommended without the use of added authentication capabilities such as IKE extended authentication (x-Auth). IKE x-Auth and wildcard PSKs are discussed in greater detail in Chapter 12. In addition to IKE PSKs with x-Auth, IKE incorporates options for stronger keying in environments that require stronger security. Two such options are RSA Encryption (nonces), and RSA Signatures (CA-signed certificates), which enable administrators to have the crypto endpoint dynamically generate a pair of cryptographic keys for authentication.

Remember that IKE is designed to enable the setup and teardown of SAs dynamically, which means that key exchange will be done more often. As such, the low computational overhead that PSK authentication offers makes it an attractive design option when their VPN performance is the top design criterion.

RSA Encryption (Encrypted Nonces)

A nonce is a random, or "nonsense," number. IKE can be configured to use the RSA cryptographic algorithm to verify the identity of peers before continuing IKE Phase I negotiation. Nonces are used to add randomness to the exchange, making it harder to crack. Figure 2-23 illustrates the creation and exchange of RSA encrypted nonces.

Figure 2-23. RSA-Encrypted Nonce Authentication

When using the RSA encrypted nonce method of ISAKMP authentication, the cryptographic endpoints follow the following series of exchanges, as numbered in Figure 2-23:

1.	Initiator (James) and Responder (Charlie) generate an RSA public and private keypair.
2.	Initiator and Responder exchange public keys.
3.	The Initiator creates a nonce and forwards it to the Responder.
4.	The Responder encrypts the nonce with the Initiator's public RSA key (obtained in Step 1), and forwards the ciphered message to the Initiator.
5.	The Initiator decrypts the ciphered nonce from the Responder. If the value matches the original nonce, the Responder has authenticated with the Initiator (Hash_I).
6.	The Responder creates a nonce and forwards it to the Initiator.
7.	The Initiator encrypts the nonce with the Initiator's public RSA key (obtained in Step 1), and forwards the ciphered nonce to the Responder (Hash_R).
8.	The Responder decrypts the ciphered message with its own private RSA key. If the decrypted nonce matches the original nonce sent from the Responder, the Initiator has authenticated with the responder.

Note

In practice, RSA cookies, Diffie-Hellman secrets, and other items specific to the identity of each crypto endpoint are combined with the nonce before they are ciphered at Initiator and Responder. The output of the cipher is usually noted as "Hash_I" and "Hash_R" for Initiator and Responder, respectively.

RSA Signatures and X.509 Certificates

RSA signatures are a form of Digital Signature, the operation of which is described previously in Figure 2-8. RSA signatures, however, combine the strength of a standard Digital Signature with the strength of the RSA encryption algorithm, also described above, to yield an RSA signature. Crypto-enabled network devices often will use RSA signatures when exchanging X.509-based certificates with an X.509 compliant Certificate Authority (CA).

ITU-T X.509 Certificates and CAs were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a CA, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. In order to effectively exchange this information, the CA must communicate certificates in a standard format that is agreed upon with its peers. ITU-T X.509 formatted certificates are commonly accepted as the standard for this type of public key cryptosystem.

Note

X.509 is discussed in greater detail in Chapter 11, "Public Key Infrastructure and IPsec VPNs." Figure 11-2 illustrates the format of an X.509v3 certificate.

Certificate Authorities enable network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into one source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations. The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that enables enhanced scalability in the number of encrypting/decrypting peers.

Endpoints using RSA signatures for IKE authentication will enroll using Simple Certificate Enrollment Protocol (SCEP), as defined by the X.509 standard. The transport used to distribute certificates in the exchange previously described uses a client-server application such as HTTP, FTP, or Lightweight Directory Access Protocol (LDAP). Cisco Systems manufactures a full set of network devices and appliances that use X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators.

Note

Public Key Infrastructures using the RSA Signatures method of IKE authentication are discussed in greater detail in Chapter 11, including design concepts and a more detailed description of the Endpoint-CA relationship within a PKI. The mechanics for configuring and troubleshooting IKE authentication with RSA-sigs is also discussed in greater detail in Chapter 11. The process of enrolling VPN endpoints in to the PKI using a CA and RSA-sigs is discussed in greater detail in Chapter 11 and summarized in Appendix A of this text.

IKE Phase I Negotiation

As we've discussed, the goal of IKE is establishment of a secure channel over which to exchange security parameters, such as those that comprise IPsec SA. This negotiation is referred to as Phase I of IKE negotiation. In order to complete IKE Phase I negotiation, and hence to establish a secure channel for security parameter negotiation, both peers must agree on the following parameters:

• Authentication Method

• Authentication Hash Algorithm

• Encryption Cipher

• Diffie-Hellman Group Number (MODP size)

Once these methods are agreed upon, the peers begin the negotiation process. The result of Phase I IKE negotiation is the establishment of an ISAKMP SA. Once ISAKMP SA has been negotiated between crypto endpoints, an authenticated channel for confidential establishment IPsec SAs can be established.

Main Mode

Main mode IKE negotiation provides identity protection between the two crypto endpoints. It does, however, consume more resources than aggressive mode. Likewise, main mode involves a more complicated exchange than aggressive mode. Main mode enables two crypto endpoints to establish an ISAKMP SA securely, without ever exchanging the identity of either crypto endpoint in clear text. To do this, IKE in Main Mode follows three steps with a set of three messages. Consider the main mode exchange between James and Charlie in Figure 2-24.

Figure 2-24. ISAKMP Negotiation in Main Mode

The following sequence of events describes the negotiation of the IKE SA in main mode as illustrated in Figure 2-24:

1.	Charlie and James exchange to agree upon a set of security parametersencryption cipher, authentication hash, authentication method, and Diffie-Hellman Group number. James initiates the process by sending a list of available proposals. Charlie responds by selecting a proposal from James' list of options and replying to James.
2.	Charlie and James exchange Diffie-Hellman public keys and nonces. The two parties are able to derive shared Diffie-Hellman keys from this information.
3.	Charlie and James are now able to authenticate each other. Now that they have shared session keys derived from Diffie-Hellman exchange, and an agreed-upon cipher, the authentication messages can be encrypted. This allows for a purely confidential exchange when establishing ISAKMP SA, as identity messages are never sent in the clear and are sent with appended hashes for message authentication.

Tip

IOS always attempts to negotiate IKE Phase I in main mode before attempting aggressive mode. However, IOS can be configured not to attempt aggressive mode upon failure to negotiate main mode. IOS will respond to crypto endpoints initiating aggressive mode exchanges.

Aggressive Mode

Unlike IKE negotiation in main mode, which involves three exchanges, aggressive mode involves only two exchanges. As with main mode, aggressive mode exchange involves an exchange of messages targeted at agreeing on encryption cipher, authentication hash, authentication method, and Diffie-Hellman group number. Unlike main mode, in aggressive mode the sender's and receiver's identities are not encrypted because they are sent concurrently with cryptographic elements needed for encryption in the first IKE aggressive mode exchange. In an aggressive mode exchange, the Diffie-Hellman group number and encryption cipher are negotiated only in the IPsec SA. Once a security proposal has been agreed upon, the two crypto endpoints authenticate each other in clear text.

In summary, IKE aggressive mode exchanges all of the information that IKE main mode does, but instead of using a 3-step exchange, aggressive mode uses a 2-step exchange. Condensing the number of exchanges weakens the security of the process, as the sender's and receiver's identities are exchanged in cleartext. Figure 2-25 illustrates the negotiation of an IKE SA using aggressive mode.

Figure 2-25. IKE Exchange in Aggressive Mode

Aggressive mode is useful for VPNs that require rapid ISAKMP SA establishment. They are also useful on crypto endpoints with low processing resources, such as software-based VPN clients on low-end workstations. The obvious tradeoff is that authentication information in ISAKMP SA negotiation is performed in the clear, and is only protected by the insertion of a message digest using the selected authentication hash algorithm.

By default, Cisco IOS will attempt to negotiate Phase 1 using main mode. If main mode fails, the default behavior is to automatically try to negotiate the SA using aggressive mode. Cisco IOS can be configured to disallow the use of aggressive mode as an option for Phase 1 negotiation, as illustrated in Example 2-14.

Example 2-14. Disallowing Aggressive Mode as an Option for Phase 1 Negotiation

James(config)#crypto isakmp aggressive-mode disable

IKE Phase II Negotiation

The goal of IKE Phase II negotiation is establishment of IPsec SAs between two endpoints. IKE uses Diffie-Hellman key exchange to negotiate the shared secret key to be used in the encryption cipher specified in the IPsec transform set. The IPsec SA can include the shared Diffie-Hellman key used to encrypt the ISAKMP SA, or it can be renegotiated over the ISAKMP SA during Phase II negotiation.

Quick Mode

IKE Phase II negotiation is done in only one mode, quick mode. Due to the fact that Phase II negotiation's goal is establishment of an IPsec SA, quick mode exchange must inform both crypto endpoints of the IPsec mode to use ESP and AH and all other relevant variables needed to populate the IPsec SA. To do this, quick mode uses a two-step exchange composed of four messages sent between initiator (James) and responder (Charlie), as illustrated in Figure 2-26.

Figure 2-26. IPsec Quick-Mode Negotiation

After IKE Phase II negotiation has successfully completed quick mode exchange, both crypto endpoints should have three established security associations in their SADB:

• ISAKMP SA This is a bidirectional SA that is used to dynamically establish a secure channel for the negotiation of IPsec SAs.

• Outbound IPsec SA This unidirectional SA is used to provide protection services offered by IPsec to traffic that is to be transmitted to the remote tunnel endpoint, identified by the SPI within the IPsec header.

• Inbound IPsec SA This unidirectional SA is used to process inbound IPsec traffic from from a remote crypto endpoint. Again, this traffic is identified by the SPI that was inserted into the IPsec header by the transmitting IPsec endpoint.

PFS

PFS guarantees that session keys are generated independently from previous session keys. With PFS enabled, would-be attackers are unable to use old session keys that have been compromised to compromise the integrity and confidentiality of current and future session keys. PFS does this by forcing renegotiation of shared Diffie-Hellman keys whenever a new negotiation of ISAKMP and IPsec SAs occurs. In doing so, PFS offers greater confidentiality, but also consumes more processing resources on the crypto endpoints, elongating the time that it takes to establish ISAKMP and IPsec SAs. As PFS is a feature based on Diffie-Hellman, the strength of PFS relies on the prime modulus size used to derive the shared secret keys. There are three prime modulus sizes offering increasing level of security (groups 1, 2, and 5). PFS is enabled when configuring the IPsec crypto map, as illustrated in Example 2-15.

Example 2-15. Configuring PFS

Charlie#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Charlie(config)#crypto map IPSECMAP-3 10 IPsec-isakmp Charlie(config-crypto-map)#set pfs ?   group1  D-H Group1 (768-bit modp)   group2  D-H Group2 (1024-bit modp)   group5  D-H Group5 (1536-bit modp)   <cr> Charlie(config-crypto-map)#set pfs group5 Charlie(config-crypto-map)#end Charlie#

Note

PFS requires IKE. As such, PFS can be configured only on crypto maps that are configured for IKE/ISAKMP. Crypto maps using manually set session keys do not support PFS.

Dead Peer Detection and IKE Keepalives

Crypto endpoints use IKE keepalives to poll the validity of active ISAKMP SAs. IKE keepalives enable routers to quickly detect when IPsec and ISAKMP SAs become inactive, or stale. This enables the crypto endpoints to optimally maintain the SADB, which also enables greater IPsec SA scalability on crypto endpoints. When a crypto endpoint does not receive three keepalives in a row, it tears down the SAs associated with that peer and initiates IKE Phase 1 negotiation with the next peer referenced in the crypto map. Figure 2-27 illustrates the process of detecting a stale SA with IKE Keepalives.

Figure 2-27. Detecting Stale SAs with IKE Keepalives

Example 2-16 illustrates Kristen's configuration for failover using IKE DPD to a redundantly defined IPsec peer. To do this, Kristen specifies the use of IKE keepalives. If Kristen's primary peer, 10.1.1.2, goes offline, she will attempt to negotiate another IPsec VPN tunnel with 10.1.1.3 after missing three IKE keepalives spaced 10s apart (Example 2-16, line 9). In addition, Kristen must have two peers defined in her crypto map in order to facilitate this failover (Example 2-16, lines 16 and 17). Because Kristen uses IKE PSKs, she must also have the shared secret key defined with both peers (Example 2-16, lines 10 and 11).

Example 2-16. Kristen Uses DPD and IKE Keepalives for VPN High Availability

Kristen Kristen#configure terminal Enter configuration commands, one per line.  End with CNTL/Z. Kristen(config)#crypto isakmp policy 10 Kristen(config-isakmp)#hash sha Kristen(config-isakmp)#authentication pre-share Kristen(config-isakmp)#encryption 3des Kristen(config-isakmp)#exit Kristen(config)#crypto isakmp keepalive 10 Kristen(config)#crypto isakmp key ncstatewolfpack address 10.1.1.2 Kristen(config)#crypto isakmp key ncstatewolfpack address 10.1.1.3 Kristen(config)#crypto map IPSECVPN-1 10 IPsec-isakmp % NOTE: This new crypto map will remain disabled until a peer         and a valid access list have been configured. Kristen(config-crypto-map)#match add 101 Kristen(config-crypto-map)#set peer 10.1.1.2 Kristen(config-crypto-map)#set peer 10.1.1.3 Kristen(config-crypto-map)#set trans IPSECVPN-1 Kristen(config-crypto-map)#end Kristen#

Dead Peer Detection (DPD) refers to a crypto endpoint's ability to detect when one of its peers goes offline. DPD can be useful on highly available peers that are receiving traffic from its remote crypto endpoints. With DPD, crypto endpoints will not send keepalives if they are sending traffic to their peers. This keeps the processing of keepalives relatively low on crypto endpoints and decreases use on links between crypto endpoints.

Configuring ISAKMP

In order to successfully configure two crypto endpoints to establish an ISAKMP SA, the security administrator must instruct the crypto endpoints to accept the appropriate security proposals, apply those ISAKMP security proposals to a crypto map, and apply that crypto map to the appropriate crypto interface or interfaces. The following provides a brief list of tasks to be executed when creating an ISAKMP policy:

Step 1.	Define the ISAKMP policy. Within the ISAKMP policy, define security parameters to be used with ISAKMP provided in the following list: Authentication Method Authentication Hash Algorithm Encryption Cipher Diffie-Hellman MODP Group
Step 2.	Instruct the crypto map to reference ISAKMP policies to negotiate ISAKMP SAs and IPsec SAs.
Step 3.	Apply the crypto map to the appropriate crypto interfaces. This will enable ISAKMP in the router, and will enable ISAKMP and IPsec SA negotiation using IKE on those crypto interfaces.

When ISAKMP policies are referenced in crypto maps, the priority keyword identifies the preference that the initiator expresses to the responder when selecting security proposals in IKE Phase I exchange. In Example 2-17, James requests that ISAKMP policy 20 be selected for IKE Phase I negotiation with Charlie. Charlie will try to accept ISAKMP policy 20, but, because he has no matching security proposal, he will select ISAKMP policy 10. James and Charlie will use ISAKMP policy 20 for IKE Negotiation, as illustrated in Figure 2-28. Example 2-17 provides the ISAKMP policy configuration corresponding to the exchange illustrated in Figure 2-28.

Figure 2-28.

Example 2-17. James and Charlie Use ISAKMP Policies for IKE Negotiation

James# James#configure terminal James(config)#crypto isakmp policy 10 James(config-isakmp)#encryption 3des James(config-isakmp)#authentication pre-share James(config-isakmp)#group 2 James(config-isakmp)#lifetime 50000 James(config-isakmp)#exit James(config)#crypto isakmp policy 20 James(config-isakmp)#hash md5 James(config-isakmp)#authentication rsa-encr James(config-isakmp)#group 5 James(config-isakmp)#exit James(config)#crypto isakmp key unctarheels address 10.1.1.2 James(config)#crypto IPsec transform-set IPSECVPN-1 esp-des James(config)#crypto map IPSECMAP-1 10 IPsec-isakmp James(config-crypto-map)#set peer 10.1.1.2 James(config-crypto-map)#set transform-set IPSECVPN-1 James(config-crypto-map)#match address 101 James(config-crypto-map)#exit James(config)#interface serial2/0 James(config-if)#crypto map IPSECMAP-1 James(config-if)#end James# Charlie# Charlie#configure terminal Charlie(config)#crypto isakmp policy 10 Charlie(config-isakmp)#encryption 3des Charlie(config-isakmp)#authentication pre-share Charlie(config-isakmp)#group 2 Charlie(config-isakmp)#lifetime 50000 Charlie(config-isakmp)#exit Charlie(config)#crypto isakmp key unctarheels address 10.1.1.1 Charlie(config)#crypto IPsec transform-set IPSECVPN-2 esp-des Charlie(config)#crypto map IPSECVPN-1 10 IPsec-isakmp Charlie(config-crypto-map)#set peer 10.1.1.1 Charlie(config-crypto-map)#set transform-set IPSECVPN-2 Charlie(config-crypto-map)#match address 101 Charlie(config-crypto-map)#exit Charlie(config)#interface serial2/0 Charlie(config-if)#crypto map IPSECMAP-1 Charlie(config-if)#end Charlie#

IKE with RAVPN Extensions

There are extensions specified to IKE that can aid in designing certain IPsec VPN models. In this section, we will explore the usefulness of two such extensions in a remote access VPN topology (RAVPN):

• IKE Mode Configuration

• IKE Extended Authentication (x-Auth)

We will use an RAVPN topology in which remote clients with software-based IPsec VPN clients installed use mode configuration for client IP address assignment and IKE x-Auth to enable administrators to provision increased granularity when authenticating client sessions.

Mode Configuration

Using mode config, administrators can dynamically manage RAVPN client addressing, domain names, WINS servers, and DNS servers on the RAVPN concentrator itself. This greatly simplifies administrative overhead of the RAVPN for both network administrators and users. Mode config will provide the RAVPN client with an IP address that will be used as the IP address of the inner ESP or AH header. The client's publicly available address, usually assigned by the clients' ISP, will populate the outer ESP or AH header.

IKE mode config offers a scalable alternative to manually assigning tunneled IP address space to each RAVPN client. With mode config, IP addresses and other parameters are configured on the concentrator and pushed to the clients after they have been authenticated in Phase I negotiation. Mode config does this by dynamically assigning IP addresses from a pool configured on the concentrator and referenced in the ISAKMP group policy. A VPN concentrator can initiate assignment of addresses to RAVPN clients, respond to requests for addresses from RAVPN clients, or both. In Figure 2-29, Kristen initiates address assignment to Charlie, and responds to James' request for an IP address. Example 2-18 illustrates the necessary configuration on Kristen, the IOS VPN concentrator in this topology. In this specific example, Kristen is configured to assign IP addresses from a locally defined pool, "RAVPN-pool." Kristen is configured to assign addresses in one of two ways:

• Address assignment in response to a request (Charlie's request in Figure 2-29).

• Address assignment when initiating an IPsec VPN tunnel (James' IP address assignment in Figure 2-29).

  Figure 2-29. Address Assignment with IKE Extended Authentication

  

Example 2-18. VPN Concentrator Settings for Extended Authentication

Kristen# Kristen#configure terminal Enter configuration commands, one per line.  End with CNTL/Z. Kristen(config)#aaa new-model Kristen(config)#aaa authentication login RAVPN-aaa group tacacs+ Kristen(config)#aaa authorization network RAVPN-aaa group tacacs+ Kristen(config)#crypto isakmp policy 10 Kristen(config-isakmp)#hash md5 Kristen(config-isakmp)#authentication pre-share Kristen(config-isakmp)#crypto isakmp client configuration group RAVPN-group Kristen(config-isakmp-group)#key ncstatewolfpack Kristen(config-isakmp-group)#domain cisco.com Kristen(config-isakmp-group)#pool RAVPN-pool Kristen(config-isakmp-group)#exit Kristen(config)#crypto IPsec transform-set RAVPN-transform esp-aes esp-sha-hmac Kristen(cfg-crypto-trans)#mode tunnel Kristen(cfg-crypto-trans)#exit Kristen(config)#crypto dynamic-map RAVPN-dyn 10 Kristen(config-crypto-map)#set transform-set RAVPN-1 Kristen(config-crypto-map)#exit Kristen(config)#crypto map RAVPN-map client authentication list RAVPN-aaa Kristen(config)#crypto map RAVPN-map isakmp authorization list RAVPN-aaa Kristen(config)#crypto map RAVPN-map client configuration address respond Kristen(config)#crypto map RAVPN-map client configuration address initiate Kristen(config)#crypto map RAVPN-map 10 IPsec-isakmp dynamic RAVPN-dyn Kristen(config)#interface FastEthernet0/0 Kristen(config-if)#crypto map RAVPN-map Kristen(config-if)#exit Kristen(config)#ip local pool RAVPN-pool 10.1.1.1 10.1.1.254 Access-list 101 permit Kristen(config)#tacacs-server host 100.1.1.254 Kristen(config)#tacacs-server directed-request Kristen(config)#tacacs-server key Cisco

X-Auth

As confidentiality continues to become increasingly important in VPNs, network administrators are increasingly turning to IPsec as a solution in Remote Access VPN deployments. We've covered, in brief, RAVPN architectures, which typically describe a large number of IPsec tunnels concentrated on one or more VPN concentrators. In this type of deployment, the ability to extend authentication (x-Auth) services down to the user level greatly enhances network administrators' granularity and flexibility when authenticating IPsec Remote Access VPN connections. For example, administrators configuring x-Auth in RAVPN deployments can offload user authentication to AAA servers such as CSACS.

X-Auth is not a replacement for IKE Phase I's existing authentication capabilities. Instead, x-Auth occurs in addition to IKE Phase I negotiation and occurs after IKE authenticates the crypto endpoint.

Tip

As x-Auth is not exactly described in Phase I negotiation, and Phase II negotiation cannot complete before Phase I negotiation (and subsequently x-Auth), x-Auth is commonly said to occur during Phase 1.5 negotiation.

As such, to use x-Auth, administrators must configure native Phase I authentication schemes and x-Auth parameters. Example 2-18 shows IPsec RAVPN configurations on an IOS-based VPN concentrator configured for x-Auth and authentication, authoring, and accounting (AAA) (as displayed in Figure 2-29).

Note

Example 2-18 contains dynamic crypto maps and wildcard PSKs, both of which are outside of the scope of this chapter. These topics are covered in greater detail in Chapter 14.

In the scenario in Example 2-18, Kristen is a router running Cisco IOS that is concentrating IPsec tunnels used for remote access by James and Charlie. Kristen uses several parameters to authenticate her remote access clientsgroup ID and key. All remote access clients must be configured with these keys in order to authenticate with Kristen. This is done in IKE Phase I negotiation. Additionally, Kristen uses x-Auth to authenticate and authorize James and Charlie against an AAA database on the TACACS+ server, 100.1.1.254. Kristen is configured to serve her remote clients with an address from the pool "RAVPN-pool," and assign them a domain name of "cisco.com."

Tip

In the configuration in Example 2-18, Kristen will attempt to authenticate any remote client that attempts to connect to her. An ACL can be configured under the ISAKMP group to prevent malicious hosts from continuously trying to connect to the concentrator, initiate authentication processes, and consume unacceptable amounts of processing overhead. Likewise, a dynamic crypto map is used, which does not define a traffic set to protect traffic (protects all traffic from concentrator to client). An access list can be added to the dynamic crypto map to provide further granularity in the protected traffic set definition.