| Extensible Authentication Protocol |
Article Index for Extensible |
Shopping Extensible |
Shopping Protocol |
Website Links For Extensible |
Information AboutExtensible Authentication Protocol |
| CATEGORIES ABOUT EXTENSIBLE AUTHENTICATION PROTOCOL | |
| cryptographic protocols | |
| authentication methods | |
|
Extensible Authentication Protocol, or '''EAP''' (pronounced ''"eep"''), is a universal Authentication mechanism, frequently used in Wireless Networks and Point-to-Point Connections . Although the EAP protocol is not limited to wireless LAN networks and can be used for wired LAN authentication, it is most often used in wireless LAN networks. Recently, the WPA and WPA2 standard has officially adopted five EAP types as its official authentication mechanisms. EAP is an authentication framework, not a specific authentication mechanism. The EAP provides some common functions and a negotiation of the desired authentication mechanism. Such mechanisms are called EAP methods and there are currently about 40 different methods. Methods defined in IETF RFCs include EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-SIM, and EAP-AKA, and in addition a number of vendor specific methods and new proposals exist. Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP, and EAP-TTLS. When EAP is invoked by an 802.1X enabled NAS (Network Access Server) device such as an 802.11 a/b/g Wireless Access Point, modern EAP methods can provide a secure authentication mechanism and negotiate a secure PMK (Pair-wise Master Key) between the client and NAS. The PMK can then be used for the wireless encryption session which uses TKIP or AES encryption. LEAP The Lightweight Extensible Authentication Protocol (LEAP) is a Proprietary EAP implementation by Cisco Systems . Cisco has since made efforts to entrench the protocol by allowing other vendors to produce LEAP-compliant products through the CCX (Cisco Certified Extensions) program. There is no native support for LEAP in any Windows operating system but is supported by third party Supplicants (IEEE speak for client software). The protocol has been known from the beginning to be vulnerable to dictionary attacks just like EAP-MD5 but it wasn't until the release of ASLEAP by Joshua Wright in 2003 that people began to argue that LEAP was a serious security liability. Cisco still maintains that LEAP can be secure if sufficiently complex passwords are used, but complex passwords are rarely used in the real world because of the difficulty they pose for average users. Newer protocols like EAP-TTLS and PEAP do not have this problem because they create a secure TLS tunnel for the MS-CHAPv2 user authentication session and can operate on Cisco and non-Cisco Access Points. EAP-TLS EAP-TLS is an IETF Open Standard , and is well-supported among wireless vendors. It offers a good deal of security, since TLS is considered the successor of the SSL standard. It uses PKI to secure communication to the RADIUS authentication server, and this fact may make it seem like a daunting task to set up. So even though EAP-TLS provides excellent security, the overhead of client-side certificates may be its Achilles Heel . EAP-TLS is the original standard wireless LAN EAP authentication protocol. Although it is rarely implemented due to a steep deployment curve, it is still considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software including Microsoft. The requirement for a client-side certificate, however unpopular it may be, is what gives EAP-TLS its authentication strength and illustrates the classic convenience vs. security trade-off. A compromised password is not enough to break into EAP-TLS enabled systems because the hacker still needs to have the client-side certificate. When the client-side certificates are housed in smartcards, this offers the most secure authentication solution available because there is no way to steal a certificate's private key from a smartcard without stealing the smartcard itself. Any physical theft of a smartcard would be immediately noticed and revoked and a new smartcard would be issued. Up until April of 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo. There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source. EAP-TLS is natively supported in MAC OS 10.3 and above, Windows 2000 SP4, Windows XP, Windows Mobile 2003 and above, and Windows CE 4.2. EAP-MD5 EAP-MD5 is another IETF open standard, but offers minimal security. The MD5 Hash Function is vulnerable to Dictionary Attack s, and as used in EAP does not support dynamic WEP. EAP-TTLS EAP- Tunneled Transport Layer Security , or '''EAP-TTLS''', was co-developed by Funk Software and Certicom , and is currently an IETF draft open standard. It is widely supported across platforms, and offers very good security, using PKI certificates only on the authentication server. PEAP PEAP is a joint proposal by Cisco Systems , Microsoft and RSA Security as an open standard. It is already widely available in products, and provides very good security. It is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication. As of May of 2005, there were two PEAP sub-types certified for the updated WPA and WPA2 standard. They are:
PEAPv0/EAP-MSCHAPv2 This version of PEAP is defined through IETF Internet Draft "draft-kamath-pppext-peapv0-00". PEAPv1/EAP-GTC PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2. It allows the use of an inner authentication protocol other than Microsoft's MSCHAPv2. Even though Microsoft (along with RSA and Cisco) co-invented the PEAP standard, Microsoft never added support for PEAPv1 in general, which means PEAPv1/EAP-GTC has no native Windows OS support. Since Cisco has always favored the use of its own less secure proprietary LEAP and EAP-FAST protocols over PEAP and markets them as simpler certificate-less solutions, standardized PEAP is rarely promoted by Cisco. With no interest from Microsoft to support PEAPv1 and little interest from Cisco to promote PEAP in general, PEAPv1 authentication is rarely used. There is no native OS support for this EAP protocol. Note: The PEAP standard was created by Microsoft, Cisco, and RSA after EAP-TTLS had already come on the market. Even with its late start, Microsoft’s and Cisco’s size allowed them to quickly overtake EAP-TTLS in the market. Microsoft and Cisco parted ways when Microsoft only supported the PEAPv0 standard while Cisco supported both PEAPv0 and PEAPv1. PEAPv0 and PEAPv1 both refer to the outer authentication method and is the mechanism that creates the secure TLS tunnel to protect subsequent authentication transactions while EAP-MSCHAPv2, EAP-GTC, and EAP-SIM refer to the inner authentication method which facilitates user or device authentication. From Cisco’s perspective, PEAPv0 supports inner EAP methods EAP-MSCHAPv2 and EAP-SIM while PEAPv1 supports inner EAP methods EAP-GTC and EAP-SIM. Since Microsoft only supports PEAPv0 and doesn’t support PEAPv1, Microsoft simply calls PEAPv0 PEAP without the v0 or v1 designator. Another difference between Microsoft and Cisco is that Microsoft only supports PEAPv0/EAP-MSCHAPv2 mode but not PEAPv0/EAP-SIM mode. However, Microsoft supports another form of PEAPv0 (which Microsoft calls PEAP-EAP-TLS) that Cisco and other third-party server and client software don’t support. PEAP-EAP-TLS does require a client-side digital certificate located on the client’s hard drive or a more secure smartcard. PEAP-EAP-TLS is very similar in operation to the original EAP-TLS but provides slightly more protection due to the fact that portions of the client certificate that are unencrypted in EAP-TLS are encrypted in PEAP-EAP-TLS. Since few third-party clients and servers support PEAP-EAP-TLS, users should probably avoid it unless they only intend to use Microsoft desktop clients and servers. Ultimately, PEAPv0/EAP-MSCHAPv2 is the only form of PEAP that most people will ever know. PEAP is so successful in the market place that even Funk Software, the inventor and backer of EAP-TTLS, had no choice but to support PEAP in their server and client software for wireless networks. This version of PEAP is defined through the IETF internet draft "draft-josefsson-pppext-eap-tls-eap-05." EAP-FAST EAP-Flexible Authentication Via Secure Tunneling is a proposal by Cisco Systems to fix the weaknesses of LEAP. Use of server certificates is optional in EAP-FAST. EAP-FAST uses a Protected Access Credential (PAC). The PAC can be provisioned manually or dynamically in Phase 0 of EAP-FAST. EAP-FAST has three phases. Phase 0 is an optional phase. In Phase 1 the client and the AAA server uses the PAC to establish TLS tunnel. In Phase 2, the client sends user information across the tunnel. EAP-FAST is defined through IETF Internet Draft "draft-cam-winget-eap-fast-03". EAP-SIM EAP For GSM Subscriber Identity is used for authentication and session key distribution using the Global System for Mobile Communications ( GSM ) Subscriber Identity Module ( SIM ) EAP-AKA EAP For UMTS Authentication And Key Agreement is used for authentication and session key distribution using the Universal Mobile Telecommunications System ( UMTS ) UMTS Subscriber Identity Module ( USIM ) SEE ALSO EXTERNAL LINKS
|
|
|