The Institute of Electrical and Electronics Engineers (www.IEEE.org) operates a group called the Standards Association (SA). Among many other standards, the IEEE-SA is responsible for the IEEE 802 family: “Local Area and Metropolitan Area Networks.” IEEE 802 is divided into working groups, each of which produces standards in a specific area, as shown in Figure 7.1. The “.11” working group produces standards for wireless LANs.

Figure 7.1. IEEE 802 Standards Working Group

The original IEEE 802.11 standard was ratified in 1997 and became an international standard in 1999. Work continues and updates to the base standard are made from time to time. Some of these, such as 802.11b and 802.11a, are complete while others are still in development. At the time this book was written, 802.11i had not been ratified and was still in draft form. Note that updates such as IEEE 802.11b are not whole new standards; they are addendums to the existing standard. Care is taken to ensure that older equipment is not made obsolete by any changes.

Standards allow manufacturers to produce products that have known physical characteristics. For example, two wireless LAN systems could not communicate with each other unless they use compatible radio frequencies and modulation methods. The standard specifies such things in detail. The IEEE 802.11 standard also defines protocol messages and operating algorithms (see Chapter 5).

Standards are very useful to manufacturers because they create a technical specification from which designs can be made. However, end users—that is, the customers who buy the products—have a different concern. IEEE 802.11 might tell them the characteristics of the product, but it does not guarantee that a product from vendor A will completely interoperate with a product from vendor B.

IEEE 802.11 is a long and complicated standard. Despite the best efforts of the standards body, there are bound to be areas that are ambiguous or not fully defined. Also there are a number of features that are optional and different manufacturers might make different choices in their designs. To avoid interoperability problems, the Wi-Fi Alliance was formed by a group of major manufacturers and the logo “Wi-Fi” was created.

To obtain Wi-Fi certification, a manufacturer must submit its product for testing against a set of “gold standard” Wi-Fi products. The Wi-Fi Alliance created its own test plan based on IEEE 802.11. Some features of IEEE 802.11 are not required for Wi-Fi certification. Conversely, there are some requirements that are additional to the standard. Where there is ambiguity in the standard, the correct behavior is defined by the way the gold standard products work. In this way interoperability is ensured. In summary, Wi-Fi defines a subset of IEEE 802.11 with some extensions, as shown in Figure 7.2.

Figure 7.2. Relationship of Wi-Fi to IEEE 802.11

The addendum to the standard that specifies the new generation of security is called IEEE 802.11i. At the time of writing, no such standard has been released, but a draft of the standard is under discussion by Task Group i of the working group. The draft is fairly complete and is unlikely to change substantially before release, but changes are certainly possible.

IEEE 802.11i defines a new type of wireless network called a robust security network (RSN). In some respects this is the same as the ordinary or WEP-based networks. However, in order to join an RSN, a wireless device has to have a number of new capabilities, as described in the following chapters. In a true RSN, the access point allows only RSN-capable mobile devices to connect and places rigorous security constraints on the process. However, because many people will want to upgrade over a period of time and use pre-RSN equipment during the upgrade, the IEEE 802.11i defines a transitional security network (TSN) in which both RSN and WEP systems can operate in parallel.

At the time of writing, no RSN-capable products are on the market. Such products cannot be released until the standard has been completed. Most existing Wi-Fi cards cannot be upgraded to RSN because the cryptographic operations required are not supported by the hardware and are beyond the capability of software upgrades. Therefore it will be some time before full RSN networks become operational. By contrast, WPA networks can be implemented immediately.

Remember that the definition of Wi-Fi came after completion of the IEEE 802.11 standard. However, the major Wi-Fi manufacturers decided that security was so important to end users that it had to move as fast as possible to deliver a replacement for WEP. Furthermore, they concluded that customers would not be prepared to just throw away all their existing Wi-Fi equipment in order to switch to RSN; they would want to upgrade their products through software. To address this need, Task Group i started to develop a security solution based around the capabilities of existing Wi-Fi products. This led to the definition of the Temporal Key Integrity Protocol (TKIP), as described in Chapter 11. TKIP is allowed as an optional mode under RSN.

