Hubbry Logo
Extensible Authentication ProtocolExtensible Authentication ProtocolMain
Open search
Extensible Authentication Protocol
Community hub
Extensible Authentication Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Extensible Authentication Protocol
Extensible Authentication Protocol
Extensible Authentication Protocol
View on Wikipedia
from Wikipedia

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by 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 (Wi-Fi) the WPA and WPA2 standards have adopted IEEE 802.1X (with various EAP types) as the canonical authentication mechanism.

Methods

[edit]

EAP is an authentication framework, not a specific authentication mechanism.[1] It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined. Methods defined in IETF RFCs include EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA, and EAP-AKA'. Additionally, a number of vendor-specific methods and new proposals exist. Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, LEAP and EAP-TTLS. Requirements for EAP methods used in wireless LAN authentication are described in RFC 4017. The list of type and packets codes used in EAP is available from the IANA EAP Registry.[2]

The standard also describes the conditions under which the AAA key management requirements described in RFC 4962 can be satisfied.

Lightweight Extensible Authentication Protocol (LEAP)

[edit]
Main article: Lightweight Extensible Authentication Protocol

The Lightweight Extensible Authentication Protocol (LEAP) method was developed by Cisco Systems prior to the IEEE ratification of the 802.11i security standard.[3] Cisco distributed the protocol through the CCX (Cisco Certified Extensions) as part of getting 802.1X and dynamic WEP adoption into the industry in the absence of a standard. There is no native support for LEAP in any Windows operating system, but it is widely supported by third-party client software most commonly included with WLAN (wireless LAN) devices. LEAP support for Microsoft Windows 7 and Microsoft Windows Vista can be added by downloading a client add in from Cisco that provides support for both LEAP and EAP-FAST. Due to the wide adoption of LEAP in the networking industry many other WLAN vendors[who?] claim support for LEAP.

LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected and easily compromised; an exploit tool called ASLEAP was released in early 2004 by Joshua Wright.[4] Cisco recommends that customers who absolutely must use LEAP do so only with sufficiently complex passwords, though complex passwords are difficult to administer and enforce. Cisco's current recommendation is to use newer and stronger EAP protocols such as EAP-FAST, PEAP, or EAP-TLS.

EAP Transport Layer Security (EAP-TLS)

[edit]

EAP Transport Layer Security (EAP-TLS), defined in 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.[5] 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-TLS 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.[6][7] Some have identified this as having the potential to dramatically reduce adoption of EAP-TLS and prevent "open" but encrypted access points.[6][7] On 22 August 2012 hostapd (and wpa_supplicant) added support in its Git repository for an UNAUTH-TLS vendor-specific EAP type (using the hostapd/wpa_supplicant project RFC 5612 Private Enterprise Number),[8] and on 25 February 2014 added support for the WFA-UNAUTH-TLS vendor-specific EAP type (using the Wi-Fi Alliance Private Enterprise Number),[9][10] 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.[11]

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 cards.[12] 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

[edit]

EAP-MD5 was the only IETF Standards Track based EAP method when it was first defined in the original RFC for EAP, RFC 2284. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks.[13] EAP-MD5 support was first included in Windows 2000 and deprecated in Windows Vista.[14]

EAP Protected One-Time Password (EAP-POTP)

[edit]

EAP Protected One-Time Password (EAP-POTP), which is described in RFC 4793, is an EAP method developed by RSA Laboratories that uses one-time password (OTP) tokens, such as a handheld hardware device or a hardware or software module running on a personal computer, to generate authentication keys. EAP-POTP can be used to provide unilateral or mutual authentication and key material in protocols that use EAP.

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.[15]

EAP Pre-Shared Key (EAP-PSK)

[edit]

[1] EAP Pre-shared key (EAP-PSK), defined in RFC 4764, is an EAP method for mutual authentication and session key derivation using a pre-shared key (PSK). It provides a protected communication channel, when mutual authentication is successful, for both parties to communicate and is designed for authentication over insecure networks such as IEEE 802.11.

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)

[edit]

EAP Password (EAP-PWD), defined in 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). It is in FreeRADIUS[16] and Radiator[17] RADIUS servers, and it is in hostapd and wpa_supplicant.[18]

EAP Tunneled Transport Layer Security (EAP-TTLS)

[edit]
"TTLS" redirects here. For the children's song, see Twinkle, Twinkle, Little Star.

EAP Tunneled Transport Layer Security (EAP-TTLS) is an EAP protocol that extends 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, Vista, or 7. Supporting TTLS on these platforms requires third-party Encryption Control Protocol (ECP) certified software. Microsoft Windows started EAP-TTLS support with Windows 8,[19] support for EAP-TTLS[20] appeared in Windows Phone version 8.1.[21]

The client can, but does not have to be authenticated via a CA-signed PKI certificate to the server. This greatly simplifies the setup procedure since a certificate is not needed on every client.

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 RFC 5281, EAP-TTLSv1 is available as an Internet draft.[22]

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

[edit]

EAP Internet Key Exchange v. 2 (EAP-IKEv2) is an EAP method based on the Internet Key Exchange protocol version 2 (IKEv2). It provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:

Asymmetric key pairs
Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party.
Passwords
Low-entropy bit strings that are known to both the server and the peer.
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. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard 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 RFC 5106, and a prototype implementation exists.

EAP Flexible Authentication via Secure Tunneling (EAP-FAST)

[edit]

Flexible Authentication via Secure Tunneling (EAP-FAST; RFC 4851) is a protocol proposal by Cisco Systems as a replacement for LEAP.[23] The protocol was designed to address the weaknesses of LEAP while preserving the "lightweight" implementation. Use of server certificates is optional in EAP-FAST. EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified.

EAP-FAST has three phases:[24]

Phase Function Description Purpose
0 In-band provisioning—provide the peer with a shared secret to be used in secure phase 1 conversation Uses Authenticated Diffie-Hellman Protocol (ADHP). This phase is independent of other phases; hence, any other scheme (in-band or out-of-band) can be used in the future. Eliminate the requirement in the client to establish a master secret every time a client requires network access
1 Tunnel establishment Authenticates using the PAC and establishes a tunnel key Key establishment to provide confidentiality and integrity during the authentication process in phase 2
2 Authentication Authenticates the peer Multiple tunneled, secure authentication mechanisms (credentials exchanged)

When automatic PAC provisioning is enabled, EAP-FAST has a 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 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.

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[25] for Windows Vista[26] and later operating systems which have an extensible EAPHost architecture for new authentication methods and supplicants.[27]

Tunnel Extensible Authentication Protocol (TEAP)

[edit]

