Cisco Secure VPN Exam Certification Guide - Cisco press

48 Chapter 2: Overview of VPN and IPSec Technologies

Triple DES

One version of the Data Encryption Standard is Triple DES (3DES) so named because it performs three encryption operations on the data. It performs an encryption process, a decryption process, and then another encryption process, each with a different 56-bit key. This triple process produces an aggregate 168-bit key, providing strong encryption. Cisco VPN products and software all support the 168-bit 3DES encryption algorithm as well as the 56-bit DES algorithm.

Message Integrity

Message integrity is accomplished by using a hashing algorithm to compute a condensed representation of a message or data file. These condensed representations are called message digests (MDs) and are of a fixed length that depends on the hashing algorithm used. All or part of this message digest is transmitted with the data to the destination host, which executes the same hashing algorithm to create its own message digest. The source and destination message digests are then compared. Any deviation means that the message has been altered since the original message digest was created. A match means that you can be fairly certain that the data have not been altered during transit.

When using the IPSec AH protocol, the message digest is created using the immutable fields from the entire IP datagram, replacing mutable fields with 0s or predictable values to maintain proper alignment. The computed MD is then placed into the Authentication Data (or ICV) field of the AH. The destination device then copies the MD from the AH and zeroes out the Authentication Data field to recalculate its own MD. Refer to Figures 2-8 and 2-10 to refresh your memory about the structure of the AH datagram.

With the IPSec ESP protocol, the process is similar. The message digest is created using the immutable data in the portion of the IP datagram from the beginning of the ESP header to the end of the ESP trailer. The computed MD is then placed into the ICV field at the end of the datagram. With ESP, the destination host does not need to zero out the ICV field because it sits outside of the scope of the hashing routine. Refer to Figures 2-9 and 2-11 for the structure of the ESP datagram.

Cisco VPN products support Message Digest 5 (MD5) and Secure Hash Algorithm-1 (SHA-1) algorithms, which use a keyed hashing mechanism called Hashed Method Authentication Code (HMAC). These three message integrity tools are described in the following sections.

Hash-Keyed Message Authentication Code

RFC 2104 describes the HMAC algorithm, because it was developed to work with existing hashing algorithms like MD5 and SHA-1. Many security processes involved in sharing data involve the use of secret keys and a mechanism called Message Authentication Codes (MACs). One party creates the MAC using the secret key and transmits the MAC to its peer partner. The peer partner creates its own MAC using the same secret key and compares the two MACs.

MD5 and SHA-1 share a similar concept, except that they do not use secret keys. That is where HMAC comes in. HMAC was developed to add a secret key into the calculation of the message

50 Chapter 2: Overview of VPN and IPSec Technologies

Preshared Keys

The process of sharing preshared keys is manual. Administrators at each end of the IPSec VPN agree on the key to use and then manually enter the key into the end device, either host or gateway. This method is fairly secure, but it does not scale well to large applications.

RSA Digital Signatures

Ronald Rivest, Adi Shamir, and Leonard Adelman developed the RSA public-key cryptosystem in 1977. Ronald Rivest also developed the MD5 hashing algorithm. A Certificate Authority (CA) provides RSA digital certificates upon registration with that CA. These digital certificates allow stronger security than do preshared keys. Once the initial configuration has been completed, peers using RSA digital certificates can authenticate with one another without operator intervention.

When an RSA digital certificate is requested, a public and a private key are generated. The host uses the private key to create a digital signature. The host sends this digital signature along with its digital certificate to its IPSec peer partner. The peer uses the public key from the digital certificate to validate the digital signature received from the peer.

RSA Encrypted Nonces

A twist in the way digital signatures are used is the process of using RSA encrypted nonces for peer authentication. A nonce is a pseudorandom number. This process requires registration with a CA to obtain RSA digital certificates. Peers do not share public keys in this form of authentication. They do not exchange digital certificates. The process of sharing keys is manual and must be done during the initial setup.

RSA encrypted nonces permit repudiation of the communication, where either peer can plausibly deny that it took part in the communication. Cisco is the only vendor that offers this form of peer authentication.

Key Management

Key management can be a huge problem when working with IPSec VPNs. It seems like there are keys lurking everywhere. In reality, only five permanent keys are used for every IPSec peer relationship. These keys are described as follows:

•Two are private keys that are owned by each peer and are never shared. These keys are used to sign messages.

•Two are public keys that are owned by each peer and are made available to anyone. These keys are used to verify signatures.

An Overview of IPSec Protocols 51

•The fifth key is the shared secret key. Both peer members use this key for encryption and hashing functions. This is the key created by the Diffie-Hellman protocol, which is discussed in the next section.

That does not seem like many keys. In fact, the private and public keys are used for multiple IPSec connections on a given peer. In a small organization, these keys could all probably be managed manually. The problem arises when trying to scale the processes to support hundreds or thousands of VPN sessions. The next sections discuss the Diffie-Hellman protocol and Certificate Authorities, which are two excellent ways of automatically managing this potential nightmare.

Diffie-Hellman Protocol

