Editing Extensible Authentication Protocol (section)

==={{anchor|EAP-TLS}}EAP Transport Layer Security (EAP-TLS)===
EAP Transport Layer Security (EAP-TLS), defined in {{IETF RFC|5216}}, is an IETF [[open standard]] that uses the [[Transport Layer Security]] (TLS) protocol, and is well-supported among wireless vendors. EAP-TLS is the original, standard wireless LAN EAP authentication protocol.

EAP-TLS is still considered one of the most secure EAP standards available, although TLS provides strong security only as long as the user understands potential warnings about false credentials, and is universally supported by all manufacturers of wireless LAN hardware and software. Until April 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo.<ref>{{cite web|title=Understanding the updated WPA and WPA2 standards|url=http://blogs.techrepublic.com.com/Ou/?p=67|publisher=techrepublic.com|access-date=2008-02-17}}</ref> There are client and server implementations of EAP-TLS in 3Com, Apple, [[Avaya]], Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft, and open source operating systems. EAP-<span lang="Vi" dir="ltr">TLS</span> is natively supported in Mac OS X 10.3 and above, [[wpa_supplicant]], Windows 2000 SP4, Windows XP and above, Windows Mobile 2003 and above, Windows CE 4.2, and Apple's iOS mobile operating system.

Unlike most TLS implementations of [[HTTPS]], such as on the [[World Wide Web]], the majority of implementations of EAP-TLS require mutual authentication using client-side [[X.509]] certificates without giving the option to disable the requirement, even though the standard does not mandate their use.<ref name="opensecurewireless"/><ref name="rfc5216s211"/> Some have identified this as having the potential to dramatically reduce adoption of EAP-TLS and prevent "open" but encrypted access points.<ref name="opensecurewireless">{{cite web|title=Open Secure Wireless |first=Christopher |last=Byrd |date=5 May 2010 |url=http://riosec.com/files/Open-Secure-Wireless.pdf |access-date=2013-08-14 |url-status=dead |archive-url=https://web.archive.org/web/20131212085700/http://riosec.com/files/Open-Secure-Wireless.pdf |archive-date=12 December 2013 }}</ref><ref name="rfc5216s211">{{Cite IETF|rfc=5216|title=The EAP-TLS Authentication Protocol|date=March 2008|quote=The certificate_request message is included when the server desires the peer to authenticate itself via public key. While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means.}}</ref> On 22 August 2012 [[hostapd]] (and wpa_supplicant) added support in its [[Git (software)|Git]] repository for an UNAUTH-TLS vendor-specific EAP type (using the hostapd/wpa_supplicant project {{IETF RFC|5612}} Private Enterprise Number),<ref>{{cite web | title= Add UNAUTH-TLS vendor specific EAP type | work= [[hostapd]] | access-date= 2013-08-14 | url= http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=065d2895b4693e8c923580dbfa31123297c8bb7d | url-status= dead | archive-url= https://archive.today/20130213070147/http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=065d2895b4693e8c923580dbfa31123297c8bb7d | archive-date= 2013-02-13 }}</ref> and on 25 February 2014 added support for the WFA-UNAUTH-TLS vendor-specific EAP type (using the [[Wi-Fi Alliance]] Private Enterprise Number),<ref>{{cite web | title= HS 2.0R2: Add WFA server-only EAP-TLS peer method | work= [[hostapd]] | access-date= 2014-05-06 | url= http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=8e5fdfabf69a7692d1a0d04f00fa103e9ff72010 | url-status= dead | archive-url= https://archive.today/20140930045346/http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=8e5fdfabf69a7692d1a0d04f00fa103e9ff72010 | archive-date= 2014-09-30 }}</ref><ref>{{cite web | title= HS 2.0R2: Add WFA server-only EAP-TLS server method | work= [[hostapd]] | access-date= 2014-05-06 | url= http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=b61e70c4f37837baf17956817f8d80a586f75770 | url-status= dead | archive-url= https://archive.today/20140930045348/http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=b61e70c4f37837baf17956817f8d80a586f75770 | archive-date= 2014-09-30 }}</ref> which only do server authentication. This would allow for situations much like HTTPS, where a wireless hotspot allows free access and does not authenticate station clients but station clients wish to use encryption ([[IEEE 802.11i-2004]] i.e. [[WPA2]]) and potentially authenticate the wireless hotspot. There have also been proposals to use [[IEEE 802.11u]] for access points to signal that they allow EAP-TLS using only server-side authentication, using the standard EAP-TLS IETF type instead of a vendor-specific EAP type.<ref>{{cite web|title=Open Secure Wireless 2.0 |first=Christopher |last=Byrd |date=1 November 2011 |url=http://riosec.com/open-secure-wireless-2.0 |access-date=2013-08-14 |url-status=dead |archive-url=https://web.archive.org/web/20131126183610/http://riosec.com/open-secure-wireless-2.0 |archive-date=26 November 2013 }}</ref>

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. With a client-side certificate, a compromised password is not enough to break into EAP-TLS enabled systems because the intruder still needs to have the client-side certificate; indeed, a password is not even needed, as it is only used to encrypt the client-side certificate for storage. The highest security available is when the "private keys" of client-side certificate are housed in [[smart card]]s.<ref>{{cite book|url=https://books.google.com/books?id=5x7iLC7fKIAC&pg=PA244|title=Microsoft Exchange Server 2003 Unleashed|author=Rand Morimoto |author2=Kenton Gardinier |author3=Michael Noel |author4=Joe Coca|year=2003|publisher=Sams|isbn=978-0-672-32581-6|page=244}}</ref> This is because there is no way to steal a client-side certificate's corresponding private key from a smart card without stealing the card itself. It is more likely that the physical theft of a smart card would be noticed (and the smart card immediately revoked) than a (typical) password theft would be noticed. In addition, the private key on a smart card is typically encrypted using a PIN that only the owner of the smart card knows, minimizing its utility for a thief even before the card has been reported stolen and revoked.