Basic Choreography

Let's look at some of the relevant message exchanges to understand how the frames fit together to form cohesive and meaningful interactions.

Beacon

An AP sends the beacon message on a periodic basis. Figure 4-8 shows the beacon frame.

Figure 4-8. Beacon Frame


The beacon was designed as the primary discovery mechanism for the STAs to get a list of all APs in a BSS. However, this is terrible in terms of security because any wanderer can get the list of all APs, SSID, and capabilities. Therefore, inside enterprises, the periodic broadcasting of beacons is usually turned off. But for public WLANs and ad-hoc networks, this is turned on.

Probe

The probe exchange typically occurs between an STA and an AP. Figures 4-9 and 4-10 show the probe request and response frames.

Figure 4-9. Probe Request Frame


Figure 4-10. Probe Response Frame


The request information set field in the probe request frame is interesting; it is a list of element IDs for which the initiator wants details. The probe response would include the IDs and the appropriate information.

The probe response contains almost all the information in the beacon.

Authentication

Authentication involves a set of exchanges; Figures 4-11 and 4-12 show the pattern and the framework. The specific exchanges depend on the algorithm and the protocols. You will see them in detail in Chapter 5, "WLAN Basic Authentication and Privacy Methods," and Chapter 7, "EAP Authentication Protocols for WLANs."

Figure 4-11. Authentication Request Frame


Figure 4-12. Authentication Framework Pattern Choreography


Figure 4-11 shows how the authentication request frame would look with the relevant fields. The type is management (00), and the subtype is authentication (1011). The data field would depend on the actual algorithms and protocols.

The 802.11 specification defines the open and shared-key authentication. This is for device authentication only and uses MAC addresses as authentication criteria. The reason for this authentication is to achieve confidentiality of data transmission. Chapter 5 covers this in more detail.

For user authentication, the mechanics are based on EAP, which is covered in detail in Chapter 7.

Figure 4-12 shows a general, conceptual choreography framework and pattern that covers both device and user authentication.

In Step 1, the initiating STA (usually a laptop or a PDA) sends the authentication request frame with various pieces of information. The target STA (usually an AP) performs internal processing (2) or communicates with AAA systems such as RADIUS server (3).

Note

For device authentication, Step 2 is usually sufficient, whereas for user authentication, corporate AAA systems would also be used.


Many exchanges are possible and will happen between the initiating STA and the AP (4). Finally, the AP sends the result frame (5) with information and reason or status code.

Deauthentication

This is a one-way notification message with the frame format shown in Figure 4-13.

Figure 4-13. Deauthentication Frame


If an STA/client wants to deauthenticate from all APs, it inserts a broadcast address to the destination address field. The frame type is management (00) and subtype deauthentication (1100). The frame also contains a reason code.

Association

As shown in Figures 4-14 and 4-15, the association frames (request and response) are simpler frames than the authentication frames.

Figure 4-14. Association Request Frame


Figure 4-15. Association Response Frame


The data might include capability information, supported data rates, QoS features, and so on for the AP to decide whether an association would result in required performance characteristics. The response frame would include a status code and (optionally) a reason code.

Reassociation

The reassociation frames are similar to the association frames, as shown in Figure 4-16.

Figure 4-16. Reassociation Frame


This frame has four addresses: the STA, the AP to be associated with, the AP it is currently associated with, and the BSS ID.

Disassociation

Like the deauthentication message, this message is a one-way notification, as shown in Figure 4-17.

Figure 4-17. Disassociation Frame


The destination address could be a broadcast address if an AP wants to disassociate with all associated STAs?for example, if it is shutting down or reorganizing for better performance.

Data

The generic data frame is shown in Figure 4-18.

Figure 4-18. Generic Data Frame


The following are a couple of points to note:

  • The type is data (10), as is the subtype (0000).

  • The source, destination, and BSS ID would be embedded in the control frame.

Reason and Status Codes

Many of the responses and notifications incorporate information and context in the form of reason and status codes. Both the reason code and the status code are 2 bytes long and thus can carry 65,536 values. When 802.11 was first introduced, there were fewer than 15 reason codes and status codes. As more and more specifications are being developed, the reason and code tables are also getting bigger. In fact, while writing this book, an overlap was found for status codes 40 to 43 between the 802.11e and 802.11i working specifications; both had defined those four status codes. But after 802.11i was published, the 802.11e revised the codes to 47 through 50. Table 4-2 lists the reason and status codes.

Table 4-2. Reason Code Table

Reason Code

Description

0

Reserved.

1

Unspecified reason.

2

Previous authentications no longer valid.

3

Deauthenticated because sending station is leaving (or has left) IBSS or ESS.

4

Disassociated due to inactivity.

5

Disassociated because AP is unable to handle all currently associated stations.

6

Class 2 frame received from nonauthenticated station.

7

Class 3 frame received from nonassociated station.

8

Disassociated because sending station is leaving (or has left) BSS.

9

Station requesting (re)association is not authenticated with responding station.

10?12

Reserved.

13

Invalid information element.

14[i]

MIC failure.

15[i]

4-Way Handshake timeout.

16[i]

Group key update timeout.

17[i]

Information element in 4-Way Handshake different from (Re)Associate Request/Probe Response/Beacon.

18[i]

Multicast cipher is not valid.

19[i]

Invalid pairwise cipher.

20[i]

