Selecting EAP

RADIUS Aocess-Cnalwrigo

RADIUS Acoess-nequ-flst

<-

RADIUS AeC8S£"Aot»pl

Cisco Lightweight Extensible Authentication Protocol (LEAP) uses the concept of mutual authentication to validate a user. Mutual authentication relies on a shared secret and the user's password, which is known by the client and the network. The authentication server sends a challenge to the client. The client uses a one-way hash of the user password to send a response to the challenge. The server creates its own response based on the user database information and compares it to the response received from the client. When the server authenticates the client, the same process is repeated in reverse so the client can authenticate the server. When this process is completed, an EAP success message is sent to the client, and both the client and the authentication server derive the dynamic Wired Equivalent Privacy (WEP) key.

This type of mutual authentication reduces the risk of access point vulnerability to man-in-the-middle attack. However, as with MD5 authentication, the user password may be vulnerable to attackers.

EAP Transport Layer Security

EAP-TLS is a standard developed by Microsoft and accepted by the Internet Engineering Task Force (IETF) as RFC 2716. It is based on the Transport Layer Security (TLS) protocol as described in another standard (RFC 2246).

Similarly to Cisco LEAP method, EAP-TLS mutually authenticates the client and the server, but in this case, passwords are not used at all. Instead, Public Key cryptography based on the Rivest, Shamir, and Adelman (RSA) handshake is used. EAP-TLS uses digital certificates or smart cards to validate both the user and the server's identity.

Figure 17-6 shows the process of authentication via EAP-TLS.

Figure 17-6. EAP-TLS Authentication Process

[View full size imagel

A m lion lira [mn

Figure 17-6. EAP-TLS Authentication Process

[View full size imagel

A m lion lira [mn

Port Unaultiorrzed

Port Unaultiorrzed

ÈAF' FIcquf^LI^IIMTliry

EAP-HmpdnwHfe«liy. rtSHsim ^ U3 Hedo. Sera« Oen. CbM Reflues!

HADILia ftccees-Fteque^. T<_5Hello , i TLS Helkj, Server Cerl. Cerl Requesf Client Cen Miüesa-rtccei^

Port Auihorized

Enp-Lflson

Port Unaulhorized

As shown in Figure 17-6, the RADIUS server sends its certificate to the client in Phase 1 of the authentication sequence (server-side TLS). The client validates the RADIUS server certificate by verifying the issuer of the certificate, a certificate authority (CA) server entity, and the contents of the digital certificate. When this is complete, the client sends its certificate to the RADIUS server in Phase 2 of the authentication sequence (client-side TLS). The RADIUS server validates the client's certificate by verifying the issuer of the certificate (CA server entity) and the contents of the digital certificate. When this is complete, an EAP-Success message is sent to the client, and both the client and the RADIUS server derive the dynamic WEP key.

The advantage of EAP-TLS is that it may be configured for a two-factor authentication systems; it is one of the strongest forms of authentication today.

The cons of EAP-TLS are that it may be more complex to deploy because of the various components, such as a CA. It is also more computationally intensive on both the client and the server.

EAP-TLS is suited for large enterprise environments that only use Microsoft Windows XP/2000/2003 with deployed certificates.

Protected EAP

Protected EAP (PEAP) is an IETF draft RFC submitted by Cisco Systems, Microsoft, and RSA Security. PEAP does not have an internal method of client authentication. It supports various EAP-encapsulated methods within a protected TLS tunnel.

PEAP supports an extensible set of user authentication methods, such as one-time token authentication and password change or aging. It uses server-side digital certificate authentication based on the PKI standard. In environments where certificates are not issued to every client, PEAP can use a Microsoft Windows username and password instead by querying the Windows domain controller, Active Directory, or other existing user database (for example Lightweight Directory Access Protocol [LDAP], Novell NetWare Directory Services [NDS], and one-time password databases).

PEAP uses the same TLS mechanisms as EAP-TLS, but adds the record protocol for encryption.

Figure 17-7 shows the PEAP authentication process.

Figure 17-7. PEAP Authentication Process

[View full size imagel

As shown in Figure 17-7, Phase 1 of the authentication sequence is the same as that for EAP-TLS (server-side TLS). A server-side TLS authentication is performed to create an encrypted tunnel and complete server-side authentication. At the end of Phase 1, an encrypted TLS tunnel is created between the user and the RADIUS server for transporting EAP authentication messages.

In Phase 2, the RADIUS server authenticates the client through the encrypted TLS tunnel via another EAP type. As an example, a user can be authenticated using a one-time password (OTP) using the EAP-GTC subtype or MS-CHAP version 2 (as defined by the PEAP draft). The RADIUS server will relay the OTP credentials (user ID and OTP) to an OTP server to validate the user login. When this is complete, an EAP-Success message is sent to the client, and both the client and the RADIUS server derive the dynamic WEP key.

EAP Flexible Authentication via Secure Tunneling

EAP Flexible Authentication via Secure Tunneling (EAP-FAST) was developed by Cisco and is available in an IETF informational draft. Cisco developed EAP-FAST to support customers that require strong password policy enforcement but do not want to deploy digital certificates. EAP-FAST provides protection against a variety of network attacks, including man-in-the-middle, replay, and dictionary attacks.

EAP-FAST uses symmetric key algorithms to achieve a tunneled authentication process. The tunnel establishment relies on a Protected Access Credential (PAC) that can be provisioned and managed dynamically by EAP-FAST through the authentication server, such as the Cisco Secure Access Control Server.

Figure 17-8 shows the EAP-FAST authentication process.

Figure 17-8. EAP-FAST Authentication Process

[View full size imagel

Authenticating

Figure 17-8. EAP-FAST Authentication Process

[View full size imagel

Port

Unauthorized:

EAPQL-Slart

Port

Unauthorized:

EAPQL-Slart

^AP-HotuesiVioenwy i iP.fieSBfnMi.lrJtliBly, PEAP PiMUJGSi -^

^TLS Hello, Server Cerl. Cipher Change

Cipftei Chanjo. •• Key ■-——-- — —>

HAflUS AiCSiS'P«(Jt!Sl. Pi AP Riuiifi^ TLS Hella. Server Cerl. Cipher Change

Cipher CMnge, Session Key Si Mi Bntmlm! SAP Ayih

Port Authorized

EAR-Logtfl

Port Unauthorized'

Phase 1 establishes a mutually authenticated tunnel. The client and server use PAC to authenticate each other and establish a secure tunnel.

Phase 2 performs client authentication in the established tunnel. The client sends username and password to authenticate and establish client authorization policy.

Optionally, Phase 0 is used infrequently to enable the client to be dynamically provisioned with a PAC. During this phase, a per-user access credential is generated securely between the user and the network. This per-user credential, known as the PAC, is used in Phase 1 of EAP-FAST authentication.

EAP-FAST supports Microsoft Windows 2000, Windows XP, and Windows CE (Power PC 2002, Power PC 2003, and CE.Net 4.2) operating systems.

EAP Methods Comparison

Table 17-4 compares the various types of EAP as to network requirements.

Recommended Programs

Crypto Ultimatum

Secret Bitcoin Profits