The development of TKIP was a great help to allow upgrade of existing systems, but the industry couldn't wait until the lengthy process of standards ratification was completed. Therefore, the Wi-Fi Alliance adopted a new security approach based on the draft RSN but only specifying TKIP. This subset of RSN is called Wi-Fi Protected Access (WPA). Many leading vendors have now produced software upgrades so existing product can be converted to support WPA and most new products are now shipped with WPA capability. The Wi-Fi Alliance has created a test plan for WPA so vendors can ensure interoperability.

Cases in which the industry has run ahead of standards are not that uncommon. This has happened a number of times in modem technology and sometimes has led to two factions of the industry selling incompatible products. Fortunately, the Wi-Fi Alliance has avoided this type of a split and most manufacturers are supporting the Wi-Fi WPA specification.

WPA and RSN share a common architecture and approach. WPA has a subset of capability focused specifically on one way to implement a network, whereas RSN allows more flexibility in implementation. RSN also supports the AES^[1] cipher algorithm in addition to TKIP, whereas WPA focuses on TKIP.^[2] Because WEP is more commonly found in corporations today, a natural approach is to implement WPA now, upgrade installed systems as required, and then move towards a full RSN solution over a period of time as new products are deployed. Eventually, as the older products are retired, this will lead to a system based entirely on IEEE 802.11i. In this way, WPA provides for the needs of all the current Wi-Fi LAN users in the most common configurations, while in the long term the full RSN allows more flexibility.

RSN and WPA share a single security architecture under which TKIP- or AES-based security protocols can operate. This architecture covers procedures such as upper-level authentication, secret key distribution, and key renewal—all of which are relevant to both TKIP and AES. The RSN architecture is quite different from that of WEP and quite a bit more complicated. However, it provides a solution that is both secure and scalable for use in large networks. One of the huge problems for WEP, from the earliest days, was that it was impractical to manage key distribution once you had more than a few tens of users. That problem has been addressed by both RSN and WPA.

Nobody can ever (legitimately) claim that a security system is unbreakable. However, it is fair to say that the RSN/WPA approach was devised with the involvement of specialist security experts and received far more scrutiny from the cryptographic community than WEP did when it was being developed. WEP received this kind of scrutiny only after it was deployed and the result was humiliation. The design of RSN/WPA has had the full participation of security experts. That doesn't guarantee that it will not be broken next week. But we doubt it will and we wouldn't be wasting time writing this book if we thought otherwise.

IEEE 802.11 Task Group i had two objectives: to create a new scalable security solution and, of course, to provide effective protection against all known passive and active attacks. It was assumed that the new solution would completely replace WEP over time. Therefore, the solution developers started from scratch. The first and most important change in approach was the separation of the user authentication process and message protection (integrity and privacy). Authentication is the process by which you prove that you are eligible to join a network (and that the network is legitimate); and message protection ensures that once you have joined the network, you can communicate without risk of interception, modification, or any of a host of other security risks. Separation of user authentication and message protection allows a solution that can be scaled from small systems to entire corporations. However, the two parts must be linked together into a security context.

The concept of a security context is important to grasp and lies at the heart of the RSN.^[3] However, the idea of a security context is by no means unique to data communications. One simple example of a security context is your travel passport. The main purpose of a passport is for government officials to check who is entering and leaving the country. Countries want to allow their own citizens to come and go, hopefully freely. To do this, they need to provide their citizens with tangible evidence that they are, in fact, citizens.

When you first apply for a passport, you are required by your country's government to provide proof of your identity. This is at the heart of the passport system. In the context of people, it's not obvious how to go about this proof of identity. To some extent possession of special documents such as birth certificates and so on might help, but these are easily forged or stolen. Many countries rely on the evidence of other people to confirm who you are. For example, in Britain you are required to get a signed statement by a nonrelative of “suitable stature.” The list of qualifications for “suitable stature” is rather strange, but generally a minister of religion or a police officer would be an example. This person must have known you for a few years and sign the form to say so. The person's role is as a sort of certification authority trusted by you and the government.

So far so good—you have been authenticated, you sent in the forms, and the government has filed your picture in a large dusty vault and agrees that you exist. Now it is necessary that you have some token to prove that fact and, more importantly, that you are the person that was originally authenticated. This is the passport document. Most countries validate the passport by embedding the authenticated photograph. Some include fingerprints or descriptions of obvious features such as “no nose” or similar. Passports also have a limited duration, after which they are no longer valid.