Tunnel Extensible Authentication Protocol (TEAP; 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 PKCS#10 format. After receiving the certificate request and authenticating the peer, the server can provision a certificate to the peer in PKCS#7 format (RFC 2325). The server can also distribute trusted root certificates to the peer in PKCS#7 format (RFC 2325). Both operations are enclosed into the corresponding TLVs and happen securely within the already established TLS tunnel.

EAP Subscriber Identity Module (EAP-SIM)

[edit]

EAP Subscriber Identity Module (EAP-SIM) is used for authentication and session key distribution using the subscriber identity module (SIM) from the Global System for Mobile Communications (GSM).

GSM cellular networks use a subscriber identity module card to carry out user authentication. EAP-SIM use a SIM authentication algorithm between the client and an Authentication, Authorization and Accounting (AAA) server providing mutual authentication between the client and the network.

In EAP-SIM the communication between the SIM card and the Authentication Centre (AuC) replaces the need for a pre-established password between the client and the AAA server.

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 RFC 4186.

EAP Authentication and Key Agreement (EAP-AKA)

[edit]

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 (USIM). EAP-AKA is defined in RFC 4187.

EAP Authentication and Key Agreement prime (EAP-AKA')

[edit]

The EAP-AKA' variant of EAP-AKA, defined in RFC 5448, and is used for non-3GPP access to a 3GPP core network. For example, via EVDO, WiFi, or WiMax.

EAP Generic Token Card (EAP-GTC)

[edit]

EAP Generic Token Card, or EAP-GTC, is an EAP method created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2 and defined in RFC 2284 and RFC 3748. EAP-GTC carries a text challenge from the authentication server, and a reply generated by a security token. The PEAP-GTC authentication mechanism allows generic authentication to a number of databases such as Novell Directory Service (NDS) and Lightweight Directory Access Protocol (LDAP), as well as the use of a one-time password.

EAP Encrypted Key Exchange (EAP-EKE)

[edit]

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 certificates. It is a three-round exchange, based on the Diffie-Hellman variant of the well-known EKE protocol.

EAP-EKE is specified in RFC 6124.

Nimble out-of-band authentication for EAP (EAP-NOOB)

[edit]

Nimble out-of-band authentication for EAP[28] (EAP-NOOB) is a 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.[29]

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

[edit]

EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP messages within that protocol's messages.[30][31]

IEEE 802.1X

[edit]
Main article: IEEE 802.1X

The encapsulation of EAP over IEEE 802 is defined in IEEE 802.1X and known as "EAP over LANs" or EAPOL.[32][33][34] EAPOL was originally designed for IEEE 802.3 Ethernet 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.[35] The EAPOL protocol was also modified for use with IEEE 802.1AE (MACsec) and IEEE 802.1AR (Initial Device Identity, IDevID) in 802.1X-2010.[36]

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 TKIP or CCMP (based on AES) encryption.

PEAP

[edit]
Main article: 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) tunnel.[37][38][39] 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.[40]

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 draft-kamath-pppext-peapv0-00. PEAPv1 and PEAPv2 were defined in different versions of draft-josefsson-pppext-eap-tls-eap. PEAPv1 was defined in draft-josefsson-pppext-eap-tls-eap-00 through draft-josefsson-pppext-eap-tls-eap-05,[41] and PEAPv2 was defined in versions beginning with draft-josefsson-pppext-eap-tls-eap-06.[42]

The protocol only specifies chaining multiple EAP mechanisms and not any specific method.[38][43] Use of the EAP-MSCHAPv2 and EAP-GTC methods are the most commonly supported.[citation needed]

RADIUS and Diameter

[edit]
Main articles: RADIUS and Diameter (protocol)

Both the RADIUS and Diameter AAA protocols can encapsulate EAP messages. They are often used by Network Access Server (NAS) devices to forward EAP packets between IEEE 802.1X endpoints and AAA servers to facilitate IEEE 802.1X.

PANA

[edit]
Main article: Protocol for Carrying Authentication for Network Access

The Protocol for Carrying Authentication for Network Access (PANA) is an IP-based protocol that allows a device to authenticate itself with a network to be granted access. PANA will not define any new authentication protocol, key distribution, key agreement or key derivation protocols; for these purposes, EAP will be used, and PANA will carry the EAP payload. PANA allows dynamic service provider selection, supports various authentication methods, is suitable for roaming users, and is independent from the link layer mechanisms.

PPP

[edit]
Main article: 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 RFC 2284, now obsoleted by RFC 3748.

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Extensible Authentication Protocol

View on Grokipedia
from Grokipedia
The Extensible Authentication Protocol (EAP) is an framework that supports multiple methods to provide flexible and secure access to networks, operating directly over data link layers such as (PPP) or without requiring IP connectivity. Defined by the (IETF) in RFC 3748, EAP enables an authenticator to initiate with a peer through a series of request-response exchanges, culminating in success or failure, while allowing backend servers to handle the actual method-specific verification. This design supports , key derivation for session security, and extensibility for new methods, making it a foundational protocol for port-based network access control. EAP originated as a PPP extension in RFC 2284, published in March 1998, which introduced the core packet format and initial authentication types like MD5-Challenge and (OTP) to allow deferred method selection during the authentication phase. It was updated and obsoleted by RFC 3748 in June 2004, expanding security considerations, adding support for expanded type codes, and defining key hierarchies such as the Master Session Key (MSK) and Extended Master Session Key (EMSK) for deriving cryptographic material. Concurrently, EAP was integrated into the standard for port-based network access control, first published in 2001, where it is encapsulated as EAP over LAN (EAPOL) for authenticating devices on wired and local area networks (LANs). This adoption extended EAP's use beyond dial-up connections to enterprise , Ethernet switches, and VPNs, with IETF RFC 3580 providing RADIUS usage guidelines tailored to 802.1X in 2003. At its core, EAP involves three main entities: the peer (the supplicant device seeking access), the authenticator (e.g., a or access point that enforces access), and an optional authentication server (e.g., ) that performs the heavy computation for complex methods. The protocol relies on lower-layer mechanisms for packet delivery and retransmission but includes features like duplicate detection and optional fragmentation within methods. Security properties vary by method but generally aim to resist , replay, and man-in-the-middle attacks, with requirements for at least 128 bits of effective key strength in the MSK and EMSK for methods supporting key derivation. EAP does not natively provide or for its packets, deferring those to underlying transports or derived keys. EAP's extensibility is evident in its registry of over 50 method types maintained by IANA, allowing diverse mechanisms from simple challenges to certificate-based or SIM-card verification. Notable methods include EAP-MD5 (Type 4) for basic password challenges, though vulnerable to attacks; EAP-TLS (Type 13), defined in RFC 5216 for mutual certificate using (TLS); and tunneled methods like Protected EAP (PEAP, Type 25) or EAP-TTLS (Type 21) that protect inner authentications. More recent developments include RFC 9190 in 2022 updating EAP-TLS to support TLS 1.3 and RFC 9427 in 2023 extending this to other TLS-based methods, with ongoing work on post-quantum enhancements as of 2025. These methods enable EAP's widespread deployment in scenarios requiring strong identity verification, such as enterprise wireless access and mobile network .

Introduction

Definition and Purpose

The Extensible Authentication Protocol (EAP) is an IETF standard protocol defined in RFC 3748, functioning as an framework that supports multiple authentication methods to transport authentication data between a peer (such as a client device) and a server (such as an server). This framework operates at the , enabling authentication without requiring IP connectivity, and is typically encapsulated within protocols like PPP or for network access control. The core purpose of EAP is to provide extensible and flexible methods for authenticating users and devices across diverse network environments, including wired and wireless local area networks (via ), virtual private networks (VPNs), and (PPP) connections. By allowing the integration of various authentication mechanisms, EAP ensures secure access to networks while accommodating evolving security requirements without overhauling the underlying transport layers. Key features of EAP include method negotiation via EAP-Request (sent by the ) and EAP-Response (sent by the peer) messages, which facilitate dynamic selection of the most suitable authentication approach from supported options. It also provides support for , where both the peer and server verify each other's identity, and key derivation, generating a Master Session Key (MSK) and Extended Master Session Key (EMSK)—each at least 64 octets long—for deriving session-specific cryptographic material to protect subsequent communications. In distinction from legacy protocols like the (PAP) and (CHAP), which rely on fixed, non-extensible mechanisms embedded directly in transport protocols such as PPP, EAP acts as a pluggable framework that decouples logic from the , enabling new methods to be added without protocol modifications. This design promotes greater security and adaptability in modern network infrastructures.

Applications and Scope

The Extensible Authentication Protocol (EAP) finds primary application in securing network access across diverse environments, including wireless local area networks (WLANs) through WPA2-Enterprise and WPA3-Enterprise modes, which leverage EAP within the IEEE 802.1X framework to authenticate users and devices before granting Wi-Fi access. In wired Ethernet networks, EAP integrates with IEEE 802.1X for port-based access control, enabling authentication at the physical layer to prevent unauthorized connections on switches and routers. For mobile networks, EAP methods such as EAP-AKA' support 3GPP standards, including forward secrecy extensions in RFC 9678 (December 2024), facilitating secure authentication in cellular systems like 5G non-public networks. Additionally, EAP is employed in virtual private networks (VPNs), particularly with protocols like IKEv2 and FlexVPN, where it provides extensible authentication for remote access scenarios. Recent deployments extend EAP to Internet of Things (IoT) devices, enabling lightweight authentication in resource-constrained settings. EAP's scope is deliberately limited to the authentication phase of network access, focusing on verifying peer identities without handling authorization or accounting functions directly. To address these broader aspects, EAP is commonly paired with the Remote Authentication Dial-In User Service (), which transports EAP messages via dedicated attributes and manages the full , , and (AAA) workflow. This separation ensures EAP remains a flexible, method-agnostic framework while relying on backend systems like RADIUS for comprehensive enforcement. Originally developed as an extension for (PPP) authentication, EAP has evolved significantly to support port-based in standards and beyond, adapting to modern infrastructures without requiring IP-layer dependencies. Its scope has broadened to include IoT protocols, such as the (CoAP), where CoAP-EAP—as standardized in RFC 9820 (September 2025)—enables efficient authentication for low-power devices by transporting EAP over UDP-based messaging to establish secure associations. This progression reflects EAP's design for extensibility, allowing seamless integration into diverse link layers from dial-up origins to constrained wireless environments. In practical scenarios, EAP underpins enterprise authentication, where devices negotiate methods like EAP-TLS or PEAP to access corporate networks securely via servers. For cellular security, EAP methods such as EAP-ERP facilitate re-authentication during inter-technology transitions, minimizing latency while maintaining session keys across and mobile networks in environments.

History and Standards

Development Timeline

The Extensible Authentication Protocol (EAP) originated with its initial proposal in RFC 2284, published in March 1998 by authors L. Blunk and J. Vollbrecht, which introduced EAP as a flexible authentication framework specifically designed for use with the Point-to-Point Protocol (PPP) to support multiple authentication mechanisms. A significant advancement came in June 2004 with the publication of RFC 3748 by B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz (editor), which obsoleted RFC 2284 and established the current base specification for EAP by expanding the range of supported authentication types and incorporating explicit security requirements to enhance robustness. Post-2004 developments included the August 2008 release of RFC 5247, which defined the EAP key hierarchy and outlined a framework for transporting and utilizing keying material derived from EAP methods, addressing needs across various deployments. In December 2013, RFC 7057 further refined EAP's applicability by updating the guidance from RFC 3748 to align with evolving usage scenarios in network authentication. Since 2022, the (IETF) has initiated discussions on refreshing the base EAP specification (RFC 3748) to accommodate contemporary security and interoperability demands, as reflected in activities within the EAP Method Update () working group. Additionally, EAP has been integrated into standards by the (3GPP), notably through methods like EAP-AKA' for primary authentication in both 3GPP and non-3GPP accesses as specified in TS 33.501.

Key RFC Specifications

The Extensible Authentication Protocol (EAP) is fundamentally defined by RFC 3748, published in June 2004 as a Proposed Standard by the IETF. This document obsoletes the earlier RFC 2284 and establishes the core EAP framework, which supports multiple authentication methods without specifying any particular mechanism, allowing for extensibility in network access authentication. It specifies the EAP packet format, consisting of a one-octet Code field (indicating Request, Response, Success, or Failure), a one-octet Identifier for matching requests and responses, a two-octet Length field for the total packet size, and a variable-length Data field containing method-specific information. Additionally, RFC 3748 assigns initial EAP method types, such as type 1 for Identity (to request or provide peer identity) and type 4 for MD5-Challenge (a simple challenge-response method using MD5 hashing). Building on this framework, RFC 5216, published in August 2008 as a Proposed Standard, defines the EAP-TLS authentication protocol, which integrates (TLS) for certificate-based between the EAP peer and server. This RFC details the handling of certificates, including fragmentation and reassembly for large certificates, and specifies key derivation processes to generate the Master Session Key (MSK) and Extended Master Session Key (EMSK) from the TLS . EAP-TLS supports optional client authentication and emphasizes strong cryptographic protections, making it suitable for environments requiring (PKI). It obsoletes the earlier RFC 2716 and aligns with TLS versions up to 1.2 at the time of publication. This was updated by RFC 9190, published in July 2022 as a Proposed Standard, which specifies the use of EAP-TLS with TLS 1.3, providing , enhanced privacy through mandatory identity protection, and compatibility with existing implementations. Similarly, RFC 5281, published in August 2008 as a Proposed Standard, specifies EAP-TTLS (Tunneled TLS), a method that establishes a TLS-encrypted for subsequent inner , protecting sensitive credentials from eavesdroppers. This RFC outlines the protocol's phases, including the outer TLS for server and the inner phase supporting protocols like EAP, PAP, CHAP, or within the tunnel. Key agreement in EAP-TTLS relies on the underlying TLS session, deriving shared keys for while allowing phased where the server is authenticated first, followed by the peer. EAP-TTLS enhances by anonymizing the peer's identity during initial exchanges. More recent advancements include RFC 7170, published in May 2014 as a Proposed Standard, which introduces the Tunnel Extensible Authentication Protocol (TEAP), a versatile tunneled method that combines outer TLS authentication (e.g., via certificates or PSK) with inner EAP methods for compound authentication, such as simultaneous machine and user credentials. TEAP supports post-authentication attributes and key wrapping for secure . This RFC was updated by RFC 9427 in June 2023 (Proposed Standard), which adapts TLS-based EAP methods—including TEAP, EAP-TLS, and EAP-TTLS—for compatibility with TLS 1.3 by defining new key derivation functions and addressing changes in TLS structures, ensuring continued against modern threats. Another notable recent specification is RFC 9140, published in December 2021 as a Proposed Standard, defining EAP-NOOB (Nimble Authentication), designed for resource-constrained IoT devices lacking pre-shared credentials. This method uses a user-assisted channel (e.g., or NFC) for initial pairing and key establishment, followed by password-authenticated (PAKE) for subsequent authentications, providing a lightweight bootstrapping solution. Most EAP-related RFCs hold Proposed Standard status within the IETF, indicating they are well-tested but not yet elevated to due to the framework's ongoing evolution. Interdependencies are common; for instance, key agreement in RFC 5281 (EAP-TTLS) depends on TLS primitives for secure tunneling and derivation of session keys. As of November 2025, ongoing IETF drafts, such as draft-ietf-emu-rfc7170bis, propose further updates to TEAP for enhanced and alignments, while the broader EAP framework in RFC 3748 continues to be refined through errata and companion RFCs like RFC 5247 for .

Protocol Architecture

Core Components

The Extensible Authentication Protocol (EAP) operates through a defined set of core components that facilitate between network entities. The primary roles include the EAP peer, which is the entity seeking access to the network and responds to authentication challenges; the , which controls access to the network and initiates the EAP method; and the EAP server, which terminates the EAP process and may reside within the or as a separate backend system. In pass-through mode, the relays EAP messages between the peer and the EAP server without performing the itself. At the lower layer, EAP is encapsulated and transported over various protocols to carry authentication messages between the peer and . Common transports include the Link Control Protocol (LCP) for (PPP) environments and the EAP over LAN (EAPOL) protocol for local area networks, ensuring reliable delivery with error detection and a minimum MTU of 1020 octets. These lower-layer mechanisms handle the framing and transmission of EAP packets without altering their content. For upper-layer integration, EAP often interfaces with Authentication, Authorization, and Accounting (AAA) protocols, such as , to enable centralized backend authentication and . The EAP server communicates with the AAA infrastructure to verify credentials and derive session keys, which are then transported back to the for securing the link. This integration supports scalable deployment in enterprise networks by offloading complex authentication logic from the authenticator. The EAP protocol employs a state machine to manage the authentication process, ensuring orderly progression through attempts. The EAP peer state machine consists of four primary states: Disabled, in which no authentication occurs due to lack of service or port control; Authenticate, where the peer processes incoming requests and generates responses; Authenticated, reached upon successful completion of authentication; and Failure, entered if authentication cannot proceed or fails. Transitions between these states are triggered by specific events, such as the receipt of an EAP-Success packet (=3) moving from Authenticate to Authenticated, or an EAP-Failure packet (=4) advancing to Failure, with the machine resetting to Disabled on port disable or timeout. A similar state machine governs the , coordinating with the peer and backend to enforce these transitions.

Message Exchange Process

The Extensible Authentication Protocol (EAP) message exchange process defines a structured sequence of interactions between the peer (supplicant) and the (often proxied to an server) to negotiate and complete authentication. This process operates over a reliable , such as PPP or , and consists of four primary packet types: EAP Request, EAP Response, EAP Success, and EAP Failure, each identified by a Code field and an Identifier for matching requests to responses. The exchange begins when the authenticator initiates communication and concludes with success or failure notification, enabling the peer to gain or be denied network access. Initiation typically starts with the authenticator sending an EAP-Request/Identity packet to the peer, prompting it to provide its identity, though this step is optional if the identity is already known through lower-layer mechanisms. The peer responds with an EAP-Response/Identity containing the requested information. Following this, the (or server) proposes an method by sending an EAP-Request packet with the Type field indicating the desired method, such as EAP-MD5 or EAP-TLS. If the peer does not support the proposed method, it rejects it by sending an EAP-Response/Nak (Type 3), listing one or more preferred alternative methods from those it supports, or an Expanded Nak (Type 254) for additional details. The then selects a mutually supported method and proceeds with an EAP-Request using that method's Type code. Once a method is negotiated, the proceeds through a series of method-specific EAP-Request and EAP-Response exchanges, where the issues challenges or requests, and the peer provides credentials or proofs, potentially involving multiple round trips until the method completes. These exchanges may include if supported by the method, but the EAP layer itself does not dictate the internal logic, leaving it to the selected method. Upon successful completion, the authentication server notifies the authenticator, which sends an EAP-Success packet (Code 3) to the peer, granting access without any additional data payload. Conversely, if authentication fails, an EAP-Failure packet (Code 4) is sent, denying access and also carrying no data. EAP methods that provide keying material optionally derive a Master Session Key (MSK), a cryptographically strong key of at least 64 octets, which the peer and can use to establish link-layer , such as for encrypting the connection post-authentication. This key is generated during the method's execution and tunneled securely if needed, supporting subsequent protocols like TLS for session protection. For error handling, the peer uses Nak responses specifically for method negotiation rejection, while the manages retransmissions of unacknowledged Requests by incrementing the Identifier and resending, with a recommended limit of 3 to 5 attempts to prevent indefinite loops. Lower-layer protocols handle general transport errors, ensuring the EAP exchange remains reliable.

EAP Authentication Methods

Tunneled Methods

Tunneled EAP methods establish a , typically using (TLS), to protect subsequent inner authentication exchanges from and man-in-the-middle attacks. These methods negotiate an outer TLS tunnel between the client (supplicant) and authentication server, within which legacy or simpler inner authentication protocols can operate securely. This approach allows enterprises to leverage existing credential systems, such as passwords, without exposing them directly to the network. EAP-TTLS, defined in RFC 5281, creates a server-side TLS tunnel initiated by the authentication server presenting its certificate to the client. Once the tunnel is established, inner authentication methods such as PAP, CHAP, MS-CHAP, or even another EAP method can be negotiated and executed within it, encapsulating packets in EAP-Message AVPs for transport. Mutual authentication is optional, as the client certificate is not required, though server certificate validation by the client is recommended to prevent impersonation. This flexibility supports a range of legacy protocols while ensuring the inner exchange remains confidential. Protected EAP (PEAP), a Microsoft-developed method documented in the MS-PEAP specification, similarly encapsulates an inner EAP method within an outer TLS tunnel secured by a server-side certificate. Unlike EAP-TTLS, PEAP does not mandate client validation of the server certificate by default in some implementations, though it is configurable; the inner method is typically MS-CHAPv2 for password-based authentication against Active Directory. The tunnel protects the inner negotiation, enabling secure use of non-certificate credentials in environments like wireless LANs. EAP-FAST, specified in RFC 4851 and developed by , uses TLS to form a mutually authenticated tunnel and incorporates Protected Access Credentials (PACs) for expedited re-authentication in subsequent sessions. The protocol operates in phases: an optional provisioning phase to distribute PACs, followed by tunnel establishment, and then inner authentication using methods like EAP-MSCHAPv2 or EAP-GTC. PACs, which are opaque keys binding the client and server, enable fast by resuming sessions without full re-handshakes, reducing latency in dynamic environments. The Tunnel Extensible Authentication Protocol (TEAP), outlined in RFC 7170, extends tunneling capabilities by combining TLS-based outer protection with support for multiple chained inner EAP methods, allowing simultaneous authentication of user and device credentials. It facilitates key sharing and expansion for methods like EAP-SIM, integrating SIM-based authentication securely within the tunnel. TEAP enhances prior methods by mandating cryptographic binding between inner and outer authentications to mitigate downgrade attacks, and it supports session resumption via TLS tickets for efficiency. These tunneled methods offer key advantages in enterprise deployments, including mitigation of and brute-force attacks on credentials by encrypting inner exchanges, compatibility with existing password infrastructures without requiring client certificates, and improved resistance to passive . Their widespread adoption stems from balancing with deployment simplicity, particularly in heterogeneous networks where full PKI rollout is impractical.

Certificate-Based Methods

Certificate-based methods in the Extensible Authentication Protocol (EAP) leverage (PKI) to provide robust between the peer and the authenticator, ensuring both parties verify each other's identities through digital certificates issued by trusted certificate authorities (CAs). These methods are particularly suited for environments requiring high assurance of authenticity, as they rely on asymmetric cryptography rather than shared secrets, mitigating risks associated with credential compromise. The primary example is EAP-TLS, which integrates the (TLS) protocol directly into the EAP framework to facilitate certificate exchange and session key establishment. EAP-TLS, defined in RFC 5216, enables full where both the server (authenticator) and the client (peer) present certificates during the TLS embedded within EAP messages. The process begins with the server sending its certificate to the peer for validation against a trusted CA chain, confirming the server's identity; conversely, the peer may optionally present its own certificate for server verification, though this is configurable based on deployment needs. Following certificate validation, the parties negotiate TLS cipher suites and derive shared session keys using the TLS Pseudorandom Function (PRF), which generates master and transient keys for securing subsequent communications. EAP-TLS was updated in RFC 9190 (2022) to support TLS 1.3 while remaining backwards compatible, replacing the PRF with the HMAC-based (HKDF), enabling post- , and improving fragmentation for large certificates. To enhance resilience against denial-of-service (DoS) attacks, EAP-TLS incorporates an optional client puzzle mechanism, where the peer solves a cryptographic challenge before proceeding, thereby increasing the computational cost for attackers attempting resource exhaustion. The security strength of certificate-based methods like EAP-TLS stems from their dependence on PKI, which provides resistance to and man-in-the-middle (MitM) attacks by binding identities to verifiable public keys, eliminating the need for transmitting sensitive credentials over the network. However, this approach necessitates a robust certificate management infrastructure, including issuance, revocation checking via Certificate Revocation Lists (CRLs) or (OCSP), and periodic renewal, which can introduce operational overhead. In practice, EAP-TLS is widely deployed in high-security environments such as government and enterprise networks, where the trade-off of certificate distribution complexity is justified by the need for strong, non-repudiable ; for instance, it underpins secure access in IEEE 802.1X-protected LANs for sensitive data transmission.

Password and Token-Based Methods

Password and token-based methods within the Extensible Authentication Protocol (EAP) framework provide authentication mechanisms that rely on shared secrets, such as passwords, or dynamic tokens, enabling deployment in environments where is unavailable or overly complex. These methods prioritize ease of use with user-held credentials while varying in security strength, particularly against offline attacks and replay scenarios. Key examples include EAP-MD5, EAP-GTC, EAP-PSK, EAP-PWD, and EAP-POTP, each defined in IETF RFCs and tailored for specific use cases like or wired network access. EAP-MD5 employs a simple challenge-response mechanism using the MD5 hash function, where the authenticator sends a random challenge to the peer, which responds with the MD5 hash of the concatenated challenge, shared password, and peer identifier. This method provides one-way authentication without mutual verification, integrity protection, or key derivation, making it lightweight but insecure for modern networks. It is vulnerable to offline dictionary attacks, as captured exchanges allow attackers to brute-force passwords without server interaction, and lacks protection against replay or man-in-the-middle attacks; consequently, it is deprecated in favor of stronger alternatives. EAP-GTC, or Generic Token Card, supports authentication via one-time passwords (OTPs) or challenge-response tokens, where the authenticator issues a prompt, and the peer replies with the generated token value or entered credential in cleartext. Designed for hardware tokens like smart cards, it enables server-side verification against a shared secret or token database but offers no built-in mutual authentication, confidentiality, or replay protection. While suitable for tunneled environments to avoid cleartext exposure, its use outside protected channels risks credential interception, and it does not generate session keys. EAP-PSK authenticates using a pre-shared symmetric key (typically 16 bytes) for and session key agreement over insecure channels, such as networks. The protocol involves a four-message exchange: the server sends a random challenge and identity request; the peer responds with its identity, random value, and a (MAC) using AES-CMAC; the server verifies and replies with its MAC; and the peer confirms. It derives an authentication key and key-derivation key from the PSK via AES-128 in modified counter mode, producing transient keys, master session keys, and extended master session keys, while providing integrity and replay protection through nonces and MACs. EAP-PSK draws from the key exchange family (inspired by AKEP2), ensuring resistance to passive attacks but lacking perfect . EAP-PWD enables password-based authentication with low-entropy secrets, resistant to offline dictionary attacks through a three-message exchange leveraging an Diffie-Hellman (ECDH) key exchange akin to (SAE) in WPA3. The server initiates with , identities, and a commitment scalar/point; the peer responds with its commitment and ; and the server finalizes with its , deriving shared keys from the password-preprocessed ECDH secret. This hunter-prey design prevents passive eavesdroppers from isolating the password for brute-force attempts, as each run incorporates ephemeral values and supports with key . It generates master and extended master session keys for subsequent . EAP-POTP facilitates protected one-time password authentication for tokens, supporting both unilateral and mutual modes with key material generation, ideal for protocols like or IKEv2. In protected mode, the peer submits an OTP TLV (using for derivation) alongside version and key identifiers; the server verifies the OTP (potentially updating PINs) and sends a confirm TLV with an HMAC-SHA-256 MAC for mutual proof; subsequent messages use AES-CBC . This HMAC-based protection ensures and of the OTP exchange, thwarting replay and modification attacks, while deriving master and extended master session keys from the . Basic mode omits protection, requiring external tunneling.

SIM and AKA-Based Methods

EAP methods based on Subscriber Identity Module (SIM) and Authentication and Key Agreement (AKA) leverage credentials stored on mobile network subscriber cards to enable secure authentication in both cellular and non-cellular access scenarios. These methods are particularly designed for interoperability between mobile networks and other access technologies, such as WLAN, by utilizing hardware-bound secrets from SIM or Universal SIM (USIM) cards rather than shared passwords. They support between the user equipment (UE) and the network, along with derivation of session keys for protecting subsequent communications. EAP-SIM, defined in RFC 4186, provides an authentication framework specifically for networks using SIM cards. The process employs a challenge-response mechanism where the EAP server, typically interfacing with the Home Location Register (HLR), retrieves multiple GSM authentication —each consisting of a random challenge (RAND), signed response (SRES), and ciphering key (Kc)—to perform authentication without exposing the permanent subscriber identity. The UE's SIM computes the SRES using the Ki and RAND, enabling verification by the server, while derived keys from multiple enhance security against replay attacks. This method supports fast re-authentication and key hierarchy for lower-layer protections, such as in environments. EAP-AKA, specified in RFC 4187, extends the SIM-based approach to third-generation () Universal Mobile Telecommunications System () networks with USIM cards, incorporating stronger . It uses 128-bit authentication keys (shared between the USIM and the Authentication Center) to generate a 128-bit RAND and authentication token (AUTN) for , ensuring the network's legitimacy via the USIM's verification of the AUTN. Unlike EAP-SIM's 64-bit Kc, EAP-AKA derives a 128-bit ciphering key (CK) and integrity key (IK), which form the basis for material suitable for or encryption. This method also facilitates 256-bit key support in later adaptations for contexts, maintaining compatibility with evolving mobile standards. EAP-AKA', introduced in RFC 5448 and updated in RFC 9048 (2021), enhances EAP-AKA for non-3GPP accesses like WLAN by introducing home-routed , where the verifies the serving network's identity to prevent unauthorized . Key improvements include binding derived keys to the access network name using a new (KDF) with SHA-256 hashing (replacing ), support for identifiers such as Subscription Permanent Identifier (SUPI) and Subscription Concealed Identifier (SUCI), and mechanisms to negotiate KDF inputs for better . The update in RFC 9048 adds privacy enhancements, such as pseudonym management for identity protection, and ensures backward compatibility while addressing vulnerabilities in legacy implementations. It was further updated in RFC 9678 (2025) to include a forward secrecy extension (EAP-AKA' FS), which uses ephemeral Diffie-Hellman to provide perfect forward secrecy for the generated session keys. A core feature across these methods is identity hiding through temporary identifiers or pseudonyms, which the UE provides in initial EAP messages to obscure the permanent IMSI or SUPI from eavesdroppers on untrusted links. Following successful , a key hierarchy derives Master Session Keys (MSK) and Transient Session Keys (TSK) from the base keys (Kc for EAP-SIM, CK/IK for EAP-AKA/AKA'), enabling secure tunneling in protocols like or . These derived keys support both confidentiality and integrity protection for the authenticated session. In specifications, SIM and AKA-based EAP methods are integral to Evolved Packet System (EPS) and 5G System (5GS) authentication. For EPS, EAP-AKA and EAP-AKA' are mandated for non-3GPP access authentication via the Evolved Packet Data Gateway (ePDG) or trusted WLAN, interfacing with the 3GPP AAA server as per TS 33.401. In 5GS, EAP-AKA' is a required primary method alongside 5G AKA for non-3GPP accesses, with the Unified Data Management (UDM) and Authentication Server Function (AUSF) handling vector generation, as detailed in TS 33.501. This integration ensures seamless mobility and security across 3GPP and non-3GPP domains.

Other Specialized Methods

Cisco's Lightweight Extensible Authentication Protocol (LEAP), introduced in the early as a EAP method, provides using a challenge-response mechanism similar to , where the client's username and hashed password are exchanged over the network. LEAP generates dynamic (WEP) keys per user session to enhance security over static WEP, but it transmits usernames in cleartext and uses reversible for passwords, making it susceptible to offline attacks. Due to these vulnerabilities, including the inherent weaknesses of WEP and tools like ASLEAP that exploit them, Cisco deprecated LEAP around 2004 in favor of more secure protocols like EAP-TLS and PEAP. EAP-IKEv2, specified in RFC 5106, adapts the version 2 (IKEv2) protocol for EAP to enable in scenarios requiring IPsec-like key exchange, supporting both certificate-based and pre-shared key (PSK) authentication. This method uses Diffie-Hellman key exchange to derive shared secrets securely, providing forward secrecy and resistance to man-in-the-middle attacks when certificates are employed, though PSK variants may be vulnerable if keys are weak. EAP-IKEv2 is particularly suited for environments needing strong cryptographic protections without relying on TLS, such as certain enterprise VPN integrations. The EAP Encrypted Key Exchange (EAP-EKE) method, detailed in an expired IETF draft from 2010, aims to authenticate users via protected by encrypted to prevent and dictionary attacks. It employs symmetric of the during the exchange, using Diffie-Hellman for key agreement, to ensure that even compromised sessions do not reveal credentials. Despite its innovative approach to , EAP-EKE saw limited adoption due to concerns at the time and the rise of more robust alternatives like EAP-TLS, with the draft expiring without advancement to RFC status. EAP-NOOB (Nimble Out-of-Band), defined in RFC 9140 published in , facilitates secure bootstrapping for (IoT) devices through an channel, such as QR codes or NFC, to establish initial trust without pre-shared secrets. The method involves a phase where the device and exchange application identifiers and nonces out-of-band, followed by an in-band EAP exchange to derive keys and authenticate, supporting both password and certificate modes post-pairing. Designed for resource-constrained environments, EAP-NOOB emphasizes simplicity and resistance to online guessing attacks by limiting attempts and using randomized nonces, making it ideal for one-time setup in smart home or industrial IoT networks. EAP-EAP, outlined in RFC 4733, serves as a tunneling mechanism to encapsulate one EAP method within another, allowing nested authentication for enhanced security or compatibility in heterogeneous networks. This approach enables an outer EAP method (e.g., EAP-TLS) to carry an inner method (e.g., EAP-MSCHAPv2) securely, protecting sensitive credentials from exposure during transmission. Primarily used in scenarios requiring , such as when legacy authentication must be secured within a modern framework, EAP-EAP supports key derivation from the inner method for session establishment while maintaining the outer method's protections.

Transport and Encapsulation

IEEE 802.1X Integration

The Extensible Authentication Protocol (EAP) is integrated into the standard for port-based network access control, enabling secure over local area networks (LANs) such as Ethernet and . In this framework, EAP messages are encapsulated within EAP over LAN (EAPOL) frames, which facilitate communication between the supplicant (the client device) and the authenticator (typically a switch or access point). EAPOL frames are transmitted using the 0x888E and include a protocol version field (1 octet, typically version 2), a type field (1 octet, e.g., 0 for EAP Packet, 1 for EAPOL-Start, 2 for EAPOL-Logoff, 3 for EAPOL-Key), a length field (2 octets indicating the body length), and a variable-length data field containing the EAP payload for exchanges. This encapsulation allows EAP to operate directly over media without requiring PPP, supporting and key agreement between ports attached to the same LAN. IEEE 802.1X employs a controlled model where the port initially resides in an unauthorized state, permitting only EAPOL frames for while blocking other traffic to prevent unauthorized access. Upon successful EAP authentication, the port transitions to the authorized state, enabling full transmission; failure results in the port remaining or reverting to unauthorized. This state management is handled by state machines in the supplicant and Port Access Entities (PAEs), applying to both wired Ethernet and environments like networks. The authenticator, operating in pass-through mode, relays EAP messages to a backend server, such as a server, using the EAP-Message RADIUS attribute to encapsulate the EAP packets. Successful authentication yields a Master Session Key (MSK) from the EAP method, from which the Pairwise Master Key (PMK) is derived—typically the first 256 bits of the MSK—for use in the WPA2/WPA3 key hierarchy, including the four-way to generate transient keys for session encryption. The 2010 revision of introduced support for (Media Access Control Security, per ) through the MACsec Key Agreement (MKA) protocol, which uses EAP-derived keys to distribute Secure Association Keys (SAKs) for link-layer encryption and integrity protection. This amendment enables incremental deployment of secure connectivity associations, including virtual ports and cipher suites like GCM-AES-128, enhancing protection against threats in shared LAN segments. with EAP integration is widely deployed in campus networks for securing wired and wireless access, providing scalable authentication for thousands of users while integrating with directory services for centralized management.

PPP and PANA Usage

The Extensible Authentication Protocol (EAP) is integrated into the (PPP) as a flexible authentication mechanism, enabling secure network access in dial-up and (VPN) scenarios. During PPP's Link Control Protocol (LCP) phase, EAP is negotiated through the Authentication Protocol Configuration Option, identified by the protocol value C227 in , which allows the to select the authentication method dynamically without prior knowledge of the peer's capabilities. EAP packets are then encapsulated within PPP Data Link Layer frames using the same protocol field, supporting request-response exchanges between the and peer to establish identity and credentials. Upon successful completion of the EAP method, the transmits an (Code 3), signaling approval and triggering the negotiation of the Internet Protocol Control Protocol (IPCP) to configure network-layer parameters, such as assignment, thereby granting the peer access to the network. This integration supports legacy remote access environments where PPP operates over serial links or switched circuits, postponing detailed until after link establishment to accommodate backend authentication servers. In contrast, the Protocol for Carrying Authentication for Network Access (PANA) provides a UDP-based transport for EAP at the network layer, facilitating authentication in scenarios without dedicated link-layer support, such as home networks or pre-IP assignment phases. Defined in RFC 5191, PANA uses UDP port 716 for communication, with the PANA Client (PaC) serving as the EAP peer and the PANA Authentication Agent (PAA) as the EAP authenticator, enabling EAP exchanges over IP even before full IP configuration is complete. The protocol includes mechanisms for reliable delivery through retransmissions and supports post-authentication IP reconfiguration, making it suitable for non-IPsec environments where lightweight bootstrapping is required. Unlike PPP, which operates at the for point-to-point connections, PANA functions as a transport-layer protocol independent of the underlying link , allowing EAP to be carried in UDP packets for flexible deployment in diverse topologies. This design is particularly advantageous for constrained devices in home or emerging networks, where PANA bootstraps secure access prior to or other higher-layer protections, contrasting with Ethernet-framed transports like .

RADIUS and Diameter Support

The Extensible Authentication Protocol (EAP) integrates with the Remote Authentication Dial-In User Service (RADIUS) to enable centralized authentication in network access scenarios, where the Network Access Server (NAS) acts as a pass-through authenticator relaying EAP messages to a backend RADIUS server. The EAP-Message attribute, defined as Type 79 in the RADIUS attribute registry, encapsulates complete EAP packets, allowing the NAS to forward them without interpreting the underlying EAP method. This attribute appears in RADIUS Access-Request packets to convey EAP-Response messages from the peer, in Access-Challenge packets to deliver EAP-Request messages from the server, and in Access-Accept packets to signal EAP-Success upon successful authentication. Multiple EAP-Message attributes may be concatenated in a single RADIUS packet if the EAP payload exceeds 253 octets, ensuring support for larger messages in multi-round exchanges. Diameter, as an evolution of RADIUS, provides enhanced scalability for AAA functions, particularly in mobile and roaming environments, through its support for EAP via the Diameter EAP Application defined in RFC 4072. The application uses an Application-Id of 5, specifically aligned with specifications for mobile networks, and employs Attribute-Value Pairs (AVPs) analogous to RADIUS attributes for message transport. The EAP-Payload AVP (AVP Code 462) carries EAP packets in Diameter-EAP-Request (DER) and Diameter-EAP-Answer (DEA) commands, enabling the NAS or authenticator to relay authentication data to backend servers while supporting proxy and redirect mechanisms for efficient handling in large-scale deployments. This structure facilitates seamless integration in architectures, where Diameter's peer-to-peer model and failure handling improve reliability over RADIUS for high-mobility scenarios. EAP methods that derive session keys transport this material securely within and to establish encrypted links, particularly in PPP contexts. In , the MS-MPPE-Recv-Key attribute (Vendor-Specific Type 16 from ) delivers the receive-side key for Microsoft Point-to-Point Encryption (MPPE) in Access-Accept packets, supporting methods like EAP-MSCHAPv2 that export keys for PPP sessions. For broader EAP key management, the EAP-Key-Name AVP (AVP Code 102 in ) provides an opaque identifier for keys derived by EAP methods, allowing secure reference and distribution without exposing the keys themselves. These mechanisms ensure that keying material remains protected during transit from the authentication server to the . To address potential man-in-the-middle (MITM) attacks where a malicious might impersonate the EAP server, EAP supports channel binding extensions that verify the integrity of the lower-layer transport. RFC 6677 defines channel-binding mechanisms for EAP methods, enabling the peer to bind authentication attributes to the AAA channel (e.g., or ) and detect discrepancies that could indicate interception or substitution. This extension integrates with and by including channel-binding data in EAP messages carried via EAP-Message or EAP-Payload attributes, thereby preventing lying attacks without requiring changes to the core AAA protocols.

Security Considerations

Common Vulnerabilities

The Extensible Authentication Protocol (EAP) exposes user identities during the initial authentication phase, as the EAP-Response/Identity packet is transmitted in cleartext, allowing eavesdroppers to snoop and capture sensitive information such as usernames or other identifiers. This vulnerability persists unless phased identity requests or anonymized identifiers are employed, but the base protocol does not enforce protection. EAP negotiation is prone to method downgrade attacks, where an attacker intercepts and modifies unprotected NAK response packets to force the selection of a weaker authentication method, such as MD5-Challenge instead of a more secure TLS-based option. This risk arises because EAP method selection lacks inherent integrity protection, enabling manipulation during the initial exchange phase. Tunneled EAP methods, including EAP-TTLS and PEAP, are susceptible to vulnerabilities within the inner if the outer TLS tunnel is compromised, such as through server certificate spoofing that allows an attacker to impersonate the and eavesdrop on or alter inner method communications. In such scenarios, the lack of cryptographic binding between outer and inner methods can expose the peer's credentials or enable man-in-the-middle interception of subsequent data. Certain EAP methods, particularly those involving intensive cryptographic operations like EAP-TLS, are vulnerable to denial-of-service attacks due to the high computational cost of TLS handshakes and fragmentation reassembly, which can exhaust server resources through repeated initiation or malformed packets. Additionally, unrestricted restart attempts in EAP-TLS can amplify this risk by allowing attackers to trigger multiple resource-draining sessions per peer. As of 2025, EAP methods relying on , such as EAP-PWD and EAP-AKA', face emerging quantum threats, where cryptographically relevant quantum computers could solve the problem, enabling private key recovery, bypass, and impersonation attacks on captured handshakes. These vulnerabilities stem from the underlying ECDH key exchanges in these protocols, which quantum algorithms like Shor's can efficiently break, compromising long-term session security.

Mitigation Strategies

To mitigate vulnerabilities in EAP deployments, such as man-in-the-middle attacks identified in prior analyses, several best practices focus on robust certificate handling, binding mechanisms, key usage verification, method selection, and monitoring. Server certificate validation is essential for certificate-based and tunneled EAP methods like EAP-TLS, where peers must verify the server's identity against trusted certificate authorities (CAs) to prevent impersonation. According to RFC 5216, EAP-TLS implementations require peers to perform path validation on the server certificate chain per RFC 5280, ensuring the certificate includes the server authentication extended key usage (id-kp-serverAuth) and is issued by a trusted CA. This validation is mandatory for tunneled methods to protect against rogue servers, with administrators configuring clients to reject untrusted or self-signed certificates. Channel binding enhances security in tunneled EAP methods by linking the outer authentication to the inner authentication, detecting discrepancies that indicate splits or lying authenticators. Defined in RFC 6677, this mechanism allows the EAP peer and server to exchange binding data (e.g., channel identifiers or attributes) at the end of the inner method, enabling verification that the same authenticator handles both phases and thwarting attacks where an alters perceived network details. Key confirmation ensures that the Master Session Key (MSK) derived from EAP is properly utilized for link-layer protection, particularly in environments. As outlined in RFC 3748, the MSK serves as input to derive the Pairwise Master Key (PMK), which is confirmed during the 4-way in WPA3-Enterprise mode through the Key Confirmation Key (KCK) for integrity checks on subsequent messages. This process verifies mutual possession of the keys, preventing unauthorized access even if succeeds but fails. Policy enforcement involves disabling legacy weak EAP methods and prioritizing robust alternatives to reduce exposure to known flaws. NIST Special Publication 800-120 recommends deprecating methods like EAP-MD5 (vulnerable to offline dictionary attacks) and LEAP (susceptible to brute-force cracking), while favoring EAP-TLS for certificate-based or EAP-AKA' for SIM-derived keys with enhanced cryptographic protections. Administrators should configure authenticators and servers to reject unsupported or insecure methods via access control lists. To address emerging quantum threats to elliptic curve-based methods, implementations should transition to enhancements, such as hybrid algorithms combining classical and PQC key encapsulation mechanisms. As of November 2025, IETF drafts propose updates to EAP-TLS and EAP-AKA' incorporating post-quantum key exchanges to maintain against quantum attacks while preserving compatibility. Auditing EAP exchanges through comprehensive logging supports incident detection and compliance, with records capturing attempts, outcomes, and key events. Best practices from Network Policy Server documentation emphasize enabling detailed logging for both and accounting in RADIUS servers, including timestamps, user identities, and EAP method details, to facilitate forensic analysis. For methods involving pre-shared keys (PSKs), such as certain password-based variants, regular (e.g., every 90 days or upon suspicion of compromise) is advised to limit exposure, as per general cryptographic key management guidelines in NIST SP 800-57.

Implementations and Recent Developments

Software and Hardware Support

The Extensible Authentication Protocol (EAP) enjoys widespread integration in major operating systems, enabling secure network authentication through native components. In Microsoft Windows, EAP is supported via the EAPHost framework, which serves as the supplicant for 802.1X scenarios and natively handles methods such as Protected EAP (PEAP) and EAP-Transport Layer Security (EAP-TLS). On systems, the daemon provides robust EAP support for authentication, facilitating WPA/WPA2/WPA3-Enterprise connections across various distributions. Apple's macOS includes built-in EAP capabilities for WPA-Enterprise networks, supporting 802.1X methods like EAP-TLS and PEAP through system-level configuration profiles. EAP implementations often rely on open-source libraries for cryptographic operations and server-side processing. provides the underlying TLS support essential for EAP methods involving certificate-based authentication, such as EAP-TLS, and is integrated into many EAP stacks for handling secure tunnels. FreeRADIUS, a prominent open-source RADIUS server, offers comprehensive backend support for EAP, including EAP-TLS, PEAP, and other methods, making it a standard choice for authentication servers in enterprise environments. Hardware support for EAP is embedded in Wi-Fi chipsets and mobile components, ensuring protocol execution at the firmware level. Wi-Fi adapters, for instance, incorporate EAPOL (EAP over LAN) functionality in their to support 802.1X authentication with methods like EAP-TLS, TTLS, and PEAP. Similarly, Qualcomm Atheros Wi-Fi chipsets enable EAPOL processing through firmware updates, allowing seamless integration with enterprise Wi-Fi security. In mobile devices, Subscriber Identity Module (SIM) cards facilitate EAP-SIM authentication, leveraging / credentials for WLAN access as defined in specifications. Interoperability across EAP implementations is promoted through certification programs, particularly by the , which tests and validates devices for WPA2-Enterprise and WPA3-Enterprise compliance, including support for key EAP methods like EAP-TLS and PEAP. This ensures consistent behavior in mixed-vendor environments, reducing deployment challenges for 802.1X networks.

Updates and Emerging Extensions

In 2025, the IETF published RFC 9678, which introduces a extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS). This extension employs ephemeral keys to ensure that session keys derived during authentication remain secure even if long-term credentials are compromised in the future, enhancing protection against retrospective attacks in mobile and networks. Similarly, RFC 9820, released in September 2025, defines an authentication service leveraging EAP over the (CoAP) to support resource-constrained IoT devices. Known as CoAP-EAP, this mechanism enables lightweight EAP exchanges in environments with limited bandwidth and power, facilitating secure authentication for IoT ecosystems without relying on heavier transport protocols. Addressing threats, 2025 IETF drafts such as draft-ietf-emu-hybrid-pqc-eapaka propose hybrid (PQC) integrations for EAP-AKA', combining classical algorithms with quantum-resistant ones like ML-KEM (based on NIST's CRYSTALS-Kyber). These enhancements extend to EAP methods using TLS, such as EAP-TLS, by incorporating hybrid key encapsulation to mitigate risks from quantum attacks on . The IETF's EAP Method Update (EMU) Working Group is actively pursuing updates to the EAP framework, including revisions to the base specification in RFC 3748, to counter modern security challenges like those in , where dynamic resource allocation demands robust, adaptable . Emerging applications position EAP as a core component in zero-trust architectures, enabling continuous verification in perimeterless networks via integrations with 802.1X. Broader discussions within standards bodies, including NIST and NSA guidelines, advocate for mandatory quantum resistance in protocols like EAP by 2030 to align with CNSA 2.0 requirements and preempt "" threats.