Invalid AKMP.

21[i]

Unsupported RSN IE version.

22[i]

Invalid RSN IE capabilities.

23[i]

IEEE 802.1X authentication failed.

24[i]

Cipher suite is rejected per security policy.

25?31

Reserved.

32[i]

Disassociated for unspecified, QoS-related reason.

33[i]

Disassociated because QAP lacks sufficient bandwidth for this QSTA.

34[e]

Disassociated because of excessive number of frames that need to be acknowledged but are not acknowledged for AP transmissions or poor channel conditions.

35[e]

Disassociated because QSTA is transmitting outside the limits of its TXOPs.

36?65,535

Reserved.

36[e]

Requested from peer QSTA because the QSTA is leaving the QBSS (or resetting).

37[e]

Requested from peer QSTA because it does not want to use the mechanism.

38[e]

Requested from peer QSTA because the QSTA received frames using the mechanism for which a setup is required.

39[e]

Requested from peer QSTA due to time out.

40?655,535

Reserved.

Legend:


[i] Added by 802.11i standard

[e] Added by 802.11e standard

Table 4-3. Status Code Table

Status Code

Description

0

Successful.

1

Unspecified failure.

2?9

Reserved.

10

Cannot support all requested capabilities in the capability information field.

11

Reassociation denied due to inability to confirm that association exists.

12

Association denied due to reason outside the scope of this standard.

13

Responding station does not support the specified authentication algorithm.

14

Received an authentication frame with an authentication transaction sequence number out of the expected sequence.

15

Authentication rejected because of challenge failure.

16

Authentication rejected due to timeout waiting for next frame in sequence.

17

Association denied because AP is unable to handle additional associated stations.

18

Association denied due to requesting station not supporting all of the data rates in the BSSBasicRateSet parameter.

19[b]

Association denied due to requesting station not supporting the Short Preamble option.

20[b]

Association denied due to requesting station not supporting the PBCC Modulation option.

21[b]

Association denied due to requesting station not supporting the Channel Agility option.

22[g]?24[g]

Reserved.

25[g]

Association denied due to requesting station not supporting the Short Slot Time option.

26[g]

Association denied due to requesting station not supporting the DSSS-OFDM option.

27?31

Reserved.

32[e]

Unspecified, QoS-related failure.

33[e]

Association denied due to QAP having insufficient bandwidth to handle another QSTA.

34[e]

Association denied due to excessive frame loss rates or poor conditions on current operating channel.

35[e]

Association (with QBSS) denied due to requesting station not supporting the QoS facility.

36[e]

Association denied due to requesting station not supporting Block Ack.

37[e]

The request has been declined.

38[e]

The request has not been successful because one or more parameters have invalid values.

39[e]

The TS has not been created because the request cannot be honored. However, a suggested TSPEC is provided so that the initiating QSTA can attempt to set another TS with the suggested changes to the TSPEC.

47[e]

The TS has not been created. However, the HC might be capable of creating a TS in response to a request after the time indicated in the TS Delay element.

48[e]

Direct Link is not allowed in the BSS by policy.

49[e]

Destination STA is not present within this QBSS.

50[e]

Destination STA is not a QSTA.

40[i]

Invalid information element.

41[i]

Invalid group cipher.

42[i]

Invalid pairwise cipher.

43[i]

Invalid AKMP.

44[i]

Unsupported RSN IE version.

45[i]

Invalid RSN IE capabilities.

46[i]

Cipher suite is rejected per security policy.

51?65,535

Reserved.

Legend:


[b] Added by 802.11b standard

[g] Added by 802.11g standard

[e] Added by 802.11e standard

[i] Added by 802.11i standard

WEP

Now that we have dealt with the basic mechanisms, the natural progression is to discuss the main feature of this book: security. The wireless nature of the medium adds two difficulties with respect to the wired medium:

  • The packets can be captured by anybody in the coverage area (as compared to the wired medium, where a person needs to connect to a jack using cables).

    Moreover, the coverage area does not conform to the physical organizational boundaries; the area often spans to outside the buildings, which enables the war-driving phenomenon. An attacker could be miles away. It is rumored that a person could drive down busy office streets of major cities and become connected to the LANs of Fortune 500 companies that have offices there.

  • Because anyone in the coverage volume can be connected to the wireless medium, we also need authentication mechanisms to interact with the medium.

The challenge is "securing the medium", so to speak, which is taken for granted in a wired environment. The 802.11 specification defines two authentication mechanisms and one confidentiality mechanism to balance the aforementioned difficulties.

Note

Remember, the pervasiveness and ubiquity of the wireless medium makes it attractive in many places and domains. For example, one would find it useful to have wireless connecting all home entertainment pieces; the same goes for guest access in enterprises, attendee access in conference centers, or access in airports, coffee houses, and other public places. So the key word is balance?achieving symmetry between the security mechanisms and the domain requirements.


The authentication methods defined in the 802.11 standard are open authentication and shared-key authentication, which are mainly aimed at device authentication. Chapter 5 covers the authentication methods and WEP in detail.

To achieve a robust wireless LAN, the specification defines WEP mechanisms, which aim to achieve the confidentiality equivalence of wires. Needless to say, the WEP proved to be less secure than intended and was deemed unsuitable for a secure wireless LAN. Chapter 6, "Wireless Vulnerabilities," delves into the common vulnerabilities of WLAN.