Let's look at some of the relevant message exchanges to understand how the frames fit together to form cohesive and meaningful interactions.
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.
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 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).
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.
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.
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.
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.
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.
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:
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.
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 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.
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.