10.5 Key Exchanges

One of the strengths of IPSec is that it is based on encryption algorithms that have been thoroughly peer-reviewed and tested. Instead of relying on a "super secure, private" encryption scheme, IPSec uses algorithms that can be viewed and dissected. This leads to the exposure of vulnerabilities and threats in a much more thorough manner than any private encryption scheme. The strength of these algorithms lies not in them being secret, but in the quality of the keys used in the algorithms. Thus, no discussion of IPSec would be complete without a discussion of key exchange protocols.

When considering IKE (Internet Key Exchange) and the key exchange protocols that define IKE, it is generally helpful to define what is needed in a key exchange. In this manner, all the protocols and packet exchanges that occur can be understood in the context of some straightforward requirements.

Encrypting data over the Internet has some particular problems associated with it. The actual encryption of data is pretty straightforward once you understand the different methods of operation for IPSec. Because the actual encryption algorithms used in IPSec are well-known, the security of an IPSec encryption is based on the quality of the keys being used. The question, then, is how do two parties on the Internet share keys with each other in a secure manner?

With some thought, a couple of solutions present themselves. We can manually set the keys. That is, we know what the key lengths are and can create keys manually. This process, however, would be tiresome, would not scale, and people would tend to create poor keys. It would be better to let the computers mindlessly churn through possible keys and look for "good" keys to use. Once a key has been generated, how do we tell the remote side of the connection what key we are going to use? Recall from our earlier material that most data encryption is done using symmetrical encryption algorithms. That is, the same key that is used to encrypt data is also used to decrypt data. We cannot just send the key over the Internet in a packet. Presumably, we are encrypting our data because we are concerned about someone intercepting it. If this is the case we have a chicken-and-egg problem. "I cannot encrypt data until I get my key across the Internet, but I need encryption to protect my key as it is sent!"

Just figuring out a way to get the key across does not solve all of our problems either. If you wanted to exchange sensitive information with someone you knew in person, you would have some way of validating who you were about to exchange information with. Because you know Joe, you could use Joe's visual appearance to provide the proof you need that you are really talking to Joe. This is not a simple matter to do over the Internet. One famous early cartoon describing the Internet culture noted that one of the primary benefits of the Internet was that, while online, nobody knew you were a dog. That is, we cannot meet face to face with the entities with which we want to communicate. It would be straightforward to create and exchange secret keys with a hacker site that was posing as a legitimate business. If this were the case, I could be encrypting all my financial data to the hacker, thinking that I was encrypting all the data to a legitimate investment site. Based on this, we need some way of securely identifying ourselves to anonymous computers over the Internet, to make sure that "Investments R Us" is really the site where my 401K is managed — and not a hacker site posing as a banking site.

However, the problems have not been all addressed yet. Now that I have figured out a way to exchange the secret key to use in our secure connection over the Internet and a way to prove that the other side is who they say they are, how do I negotiate all the options that are available in IPSec? Depending on the IPSec implementation, at the very least, the two sides of a connection will have to agree on whether to use AH, ESP, or ESP-Authentication, transport, or tunnel mode. But there is more. IPSec supports multiple encryption algorithms and multiple hash algorithms. Which ones out of these options do the two sides support? Which options available with the algorithms are also supported? There needs to be some initial negotiations to determine all of this information.

Once the secure connection is set up, our problems are still not resolved. Somone capturing our encrypted data could, in theory, break our encryption keys if they were to capture the data for a long enough period of time. This is because although it looks like random data, the encrypted data itself is not random. In tunnel mode, there is going to be another IP header and possibly a transport layer header that is encrypted. In the IP header, at least there are going to be fields and addresses that may be guessed at. Through a number of packets, someone with the aid of a very powerful computer may be able to piece together the secret key. To combat this threat, we are going to want something that allows us to change our keys without having to go through the entire key exchange process again. There also may be limitations on the lifetime of the security association that is used to identify the connection. These are all other options that need to be negotiated during connection setup.

