802.1x and EAP Authentication Protocols

IEEE developed the 802.1x standard, called Extensible Authentication Protocol (EAP), so that LAN bridges/switches can perform port-based network access control. 802.1x was therefore considered a supplement to the IEEE 802.1d standard. The 802.1x (EAP) standard was quickly discovered and adopted for wireless LAN access control. Cisco Systems has supported the 802.1x authentication since December 2000.

Cisco Systems, Microsoft, and other vendors have developed several variations of EAP; different clients support one or more of those EAP varieties. 802.1x leverages many of the existing standards. Following are a few of the important EAP features and benefits:

■ The RADIUS protocol with a RADIUS server can be used for AAA centralized authentication. Users are authenticated based on usernames and passwords stored in an active directory available in the network (based on RFC 2284). The RADIUS server or Cisco Access Control Server (ACS) can use this directory. See Figure 9-1 in this topic.

■ Authentication is mutual between the client and the authentication server (RADIUS Server). The client software, which is required by the authentication protocols to participate in the authentication process, is commonly referred to as a supplicant.

■ 802.1x can be used with multiple encryption algorithms, such as AES, WPA TKIP, and WEP.

■ Without user intervention, 802.1x uses dynamic (instead of static) WEP keys. These WEP encryption keys are derived after authentication.


■ One-time password (OTP) can be used to encrypt plaintext passwords so that unencrypted passwords do not have to be sent over insecure connections/applications such as Telnet and FTP.

■ 802.1x supports roaming in public areas and is compatible with existing roaming technologies.

■ Policy control is centralized, as is management of the user database.

The components that are required for 802.1x authentication are an EAP-capable client (the supplicant), 802.1x-capable AP (the authenticator), and EAP-capable RADIUS server (the authentication server). Optionally, the authentication server may use an external user database.

Figure 9-1 shows these components.

Figure 9-1 801.2x (EAP) Authentication Components

801.2x (EAP) Authentication Components

The EAP-capable client requires an 802.1x-capable driver and an EAP supplicant. The supplicant may be provided with the client card, be native in the client operating system, or be obtained from the third-party software vendor. The EAP-capable wireless client (with the supplicant) sends authentication credentials to the authenticator. The authenticator is usually located at the enterprise edge, between the enterprise network and the public or semipublic devices. The authenticator sends the received authentication credentials to the authentication server. The authentication server refers to a user database to check the validity of the authentication credentials and to determine the network access level of a valid user. Some examples of authentication servers are Cisco Secure ACS, Microsoft IAS, and Meetinghouse Aegis. The local RADIUS database or an external database such as Microsoft Active Directory can be used for authentication. Authentication does not always use a RADIUS database or an external database; for example, Cisco IOS can perform local authentication based on the usernames and passwords stored in a device configuration (running-config). Please note however that local authentication is neither a scalable nor a secure authentication option.

EAP Authentication Protocols

802.1x does not provide LAN access to a client that is attempting access through a LAN switch port or a wireless AP until the client has been authenticated. Many authentication protocols are variations of EAP and work within the framework of 802.1x. The most popular protocols used in Cisco wireless networking environments are briefly discussed in the following sections.

Cisco LEAP

Cisco LEAP is one of the 802.1x authentication types for WLANs and, like the other EAP types, it is supported by Wi-Fi WPA and WPA2. Cisco LEAP supports strong mutual authentication between the client and a RADIUS server using a logon password as the shared secret, and it provides dynamic per-user, per-session encryption keys. Cisco LEAP is included with all Cisco wireless products, Cisco Aironet products, and Cisco-compatible client devices.

Following are the important capabilities that LEAP provides, making it somewhat unique compared to the other EAP variations:

■ Fast, secure roaming (Layer 2 and Layer 3) with Cisco or Cisco-compatible clients

■ True single login with an existing username and password using Windows NT/2000 Active Directory (or Domain)

■ Support for a wide range of operating systems (such as Microsoft, Macintosh, Linux, and DOS)

Following are the client operating systems that Cisco LEAP supports:

■ Microsoft Windows 98, XP, and CE

■ Mac OS (9.X or 10.X)

■ Linux (Kernel 2.2 or 2.4)

■ DOS

Following are the RADIUS servers and user databases that Cisco LEAP supports:

■ Cisco Secure ACS and Cisco Network (Access) Registrar

■ Meetinghouse Aegis

■ Interlink Merit

■ Funk Odyssey Server and Funk Steel-Belted

■ Products that use the Interlink Networks server code (such as LeapPoint appliances) Following are the Cisco wireless devices that Cisco LEAP supports:

■ Cisco Aironet autonomous APs and LWAPs

■ Cisco WLAN controllers

■ Cisco Unified Wireless IP Phone 7920 handset