When the government accepts your form, it establishes a security context. The passport proves that the context exists and that it refers only to you. Of course, this proof of context is extremely weak. It is relatively easy to fool the authentication process or modify the passport document. In particular, you can take over someone else's context by changing the picture in the passport. There are a lot of implicit trust relationships here. The immigration officer trusts the passport office not to issue fake passports, and the government agency trusts the immigration officer to perform a real check. This brings out the point that in authentication, you often have to trust other parties.

An RSN's security context has to be far stronger than that of a passport. However, the general concept is the same—an authentication process followed by a limited-life security context giving rights to the participants. A lot of the architecture of RSN relates to how to establish and maintain a security context between wireless LAN devices (usually a mobile device and an access point). The backbone of this context is the secret key.

Security relies heavily on secret keys. And security is completely lost if the keys are copied or stolen. In the passport example, the passport document is the rough equivalent of a key. It is not used for encryption or any such functions, but the assumption is that it cannot be copied (in other words, forged) and it will not be stolen or willingly given up. If either of these events occurs, the whole system breaks down.

In RSN the security context is defined by the possession of limited-life keys. Unlike with WEP, in RSN there are many different keys forming part of a key hierarchy, and most of these keys are not known before the authentication process completes. In fact, the creation of the keys is done in real time as the security context is established after authentication. Because they are created in real time, they are referred to as temporal keys. These temporal keys may be updated from time to time, but they are always destroyed when the security context is closed.

A key is basically a shared secret between two or more parties. Perhaps it would be more accurate to say that a key is any shared data that is useful only if it is kept secret. The magic word abracadabra is not very magical because everyone knows it and, by saying it, you're not actually doing anything. A real magic word is one that only a special group knows and that gives the group privileges or power. So it is with keys.

Keys can be used in two distinct ways. They can provide proof of your identity (such as a passport) and they can give access to services (such as the key to your car). Purists will point out that this is really the same thing because you get access to the service by proving that you are the person who has permission. However, the distinction is useful when looking at the way keys are used.

During the authentication phase, you have to prove your identity by demonstrating that you have knowledge of a secret. Passing this test entitles you to receive the other keys—those that open doors and start engines, for example. In the case of RSN, correctly authenticating enables you to receive or create the keys that are used for encryption and data protection. These useful keys are sometimes called the temporal or session keys because they work only so long as the security context is in place.

In principle, temporal keys can be created out of thin air. For example, when encrypting messages between two parties, you simply require that both parties (and only these parties) have the same key value. You don't care what that value is, so if you have a way that two parties can separately generate the same “random” number at roughly the same time, you can use that as the key. When you have finished communicating, you can just throw away the key.

Authentication is based on some shared secret information that cannot be created automatically. An authentication key must be created by someone trusted and attached to the holder in such a way that it can't easily be copied or stolen. And, of course, the trusted key giver has to be certain of the identity of the key receiver. The basis of all authentication methods, therefore, is that the entity that is to be authenticated possesses some special information in advance, which is called the master key. Using the master key in a way that protects it from discovery is very important. As a general rule, the master key is rarely, if ever, used directly; instead, it is used to create temporal keys. (WEP, of course, rode through this rule by using the master key both in authentication and encryption.)

In summary, there are two types of keys: a fixed or master key that provides proof of identity, and any number of temporal keys that are created or derived from the master key for use in the security protocol. Understanding this distinction helps to understand the way in which RSN is designed.

Despite the best efforts of social reformers, humans tend to organize things into layers when it comes to management. There was a fashion in the 1980s for start-up companies to be organized on a communal basis in which everyone was equally important and all meetings were open. Nice touch, but the reality is that every one of those companies that grew beyond a handful of people coalesced into a layer management structure very rapidly. People must have a limited scope of control in order to be effective. Therefore, if the organization is to scale up in size, you have to allow specialization of function and different levels of policy control.

So what's this got to do with Wi-Fi LANs? Well, in some ways, WEP was like the trendy start-up. All the security issues were bundled into a single simple package of measures and all were defined within a single standard. Quite distinct from the technical failings of WEP, this resulted in a solution that could not be scaled beyond a handful of devices. Some functions, such as encryption, are very local affairs and are only relevant to the Wi-Fi LAN hardware that is doing the actual communication. But other issues, in particular the decisions about who is allowed to access the network, have very wide importance and need to be consistent across an entire network.

For these reasons, it is necessary to identify and implement management layers in the security solution. This can be seen in the passport control system that involves layers of government from the immigration officer at the airport desk, through the passport administration center and up to the immigration policy decision makers in the Cabinet.

In the context of wireless LAN security, three layers are clearly identified. In fact, these layers are not specific to wireless LAN, but apply to any LAN-related security system. An advantage to choosing this layered model is that the RSN solution can fit into existing security architectures that have been deployed for other purposes and also leverage the standards that already exist.

The three layers of security are:

The wireless LAN layer is the worker. It is the job of this layer to deal with raw communications, advertising capabilities and accepting applications to join the network. The wireless LAN layer is also responsible for encrypting and decrypting the actual data once a security context is established.

The access control layer is the middle manager. It is the job of this layer to manage the security context. It must stop any data passing to or from an enemy. Here an “enemy” is defined as anyone who does not have a current security context established. The access control layer is fickle, and you can immediately change your status from enemy to friend when authentications occur and the security context is established. The access control layer talks to the authentication layer to know when it may open the security context and it participates in creating the associated temporal keys.

The most senior layer is the authentication layer. At this layer the policy decisions are made and proofs of identity are accepted (or rejected). In effect the authentication layer has power of veto over anyone who wants to join the LAN and delegates power to the access control layer once it approves the application for someone to join the LAN. The wireless LAN layer obviously resides in the wireless device contained in the access point. Usually the access control layer resides completely in the access point. Although in small systems the authentication layer might be in the access point also, in larger systems, the authentication layer is usually implemented in an authentication server quite separate from the access points. This ability to centralize the authentication server provides a scalable way to manage the user database. In other words, it solves the key management problems of WEP and makes it easier to integrate Wi-Fi LANs into the overall corporate security management system.

On a mobile station, there are similar layers. Typically, the wireless LAN layer is implemented in the Wi-Fi adapter card and its associated software drivers. The access control and authentication services may be implemented in the operating system or, for older systems, in the application level software provided by the manufacturer. Remember that it is very important that the mobile device also authenticates the network to ensure that it is not joining a fake network set up by an attacker. Figure 7.3 shows the relationship of all the layers and a typical example of where the layers operate. Note that in the figure “supplicant” refers to the part of the mobile device's operating system that makes the request to join the wireless LAN.

Figure 7.3. Relationship of Layers

The next few chapters cover a bewildering number of standards, mostly those of IEEE 802 and IETF (RFCs). The following reference list of all the standards that we mention should help you keep track of these standards and serve as a roadmap to indicate if and where they fit into the RSN picture. You may find you want to refer back here as the picture starts to form in your mind.

Pictorial Map

Figure 7.4 shows a pictorial map of the main standards used in an RSN solution based on TLS authentication. Inevitably the picture is a bit simplistic, but it shows how the TLS authentication process is buried inside a set of standards that provide the communications first between the mobile device and the access point and then between the access point and the authentication server. The links are shown as a set of concentric tubes; the outer tube is the communications medium and successive inner tubes are the encapsulations used to transport the information. As we said at the beginning of this section, we do not expect you to understand the whole picture from looking at Figure 7.4, but we hope it will form a reference point to which you can return.

Figure 7.4. Main Standards in an RSN Solution Based on TLS

In earlier chapters we alluded frequently to “the new security solutions.” We talked a lot about the difficulty of implementing good security and explained how the existing Wi-Fi security solutions had fallen short of what was needed. In this chapter we introduced IEEE 802.11i RSN and Wi-Fi Protected Access (WPA). This new generation of security methods will take over from WEP and finally meet the needs of both high security and scalability for large systems.

Systems based on RSN and WPA need not be complicated to install if the vendor has delivered all the pieces correctly. However, many pieces are required, and a full explanation takes some time. In this book we devote Chapters 8 through 12 to describing all the pieces and the way in which they depend on each other. To ease the learning process, in this chapter we have described a layered approach to thinking about the various components and have provided a map to show how the numerous standards fit together in an implementation.

As with many complicated systems, when all the pieces are put together it is not hard to understand what is going on. The difficulty is that in the beginning you can be overwhelmed by the number of pieces. To ease you through this burden, in the following chapters we lead you through the core access control descriptions first, and then look at the higher layers that provide the authentication. Finally we return to the wireless level to look at key distribution and implementation of the actual Wi-Fi security protocols.