Extensible Authentication Protocol: Difference between revisions

Revision as of 06:33, 28 June 2022

Latest revision as of 12:02, 4 August 2025

(24 intermediate revisions by 14 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]] (WiFiWi-Fi) the WPA and WPA2 standards have adopted IEEE 802.1X (with various EAP types) as the canonical authentication mechanism.

==Methods==

Line 42:

EAP Password (EAP-PWD), defined in {{IETF RFC|5931}}, is an EAP method which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.

EAP-PWD is in the base of Android 4.0 (ICS),. itIt is in FreeRADIUS <ref>[http://code.metager.de/source/xref/freeradius/server/src/modules/rlm_eap/types/ FreeRADIUS EAP module rlm_eap_pwd]</ref> and Radiator <ref>{{cite mailing list|url=http://www.open.com.au/pipermail/radiator-announce/2012-June/000018.html|title=Added support for EAP-PWD per RFC 5931|first=Mike|last=McCauley|mailing-list=radiator-announce}}]</ref> RADIUS servers, and it is in hostapd and wpa_supplicant.<ref>[http://community.arubanetworks.com/t5/Technology-Blog/Secure-authentication-with-only-a-password/ba-p/36524 Secure-authentication with only a password]</ref>

{{anchor|EAP-TTLS}}

Line 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 {{IETF RFC|5281}}, EAP-TTLSv1 is available as an Internet draft.<ref>[//tools.ietf.org/html/{{cite IETF|draft=draft-funk-eap-ttls-v1-01|title=EAP TTLSv1Tunneled InternetTLS draft]Authentication Protocol Version 1 (EAP-TTLSv1)}}</ref>

===EAP Internet Key Exchange v. 2 (EAP-IKEv2)===

Line 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. In particularHowever, not all of the followingnine theoretical combinations are expected toin bepractice. usedSpecifically, inthe practicestandard {{IETF RFC|5106}} lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key.

EAP-IKEv2 is described in {{IETF RFC|5106}}, and a [http://eap-ikev2.sourceforge.net prototype implementation] exists.

Line 82:

|}

When automatic PAC provisioning is enabled, EAP-FAST has a slight vulnerability where an attacker can intercept the PAC and use that to compromise user credentials. This vulnerability is mitigated by manual PAC provisioning or by using server certificates for the PAC provisioning phase.

It is worth noting that the PAC file is issued on a per-user basis. This is a requirement in {{IETF RFC|4851}} sec 7.4.4 so if a new user logs on the network from a device, a new PAC file must be provisioned first. This is one reason why it is difficult not to run EAP-FAST in insecure anonymous provisioning mode. The alternative is to use device passwords instead, but then the device is validated on the network not the user.

Line 88:

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>[{{cite web|url=http://www.cisco.com/en/US/docs/wireless/wlan_adapter/eap_types/fast/admin/guide/FAST_admin.html|title=EAP-FAST ]for {{webarchiveWindows Vista Administrator Guide|archive-url=https://web.archive.org/web/20090210002337/http://www.cisco.com/en/US/docs/wireless/wlan_adapter/eap_types/fast/admin/guide/FAST_admin.html |archive-date=February 10, 2009 }}</ref> for [[Windows Vista]]<ref>[http://blogs.msdn.com/eapteam/archive/2008/10/17/how-do-i-install-cisco-eap-fast-on-my-computer.aspx How do I install CISCO EAP-FAST on my computer?]</ref> and later operating systems which have an extensible EAPHost architecture for new authentication methods and supplicants.<ref>[http://www.microsoft.com/technet/technetmag/issues/2007/05/CableGuy/default.aspx EAPHost in Windows]</ref>

=== Tunnel Extensible Authentication Protocol (TEAP) ===

Tunnel Extensible Authentication Protocol (TEAP; {{IETF RFC|7170}}) is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV (Type-Length-Value) objects are used to convey authentication-related data between the EAP peer and the EAP server.

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 [rfc:2315 PKCS#7] format ({{IETF RFC|2325}}). The server can also distribute trusted root certificates to the peer in [rfc:2315 PKCS#7] format ({{IETF RFC|2325}}). Both operations are enclosed into the corresponding TLVs and happen insecurely within the secure way inside previouslyalready established TLS tunnel.

===EAP Subscriber Identity Module (EAP-SIM)===

Line 121:

==={{anchor|EAP-NOOB}}Nimble out-of-band authentication for EAP (EAP-NOOB)===

Nimble out-of-band authentication for EAP<ref>{{cite webIETF | urlrfc = https://tools.ietf.org/html/draft-ietf-emu-eap-noob9140 | title = Nimble out-of-band authentication for EAP (EAP-NOOB) Draft | first1 = Tuomas | last1 = Aura | first2 = Mohit | last2 = Sethi | publisherfirst3 = IETFA. Trust| last3 = Peltonen | date = 2020-07-21December 2021}}</ref> (EAP-NOOB) is a proposed (work in progress, not RFC) generic bootstrapping solution for devices which have no pre-configured authentication credentials and which are not yet registered on any server. It is especially useful for Internet-of-Things (IoT) gadgets and toys that come with no information about any owner, network or server. Authentication for this EAP method is based on a user-assisted out-of-band (OOB) channel between the server and peer. EAP-NOOB supports many types of OOB channels such as QR codes, NFC tags, audio etc. and unlike other EAP methods, the protocol security has been verified by formal modeling of the specification with [[ProVerif]] and [[MCRL2]] tools.<ref>[https://github.com/tuomaura/eap-noob/tree/master/protocolmodel EAP-NOOB Model on GitHub]</ref>

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>{{Citecite book | doi=10.1007/0-387-23483-7_189 | chapter=HTTPS, Secure HTTPS |work title=SpringerReferenceEncyclopedia of Cryptography and Security |publisher date=Springer-Verlag2005 |doi last1=10.1007/springerreference_292Pedersen |title first1=SpringerTorben ''Reference''|year pages=2011268–269 | isbn=978-0-387-23473-1 }}</ref><ref>{{Citation|last=Plumb, Michelle |title=CAPPS : HTTPS Networking|oclc=944514826}}</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>{{cite IETF|rfc=3748|title=Extensible Authentication Protocol (EAP)|section=3.3|sectionname=EAP Usage Within IEEE 802}}</ref><ref>{{cite IETF|rfc=3748|title=Extensible Authentication Protocol (EAP)|section=7.12|sectionname=Link Layer}}</ref><ref>IEEE 802.1X-2001, § 7</ref> EAPOL was originally designed for [[IEEE 802.3]] ethernetEthernet in 802.1X-2001, but was clarified to suit other IEEE 802 LAN technologies such as [[IEEE 802.11]] wireless and [[Fiber Distributed Data Interface]] (ANSI X3T9.5/X3T12, adopted as ISO 9314) in 802.1X-2004.<ref>IEEE 802.1X-2004, § 3.2.2</ref> The EAPOL protocol was also modified for use with [[IEEE 802.1AE]] (MACsec) and [[IEEE 802.1#802.1AR|IEEE 802.1AR]] (Initial Device Identity, IDevID) in 802.1X-2010.<ref>IEEE 802.1X-2010, § 5</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 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>Microsoft's{{cite PEAP version 0, [http://tools.ietf.org/html/IETF|draft=draft-kamath-pppext-peapv0-00|title=Microsoft's draft-kamath-pppext-peapv0-00],PEAP version 0 (Implementation in Windows XP §SP1)|section=1.1|sectionname=EAP encapsulation}}</ref><ref name="peapv2-10_abstract">{{Cite IETF|title=Protected EAP Protocol (PEAP) Version 2, [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-10 =draft-josefsson-pppext-eap-tls-eap-10], abstract|section=Abstract|nosec=yes}}</ref><ref>{{cite IETF|title=Protected EAP Protocol (PEAP) Version 2, [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-10 =draft-josefsson-pppext-eap-tls-eap-10], §|section=1|sectionname=Introduction}}</ref> The purpose was to correct deficiencies in EAP; EAP assumed a protected communication channel, such as that provided by physical security, so facilities for protection of the EAP conversation were not provided.<ref>{{cite IETF|title=Protected EAP Protocol (PEAP) Version 2, [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-07 =draft-josefsson-pppext-eap-tls-eap-07], §|section=1|sectionname=Introduction}}</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), [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-05 =draft-josefsson-pppext-eap-tls-eap-05], §|section=2.3}}</ref> and PEAPv2 was defined in versions beginning with [http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-06 draft-josefsson-pppext-eap-tls-eap-06].<ref>{{cite IETF|title=Protected EAP Protocol (PEAP), [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-06 =draft-josefsson-pppext-eap-tls-eap-06], §|section=2.3|sectionname=Version negotiation}}</ref>

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, [http://tools.ietf.org/html/|draft-josefsson-pppext-eap-tls-eap-10 =draft-josefsson-pppext-eap-tls-eap-10],|page=11|sectionname=Protocol §2Overview}}</ref> Use of the [[EAP-MSCHAPv2]] and [[EAP-GTC]] methods are the most commonly supported.{{Citation needed|date=April 2010}}

===RADIUS and Diameter===

Line 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"]

* [{{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|work=Steel Belted Radius Carrier 7.0 Administration and Configuration Guide|publisher=[[Juniper Networks]]}}

{{Authentication APIs}}