In 1976, Whitfield Diffie and Martin Hellman developed the first public key cryptographic technique. The Diffie-Hellman (D-H) key agreement protocol allows two peers to exchange a secret key without having any prior secrets. This protocol is an example of an asymmetrical key exchange process in which peers exchange different public keys to generate identical private keys. This protocol is over 20 years old and has withstood the test of time.

The Diffie-Hellman protocol is used in IPSec VPNs, but you have to look hard to find it. It is used in the process of establishing the secure channel between peers that IPSec rides on. The trail is as follows:

1IPSec uses the Internet Security Association and Key Management Protocol (ISAKMP) to provide a framework for authentication and key exchange.

2ISAKMP uses the IKE Protocol to securely negotiate and provide authenticated keying material for security associations.

3IKE uses a protocol called OAKLEY, which describes a series of key exchanges and details the service provided by each.

4OAKLEY uses Diffie-Hellman to establish a shared secret key between peers.

Symmetric key encryption processes then use the shared secret key for encryption or authentication of the connection. Peers that use symmetric key encryption protocols must share the same secret key. Diffie-Hellman provides an elegant solution for providing each peer with a shared secret key without having to keep track of the keys used.

Diffie-Hellman is such a clean process that you might wonder why we need symmetric key encryption processes. The answer is that asymmetric key encryption processes are much too slow for the bulk encryption required in high-speed VPN circuits. That is why the Diffie-Hellman protocol has been relegated to creating the shared secret key used by symmetric key encryption protocols.

IPSec peers use the Diffie-Hellman Protocol to generate the shared secret key that is used by AH or ESP to create authentication data or to encrypt an IP datagram. The receiving peer uses the D-H shared secret key to authenticate the datagram and decrypt the payload.

52 Chapter 2: Overview of VPN and IPSec Technologies

No discussion of Diffie-Hellman would be complete without showing the mechanisms involved in creating the shared secret key. Table 2-8 shows the Diffie-Hellman process of creating the key between two IPSec peers called Able and Baker. Notice that the shared secret key never travels over the network between the peers.

An Overview of IPSec Protocols 53

Certificate Authorities

Another method of handling keys that does not take a lot of administrative support is to use Certificate Authorities (CAs) as a trusted entity for issuing and revoking digital certificates and for providing a means to verify the authenticity of those certificates. CAs are usually third-party agents such as VeriSign or Entrust, but for cost savings, you could also set up your own CA using Windows 2000 Certificate Services.

The following list describes how CAs work:

1A client that wants to use digital certificates creates a pair of keys, one public and one private. Next, the client prepares an unsigned certificate (X.509) that contains, among other things, the client’s ID and the public key that was just created. This unsigned certificate is then sent to a CA using some secure method.

2The CA computes a hash code of the unsigned certificate. The CA then takes that hash and encrypts it using the CA’s private key. This encrypted hash is the digital signature, and the CA attaches it to the certificate and returns the signed certificate to the client. This certificate is called an Identity Certificate and is stored on the client device until it expires or is deleted. The CA also sends the client its own digital certificate, which becomes the root certificate for the client.

3The client now has a signed digital certificate that it can send to any other peer partner. If the peer partner wants to authenticate the certificate, it decrypts the signature using the CA’s public key.

It is important to note that a CA only sends a client’s certificate to that client itself. If the client wants to establish IPSec VPNs with another client, it trades digital certificates with that client, thereby sharing public keys.

When a client wants to encrypt data to send to a peer, it uses the peer’s public key from the digital certificate. The peer then decrypts the package with its private key.

When a client wants to digitally sign a package, it uses its own private key to create a “signed” hash of the package. The receiving peer then uses the client’s public key to create a comparison hash of the package. When the two hash values match, the signature has been verified.

Another function of a CA is to periodically generate a list of certificates that have expired or have been explicitly voided. The CA makes these Certificate Revocation Lists (CRLs) available to its customers. When a client receives a digital certificate, it checks the CRL to find out if the certificate is still valid.

You learn more about CAs and digital certificates in Chapter 5, “Configuring Cisco VPN 3000 for Remote Access Using Digital Certificates.”

54 Chapter 2: Overview of VPN and IPSec Technologies

Authenticating IPSec Peers and Forming Security Associations

The protocol that brings all the previously mentioned protocols together is the Internet Key Exchange (IKE) Protocol. IKE operates in two separate phases when establishing IPSec VPNs. In IKE Phase 1, it is IKE’s responsibility to authenticate the IPSec peers, negotiate an IKE security association between peers, and initiate a secure tunnel for IPSec using the Internet Security Association and Key Management Protocol (ISAKMP).

In IKE Phase 2, the peers use the authenticated, secure tunnel from Phase 1 to negotiate the set of security parameters for the IPSec tunnel. Once the peers have agreed on a set of security parameters, the IPSec tunnel is created and stays in existence until the Security Associations (SAs) (either IKE or IPSec) are terminated or until the SA lifetimes expire.

Combining Protocols into Transform Sets

Configuring IPSec in Cisco devices is fairly simple. You need to identify the five parameters that IKE uses in Phase 1 to authenticate peers and establish the secure tunnel. Those five parameters and their default settings for the VPN 3000 Concentrator Series are as follows:

•Encryption algorithm—56-bit DES (default) or the stronger 168-bit 3DES.

•Hash algorithm—MD5 (default) or the stronger SHA-1.

•Authentication method—Preshared keys, RSA encrypted nonces, or the most secure, RSA digital signatures (also the default).

•Key exchange method—768-bit Diffie-Hellman Group 1 (default) or the stronger 1024-bit Diffie-Hellman Group 2.

•IKE SA lifetime—The default is 86,400 seconds or 1 day. Shorter durations are more secure but come at a processing expense.

Whatever parameters you choose for IKE Phase 1 must be identical on the prospective peer, or the connection is not established. Once you have these configured, the only other values you need to supply to establish the IPSec tunnel in IKE Phase 2 are as follows:

•IPSec protocol—AH or ESP

•Hash algorithm—MD5 or SHA-1 (These are always HMAC assisted for IKE Phase 2.)

•Encryption algorithm if using ESP—DES or 3DES

NOTE The AH Protocol is seldom used in production environments today. SHA-HMAC and MD5HMAC are now available to provide additional packet integrity for ESP. A second argument for not using AH is that AH does not support NAT or PAT, essential components of secure networks and useful tools for extending IPv4 addresses into private networks.

An Overview of IPSec Protocols 55

In a VPN network environment, you can have different security requirements for each VPN. If you are going router to router within a physically secured building, you might not want the added processing expense of ESP on that VPN. VPN connections to one of the routers from the Internet, however, might need ESP’s encryption.

To facilitate the configuration process for devices that need to support a variety of IPSec VPNs, the IPSec parameters are grouped into predefined configurations called transforms. The transforms identify the IPSec protocol, hash algorithm, and when needed, the encryption algorithm. Only a handful of valid transforms are available; they are identified in Table 2-9.

Transforms are used to identify the types of IPSec tunnels that a host supports. A specific IPSec tunnel can support up to three transforms in a strictly regulated structure called a transform set. You can configure multiple transform sets within a device’s crypto policy to identify acceptable combinations that can be used for establishing IPSec tunnels. A transform set can be any of the following valid combinations.

56Chapter 2: Overview of VPN and IPSec Technologies

•One AH authentication transform:

—ah-md5-hmac

—ah-sha-hmac

—ah-rfc1828

•One ESP encryption transform:

—esp-des

—esp-3des

—esp-null

—esp-rfc1829

•One ESP encryption transform <AND> one ESP authentication transform:

—esp-des esp-md5-hmac

—esp-des esp-sha-hmac

—esp-3des esp-md5-hmac

—esp-3des esp-sha-hmac

—esp-null esp-md5-hmac

—esp-null esp-sha-hmac

•One AH authentication transform <AND> one ESP encryption transform in the following combination only:

—ah-rfc1828 esp-rfc1829

•One AH authentication transform <AND> one ESP encryption transform <AND> one ESP authentication transform:

—ah-md5-hmac esp-des esp-md5-hmac

—ah-md5-hmac esp-des esp-sha-hmac

—ah-md5-hmac esp-3des esp-md5-hmac

—ah-md5-hmac esp-3des esp-sha-hmac

—ah-md5-hmac esp-null esp-md5-hmac

—ah-md5-hmac esp-null esp-sha-hmac

—ah-sha-hmac esp-des esp-md5-hmac

—ah-sha-hmac esp-des esp-sha-hmac

—ah-sha-hmac esp-3des esp-md5-hmac

—ah-sha-hmac esp-3des esp-sha-hmac

—ah-sha-hmac esp-null esp-md5-hmac

—ah-sha-hmac esp-null esp-sha-hmac

Establishing VPNs with IPSec 57

Establishing VPNs with IPSec

4 How IPSec works

As you can see from the previous discussion, IPSec was designed to use a robust set of protocols and processes. You could establish VPNs without knowing much about these protocols, but the results would be haphazard at best. Good practice dictates a sequence of preparation steps that you should take before you can effectively configure a device for IPSec. Those preconfiguration steps are as follows:

Step 1 Establish an IKE policy—This policy must be identical on both ends of a VPN. The following elements go into the IKE policy:

—Key distribution method—Manual or certificate authority.

—Authentication method—Mostly determined by the key distribution method you select. Manual distribution uses preshared keys. Certificate authority distribution uses RSA encrypted nonces or RSA digital signatures.

—IP address and host names of peers—IP needs to know where to locate potential peers, and access control lists on intermediate devices need to permit the peers to communicate. IPSec configuration requires the fully qualified domain name (FQDN) of the device as well as the IP address.

—IKE policy parameters—Used by ISAKMP to establish the secure tunnel of IKE Phase 1. IKE policies consist of the following five parameters:

Encryption algorithm (DES/3DES) Hash algorithm (MD5/SHA-1)

Authentication method (Preshared, RSA encryption, RSA signatures) Key exchange (D-H Group 1/D-H Group 2)

IKE SA lifetime (86,400 seconds by default)