Extensible Authentication Protocol: Difference between revisions

Revision as of 17:16, 3 September 2023

Latest revision as of 12:02, 4 August 2025

(8 intermediate revisions by 8 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.