This book avoids focusing on vendor-specific or proprietary approaches. However, we make an exception for Cisco LEAP because it has been quite widely deployed and a number of authentication server manufacturers have added support in their RADIUS servers. LEAP, sometimes called EAP-Cisco Wireless, is interesting in that it was really the first commercial use of IEEE 802.1X and EAP for wireless LAN. The basic model used in LEAP is the same as that used in WPA, although the two should not be confused. LEAP is definitely not WPA. It falls far short of the security levels provided by WPA or RSN, but its introduction was farsighted and solved some real problems in wireless LAN deployment.
LEAP has not been standardized and the details have not been published. However, the protocol has been reverse-engineered and made public, enabling other vendors to implement compatible components. The information in this book is based on that publicly available material and a certain amount of inspired guesswork. Therefore, it cannot be guaranteed accurate. If you want the official details, you should apply to Cisco directly.
Consistent with IEEE 802.1X, LEAP divides the system into a supplicant, authenticator, and authentication server. The supplicant resides in the mobile device. At the time LEAP was introduced, workstation operating systems did not support IEEE 802.1X and special software and drivers had to be loaded for this function.
The authenticator resides in the access point. Naturally, such support was initially restricted to Cisco access points. Note that a generic IEEE 802.1X authenticator is not sufficient because of the way the encryption keys are handled. The access point must have specific support for LEAP as well as IEEE 802.1X.
The authentication server is implemented by a RADIUS server. LEAP follows the approach for EAP over RADIUS in RFC2869, although this RFC was still in draft form when LEAP was designed. It also uses proprietary RADIUS attributes to pass keys back from the server.
LEAP is a two-way challenge response protocol based on a shared secret key known to the authentication server and the mobile device (not the access point). It is based on the MS-CHAPv1 commonly used for remote dial-up authentication. Unlike conventional MS-CHAP, the authentication is mutual, with separate challenges being issued by the authentication server and the mobile device. This does not explicitly authenticate the access point itself. If a rogue access point could somehow be attached to the wired network with a connection to the authentication server, it could act as a "man in the middle" in the authentication exchange. However, the access point must have a legitimate security relationship with the authentication server to receive the session encryption key, so a rogue access point would be unable to send or receive encrypted data to the mobile device.
Once mutual authentication is completed, the session encryption key is sent to the access point in a RADIUS attribute. This attribute is encrypted using a secret shared between the access point and the server. The client also computes a copy of the session key. The key is not transmitted across the wireless link but is computed based on some nonce value. We do not know how this is done because it is a proprietary protocol, but our best guess is that is uses some combination of the challenge text exchanged during authentication. The access point signals successful authentication by sending an EAPOL-Success message to the mobile device. It then activates encryption by sending an EAPOL-Key message. The process is summarized here and shown in Figure 9.16:
The authentication server challenges the mobile device by sending a random string. The mobile device must prove it knows the key by sending a response derived from the challenge.
The mobile device sends a challenge to the authentication server, which must also respond correctly.
The authentication server generates and sends a session key to the access point with the EAP success notification in a RADIUS message.
The access point notifies the mobile device of authentication using the EAPOL-Success message. At this point the client computes the matching session key.
The access point sends an EAPOL-Key message to activate encryption. Note that this does not send the actual key; it is just a notification message.
The mobile device and access point communicate using WEP encryption.
On the wireless side LEAP uses IEEE 802.1X and EAPOL as described in Chapter 8 on access control. On the wired side LEAP uses EAP over RADIUS. The EAP type number for LEAP is 17.
LEAP embodies many of the base concepts that are now incorporated into WPA and RSN. However, WPA/RSN has added many more details that improve the overall security. LEAP originally ran over WEP, which has known weaknesses, although the ability of LEAP to generate temporary keys helps reduce the effectiveness of attacks. LEAP uses MS-CHAPv1, which is known to be vulnerable to some dictionary attacks. Overall, though, LEAP represented a major step forward in wireless LAN security when it was introduced, with the benefits of:
Mutual authentication
Temporary session keys
Centralized key management