Content deleted Content added
Davidburgess (talk | contribs) |
Mad Jim Bey (talk | contribs) Reverting edit(s) by 2A01:5EC0:B802:6196:B94B:9B56:F7D7:F8AF (talk) to rev. 1288312694 by Eveninglatte: Disruptive editing (RW 16.1) |
||
| (28 intermediate revisions by 17 users not shown) | |||
Line 1:
{{Short description|Authentication protocol for the point-to-point protocol}}
'''Extensible Authentication Protocol''' ('''EAP''') is an authentication framework frequently used in network and internet connections. It is defined in {{IETF RFC|3748}}, which made {{IETF RFC|2284}} obsolete, and is updated by {{IETF RFC|5247}}.
EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a [[wire protocol]]; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages. EAP is in wide use. For example, in [[IEEE 802.11]] (
==Methods==
EAP is an authentication framework, not a specific authentication mechanism.<ref name="rfc3748_sec1">
The standard also describes the conditions under which the AAA key management requirements described in
===Lightweight Extensible Authentication Protocol (LEAP)===
Line 17 ⟶ 18:
==={{anchor|EAP-TLS}}EAP Transport Layer Security (EAP-TLS)===
EAP Transport Layer Security (EAP-TLS), defined in
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">{{
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.
===EAP-MD5===
EAP-MD5 was the only IETF Standards Track based EAP method when it was first defined in the original RFC for EAP,
===EAP Protected One-Time Password (EAP-POTP)===
EAP Protected One-Time Password (EAP-POTP), which is described in
The EAP-POTP method provides two-factor user authentication, meaning that a user needs both physical access to a token and knowledge of a [[personal identification number]] (PIN) to perform authentication.<ref>{{cite web|url=http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/EAP-027.html |title=EAP-POTP Authentication Protocol |publisher=Juniper.net |access-date=2014-04-17}}</ref>
===EAP Pre-Shared Key (EAP-PSK)===
<ref name="rfc3748_sec1" /> EAP Pre-shared key (EAP-PSK), defined in
EAP-PSK is documented in an experimental RFC that provides a lightweight and extensible EAP method that does not require any public-key cryptography. The EAP method protocol exchange is done in a minimum of four messages.
===EAP Password (EAP-PWD)===
EAP Password (EAP-PWD), defined in
EAP-PWD is in the base of Android 4.0 (ICS)
{{anchor|EAP-TTLS}}
===EAP Tunneled Transport Layer Security (EAP-TTLS)===
{{Redirect|TTLS|the children's song|Twinkle, Twinkle, Little Star}}
EAP Tunneled Transport Layer Security (EAP-TTLS) is an EAP protocol that extends [[Transport Layer Security|TLS]]. It was co-developed by [[Funk Software]] and [[Certicom]] and is widely supported across platforms. Microsoft did not incorporate native support for the EAP-TTLS protocol in [[Windows XP]], [[Windows Vista|Vista]], or [[Windows 7|7]]. Supporting TTLS on these platforms requires third-party Encryption Control Protocol (ECP) certified software. [[Microsoft Windows]] started EAP-TTLS support with [[Windows 8]],<ref>[https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh945104(v=ws.11) Extensible Authentication Protocol (EAP) Settings for Network Access]</ref> support for EAP-TTLS<ref>{{cite web|url=http://forums.wpcentral.com/windows-phone-8/200619-802-1x-eap-ttls-support.html |title=802.1x / EAP TTLS support? – Windows Phone Central Forums |publisher=Forums.wpcentral.com |access-date=2014-04-17}}</ref> appeared in Windows Phone [[Windows Phone 8.1|version 8.1]].<ref>{{cite web|url=https://technet.microsoft.com/library/dn643706.aspx |title=Enterprise Wi-Fi authentication (EAP) |publisher=Microsoft.com |access-date=2014-04-23}}</ref>
Line 52 ⟶ 54:
After the server is securely authenticated to the client via its CA certificate and optionally the client to the server, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from [[eavesdropping]] and [[man-in-the-middle attack]]. Note that the user's name is never transmitted in unencrypted clear text, improving privacy.
Two distinct versions of EAP-TTLS exist: original EAP-TTLS (a.k.a. EAP-TTLSv0) and EAP-TTLSv1. EAP-TTLSv0 is described in
===EAP Internet Key Exchange v. 2 (EAP-IKEv2)===
Line 60 ⟶ 62:
;Symmetric keys: High-entropy bit strings that are known to both the server and the peer.
It is possible to use a different authentication [[credential]] (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key.
EAP-IKEv2 is described in
===EAP Flexible Authentication via Secure Tunneling (EAP-FAST)===
Flexible Authentication via Secure Tunneling (EAP-FAST;
EAP-FAST has three phases:<ref>{{cite web|url=http://www.ciscopress.com/articles/article.asp?p=369223&seqNum=5 |title=EAP-FAST > EAP Authentication Protocols for WLANs |publisher=Ciscopress.com |access-date=2014-04-17}}</ref>
Line 80 ⟶ 82:
|}
When automatic PAC provisioning is enabled, EAP-FAST has a
It is worth noting that the PAC file is issued on a per-user basis. This is a requirement in
EAP-FAST can be used without PAC files, falling back to normal TLS.
EAP-FAST is natively supported in Apple OS X 10.4.8 and newer. [[Cisco]] supplies an EAP-FAST module<ref>
=== Tunnel Extensible Authentication Protocol (TEAP) ===
Tunnel Extensible Authentication Protocol (TEAP;
In addition to peer authentication, TEAP allows the peer to ask the server for a certificate by sending a request in [[Certificate signing request|PKCS#10]] format. After receiving the certificate request and authenticating the peer, the server can provision a certificate to the peer in
===EAP Subscriber Identity Module (EAP-SIM)===
Line 102 ⟶ 104:
The A3/A8 algorithms are being run a few times, with different 128 bit challenges, so there will be more 64 bit Kc-s which will be combined/mixed to create stronger keys (Kc-s won't be used directly). The lack of mutual authentication in GSM has also been overcome.
EAP-SIM is described in
===EAP Authentication and Key Agreement (EAP-AKA)===
Extensible Authentication Protocol Method for [[Universal Mobile Telecommunications System]] (UMTS) Authentication and Key Agreement (EAP-AKA), is an EAP mechanism for authentication and session key distribution using the UMTS Subscriber Identity Module ([[Universal Subscriber Identity Module|USIM]]). EAP-AKA is defined in
===EAP Authentication and Key Agreement [[prime (symbol)#Use in mathematics, statistics, and science|prime]] (EAP-AKA')===
The EAP-AKA' variant of EAP-AKA, defined in
===EAP Generic Token Card (EAP-GTC)===
EAP Generic Token Card, or EAP-GTC, is an EAP method created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2 and defined in
===EAP Encrypted Key Exchange (EAP-EKE)===
EAP with the [[encrypted key exchange]], or EAP-EKE, is one of the few EAP methods that provide secure mutual authentication using short passwords and no need for [[public key certificate]]s. It is a three-round exchange, based on the [[Diffie–Hellman key exchange|Diffie-Hellman]] variant of the well-known EKE protocol.
EAP-EKE is specified in
==={{anchor|EAP-NOOB}}Nimble out-of-band authentication for EAP (EAP-NOOB)===
Nimble out-of-band authentication for EAP<ref>{{cite
EAP-NOOB performs an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) over the in-band EAP channel. The user then confirms this exchange by transferring the OOB message. Users can transfer the OOB message from the peer to the server, when for example, the device is a smart TV that can show a QR code. Alternatively, users can transfer the OOB message from the server to the peer, when for example, the device being bootstrapped is a camera that can only read a QR code.
==Encapsulation==
EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to [[Encapsulation (networking)|encapsulate]] EAP messages within that protocol's messages.<ref>{{
===IEEE 802.1X===
{{Main|IEEE 802.1X}}
The encapsulation of EAP over [[IEEE 802]] is defined in [[IEEE 802.1X]] and known as "EAP over LANs" or EAPOL.<ref>
When EAP is invoked by an 802.1X enabled [[Network Access Server]] (NAS) device such as an [[IEEE 802.11i-2004]] Wireless Access Point (WAP), modern EAP methods can provide a secure authentication mechanism and negotiate a secure private key (Pair-wise Master Key, PMK) between the client and NAS which can then be used for a wireless encryption session utilizing [[Temporal Key Integrity Protocol|TKIP]] or [[CCMP (cryptography)|CCMP]] (based on [[Advanced Encryption Standard|AES]]) encryption.
Line 136 ⟶ 138:
{{Main|Protected Extensible Authentication Protocol}}
The [[Protected Extensible Authentication Protocol]], also known as Protected EAP or simply PEAP, is a protocol that encapsulates EAP within a potentially encrypted and authenticated [[Transport Layer Security]] (TLS) [[tunneling protocol|tunnel]].<ref>
PEAP was jointly developed by Cisco Systems, Microsoft, and RSA Security. PEAPv0 was the version included with [[Microsoft]] [[Windows XP]] and was nominally defined in [http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 draft-kamath-pppext-peapv0-00]. PEAPv1 and PEAPv2 were defined in different versions of ''draft-josefsson-pppext-eap-tls-eap''. PEAPv1 was defined in [http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-00 draft-josefsson-pppext-eap-tls-eap-00] through [http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-05 draft-josefsson-pppext-eap-tls-eap-05],<ref>{{cite IETF|title=Protected EAP Protocol (PEAP)
The protocol only specifies chaining multiple EAP mechanisms and not any specific method.<ref name="peapv2-10_abstract"/><ref>{{cite IETF|title=Protected EAP Protocol (PEAP) Version 2
===RADIUS and Diameter===
Line 155 ⟶ 157:
{{Main|Point-to-Point Protocol}}
EAP was originally an authentication extension for the [[Point-to-Point Protocol]] (PPP). PPP has supported EAP since EAP was created as an alternative to the [[Challenge-Handshake Authentication Protocol]] (CHAP) and the [[Password Authentication Protocol]] (PAP), which were eventually incorporated into EAP. The EAP extension to PPP was first defined in
==See also==
Line 177 ⟶ 179:
* [http://wire.cs.nctu.edu.tw/wire1x/ WIRE1x]
* [https://web.archive.org/web/20071023234216/http://www.ietf.org/html.charters/emu-charter.html "IETF EAP Method Update (emu) Working Group"]
*
{{Authentication APIs}}
| |||