802.1X provides an extensible framework for controlling WLAN usage. But
802.1X is merely an envelope that carries some type of Extensible
Authentication Protocol (EAP).
Which of the 50 defined EAP Types would work best in your WLAN? In this
tip, we compare the most popular EAP Types used with 802.1X,
authentication methods that can be supported by each, known
vulnerabilities and suitable usage environments.
EAP-MD5 (Message Digest #5)
LEAP (Lightweight EAP)
EAP-TLS (Transport Layer Security)
EAP-TTLS (Tunneled TLS)
PEAP (Protected EAP)
EAP-MSCHAPv2 (Microsoft Challenge Handshake Protocol)
EAP-GTC (Generic Token Card)
EAP-SIM (Subscriber Identity Module)
EAP-AKA (Authentication and Key Agreement)
EAP-FAST (Flexible Authentication via Secure Tunneling)
Wi-Fi Alliance Certification
EAP-MD5 (Message Digest #5)
This EAP type provides one-way client authentication. The server sends the client a random challenge. The client proves its identity by hashing the challenge and its password with MD5. Because a man in the middle could see both the challenge and response, EAP-MD5 is vulnerable to dictionary attack when used over an open medium. Since there is no server authentication, it's also vulnerable to spoofing. Finally, EAP-MD5 cannot deliver keys. As a result, EAP-MD5 may be used over Ethernet but should never be used over a WLAN.
LEAP (Lightweight EAP)
Also known as EAP-Cisco Wireless, this EAP type provides mutual client and server authentication over Cisco WLANs. As with EAP-MD5, a LEAP server sends the client a random challenge, which the client uses to return a hashed password. The authenticated client challenges the server for its password, followed by a key exchange. Because LEAP is a proprietary protocol, it can only be used in corporate WLANs with Cisco APs and Cisco-compatible cards. Like EAP-MD5, LEAP is vulnerable to dictionary attack. Today, many attack tools can be used to crack LEAP-authenticated passwords, and better EAP types are widely supported by Cisco-compatible APs and cards. New WLANs should therefore avoid using LEAP.
EAP-TLS (Transport Layer Security)
This EAP type is generally regarded as the strongest available and the most expensive to deploy. It provides mutual certificate authentication between client and server, using the standard TLS protocol (a descendant of the SSL protocol used to secure most Web transactions.) The server uses TLS to demonstrate that it holds a digital certificate, requesting the same from the client. The client uses its certificate to prove its identity and keying material is exchanged. The TLS tunnel ends once authentication has been completed, but the keys delivered by EAP-TLS can be used to encrypt data with AES, TKIP or WEP. EAP-TLS is a good fit in WLANs where clients already have digital certificates or where high security needs justify investment in a public key infrastructure to manage those certificates.
EAP-TTLS (Tunneled TLS)
This EAP type balances security vs. deployment cost by replacing client-side certificates with legacy password authentication methods like PAP, CHAP and MSCHAPv2. EAP-TTLS requires the server to authenticate itself by certificate and establish a TLS tunnel through which to challenge the client. Even when a cleartext password is returned, the client's response is obscured by the TLS tunnel. To avoid exposing the client's name, EAP-TTLS should be configured to send an "anonymous" identity when 802.1X starts, then send the actual identity through the TLS tunnel. That tunnel ends when authentication is completed and keys are delivered. EAP-TTLS can be a good fit for WLANs that wish to reuse legacy user authentication databases (e.g., LDAP, Active Directory) in a secure fashion.
PEAP (Protected EAP)
PEAP is very similar to EAP-TTLS but uses different client authentication protocols. Like EAP-TTLS, PEAP provides mutual authentication, using server certificates, a TLS tunnel and client authentication through that encrypted tunnel. Unlike EAP-TTLS, PEAP requires the client to use another EAP type, like EAP-MSCHAPv2 or EAP-GTC (see below). Although the same user credentials can be used with EAP-TTLS, a PEAP authentication server must be able to parse both EAP and the contained legacy authentication protocols. Today, PEAP is more broadly supported than EAP-TTLS; the best choice for your network depends on the kinds of clients used in your WLAN.
Note: It is critical to use the same version of PEAP on clients and servers. PEAPv0/EAP-MSCHAPv2 requires 802.1X supplicant (client) software included in Windows Vista, Windows XP (SP2 or later), and Windows Mobile 6. PEAPv1/EAP-GTC requires another 802.1X supplicant, like the one installed with Cisco's Aironet Client Utility. These supplicants are mutually exclusive -- installing a PEAPv1 client replaces any existing PEAPv0 client.
EAP-MSCHAPv2 (Microsoft Challenge Handshake Protocol)
This EAP type can be used inside the TLS tunnel created by Protected EAP. EAP-MSCHAPv2 wraps Microsoft's Challenge Handshake Protocol inside the Extensible Authentication Protocol. It is a good fit for companies that want to reuse Microsoft user credentials and servers (e.g., NT Domain Controllers, Windows Active Directories) for wireless authentication. Similar goals can also be accomplished with EAP-TTLS/MSCHAPv2 when using a non-Microsoft wireless client to control connections (e.g., Juniper Odyssey).
EAP-GTC (Generic Token Card)
This EAP type can be used inside the TLS tunnel created by Protected EAP. EAP-GTC defines an EAP envelope to carry "one time passwords" generated by token cards like RSA SecurID. It is a good fit for companies that use two-factor authentication to avoid common password compromises (e.g., passwords shared with others, written on sticky notes, stored on stolen laptops) -- especially where such tokens are already in use by a remote access VPN. Those starting a WLAN from scratch must decide whether token deployment cost is justified, since EAP-GTC requires both third-party 802.1X supplicant software installation and token distribution.
EAP-SIM (Subscriber Identity Module)
This EAP type provides mutual authentication, based on the SIM card found in cellular telephones sold by GSM carriers. A SIM may be a small chip inserted into in a dual-mode phone, a wireless data card or a mobile broadband USB stick. That smartcard implements the authentication algorithm normally used by cellular handsets to authenticate to GSM telephone networks. 802.1X requests carrying EAP-SIM are relayed through the carrier's roaming gateway to a GSM authentication server. This type can be used to authenticate devices like smartphones that roam between commercial 802.11 hotspots and GSM networks.
EAP-AKA (Authentication and Key Agreement)
EAP-AKA is similar to EAP-SIM, but meets the needs of non-GSM carriers by using the User Service Identity Module (USIM) employed by Universal Mobile Telecommunications System (UMTS) networks. Although your carrier's network determines which type your smartphone must use, the permanent authentication keys used by EAP-AKA are considered stronger than the derived authentication keys used by EAP-SIM.
EAP-FAST (Flexible Authentication via Secure Tunneling)
This EAP type was created by Cisco as a replacement for LEAP; it is readily available today in Cisco APs and Cisco-compatible wireless cards. Like PEAP and EAP-TTLS, FAST provides tunneled mutual authentication. However, EAP-FAST does not require the server to authenticate itself with a digital certificate. Instead, a one-time provisioning exchange establishes a shared secret, called a Protected Access Credential (PAC) Key. That PAC Key is used for all subsequent authentications. EAP-FAST caters to small footprint clients, like VoWiFi handsets, that would be noticeably slowed by digital certificate signature verification.
Wi-Fi Alliance Certification
The Wi-Fi Alliance has long required the following EAP types for WPA2-Enterprise certification: EAP-TLS, EAP-TTLS, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC, and EAP-SIM. In May 2009, two optional types were added to this Wi-Fi Alliance test program: EAP-AKA and EAP-FAST. To determine which EAP types your products support, see the Wi-Fi Alliance's Certified Products page. Products that have not been certified may still interoperate, but it is wise to check for EAP type compatibility when deploying 802.1X in multi-vendor WLANs.
>> Read the next tip: How to configure VLANs with 802.1x for WLAN authorization
26 Jun 2009This EAP type provides one-way client authentication. The server sends the client a random challenge. The client proves its identity by hashing the challenge and its password with MD5. Because a man in the middle could see both the challenge and response, EAP-MD5 is vulnerable to dictionary attack when used over an open medium. Since there is no server authentication, it's also vulnerable to spoofing. Finally, EAP-MD5 cannot deliver keys. As a result, EAP-MD5 may be used over Ethernet but should never be used over a WLAN.
LEAP (Lightweight EAP)
Also known as EAP-Cisco Wireless, this EAP type provides mutual client and server authentication over Cisco WLANs. As with EAP-MD5, a LEAP server sends the client a random challenge, which the client uses to return a hashed password. The authenticated client challenges the server for its password, followed by a key exchange. Because LEAP is a proprietary protocol, it can only be used in corporate WLANs with Cisco APs and Cisco-compatible cards. Like EAP-MD5, LEAP is vulnerable to dictionary attack. Today, many attack tools can be used to crack LEAP-authenticated passwords, and better EAP types are widely supported by Cisco-compatible APs and cards. New WLANs should therefore avoid using LEAP.
EAP-TLS (Transport Layer Security)
This EAP type is generally regarded as the strongest available and the most expensive to deploy. It provides mutual certificate authentication between client and server, using the standard TLS protocol (a descendant of the SSL protocol used to secure most Web transactions.) The server uses TLS to demonstrate that it holds a digital certificate, requesting the same from the client. The client uses its certificate to prove its identity and keying material is exchanged. The TLS tunnel ends once authentication has been completed, but the keys delivered by EAP-TLS can be used to encrypt data with AES, TKIP or WEP. EAP-TLS is a good fit in WLANs where clients already have digital certificates or where high security needs justify investment in a public key infrastructure to manage those certificates.
EAP-TTLS (Tunneled TLS)
This EAP type balances security vs. deployment cost by replacing client-side certificates with legacy password authentication methods like PAP, CHAP and MSCHAPv2. EAP-TTLS requires the server to authenticate itself by certificate and establish a TLS tunnel through which to challenge the client. Even when a cleartext password is returned, the client's response is obscured by the TLS tunnel. To avoid exposing the client's name, EAP-TTLS should be configured to send an "anonymous" identity when 802.1X starts, then send the actual identity through the TLS tunnel. That tunnel ends when authentication is completed and keys are delivered. EAP-TTLS can be a good fit for WLANs that wish to reuse legacy user authentication databases (e.g., LDAP, Active Directory) in a secure fashion.
PEAP (Protected EAP)
PEAP is very similar to EAP-TTLS but uses different client authentication protocols. Like EAP-TTLS, PEAP provides mutual authentication, using server certificates, a TLS tunnel and client authentication through that encrypted tunnel. Unlike EAP-TTLS, PEAP requires the client to use another EAP type, like EAP-MSCHAPv2 or EAP-GTC (see below). Although the same user credentials can be used with EAP-TTLS, a PEAP authentication server must be able to parse both EAP and the contained legacy authentication protocols. Today, PEAP is more broadly supported than EAP-TTLS; the best choice for your network depends on the kinds of clients used in your WLAN.
Note: It is critical to use the same version of PEAP on clients and servers. PEAPv0/EAP-MSCHAPv2 requires 802.1X supplicant (client) software included in Windows Vista, Windows XP (SP2 or later), and Windows Mobile 6. PEAPv1/EAP-GTC requires another 802.1X supplicant, like the one installed with Cisco's Aironet Client Utility. These supplicants are mutually exclusive -- installing a PEAPv1 client replaces any existing PEAPv0 client.
EAP-MSCHAPv2 (Microsoft Challenge Handshake Protocol)
This EAP type can be used inside the TLS tunnel created by Protected EAP. EAP-MSCHAPv2 wraps Microsoft's Challenge Handshake Protocol inside the Extensible Authentication Protocol. It is a good fit for companies that want to reuse Microsoft user credentials and servers (e.g., NT Domain Controllers, Windows Active Directories) for wireless authentication. Similar goals can also be accomplished with EAP-TTLS/MSCHAPv2 when using a non-Microsoft wireless client to control connections (e.g., Juniper Odyssey).
EAP-GTC (Generic Token Card)
This EAP type can be used inside the TLS tunnel created by Protected EAP. EAP-GTC defines an EAP envelope to carry "one time passwords" generated by token cards like RSA SecurID. It is a good fit for companies that use two-factor authentication to avoid common password compromises (e.g., passwords shared with others, written on sticky notes, stored on stolen laptops) -- especially where such tokens are already in use by a remote access VPN. Those starting a WLAN from scratch must decide whether token deployment cost is justified, since EAP-GTC requires both third-party 802.1X supplicant software installation and token distribution.
EAP-SIM (Subscriber Identity Module)
This EAP type provides mutual authentication, based on the SIM card found in cellular telephones sold by GSM carriers. A SIM may be a small chip inserted into in a dual-mode phone, a wireless data card or a mobile broadband USB stick. That smartcard implements the authentication algorithm normally used by cellular handsets to authenticate to GSM telephone networks. 802.1X requests carrying EAP-SIM are relayed through the carrier's roaming gateway to a GSM authentication server. This type can be used to authenticate devices like smartphones that roam between commercial 802.11 hotspots and GSM networks.
EAP-AKA (Authentication and Key Agreement)
EAP-AKA is similar to EAP-SIM, but meets the needs of non-GSM carriers by using the User Service Identity Module (USIM) employed by Universal Mobile Telecommunications System (UMTS) networks. Although your carrier's network determines which type your smartphone must use, the permanent authentication keys used by EAP-AKA are considered stronger than the derived authentication keys used by EAP-SIM.
EAP-FAST (Flexible Authentication via Secure Tunneling)
This EAP type was created by Cisco as a replacement for LEAP; it is readily available today in Cisco APs and Cisco-compatible wireless cards. Like PEAP and EAP-TTLS, FAST provides tunneled mutual authentication. However, EAP-FAST does not require the server to authenticate itself with a digital certificate. Instead, a one-time provisioning exchange establishes a shared secret, called a Protected Access Credential (PAC) Key. That PAC Key is used for all subsequent authentications. EAP-FAST caters to small footprint clients, like VoWiFi handsets, that would be noticeably slowed by digital certificate signature verification.
Wi-Fi Alliance Certification
The Wi-Fi Alliance has long required the following EAP types for WPA2-Enterprise certification: EAP-TLS, EAP-TTLS, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC, and EAP-SIM. In May 2009, two optional types were added to this Wi-Fi Alliance test program: EAP-AKA and EAP-FAST. To determine which EAP types your products support, see the Wi-Fi Alliance's Certified Products page. Products that have not been certified may still interoperate, but it is wise to check for EAP type compatibility when deploying 802.1X in multi-vendor WLANs.
>> Read the next tip: How to configure VLANs with 802.1x for WLAN authorization
All Rights Reserved, Copyright 2000 - 2016, TechTarget | Read our Privacy Statement
0 comentários:
Postar um comentário