The Components of IPSec

IPSec Tunnel Termination

IPSec tunnel termination can occur for one of two reasons: it is deleted or the IPSec SA lifetime expires. When an IPSec SA lifetime expires, IKE phase 2 negotiation begins again and, if needed, so does IKE phase 1 negotiation.

Well, it’s about time you started learning about the different IPSec components, but before moving on, you might want to go back and review anything that’s still unclear. It would be pretty sweet if I could show you how to create a tunnel between this book and your brain so that all this data could just flow into it without studying, huh? Maybe someday, but for now you’ll have to deal with the grind. So take a break if you need to, and then let’s get into IPSec components.

The Components of IPSec

All rested up? Good—let’s get back to it then! You’ve just learned about how IPSec operates and about IKE. With that foundation in place, you’re ready to take a detailed look at the encapsulations that make IPSec possible and at the IKE components. So without further ado, let’s get down to the skinny on both IPSec encapsulation and IKE!

IPSec Encapsulation

IPSec handles packet encapsulation through the use of ESP and/or AH. ESP encrypts the payload of a packet, whereas AH provides protection to the entire datagram by embedding the header in the data and verifying the integrity of the IP datagram.

IPSec can encapsulate data by one of two methods: transport mode or tunnel mode.

Transport Mode Encapsulation

Transport mode encapsulation uses the original IP header and inserts the header for ESP and/ or AH. In transport mode, the original IP header must contain a routable IP address.

Figure 7.2 illustrates the format of a packet using ESP in transport mode.

F I G U R E 7 . 2 Packet format using ESP in transport mode

Authenticated

Encrypted

224 Chapter 7 Understanding Cisco IOS IPSec Support

Figure 7.3 illustrates the format of a packet using AH in transport mode.

F I G U R E 7 . 3 Packet format using AH in transport mode

Authenticated

Figure 7.4 illustrates the format of a packet using ESP and AH in transport mode.

F I G U R E 7 . 4 Packet format using ESP and AH in transport mode

Authenticated

Encrypted

Great! With transport mode down, let’s look at tunnel mode.

Tunnel Mode Encapsulation

When you use tunnel mode encapsulation, the original IP header doesn’t transport the packet. Instead, a new IP header is created using the IP addresses of the IPSec peers as the source and destination of the packet. This mode works great when you’re creating a VPN across the Internet because the addresses of the originating devices can be private, so they’re less vulnerable to unwanted access. As with transport mode, tunnel mode uses ESP and/or AH.

Figure 7.5 illustrates the format of a packet using ESP in tunnel mode.

F I G U R E 7 . 5 Packet format using ESP in tunnel mode

Authenticated

Encrypted

Figure 7.6 illustrates the format of a packet using AH in tunnel mode.

F I G U R E 7 . 6 Packet format using AH in tunnel mode

Authenticated

Figure 7.7 illustrates the format of a packet using ESP and AH in tunnel mode.

Encrypted

Internet Key Exchange (IKE)

IPSec can be configured with or without Internet Key Exchange (IKE), but it’s really a better idea to use IKE. IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for the IPSec standard. It’s a hybrid protocol that implements the OAKLEY key exchange and SKEME key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework.

Now’s a good time to define some of the terms I just threw at you:

ISAKMP Internet Security Association and Key Management Protocol (ISAKMP) is a protocol framework that defines the payload format, the mechanics of implementing a key exchange protocol, and the negotiation of an SA.

OAKLEY Having nothing to do with high-tech, seriously cool sunglasses, OAKLEY is a key exchange protocol that defines how to derive authenticated keying material.

SKEME SKEME is a key exchange protocol that defines how to derive authenticated keying material with rapid key refreshment.

226 Chapter 7 Understanding Cisco IOS IPSec Support

Now that you’re clear on the terminology, let’s get back into the discussion. IKE gives us the goods in the following six ways:

IKE eliminates the need to manually specify all the IPSec security parameters in the crypto maps at both peers.

IKE allows you to specify a lifetime for the IPSec security SA.

IKE allows encryption keys to change during IPSec sessions.

IKE allows IPSec to provide anti-replay services.

IKE permits certification authority (CA) support for a manageable, scalable IPSec implementation.

IKE allows dynamic authentication of peers.

So, how is IKE able to provide these goodies? That’s what you’re about to find out.

IKE consists of the two phases mentioned earlier in this chapter: IKE phase 1 and IKE phase 2. During phase 1, IKE negotiates the IKE SAs and authenticates the IPSec peers. During phase 2, IKE negotiates the IPSec SAs and creates the IPSec tunnel.

