And EAP Authentication Protocols

--->-—

->

RADIUS Server Authenticates Client

Client Authenticates RADIUS Server

<-

-<-

Derive

Derive

Key Management

WPA or CCKM Key Management Used

Protected Data Session

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

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.

Client

Access Point

Client

Access Point

Request/Identity

Identity

RADIUS Server

External

User Database

Access Point Blocks All Requests Until Authentication Completes

Identity eo

Establish a Secure Tunnel (PAC and TLS)

PAC-Opaque

PAC-Opaque

Server Authenticates Client - <—

Key Management

->- WPA or CCKM Key Management Used

Protected Data Session

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 nonWindows 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

Client

Client

RADIUS Server

Request/Identity

Access Point Blocks All Requests Until Authentication Completes

Request/Identity

Access Point Blocks All Requests Until Authentication Completes de teg

Key Management

->- WPA Key Management Used

Protected Data Session

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

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.

Client

Access Point

Client

Request/Identity

Access Point

RADIUS Server

External

User Database

Access Point Blocks All Requests Until Authentication Completes

Request/Identity

Access Point Blocks All Requests Until Authentication Completes eo dti

Key Management

WPA Key Management Used

Protected Data Session

As stated earlier, PEAP goes through two phases. As shown in Figure 9-5, in Phase 1, or the serverside 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 80211i Authentication and Key Management

Client

Security Capability Discovery

802.1x Authentication

802.1x Key Management

Four-Way Key Handshake

Two-Way Group Key Handshake

Authenticator