■ Workgroup bridges, wireless bridges, and repeaters

■ Many Cisco and Cisco-compatible WLAN client devices

Figure 9-2 displays the Cisco LEAP authentication process. A wireless client can only transmit EAP traffic (no other traffic type) until a RADIUS server authenticates it. The authentication can be initiated by the client Start message or by the AP Request/Identity message. Either way, the client responds to the AP with a username. When the AP receives the username, it encapsulates it in the Access Request message (a RADIUS message type) and sends it to the RADIUS server. In the next two steps, the RADIUS server authenticates the client, and then the client authenticates the RADIUS server through a challenge/response process (through the AP).

Figure 9-2 Cisco LEAP

Cisco LEAP

In the challenge/response process, one party sends a challenge (a randomly generated bit sequence) to the other, and the other party sends a response back. The response is generated using an algorithm such as MD5, which takes the challenge, plus a password that both parties share, and perhaps other input such as a session ID. The benefit of the challenge/response process is that the shared password is not sent from one party to the other.

When the RADIUS server and the client successfully authenticate each other, they submit a Success (RADIUS) message to each other (through AP). Next, the RADIUS server and the client generate a pairwise master key (PMK). The RADIUS server sends its PMK to the AP so that the AP stores it locally for this particular client. Finally, the client and the AP, using the PMKs each hold, perform a four-way handshake that allows them to exchange encrypted traffic and have a protected data session.

EAP-FAST

Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) was developed by Cisco Systems and submitted to the Internet Engineering Task Force (IETF) in 2004. Cisco LEAP requires use of strong passwords; for a customer who cannot enforce a strong password policy and does not want to use certificates, migrating to EAP-FAST is a good solution because it provides safety from dictionary attacks. EAP-FAST is standards based (nonproprietary) and is considered flexible and easy to deploy and manage. Some of the main features and benefits of EAP-FAST are as follows:

■ Supports Windows single sign-on for Cisco Aironet clients and Cisco-compatible clients

■ Does not use certificates or require PKI support on client devices but does provide for a seamless migration from Cisco LEAP

Supports Windows 2000, Windows XP, and Windows CE operating systems

■ Provides full support for 802.11i, 802.1x, TKIP, and AES

■ Supports WPA and WPA2 authenticated key management on Windows XP and Windows 2000 client operating systems

■ Supports wireless domain services (WDS) and fast secure roaming with Cisco Centralized Key Management (CCKM)

■ Supports password expiration or change (Microsoft password change) EAP-FAST consists of three phases:

Phase 0 (provision PAC)—In this phase, the client is dynamically provisioned with a Protected Access Credential (PAC) through a secure tunnel. Phase 0 is considered optional, because PAC can be manually provided to the end-user client. PAC is used in

Phase 1 of EAP-FAST authentication. PAC consists of a secret part and an opaque part. It has a specific user ID and an authority ID associated with it.

Phase 1 (establish secure tunnel)—In this phase, the Authentication, Authorization, and Accounting (AAA) server (such as the Cisco Secure ACS v. 3.2.3) and the client use PAC to authenticate each other and establish a secure tunnel.

Phase 2 (client authentication)—In this phase, the client sends its credentials to the RADIUS server through the secure tunnel, and the RADIUS server authenticates the client and establishes a client authorization policy.

Figure 9-3 displays the EAP-FAST authentication process. A wireless client can transmit only EAP traffic (no other) until a RADIUS server authenticates it. First, the client sends an EAP over LAN (EAPOL) start frame to the AP, and the AP returns a request/identity to the client.

Figure 9-3 EAP-FAST

EAP-FAST

Next, the client sends its network access identifier (NAI) address to the AP, which in turn sends it to the RADIUS server. The client and the server then perform mutual authentication using Phase 1 and Phase 2 of EAP-FAST process, and the RADIUS server sends a session key to the AP in a Success packet.

After that, the client and the RADIUS server negotiate and derive a session key. (This process varies depending whether the client is using WEP or 802.11i.) The client and the AP use these keys during this session.

At the end of the session, the client sends an EAPOL-logoff packet to the AP, returning it to the preauthentication state (filtering all but EAPOL traffic).

EAP-TLS

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) uses the Transport Layer Security (TLS) protocol. TLS is an IETF standard protocol that has replaced the Secure Socket Layer (SSL) protocol. TLS provides secure communications and data transfers over public domains such as the Internet, and it provides protection against eavesdropping and message tampering. EAP-TLS uses PKI; therefore, the following three requirements must be satisfied:

■ The client must obtain a certificate so that the network can authenticate it.

■ The AAA server needs a certificate so that the client is assured of the server authenticity.

■ The certification authority server (CA) must issue the certificates to the AAA server(s) and the clients.