IKE relies heavily on Diffie-Hellman during phase 1, so let’s take a closer look at that feature.

Diffie-Hellman Key Agreement

The Diffie-Hellman (DH) Agreement is a means for two parties to agree on a shared secret number that is then used to encrypt secret keys for other algorithms such as DES and MD5. DH occurs in phase 1 of IKE negotiation.

The process of DH occurs over unsecured lines.

Before diving right into how DH works, here’s a list of keys you need to understand:

P P is a randomly generated prime integer.

G G is a primitive root of P.

Xa Xa is a private key generated by the formula (G mod P).

Xb Xb is a private key generated by the formula (G mod P).

Ya Ya is a public key generated by the formula ((G to the power of Xa) mod P).

Yb Yb is a public key generated by the formula ((G to the power of Xb) mod P).

ZZ ZZ is a shared secret key generated by the formula ((Yb to the power of Xa) mod P) on one device and the formula ((Ya to the power of Xb) mod P) on the other device.

Mod stands for a modulus or division.

Now, with the terminology and formulas out of the way, you’re ready to get into the six-step process DH goes through in the creation of ZZ. Use the network in Figure 7.8 for reference in this discussion of DH.

F I G U R E 7 . 8 A Diffie-Hellman network

1.The first step of DH uses the generated P value on each device to create the G value. The following steps are what the devices in Figure 7.8 actually go through:

A.Both R1 and R2 generate a P value.

B.R1 transmits its P value to R2, and R2 transmits its P value to R1.

C.Both R1 and R2 use the two P values to create G.

2.The second step of DH uses G and P on each device to generate Xa on one device and Xb on the other device. The routers in Figure 7.8 go through the following process:

A.R1 uses the formula (G mod P) to create its private key Xa.

B.R2 uses the formula (G mod P) to create its private key Xb.

3.Now it’s time to generate each device’s public key. To generate the public keys for R1 and R2, the devices in Figure 7.8 go through the following process:

A.Using the formula ((G to the power of Xa) mod P), R1 creates its public key Ya.

B.Using the formula ((G to the power of Xb) mod P), R2 creates its public key Yb.

4.The devices now exchange their public keys. R1 sends its public key, Ya, to R2, and R2 sends its public key, Yb, to R1.

5.R1 and R2 generate the secret shared key ZZ. R1 uses the formula ((Yb to the power of Xa) mod P) to create ZZ, and R2 uses the formula ((Ya to the power of Xb) mod P) to create ZZ.

6.On each device, ZZ encrypts the key that will be used by DES or MD5 for the purpose of encrypting data.

Once this last step has been completed, DH is finished with its initial function. But DH can be used later in IKE phase 2 to generate new keying material for IPSec SAs.

All right, now you understand how DH is used with IKE—great! So let’s look at some of the authentication mechanisms available to IKE during phase 1 that it can use to authenticate a peer’s identity.

228 Chapter 7 Understanding Cisco IOS IPSec Support

Authentication

I’ve mentioned authentication several times in this chapter, but I’ve never gone into any detail. That’s exactly what I’m going to do here. Any of the following three authentication types can be used for IKE:

Pre-Shared Keys

Pre-shared keys must be configured on each IPSec peer, and any keys used have got to be the same on each peer. This is because IKE peers authenticate each other by creating and sending a keyed hash that includes the pre-shared key. Once the receiving peer receives the hash, it attempts to create the same hash by using its configured pre-shared key. Needless to say, the peer is authenticated only if the hashes match.

RSA-Encrypted Nonces

RSA-encrypted nonces are a type of public/private key cryptography that truly is very secure, but it’s not very scalable. A nonce is a pseudo-random number. RSA-encrypted nonces can be used to authenticate the IKE exchange and the Diffie-Hellman Key Agreement.

So let’s take a look at how RSA-encrypted nonces work. This section could get a little confusing, so I’ll use an example.

Suppose you have two devices you want to peer using RSA-encrypted nonces: R1 and R2. You’ve got to manually generate a public key on both R1 and R2, and then manually enter the public key generated by R1 into R2 and vice versa.

Next, R1 generates a nonce that it then encrypts along with its IKE identity using RSA encryption and the public key that was manually entered. R1 transmits the cipher text to R2. While R1 is doing all of this, R2 is doing the same using the public key that you manually entered into it.

Once R1 receives the encrypted packet from R2, it decrypts the packet using its own private RSA key. After the packet has been decrypted, R1 removes both the nonce and R2’s IKE identity. R1 then hashes R2’s nonce and IKE identity and sends the hash back to R2. R2 is performing all these same functions simultaneously.

After both R1 and R2 receive their respective hash, each device then hashes its own nonce and IKE identity. With that done, each device compares the hash it received with the hash it just generated to determine if they match. If they do, authentication has occurred.

RSA-encrypted nonces are not very scalable because of the fact that you’ve got to both manually generate and then exchange public keys. Even so, RSA signatures do scale the best.

RSA Signatures and Digital Certificates

RSA signatures rely on digital signatures—something I’ll get to in a second. It’s actually through the use of digital signatures that RSA signatures overcome the scalability limitations of RSAencrypted nonces.

You still need to manually generate the public/private key pair on each device when you use RSA signatures. And once you’ve done that, you’ve got to register each peer with a certificate authority (CA). When you register a device with the CA, it also registers the public key you’ve just generated. The CA then issues a signed digital certificate to you, validating that you really are who you say you are. Each peer absolutely must have a signed digital certificate before RSA can be used.

Once each device has a signed digital certificate, they send them, along with their IKE identities, to the other device. The IKE exchange is authenticated by the signed digital certificate.

Why is this good? Well, because using digital certificates eliminates that nasty need to manually enter a device’s generated public key in each and every device that it needs to peer with, that’s why! It’s a significant advantage because it allows for greater scalability.

Now it’s time to talk in depth about digital certificates. They contain device-specific information such as the device’s name and IP address, as well as its generated public key. This is why a digital certificate can be used in place of manually entering public keys for IKE authentication.

But how does this all work? Well, first of all, the CA that you’re using needs to be trusted by the devices that you want to be able to peer with. This occurs when the device first begins talking to the CA. The following are the steps required for a device to receive a signed digital signature from a CA:

1.You must manually generate the public/private key pair on the device.

2.The device requests the specified CA’s public key.

3.The CA sends its public key to the device.

4.The device requests a signed digital certificate from the CA. In that request, the device includes device-specific information and its public key.

5.The CA generates the digital signature, incorporating both the device’s public key and the CA’s private key.

6.The CA sends the signed digital signature back to the device.

So after a device receives its signed digital signature, it offers it to all the devices it wants to peer with. A peer device trusts the device’s public key once it verifies the device’s signature using the public key from the CA. This entire process is a type of Digital Signature Standard (DSS) encryption.

DSS encryption is a mechanism that uses digital signatures to protect data.

Cisco fully supports the use of digital certificates by IKE and implements the following standards:

X.509v3 The standard certificate format. X.509v3 specifies how to form a certificate.

CRLv2 The certificate revocation list, version 2. CRLv2 is a list of revoked certificates, that is, certificates that should no longer be trusted.

230 Chapter 7 Understanding Cisco IOS IPSec Support

Certificate Enrollment Protocol (CEP) A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early implementation of Certificate Request Syntax (CRS), a standard proposed to the Internet Engineering Task Force (IETF). CEP specifies how a device communicates with a CA, including how to retrieve the CA’s public key, how to enroll a device with the CA, and how to retrieve a certificate revocation list (CRL). CEP uses RSA’s PKCS (Public-Key Cryptography Standards) 7 and 10 as key component technologies. The IETF’s Public Key Infrastructure (PKI) Working Group is moving forward to standardize a protocol for these functions, either CRS or an equivalent. When an IETF standard is stable, Cisco will add support for it.

IKE Mode Configuration

IKE mode configuration allows IKE to scale an IPSec policy out to remote users. This is accomplished by permitting a gateway to download an IP address and other network-level configuration through Dynamic Host Configuration Protocol (DHCP) to a client during IKE negotiation. Afterward, this address is used as the inner IP address to be encapsulated under IPSec and can then be matched against an IPSec policy.

The last IKE feature I need to describe is IKE’s extended authentication capabilities.

IKE Extended Authentication (XAuth)

Until the advent of IKE extended authentication (XAuth), IKE was only able to support authentication of the device, but not of the user. XAuth introduced a way for IKE to use AAA to authenticate the user after it has authenticated the device, adding an extra level of security to the network.

That’s really all there is to understanding IPSec. The following sidebar explores Cisco’s IOS Cryptosystem and goes further into the encryption and hash algorithms described earlier.

Cisco IOS Cryptosystem

To put it simply, a cryptosystem is a combination of encryption technologies, working in harmony, that are used to encrypt data so that only the intended receiver can decrypt it. Cisco uses the following four technologies to create its IOS Cryptosystem:

Digital Encryption Standard (DES)

Message Digest 5 (MD5)

Digital Signature Standard (DSS)

Diffie-Hellman Key Agreement

These four technologies perform the following tasks in Cisco’s cryptosystem:

DES encrypts data.

MD5 creates a message hash.