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.
Figure 13.2. Mobile Device Supporting Both Supplicant and Authenticator
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
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.