EAP-TLS is one of the original EAP authentication methods, and it is used in many environments. However, some customers are not in favor of using PKI and certificates for authentication purposes. The supported clients for EAP-TLS include Microsoft Windows 2000, XP, and CE, plus non-Windows platforms with third-party supplicants, such as Meetinghouse. EAP-TLS also requires a supported RADIUS server such as Cisco Secure ACS, Cisco Access Registrar, Microsoft IAS, Aegis, and Interlink. One of the advantages of Cisco and Microsoft implementation of EAP-TLS is that it is possible to tie the Microsoft credentials of the user to the certificate of that user in a Microsoft database, which permits a single logon to a Microsoft domain.

Figure 9-4 displays the EAP-TLS authentication process. The wireless client associates with the AP using open authentication. The AP restricts (denies) all traffic from the client except EAP traffic until the RADIUS server authenticates the client. First, the client sends an EAPOL start frame to the AP, and the AP returns a request/identity to the client.

Figure 9-4 EAP-TLS

EAP-TLS

Second, the client sends its NAI address to the AP, which in turn sends it to the RADIUS server. The client and the server then perform mutual authentication using an exchange of digital certificates, and the RADIUS server sends a session key to the AP in a Success packet.

Third, the RADIUS server and the client negotiate and derive the session encryption; this process varies depending on whether the client is using WEP or 802.11i. The client and the AP use these keys during this session.

At the end of the session, the client sends an EAPOL-logoff packet to the AP, returning it to the preauthentication state (filtering all but EAPOL traffic).

PEAP

Protected Extensible Authentication Protocol (PEAP) is yet another 802.1x authentication type for WLANs, submitted by Cisco Systems, Microsoft, and RSA Security to the IETF as an Internet Draft. With PEAP, only the server authentication is performed using PKI certificate; therefore, installing digital certificates on every client machine (as is required by EAP-TLS) is not necessary. The RADIUS server must have self-issuing certificate capability, you must purchase a server certificate per server from a PKI entity, or you must set up a simple PKI server to issue server certificates.

PEAP works in two phases. In Phase 1, server-side authentication is performed, and an encrypted tunnel (TLS) is created. In Phase 2, the client is authenticated using either EAP-GTC or EAP-MSCHAPv2 within the TLS tunnel. The two implementations are called PEAP-GTC and PEAP-MSCHAPv2. If PEAP-GTC is used, generic authentication can be performed using databases such as Novell Directory Service (NDS), Lightweight Directory Access Protocol (LDAP), and OTP. On the other hand, if PEAP-MSCHAPv2 is used, authentication can be performed using databases that support MSCHAPv2, including Microsoft NT and Microsoft Active Directory. PEAP-MSCHAPv2 supports single sign-on, but the Cisco PEAP-GTC supplicant does not support single logon.

Figure 9-5 displays the PEAP authentication process. The wireless client associates with the AP using open authentication. The AP restricts (denies) all traffic from the client except EAP traffic until the RADIUS server authenticates the client.

Figure 9-5 PEAP

PEAP

As stated earlier, PEAP goes through two phases. As shown in Figure 9-5, in Phase 1, or the server-side authentication phase, the client authenticates the server using a CA to verify the digital certificate of the server. Then the client and server establish an encrypted tunnel. In Phase 2, or the client-side authentication phase, the client submits its credentials to the server inside the TLS tunnel using either EAP-GTC or EAP-MSCHAPv2.

Next, the RADIUS server sends the session key to the AP in a Success packet, and the RADIUS server and client negotiate and derive a session encryption key. (This process varies depending whether the client is using WEP or 80211i.) The client and the AP use the session key during this session.

At the end of the session, the client sends an EAPOL-logoff packet to the AP, returning it to the preauthentication state (filtering all but EAPOL traffic).

WPA, 802.11i, and WPA2

WPA is a standards-based security solution introduced by Wi-Fi Alliance in late 2003 to address the vulnerabilities of the original 802.11 security implementations (WEP). The IEEE standard for security, IEEE 802.11i was ratified in 2004.

The most important features/components of WPA that you need to know and remember are as follows:

■ Authenticated key management—WPA performs authentication using either IEEE 802.1x or PSK prior to the key management phase.

■ Unicast and broadcast key management—After successful user authentication, message integrity and encryption keys are derived, distributed, validated, and stored on the client and the AP.

■ Utilization of TKIP and MIC— Temporal Key Integrity Protocol (TKIP) and Message Integrity Check (MIC) are both elements of the WPA standard, and they secure a system against WEP vulnerabilities such as intrusive attacks.

■ Initialization Vector Space Expansion—WPA provides per-packet keying (PPK) via IV hashing and broadcast key rotation. The IV is expanded from 24 bits (as in 802.11 WEP) to 48 bits.

