Extensible Authentication Protocol: Difference between revisions

Revision as of 16:01, 10 November 2022

Latest revision as of 12:02, 4 August 2025

(17 intermediate revisions by 13 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 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 93:

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 126:

==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.