Chapter 13 covers a range of topics. We look at the process by which a mobile device is able to find an access point and join the network. This leads to a discussion on how the mobile device and access point ensure they have compatible security properties and how a mobile device might be able to roam from one access point to another which incurring a large delay due to the authentication process.
In the second half of the chapter, we revisit the IBSS or ad-hoc style of network. Such networks do not use access points and present extra problems for security implementation. In this chapter we look at the solution proposed by the IEEE 802.11i standards group.
A Wi-Fi LAN needs to be coordinated at many levels. At the lowest levels the IEEE 802.11 standard specifies procedures to synchronize timing and avoid multiple devices transmitting at the same time. At higher levels there are procedures to enable smooth joining and exiting from the network. We are interested in these higher-level procedures because they impact on the security operations.
Most Wi-Fi LAN systems are organized with one or more access points and a number of clients. A typical home installation has one access point and two or three clients. A large corporate network might have hundreds of access points and thousands of clients. In IEEE 802.11, networks of this type are called infrastructure mode or ESS networks. IEEE 802.11 also supports a mode called ad-hoc or IBSS network. The significant difference is that in IBSS mode, there is no access point and any mobile device can talk to any other directly. On the face of it, IBSS is simpler and more efficient for small networks but creates management problems because no one device is in control.
As we described in Chapter 5, both types of networks are controlled using management messages that are independent of the actual data being passed from device to device. The management and control messages allow the network to share the available transmission time efficiently and also enable the access point to exercise control of the network. For a review of the types of messages used, look again at Chapter 5.
From an architectural point of view, IBSS presents quite a few problems for security. If you have an access point, you can give that access point the responsibility for checking the credentials of new devices and, because all the data must pass through, it can effectively block unwelcome devices. However, in the IBSS case you cannot enforce effective controls because any device can talk to any other. We come back to this issue later in the chapter. For now, though, let's review the procedures and messages that allow the access point to maintain control in an ESS network.
The original IEEE 802.11 required that a new mobile device (an aspirant device) must pass two phases before being allowed to join the network. The first phase is an authentication exchange whereby the aspirant device is supposed to prove its credentials to the access point. We now know that the original method was very insecure, but the basic idea was to block any unwanted devices by rejecting them at an early stage. If an aspirant device passes the authentication phase it is then required to associate to the access point. The process of association is intended to check that the capabilities of the device and the access point are compatible and negotiate some of the variable parameters such as data rate. Once a device is associated, it must send all its data frames to the access point, which will then be responsible for forwarding the data on to its destination.
If the device decides to move to another access point, perhaps for better signal strength, it is required to dissociate from the current access point before associating with the new one. No device can be associated with two access points at the same time. By contrast, in the original IEEE 802.11 standard, it is acceptable to authenticate with another access point in advance, to reduce time during the handover.
In RSN/WPA we cannot use so simple a system. RSN/WPA is based on IEEE 802.1X and EAP. From the point of view of IEEE 802.11, EAP messages are not management or control frames. They do not belong to IEEE 802.11 and are therefore treated like ordinary data frames. Before we can even start the IEEE 802.1X process, an aspirant device must already be connected (in other words, associated) with the access point. This turns the process of joining on its head because it means that association must be done before authentication! The network is protected by blocking data until the IEEE 802.1X and key handshakes have occurred.
For WPA/RSN the management messages that are used for authentication in the older systems are still used, but they play no part in security. However, the management messages for association still have an important role and are used in negotiating the security method to be used. To see how this is done, let's quickly review the message sequences.
The access point sends out beacon messages, usually about ten times a second. The beacons include information about the capabilities of the access point and also serve as a timing reference for some of the protocol operations such as power saving modes. Here we are concerned with the ability of the beacons to advertise capabilities. The items to be advertised include things like the network name or SSID, the supported data rates, and so on.
When a mobile device is looking for an access point with which to connect, it can listen on each radio channel for beacons or it can speed things up by issuing a probe request that basically says, “Is anybody there?” An access point receiving the request can reply immediately with a probe response, essentially with the same information as a beacon. This process allows a new mobile device to scan around quickly and find the access points available. It also allows a connected device to keep one eye open for other access points with better signal strength that might be candidates for roaming.
Once a device has identified a target access point, it attempts to pass the two stages of authentication and association. For WPA/RSN, the access point allows open authentication. This simply means that the authentication exchange is two messages:
The mobile device asks to be authenticated.
The access point says “OK.”
No actual authentication is performed; it is just a null process.
The second part is more important. The device sends an association request to the access point. This tells the access point about the capabilities of the device and also specifies which capabilities of the access point the device wants to use. Assuming the access point finds these acceptable, it generally sends an association response, allowing the device to join the network. In the case of RSN and WPA, the device must then complete the IEEE 802.1X procedure and the pairwise key handshake before sending data.
The messages that pass capabilities information include capability bits and Information Elements, as described in Chapter 5. RSN/WPA systems have a specific Information Element that is used to negotiate the type of security that will be used. This works as follows. If an access point supports either RSN or WPA (or both), it includes in its beacon and probe response an Information Element with the following information:
Whether the access point is using preshared key or authentication server (key management)
What group security mechanism is operating
A list of one or more pairwise key security mechanisms that are supported
For example, a company that is transitioning from WEP to WPA might use WEP for broadcast (group) security and allow either WEP or TKIP on a device-by-device basis. The Information Element would inform WPA devices and they would select to use WEP/TKIP. The older WEP stations would not understand the new Information Element and would continue to use WEP/WEP, which is acceptable in this case. Later, the company might discontinue the use of WEP and the Information Element would indicate TKIP for broadcasts and only TKIP for pairwise connections.
If that same company then migrated to RSN, it might start advertising TKIP for broadcast and a choice of AES or TKIP for pairwise connections. The Information Element for RSN is not quite the same as for WPA and may contain more information. RSN is indicated by a capability bit and, if this bit is set, the default is to use AES–CCMP for both group and pairwise connections. The Information Element would be needed only if, as in the example above, a choice was offered.
The Information Element (IE) described so far is sent by the access point in beacons and probe responses. The mobile device must also include an Information Element in its association request if it wants to use the security capabilities. Although the IE sent by the access point might have a list of protocols to choose, the one sent with the association request must indicate only a single choice. This is the selection made by the mobile device and defines the protocol that will be used from that point on.
If the access point advertises a choice of TKIP or WEP, the mobile device may legitimately select to use WEP. This would be pretty strange, though. If the mobile device understands the Information Element, it must support WPA or RSN, so why would it choose an inferior security system like WEP? The simple answer is that it would not—unless there had been foul play. This example leads us to a potential weakness that must be prevented.
Suppose an attacker watches an access point and makes a note of what information is sent in probe responses. Remember that these messages are not encrypted; they are open for all to see. Suppose the access point is offering both TKIP and WEP. Now a new mobile device arrives and issues a probe request. The access point responds, but the attacker goes into action and blocks the response by transmitting some well-timed garbage. The attacker now forges a message that looks exactly like the valid response except that it offers only WEP as a choice. The mobile device thinks the access point only supports WEP and associates with this choice. The access point might think this is strange, but it appears quite valid. What the attacker has achieved is to force the mobile device to use a weaker security method; he has successfully weakened the target system.
To prevent this type of attack, both the access point and the mobile device send another copy of the valid Information Element during the pairwise four-way handshake. The four-way handshake is protected against any sort of tampering so, although the attacker can substitute the modified Information Element in the original response, he can't substitute it in the four-way handshake. Therefore, by keeping a copy of the original message, both the mobile device and the access point can detect the attack and drop the connection.
In this example, protection of the Information Element sent by the mobile device seems less important. Suppose the mobile device selects TKIP and indicates this in its association request. There wouldn't be much point in an attacker changing the selection to WEP because, even if accepted by the access point, not much will happen when the mobile device sends TKIP-encrypted frames to an access point that is expecting WEP! However, there is another reason for protecting the mobile device's selection. This is a more subtle reason and is associated with the process of preauthentication described in the next section.
If you have a mobile device and move around a reasonably sized network, you need to roam. Or, to be more specific, your mobile device has to switch from one access point to another due to the limited coverage area of each access point. Ideally, you would like this to happen so fast that you, the user, don't notice it happening. You don't want your laptop to freeze up for a few seconds each time it happens and, worse still, you don't want it to come back with a “network failure” message in the middle of a file transfer.
To achieve this type of seamless handover, you need the switchover to be very fast, preferably milliseconds. This has two implications. First, you need the switchover to occur before you get outside the coverage area of the access point you are currently using. Second, you want the new access point to accept you as quickly as possible so you can continue operation. Security presents a problem for the second objective.
If you wait until the switchover before starting the authentication process, it could take a few seconds before the access point lets you back onto the network. This is especially true if you are using upper-layer authentication needing the services of some remote authentication server. One way to get around this problem is to do the authentication in advance so the access point is ready to let you join as soon as you are ready. The process is called preauthentication.
The original IEEE 802.11 WEP system allowed preauthentication using the simple authenticate messages. However, these messages are not relevant to RSN or WPA. We need to perform full authentication using IEEE 802.1X, including upper-layer authentication if required. The superficial difficulty is that we can't talk to the new access point until after we have associated with it—or can we? Remember, we do have an existing connection with the old access point, which, if we are doing things right, is still connecting us to the wired network. Clearly the new access point must be on the same wired network if the roaming operation is to make any sense. Therefore, we should be able to talk to the new access point via its wired connection. Although we may detect the new access point from the radio signal, we preauthenticate using the wired infrastructure. This is shown in Figure 13.1.
In principle, communicating via the wired network allows the mobile device to perform all the same EAP operations that would typically be performed wirelessly after association. This includes the conversation with a remote authentication server as well as the four-way pairwise key exchange and the group key exchange. Because all the messages are sent in EAPOL messages, they can travel equally well over a wired or wireless LAN. We say “in principle” because, although it is practical, this approach does drive a dump truck through the underlying architecture assumptions in IEEE 802.1X and causes sleepless nights among the standards purists. The problem is that technically the IEEE 802.1X authenticator controls a data port that is created when the station associates. But with preauthentication, no such port exists yet. You can think of ways to deal with this problem by creating a temporary port that get connected later, but it is a bit messy.
If preauthentication is done, the mobile can have an entire set of keys already in place at the point where it roams and associates with the new access point. If the new access point can map the mobile device onto the temporary IEEE 802.1X port that was authorized earlier, it can resume communication immediately. This is where we make further use of the copies of the Information Element that are included with the four-way handshake. When the mobile device preauthenticates, it needs to inform the authenticator which type of cipher it is going to use. This information is provided in the Information Element sent with the handshake. When the mobile device finally roams, the new access point needs to check that it has selected the same cipher in the association request that it selected during the handshake.
Several times we have mentioned IBSS networks, also called ad-hoc networks, and deferred discussion on the security issues. This section finally looks at these issues in detail and discusses a solution that may be available. At the time of writing, WPA does not provide a security solution for IBSS.
Chapter 7 discusses the security context. Security operations take place within a limited context that has a clear start and end. In other words, the context is created by some actions and closed by some other actions. This approach maps quite well into networks with an access point because the access point has master control of the local network. It is a place where the authenticator can reside and all the mobile devices can establish and break a security context with that authenticator.
The major advantage of an IBSS network is that there is no master device. All devices have equal status and any device can talk to any other device. This is also the major problem with IBSS networks from a security standpoint.
First, let's quickly review how an IBSS network operates. Suppose a group of people get together in a conference room for a meeting and they want to share information among their laptop computers. They agree on an SSID or network name that they will use for their meeting and configure it into their laptops, specifying IBSS operation. When the first laptop is enabled, it starts looking for beacons containing the target SSID. It ignores beacons from access points and looks only for beacons from other devices in IBSS mode. If it doesn't see any beacons, it realizes that it is the first arrival and starts sending beacons itself.
The next laptop to turn on sees the beacon from the first laptop, with the correct SSID, and synchronizes its timing. Now the two devices may share the process of sending beacons according to an algorithm defined in the IEEE 802.11 standard. If the first station goes away, the second one sends all the beacons by itself. If any device has a broadcast message to send, it just transmits and all the others listen. If any device wants to send a frame to another device, it just transmits with the target device's MAC address as the destination. Note that there is no process of association and devices can come and go as they please without any hellos or goodbyes.
In our simple example, this works very nicely. All the people in the conference room are within range of each other and all the laptops can communicate. If somebody goes out of range, they are cut off; there is no concept of roaming. Now we come to the security problem.
The conference participants might realize that their session is incredibly insecure. Not only can outsiders see their data, but anyone can join in the network just by observing the SSID over the air. What they would like is to agree on a password at the start of the meeting, limit access only to those who know the password, and encrypt the data. On the face of it, this seems straightforward, but what does it mean to “limit access to those who know the password”? Because there is no coordinator, every mobile device has to block the unwelcome newcomer and because there is no association, how do you set up encryption that needs things like sequence numbers and exchanges of nonces?
This is the problem with IBSS. Intuitively, it seems simple to share a password around the table and just encrypt the data with it. But good security is never simple. It's easy to say things like, “Oh well, it's good enough for this application; after all, meetings only last an hour or so.” But this is the path that leads to problems, as we saw with WEP. Eventually people use the technology in areas in which it is “no longer good enough” and then security breaches occur. Consider that some people have proposed to use IBSS mode to implement ad-hoc neighborhood mesh networks for broadband connection to the home. A simple solution that might be good enough for short meetings will certainly fail in such an application.
There are solutions that can work and are secure. Unfortunately, they are not simple. The current proposal for IEEE 802.11i works as follows. First, let's assume that every mobile device has two personalities. When it wants to talk to another device, it assumes the role of a supplicant. When someone else wants to talk to it, it assumes the role of an authenticator. Think of a football team playing at home or away; the mobile device is either visiting (as a supplicant) or hosting (as an authenticator). This is shown is Figure 13.2, in which the role played by the device depends on the direction of communications.
Now that we have established the roles of supplicant and authenticator, we can apply the principles of IEEE 802.1X. Of course we can't use upper-layer authentication because there is no way to attach to a common authentication server. However, we can use a preshared key, which is quite appropriate for the meeting case in which the master key is distributed verbally. Once we have the preshared key and IEEE 802.1X in place, we can almost use the same approach for IBSS as we did for ESS. We can use the four-way handshake to establish pairwise keys, including the exchange of nonces. We can also use the Information Element to establish the starting value of the sequence counter. “Almost” is the operative word here because there are a couple of problems yet to solve.
The first issue is that, if we follow this model to the letter, we have to establish separate pairwise keys for each direction of communication. There are two supplicants and two authenticators, which is inefficient and unnecessary. Therefore, the device with the lowest MAC address goes first and establishes the temporal keys, and then the authenticator in the other direction uses the same set without further ado.
The second issue is more difficult. What do we do about the group keys? Intuitively, you would think that the group keys would be shared by all the devices in the IBSS. However, there are a number of problems with this approach. Who would be responsible for creating the group key given that there is no master? And how does the group key get distributed to everyone when you don't know who else is out there? To solve this problem, we need to go back to first principles and remind ourselves of the purpose for the group key. It is to protect multicasts and broadcasts, not to allow “any to any” communication. Multicasts are one to many communications, not many to many.
In the case of an ESS network, the “one” is always the access point. In the case of an IBSS network, the “one” is the device currently transmitting the multicast. It follows that there can be a separate group key for each mobile device that is used only when that particular device is sending a multicast. Providing all the intended recipients (the “many”) know the sender's group key, they can receive the message. The sender is now responsible for maintaining its own group key and for delivering it to all the other devices with which it has a pairwise key relationship.
So now we have the IBSS security solution. It is complicated. Ironically, the fact that ad-hoc networks are so simple to set up makes them more complicated to secure. In summary, the process is as follows
The first device starts up and begins beaconing.
The second device starts up, detects the beacons, and synchronizes.
Whichever device has the lower MAC address now acts as a supplicant and authenticates to the other device using IEEE 802.1X. It then performs the four-way pairwise handshake to establish temporal keys derived from a shared master secret.
Both devices now send the other their group key.
At this point the two devices can communicate privately. Now a third device arrives and wants to join the network. It must first synchronize and then perform separate pairwise key handshakes with each of the two existing devices. It must then share its group key with both the other stations and receive a group key from each of them. It has to remember five sets of keys (including its own group key).
At this point you start to see the complexity. In general, if there are N devices in the ad-hoc network, each must keep track of 2*N–1 keys. So for 16 devices, you need to track 31 sets of keys to remain connected. This is the problem: The solution does not scale to large numbers of devices. However, given that all the devices have to be in a single wireless cell so they can all hear each other, maybe that is not too much of a price to pay. At least it's secure.
This brief chapter collects together the loose ends left over after the substantial chapters describing the security protocol. We started by reviewing the process by which mobile devices join to an access point. We then explained the use of the WPA/RSN Information Element that is employed in the negotiation of security capabilities between the mobile device and the access point.
After considering the process for joining a network, we looked at the issue of roaming from one access point to another. A problem is created if a full authentication handshake is needed every time such a roam occurs because the authentication exchange could take a second or even more. At the time of writing, there are a number of proposals for “fast roaming” using preauthentication or cached keys. We looked at one example of a preauthentication scheme.
Finally we returned to the difficult issue of security in IBSS (ad-hoc) networks. In this case the lack of a central coordinating device such as the access point creates a problem. We reviewed the approach for IBSS security as defined for IEEE 802.11i.