Tuesday, February 9, 2010

Secure 802.11 WLANs

The WLAN industry recognized the vulnerabilities in 802.11 authentication and data privacy. To provide users with a secure WLAN solution that is scalable and manageable, the IEEE has augmented 802.11 security by developing enhancements to 802.11 authentication and encryption. The changes are being incorporated into the 802.11i draft standard. To date, the 802.11i draft has not been passed as a standard, so the Wi-Fi Alliance has put together an subset of the components of 802.11i called Wi-Fi Protected Access (WPA). This section details and explains 802.11i and WPA components.

Although this chapter has detailed 802.11 security as a combination of Open/Shared Key authentication and WEP encryption so far, many mistakenly believe WEP to be the only component to WLAN security. Wireless security actually consists of four facets:
  • The authentication framework— This facet is the mechanism that accommodates the authentication algorithm by securely communicating messages between the client, AP, and authentication server.
  • The authentication algorithm— This facet is the algorithm that validates the user credentials.
  • The data privacy algorithm— This facet provides data privacy across the wireless medium for data frames.
  • The data integrity algorithm— This facet provides data integrity across the wireless medium to ensure to the receiver that the data frame was not tampered with.

Facet 1: The Authentication Framework

The authentication framework in 802.11 is the 802.11 authentication management frame. The authentication frame facilitates Open and Shared Key authentication algorithms, yet the frame itself does not possess the ability to authenticate a client. Because the shortcomings of 802.11 authentication have already been highlighted, it is important to understand what is needed to provide secure authentication in a WLAN.

802.11 is missing some key components to provide effective authentication:
  • Centralized, user-based authentication
  • Dynamic encryption keys
  • Encryption key management
  • Mutual authentication

User-based authentication is critical for network security. Device-based authentication, such as Open or Shared Key authentication, does not prevent unauthorized users from using
authorized devices. Also, logistical issues, such as lost or stolen devices and employee termination, can force network administrators to manually rekey all 802.11 APs and clients. Centralized, user-based management via an authentication, authorization, and accounting (AAA) server, such as a RADIUS, lets you allow or disallow specific users, regardless of the specific devices they use.

The requirement for user-based authentication has a positive side effect: user-specific encryption keys. Authentication types that support the creation of dynamic encryption keys fit well into the WLAN security and management model. Per user, dynamic keys relieve the network administrator from having to statically manage keys. Encryption keys are dynamically derived and discarded as the user authenticates and disconnects from the network. Should you need to remove a user from the network, you only need to disable her account to prevent her access.

Mutual authentication is two-way authentication. The "two-way" nature comes from not only the network authenticating the client, but also the client authenticating the network. In Open and Shared Key authentication, the AP or network authenticates the client. The client does not know for sure that the AP or network is valid because no mechanism is defined in the 802.11 specification to allow the client to authenticate the network. As a result, a rogue AP or rogue client station can pose as a valid AP and subvert the data on the client's machine. Figure 4-17 diagrams one-way authentication versus mutual authentication.


802.11 WLAN vendors and the IEEE understand the need to augment and replace existing security mechanisms, both in authentication and encryption. Work is currently underway in task group I of the 802.11 working group, and after the changes are complete, the security specifications will be ratified as the 802.11i specification.

The IEEE has addressed the shortcomings of 802.11 authentication by incorporating the 802.1X authentication framework. 802.1X itself is an IEEE standard that provides all 802 link layer topologies with extensible authentication, normally seen in higher layers. 802.1X is based on a Point-to-Point Protocol (PPP) authentication framework known as the Extensible Authentication Protocol (EAP). In oversimplified terms, 802.1X encapsulates EAP messages for use at Layer 2. 802.11i incorporates the 802.1X authentication framework requiring its use for user-based authentication. Figure 4-18 illustrates 802.1X with respect to authentication algorithms and 802 link layer topologies.


EAP (RFC 2284) and 802.1X do not mandate the use of any specific authentication algorithm. The network administrator can use any EAP-compliant authentication type for either 802.1X or EAP authentication. The only requirement is that both the 802.11 client (known as the supplicant) and the authentication server support the EAP authentication algorithm. This open and extensible architecture lets you use one authentication framework in differing environments, where each environment may use a different authentication type. Examples of EAP authentication types include the following:
  • EAP-Transport Layer Security (EAP-PEAP)— Operates similar to Secure Sockets Layer (SSL) at the link layer. Mutual authentication is accomplished via server-side digital certificates used to create a SSL tunnel for the client to securely authenticate to the network.
  • EAP-Message Digest 5 (EAP-MD5)— Similar to the Challenge Handshake Authentication Protocol (CHAP), EAP-MD5 provides a password based, one-way authentication algorithm.
  • EAP-Cisco— Also known as LEAP, EAP-Cisco was the first EAP type defined specifically for use in WLANs. EAP-Cisco is a password-based, mutually authenticating algorithm.
802.1X authentication requires three entities:
  • The supplicant - Resides on the WLAN dient
  • The authenticator— Resides on the AP
  • The authentication server— Resides on the RADIUS server

No comments:

Post a Comment