Jan. 21, 2011, 9:36 a.m.
posted by prosto
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:
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.
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. Figure illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE.
Charlie Specifies a Lifetime for His IPsec SAs, Negotiated with James During IKE
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:
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 Figure.
ISAKMP Policy Diffie-Hellman Configuration (Charlie Selects DH MODP 2)
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. 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.
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:
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.
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 Figure, using the Diffie-Hellman shared secret as the symmetric encryption key on each peer.
James Configures IPsec and IKE Encryption Ciphers.
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:
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.
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). Figure shows the required IKE configurations on James and Charlie.
IKE Configurations for James and Charlie Using PSKs
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 illustrates the creation and exchange of RSA encrypted nonces.
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:
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. 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.
X.509 is discussed in greater detail in Chapter 11, "Public Key Infrastructure and IPsec VPNs." Figure 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.
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:
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 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.
ISAKMP Negotiation in Main Mode
The following sequence of events describes the negotiation of the IKE SA in main mode as illustrated in Figure:
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.
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 illustrates the negotiation of an IKE SA using aggressive mode.
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 Figure.
Disallowing Aggressive Mode as an Option for Phase 1 Negotiation
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.
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.
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:
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 Figure.
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 illustrates the process of detecting a stale SA with IKE Keepalives.
Detecting Stale SAs with IKE Keepalives
Figure 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 (Figure, line 9). In addition, Kristen must have two peers defined in her crypto map in order to facilitate this failover (Figure, lines 16 and 17). Because Kristen uses IKE PSKs, she must also have the shared secret key defined with both peers (Figure, lines 10 and 11).
Kristen Uses DPD and IKE Keepalives for VPN High Availability
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.
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:
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 Figure, 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. Figure provides the ISAKMP policy configuration corresponding to the exchange illustrated in Figure.
James and Charlie Use ISAKMP Policies for IKE Negotiation
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):
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.
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, Kristen initiates address assignment to Charlie, and responds to James' request for an IP address. Figure 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:
VPN Concentrator Settings for Extended Authentication
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.
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. Figure shows IPsec RAVPN configurations on an IOS-based VPN concentrator configured for x-Auth and authentication, authoring, and accounting (AAA) (as displayed in Figure).
Figure 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 Figure, 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, 126.96.36.199. 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."
In the configuration in Figure, 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.