We can see that the process of exchanging keys, to be fully functional in an Internet IPSec environment, needs much more thought than simply the generation of "nice" keys. This is the reason the IKE process can be some-what complicated.

Understanding the key exchange process is more than just academic. If you are considering an IPSec VPN as a countermeasure for your company, understanding IKE and what goes on with each stage of the IKE negotiations will go a long way in helping you better evaluate the protection offered by an IPSec VPN. Not all options and devices are created equally. Knowing the keying process will also help you quickly troubleshoot any VPN connectivity issues as, most of the time, it is not the encryption process itself that is failing; rather, IKE has failed to operate in the normal manner. If an IPSec VPN is going to fail, it is generally going to fail during the initial key exchange phase. Even if it does not, being able to understand the key exchange phase will help you to quickly eliminate this as a possibility and focus on other common failure instances.

For many, one of the most confusing elements in understanding the key exchange process is simply understanding the relationship between the four protocols that are commonly referenced when talking about key exchanges. The high-level view is this: the Internet Key Exchange (IKE) is the protocol used to exchange keys between IPSec peers. Then why is it so complicated? The answer is that IKE is not really a single protocol, but like IPSec itself, is a combination of protocols, each of which contributes its own elements to IKE.

The protocols that make up IKE are the Internet Security Association and Key Management Protocol (ISAKMP, pronounced eyesa-CAMP), Oakley, and the Secure Key Exchange Mechanism (SKEME). Each one of these describes a certain function of the IKE protocol itself.

Because we are primarily interested in the operation of IKE, we will discuss the other contributing protocols in only enough depth to explain their relationship to IKE. The first protocol is ISAKMP. ISAKMP is a protocol that defines the process of exchanging keys over the Internet and the method of authentication, but does not define the actual process. Alone, ISAKMP does not do much for us. ISAKMP is similar to the concept of "house." When someone says, "We need to build a house," this conjures an image of the final goal of the project. We think, "OK, we need a foundation, a roof. Some doors and windows would be nice." However, we do not have enough information to actually build the house. We need to determine how big the windows are going to be, what kind of doors are required, how many corners are in the foundation, if there will be a walk-out basement, etc. To actually build the house, we are going to need some more detailed blueprints with information specific to the house we are trying to build. With ISAKMP, we have determined what goals need to be reached, but not how to actually implement them. In fact, most of what ISAKMP does for our IPSec key exchange protocols is lend a convenient header format and order of packet exchange.

Oakley is a protocol that helps provide those specifics. To continue with the house analogy, Oakley is our blueprint. It tells the parties in an IPSec key exchange how to authenticate each other and how to exchange the secret keys in a secure manner to create a security association. Oakley also defines what methods of authentication are acceptable and how to authenticate a remote party using certificates.

Once the connection is established, SKEME provides a mechanism to be used in the re-keying process. Re-keying is the periodic refreshment of keys used to encrypt data. Although the algorithms used to protect data are thought to be secure, to improve their security, the keys are periodically changed in order to cause anyone who is trying to break the keys based upon capturing data to have to start their work over again each time the key is refreshed.

In summary, the IKE protocol is a specific implementation of the ISAKMP/Oakley and SKEME framework. While each of the associated protocols include guidelines from the general to the specific, none of them need to be used specifically with the IPSec protocol. ISAKMP/Oakley and SKEME can be used with other protocols that require key exchanges. IKE simply defines the specifics when using those protocols with an IPSec key exchange. To put the finishing touches on the house analogy, IKE is the detailed blueprint, including wiring, heating, air conditioning, and measurements, that you would use to create a very specific house. Now that the relationship has been explained, for the rest of this discussion, we will be using the terminology "IKE" to describe the key exchange process, but you will know that we are really borrowing from parts of other protocols to enable all that we want in an Internet key exchange protocol.