Wireless security: Extensible authentication protocols
Wireless security uses a family of Extensible Authentication Protocols, EAP, for the mutual authentication of a client (supplicant) and an authenticator; the authenticator in most cases would be a wireless access point (AP), with or without an authentication server. EAP is an authentication framework that specifies methods of secure key distribution and usage. There are approximately 40 EAP methods in use (see chart). Each method uses varying degrees of security and adds security features such as dynamic key distribution, encrypted tunnels, key rotation, digital certificates and user, rather than device, authentication. It should be noted that EAP authentication methods are used almost exclusively for enterprise level networks with hundreds or thousands of clients; small office and home office (SOHO) networks rarely have a need for this level of security.
EAP has two primary features: It provides a segregated message exchange, which ties into the second feature, extensibility. EAP is a common Layer 2 security framework in which many different authentication mechanisms can be used. These authentication mechanisms are dynamically selected, based on the negotiation between the supplicant and authenticator; the authentication mechanism negotiation and selection occurs separately from any other action being performed on the data, such as network protocol encapsulation.
Wireless requests and replies
All flavors of EAP use a three-party model: the party requesting access (the supplicant); the party requesting authentication (the authenticator); and the authentication server (AS), which contains authorized user databases and issues permissions. In wireless applications, the most common supplicant is a mobile device wishing to access a network. The authenticator is usually a wireless access point (AP). The AS is a dedicated server, often referred to as the network access server. The must common designation is remote access dial-in user service (RADIUS). In many installations, one device, usually a wireless AP, handles the authenticator and AS tasks. The authenticator controls two virtual ports: the controlled and uncontrolled ports. The initial exchanges between the supplicant and authenticator take place over the uncontrolled port; upon successful authentication, the authenticator opens the controlled port to the supplicant.
The main purpose of EAP is to authenticate the supplicant and authorize it to use network resources. The basic EAP framework follows: The supplicant requests access after Open System Authentication. An exchange of EAP messages over the uncontrolled port ensues; upon successful authentication, the supplicant is allowed access to the controlled port. Subsequently, encryption keys are generated and distributed over the secure channel (controlled port); secure communication is achieved. All EAP mechanisms follow this same basic protocol of identity exchange, verification, and key distribution; some mechanisms authenticate only one party.
EAP Messages are encapsulated in EAP Over LAN (EAPOL) frames. There are five types of EAPOL frames:
- EAP-Packet: The most common type, used in request/response frame exchanges
- EAPOL-Start: Used by the supplicant to start the EAP process; optional
- EAPOL-Logoff: Used to terminate the EAP session and shut down the secure port
- EAPOL-Key: Used during the 4-way handshake to exchange dynamic encryption keys
- EAPOL-Encapsulated-Alert: Used to send alerts to the virtual ports.
The generic supplicant-authenticator-authentication server EAP process is illustrated in Figure 1:
Common extensible authentication protocols
Here are the most common implementations of EAP:
EAP-TLS: Extensible authentication protocol-transport layer security. This method uses mutual authentication and pre-issued digital certificates. The supplicant and authenticator exchange digital certificates to prove their respective identities. A certificate authority, or certificate server, is used to create and store the certificate information for each entity. This method uses public key encryption methods, which will be discussed in the next blog. Implementing EAP-TLS requires additional cost and administration overhead, but provides a very high level of security and integrity.
EAP-TTLS: EAP-tunneled TLS. This method provides all of the benefits of EAP-TLS, but does not require the use of digital certificates from the supplicant. The authenticator must prove its identity by providing a digital certificate, which is the authenticator’s "public" key. In public key encryption there are two keys: the public key and the private key. Using this key, the supplicant can encrypt communication with the authenticator, forming a secure virtual "tunnel" between the two. Once the tunnel is set up, the supplicant can authenticate using several methods, either EAP or password based. Client-side certificates may be used but are not required. Elimination of the client-side certificate substantially reduces the cost and overhead required.
PEAP: Protected EAP. PEAP is similar to EAP-TLS in that it creates an encrypted TLS tunnel through which the supplicant’s identity is authenticated. PEAP is probably the most common and widely supported EAP method used for WLAN security. PEAP encapsulates other EAP methods within the TLS tunnel—"EAP within EAP." PEAP comes in three major versions:
- EAP-PEAPv0 (MSCHAPv2): Uses the Microsoft challenge handshake authentication protocol. Very commonly used, uses username and password for authentication; client side certificates are not used or supported.
- EAP-PEAPv0 (EAP-TLS): Also used as a stand-alone authentication method as shown above; uses an encrypted tunnel to validate client-side certificates. No username or password is used.
- EAP-PEAPV1 (EAP-GTC): EAP-generic token card. Developed by Cisco to provide interoperability with existing security token systems such as RSA SecurID. This iteration also allows the use of plaintext usernames and passwords within a secure tunnel.
LEAP: Lightweight EAP. Developed by Cisco, LEAP is easy to deploy, but is proprietary and primarily used in Cisco-based networks. It supports supplicants that do not support EAP. LEAP supports RADIUS, mutual authentication, and a wide range of EAP mechanisms. Though a certificate is required at the authenticator for secure tunnel setup, supplicant authentication can be accomplished by several methods, including certificates and password-based schemes. Authenticator authentication is not mandatory, leaving the network vulnerable to rogue access points impersonating an authentication server. LEAP is considered a weak method of authentication.
EAP-MD5: EAP-message digest 5 is perhaps the simplest to implement for WLANs, the most insecure mechanism, and has largely been abandoned. MD5 authenticates by the authenticator sending a challenge to the supplicant consisting of a random string. The supplicant responds by sending the challenge, the random string, and the password "hashed" to the authenticator. MD5 only authenticates the supplicant; this makes MD5 susceptible to rogue access points and "man-in-the-middle" attacks. MD5 is considered a weak method of authentication and is not used.
EAP-FAST: EAP-flexible authentication via Secure Tunneling. Originally a Cisco proprietary authentication method, it was developed as a replacement for LEAP. This method supports both mutual authentication and tunneled authentication like other methods mentioned above. It also uses asymmetric and symmetric encryption methods during authentication. Another difference is that EAP-FAST does not use digital certificates to create the encrypted tunnel; it uses a protected access credential (PAC). A PAC is a shared secret that is developed on an authentication server and installed on the supplicant(s). The PAC is derived from a master encryption key and is unique to each supplicant identity. While very secure if implemented properly, EAP-FAST can be vulnerable to man-in-the-middle attacks in certain instances.
Included is a chart listing the various flavors of EAP. It contains enough information to allow the interested reader to find more information about these mechanisms.
– Daniel E. Capano, owner and president, Diversified Technical Services Inc. of Stamford, Conn., is a certified wireless network administrator (CWNA), firstname.lastname@example.org. Edited by Chris Vavra, production editor, CFE Media, Control Engineering, email@example.com.
See other wireless tutorials from Capano on the following topics:
Wireless security: Port-based security, EAP, AKM
Wireless security: IEEE 802.11 and CCMP/AES
Wireless security legacy, background
See wireless webcasts, some for PDH credit.
Control Engineering has a wireless page.