Issues in Pre-Standard IEEE 802.11i Implementations

Known security vulnerabilities in 802.11

The IEEE 802.1X standard focuses largely on use within wired networks. Utilizing IEEE 802.1X to secure 802.11 is the job taken on by IEEE 802.11 Task Group I. As a result, the IEEE 802.1X specification does not directly address known weaknesses in 802.11, including:

a. Use of 802.11 without encryption. Unencrypted 802.11 sessions are subject to snooping and hijacking, regardless of how the session is authenticated. As a result, customers desiring confidentiality and session hijacking protection should operate 802.11 networks with encryption enabled.

b. Weaknesses in WEP. The weaknesses of the WEP encryption scheme are well documented, and cannot be remedied merely by the application of enhanced authentication and key management schemes such as IEEE 802.1X.  For example, WEP lacks support for per-packet integrity protection and offers only weak encryption. This enables a wide variety of attacks, including insertion of packets into the data stream. As a result, customers with deployed 802.11 networks using WEP should consider transitioning to alternative ciphers under development by IEEE 802.11 Task Group I, such as TKIP and WRAP.

c. Lack of authentication for 802.11 management messages. 802.11 management messages include the beacon, probe request/response, association request/response, reassociation request/response, disassociation, and deauthentication. Without authenticating these management messages, denial of service attacks are possible.  IEEE 802.1X pre-authentication takes care of most of these vulnerabilities, since it enables authentication and key derivation prior to exchange of management frames. Customers should utilize these enhancements to 802.11 security when available.

Issues addressed in the current IEEE 802.11 TgI draft but not yet implemented

Since the IEEE 802.1X specification doesn't provide much guidance on how to adapt it for use with 802.11,  these issues are addressed in the IEEE 802.11 Task Group I documents.  These include the following functionality that may not be implemented in pre-standard versions of the protocol:

d. Mandatory mutual authentication. For use with IEEE 802.11, the IEEE 802.11 Tg I specification requires that supplicants and authenticators not send data traffic until mutual authentication is complete. Some pre-standard implementations do not support this. 802.11 Task Group I also mandates use of EAP methods providing mutual authentication, such as EAP SRP or EAP TLS. Most existing implementations do support this today, including Windows XP, which ships with support for EAP TLS.

e. Use of ciphers providing per-packet authentication as well as encryption. The IEEE 802.11 Tg I specification defines two new ciphersuites, TKIP and WRAP, both of which include support for per-packet integrity protection and confidentiality.  TKIP  should be available in the near future, can typically be deployed as an upgrade to existing access points, and includes support for a (weak) message integrity check. However, it is largely based on WEP, and as a result, is only a short term solution. Customers should be planning on migrating to AES-based ciphers such as WRAP in the long term, with keys provided by IEEE 802.1X.

Known issues with pre-standard IEEE 802.11 Tgi implementations

Since the demand for IEEE 802.11 Tgi implemenations has been fierce, many vendors are now shipping pre-standard implementations of it, some of which have encountered issues. Here are some of the things to watch out for:

f. Dictionary attacks on EAP methods. 802.11 frames, including 802.1X messages, are easily sniffed. For this reason, IEEE 802.11 Task Group I recomends EAP methods resistent to dictionary attack. It's worth heeding this advice, since dictionary attacks enable an attacker to recover the user password, which often can provide access to more than just the 802.11 network. Therefore these attacks are more serious than the previously documented WEP attacks and customers using 802.1X should strongly consider adopting dictionary attack-resistent authentication methods such as EAP TLS, SRP, TTLS and PEAP.

g. Attacks on the default key. Some early IEEE 802.1X implementations cannot use the per-session keys derived in IEEE 802.1X to encrypt the data. Instead, these implementations only encrypt data using the multicast/broadcast keys known in the 802.11 lingo as "default keys". Such implementations are vulnerable to many of the WEP attacks, particularly if the default keys are not automatically changed in a frequent and unpredictable way. Since Access Points typically do not have much randomness with which to change default keys securely, administrators may wish to automate this themselves using scripts or SNMPv3. Of course, for this to be secure, the Access Points need to support updating of the default key as well as secure management mechanisms such as SNMPv3 or SSH.

h. Denial of service attacks based on sending of EAPOL-Logoff frames. Since the EAPOL logoff frame is not authenticated an attacker can potentially spoof this frame, logging the user off the Access Point. Access Point vendors whose implementations are susceptible to these attacks should fix their implementations. Since the purpose of the EAPOL-Logoff frame is to signal disconnection, and this is already taken care of by the 802.11 Disassociation message (which can be authenticated) it is not clear that EAPOL-Logoff frame is really necessary with 802.11. As a result, Access Points should consider filtering these messages, and the IEEE 802.11 Tg I specification should clarifying this issue going forward.

i. Denial of service attacks based on sending of EAPOL-Start frames. An attacker can attempt to bring down an Access Point by flooding it with EAPOL-Start frames. Access Point vendors whose implementations are susceptible to these attacks should fix their implementations. The key to avoiding problems is not to allocate significant resources on receipt of an EAPOL-Start frame.

j. Denial of service attacks based on cycling through the EAP Identifier space. An attacker could attempt to bring down an Access Point by consuming the EAP Identifier space (0-255). Access Point vendors whose implementations are susceptible to these attacks should fix their implementations. Since the EAP Identifier is only required to be unique within a single Port or 802.11 Association, there is no need for an Access Point to lock out further connections once the Identifier space has been exhausted. This issue should be clarified in the revision to the IEEE 802.1X specification.

k. Denial of service attacks based on sending of premature EAP Success packets. The IEEE 802.1X specification enables a client to avoid bringing up its interface where the required mutual authentication has not been completed. This enables a well implemented Supplicant to avoid being fooled by a rogue Authenticator sending premature EAP Success packets. Supplicant implementations that are vulnerable to this attack should fix their implementations. This issue should be clarified within the revisions to the EAP and IEEE 802.1X specifications.

l. Denial of service attacks based on spoofing EAP Failure packets. The EAP specification requires clients to be able to rely on alternative indications of authentication success or failure. This enables a well implemented Supplicant to avoid being fooled by an attacker spoofing EAP Failure packets. For example, a Supplicant that receives an EAP-Failure from an Authenticator outside of an 802.1X exchange can ignore the packet. If the Authenticator wishes to remove the Supplicant, this will later be followed by a Disassociation frame, which can be authenticated. Supplicant implementations that are vulnerable to this attack should fix their implementations. This issue should be clarified within a revision to the EAP and IEEE 802.11 TgI specifications.

m. Denial of service attacks based on modification of EAP packets. Integrity protection and encryption of packets is supported within individual EAP methods. For example, the EAP TLS protocol provides integrity protection and encryption for authentication and key management exchanges, including indications of Failure (TLS Alert) and Success (Finished message). In addition, more recent proposals protect the entire EAP exchange by encapsulating it within TLS. These proposals are known as Protected EAP (PEAP) and Tunnelled TLS (TTLS). Customers wishing to address packet modification attacks should migrate to use of the EAP TLS, PEAP or TTLS protocols.

Paper by University of Maryland on IEEE 802.11 Tgi Security
Cisco response to University of Maryland paper