References

  1. https://datatracker.ietf.org/doc/html/rfc3748
  2. https://datatracker.ietf.org/doc/html/rfc2284
  3. https://www.iana.org/assignments/eap-numbers
  4. https://www.rfc-editor.org/rfc/rfc9190.html
  5. https://datatracker.ietf.org/doc/html/rfc9427
  6. https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access
  7. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/12-4/sec-user-8021x-12-4-book/sec-vpn-ac-802-1x.html
  8. https://datatracker.ietf.org/doc/rfc9048/
  9. https://datatracker.ietf.org/doc/html/rfc9678
  10. https://www.cisco.com/c/en/us/support/docs/security/flexvpn/220536-configure-anyconnect-flexvpn-with-eap-an.html
  11. https://datatracker.ietf.org/doc/html/rfc9820
  12. https://datatracker.ietf.org/doc/html/rfc3579
  13. https://www.cisco.com/c/en/us/support/docs/wireless/aironet-1100-series/44844-leapserver.html
  14. https://www.rfc-editor.org/info/rfc2284
  15. https://www.rfc-editor.org/info/rfc3748
  16. https://www.rfc-editor.org/info/rfc5247
  17. https://www.rfc-editor.org/info/rfc7057
  18. https://www.ericsson.com/en/blog/2022/4/extensible-authentication-protocol-eap-networks
  19. https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/17.07.00_60/ts_133501v170700p.pdf
  20. https://datatracker.ietf.org/doc/html/rfc5216
  21. https://datatracker.ietf.org/doc/html/rfc9190
  22. https://datatracker.ietf.org/doc/html/rfc5281
  23. https://datatracker.ietf.org/doc/html/rfc7170
  24. https://datatracker.ietf.org/doc/html/rfc9140
  25. https://datatracker.ietf.org/doc/html/rfc5247
  26. https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
  27. https://datatracker.ietf.org/doc/html/rfc3748#section-1.2
  28. https://datatracker.ietf.org/doc/html/rfc3748#section-3.1
  29. https://datatracker.ietf.org/doc/html/rfc3748#section-3.2
  30. https://datatracker.ietf.org/doc/html/rfc3579#section-2
  31. https://datatracker.ietf.org/doc/html/rfc4137#section-3.1
  32. https://datatracker.ietf.org/doc/html/rfc4137#section-3.2
  33. https://datatracker.ietf.org/doc/html/rfc4137#section-4
  34. https://datatracker.ietf.org/doc/html/rfc3748#section-2
  35. https://datatracker.ietf.org/doc/html/rfc3748#section-4.2
  36. https://datatracker.ietf.org/doc/html/rfc3748#section-5.1
  37. https://datatracker.ietf.org/doc/html/rfc3748#section-5.3
  38. https://datatracker.ietf.org/doc/html/rfc3748#section-5.3.2
  39. https://datatracker.ietf.org/doc/html/rfc3748#section-2.1
  40. https://datatracker.ietf.org/doc/html/rfc3748#section-2.1.2
  41. https://datatracker.ietf.org/doc/html/rfc3748#section-7.10
  42. https://datatracker.ietf.org/doc/html/rfc3748#section-4.3
  43. https://datatracker.ietf.org/doc/html/rfc6678
  44. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/a128a089-0919-41a5-a0c2-9f25ef28289d
  45. https://datatracker.ietf.org/doc/html/rfc4851
  46. https://datatracker.ietf.org/doc/html/rfc4764
  47. https://datatracker.ietf.org/doc/html/rfc5931
  48. https://datatracker.ietf.org/doc/html/rfc4793
  49. https://datatracker.ietf.org/doc/html/rfc4186
  50. https://datatracker.ietf.org/doc/html/rfc4187
  51. https://datatracker.ietf.org/doc/html/rfc5448
  52. https://datatracker.ietf.org/doc/html/rfc9048
  53. https://datatracker.ietf.org/doc/rfc9678/
  54. https://www.3gpp.org/dynareport/33401.htm
  55. https://www.3gpp.org/dynareport/33501.htm
  56. https://community.cisco.com/t5/wireless-mobility-knowledge-base/cisco-leap/ta-p/3133135
  57. https://www.kb.cert.org/vuls/id/473108
  58. https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/access_registrar/9-3/user/guide/user_guide/eap.html
  59. https://standards.ieee.org/ieee/802.1X/7345/
  60. https://datatracker.ietf.org/doc/html/rfc3580
  61. https://www.cs.cmu.edu/~prs/wirelessS24/handouts/L11-WiFi-mngt.pdf
  62. https://datatracker.ietf.org/doc/html/rfc5191
  63. https://datatracker.ietf.org/doc/html/rfc2869
  64. https://datatracker.ietf.org/doc/html/rfc3579#section-3.1
  65. https://datatracker.ietf.org/doc/html/rfc4072
  66. https://datatracker.ietf.org/doc/html/rfc4072#section-2.1
  67. https://datatracker.ietf.org/doc/html/rfc4072#section-3
  68. https://datatracker.ietf.org/doc/html/rfc4072#section-2.3
  69. https://datatracker.ietf.org/doc/html/rfc2548#section-2.2
  70. https://datatracker.ietf.org/doc/html/rfc4072#section-4.1.4
  71. https://datatracker.ietf.org/doc/html/rfc3748#section-7.1
  72. https://datatracker.ietf.org/doc/html/rfc3748#section-7.3
  73. https://datatracker.ietf.org/doc/html/rfc3748#section-7.8
  74. https://datatracker.ietf.org/doc/html/rfc3748#section-7.2.1
  75. https://datatracker.ietf.org/doc/html/rfc6678#section-4.6.3
  76. https://datatracker.ietf.org/doc/html/rfc5216#section-2.1.5
  77. https://datatracker.ietf.org/doc/html/rfc5216#section-2.1.3
  78. https://www.ietf.org/archive/id/draft-reddy-emu-pqc-eap-tls-00.html
  79. https://www.ietf.org/archive/id/draft-ar-emu-pqc-eapaka-04.html
  80. https://datatracker.ietf.org/doc/html/rfc5280
  81. https://datatracker.ietf.org/doc/html/rfc6677
  82. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-120.pdf
  83. https://datatracker.ietf.org/doc/draft-reddy-emu-pqc-eap-tls/
  84. https://datatracker.ietf.org/doc/draft-ietf-emu-pqc-eapaka/
  85. https://w1.fi/wpa_supplicant/
  86. https://support.apple.com/guide/deployment/dynamic-wep-wpa-enterprise-wpa2-settings-dep1c4b37ac2/web
  87. https://www.freeradius.org/documentation/freeradius-server/4.0.0/howto/modules/eap/index.html
  88. https://freeradius.org/documentation/freeradius-server/3.2.9/tutorials/eap-tls.html
  89. https://www.intel.com/content/www/us/en/support/articles/000006664/wireless.html
  90. https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_25_Munich/Docs/PDF/S3-020557.pdf
  91. https://datatracker.ietf.org/doc/rfc9820/
  92. https://datatracker.ietf.org/doc/draft-ietf-emu-hybrid-pqc-eapaka/
  93. https://datatracker.ietf.org/wg/emu/about/
  94. https://www.cisco.com/c/en/us/solutions/collateral/enterprise/design-zone-security/zt-user-device-dg.html
Add your contribution
Related Hubs
User Avatar
No comments yet.