Figure 9-6 displays the WPA (and 802.11i) authentication process. First, the client and the AP exchange the initial association request (probe request) and agree to a specific security capability. Next, the client and the authentication server (RADIUS server) perform the standard 802.1x authentication. Upon successful authentication, the authentication server generates and sends a master key to the AP; the client generates the same master key. These are called the PMK, which can be generated as a result of an 802.1x authentication process between the client and the server. The PMK can also be generated based on a 64-HEX character PSK. 

Figure 9-6 WPA and 802.11i Authentication and Key Management

WPA and 802.11i Authentication and Key Management

After completion of 802.1x authentication and 802.1x key management, the client and the AP perform a Four-Way Key Handshake and exchange a nonce, a WPA information element, a pairwise transient key (PTK), and MIC key information. This ensures validity of the AP and creates a trusted session between the client and the AP.

The final step is the two-way key handshake that the client and the AP exchange. The purpose of this handshake is to derive a group transient key (GTK), which provides a group key plus MIC keys (used for checking data integrity).

Following are the main shortcomings and issues of WPA:

■ Even though WPA uses TKIP, which is an enhancement to 802.11 WEP, it relies on the RC4 encryption. (RC4 has known shortcomings.)

■ WPA requires AP firmware support, software driver support for wireless cards, and operating system support (or a supplicant client). There is no guarantee that the manufacturers of all these components that you own will release upgrades to support WPA. Furthermore, because some vendors do not support mixing WEP and WPA (Wi-Fi Alliance does not support mixing WEP and WPA either), an organization wanting to deploy WPA has to replace a significant number of wireless infrastructure components.

■ WPA is susceptible to a specific DoS attack; if an AP receives two successive packets with bad MICs, the AP shuts down the entire basic service set (wireless service) for one minute. Furthermore, if small and noncomplex PSKs are used instead of 802.11i or EAP, an attacker who performs dictionary attacks on captured traffic can discover them.

Less than a year after the release of WPA by Wi-Fi Alliance, IEEE ratified the 802.11i standard (June 2004). 802.11i provides stronger encryption, authentication, and key management strategies for wireless data and system security than its predecessor, 802.11 WEP. Following are the three main components added by 802.11i:

■ 802.1x authentication

■ AES encryption algorithm

■ Key management (similar to WPA)

WPA2, the next generation or supplement to WPA, was developed by Wi-Fi Alliance and is interoperable with IEEE 802.11i. WPA2 implements AES as per the National Institute of Standards and Technology (NIST) recommendation, using Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP). Following are the key facts about WPA2:

■ It uses 802.1x for authentication. (It also supports PSKs.)

■ It uses a similar method of key distribution and key renewal to WPA.

■ It supports Proactive Key Caching (PKC).

■ It uses Intrusion Detection System (IDS).

Because of the nature of RF medium, the wireless standards mandate that IDS works at physical and data link layers. Wireless IDS addresses wireless and standards-based vulnerabilities with the following capabilities:

■ Detect, locate, and mitigate rogue devices.

■ Detect and manage RF interference.

■ Detect reconnaissance.

■ Detect management frames and hijacking attacks.

■ Enforce security configuration policies.

■ Perform forensic analysis and compliance reporting as complementary functions.

WPA and WPA2 have two modes: Enterprise mode and Personal mode. Within each mode is an encryption support and user authentication. Products that support both the PSK and the 802.1x authentication methods are given the term Enterprise mode. Note that for 802.1x authentication, an AAA/RADIUS server is required. Enterprise mode is targeted at medium to large medium to large environments, such as education and government departments. Products that only support PSK for authentication and require manual configuration of a PSK on the AP and clients are given the term Personal mode. (No authentication server is required.) Personal mode is targeted at small business environments such as small office, home office (SOHO). Table 9-2 displays the authentication and encryption methods that WPA and WPA2 use in Enterprise and Personal modes.

Table 9-2 WPA/WPA2 Enterprise and Personal Modes

Mode

WPA

WPA2

Enterprise mode

Authentication: IEEE 802.1x/EAP Encryption: TKIP/MIC

Authentication: IEEE 802.1x/EAP Encryption: AES-CCMP

Personal mode

Authentication: PSK Encryption: TKIP/MIC

Authentication: PSK Encryption: AES-CCMP

Even though WPA2 addresses the security shortcomings of WPA, an enterprise must consider the following WPA2 issues while evaluating and deciding to migrate to WPA2:

■ The wireless client (supplicant) must have a WPA2 driver that is EAP compatible.

■ The RADIUS server must support EAP.

■ Because WPA2 is more CPU-intensive than WPA (mostly due to usage of AES encryption), hardware upgrades are often required (rather than just firmware upgrades).

■ Some older devices cannot be upgraded, so they might need to be replaced.

Next post:

Previous post: