How EAP Works in 802.1X: EAP Methods Compared

EAP Is a Framework, Not a Protocol

EAP (Extensible Authentication Protocol, RFC 3748) is a framework that defines how authentication messages are formatted and transported — not how credentials are actually verified. The actual credential exchange is handled by EAP "types" or "methods" that run on top of the base EAP framework.

This design is intentional. EAP was built to support multiple authentication mechanisms — passwords, certificates, tokens, smart cards — without changing the underlying transport. Each method is negotiated during the authentication exchange: the authentication server proposes a method, the supplicant accepts or requests a different one, and they proceed.

EAP messages are carried over two transports depending on where they are in the network path:

• Between supplicant and authenticator: EAPOL (EAP over LAN, Ethernet type 0x888E)
• Between authenticator and authentication server: RADIUS (inside Access-Request/Challenge/Accept packets)

The authenticator is transparent to the EAP conversation — it relays EAP payloads it cannot inspect. This is covered in detail in Article 4: EAPOL Explained: How 802.1X Traffic Moves Over the Wire.

EAP Packet Structure

An EAP packet has four fields:

• Code (1 byte): 1=Request, 2=Response, 3=Success, 4=Failure
• Identifier (1 byte): Matches requests to responses
• Length (2 bytes): Total length of the EAP packet
• Data: Method-specific content, present in Request and Response packets

EAP Request and Response packets include a Type field as the first byte of Data, identifying the EAP method being used. Type values include:

• 1: Identity
• 4: MD5 Challenge
• 13: EAP-TLS
• 25: PEAP
• 43: EAP-FAST

The EAP Type negotiation happens at the beginning of the exchange. If the supplicant doesn't support the type proposed by the server, it sends an EAP-Nak (Type 3) listing the types it will accept.

PEAP: Protected EAP

PEAP is the most widely deployed EAP method in enterprise environments. It addresses the fundamental weakness of earlier methods like EAP-MD5 — sending credentials over an unencrypted channel — by wrapping the credential exchange inside a TLS tunnel.

How PEAP Works

Phase 1 — TLS Tunnel Establishment:
The server (ISE) presents its certificate to the supplicant. The supplicant validates the certificate against its trusted CA store. If valid, a TLS 1.2 (or 1.3, depending on configuration) session is established. This tunnel encrypts everything that follows.

Phase 2 — Inner Authentication:
Inside the TLS tunnel, a second EAP exchange occurs. The most common inner method is EAP-MSCHAPv2, which uses Microsoft's challenge-response password authentication. The supplicant sends the username and a hashed version of the password. ISE forwards the MSCHAPv2 exchange to Active Directory for verification.

The inner identity (the real username) is hidden inside the TLS tunnel. The outer identity — what the supplicant sends before the tunnel is established — can be anonymized (e.g., anonymous@domain.com). This protects the username from passive eavesdropping.

PEAP Requirements

• Server certificate on ISE: Required. ISE presents this certificate during Phase 1. The supplicant must trust the CA that signed it. In practice, this means the CA certificate (your internal PKI root or an intermediate) must be deployed to all endpoints via Group Policy or MDM.
• Client certificate: Not required. Credentials are username/password via MSCHAPv2.
• Identity source: Active Directory (most common) or ISE internal identity store.

PEAP Strengths and Weaknesses

Strengths:

• No client certificate infrastructure required — works with existing AD credentials
• Widely supported by all OS platforms (Windows, macOS, Linux, Android, iOS)
• Identity hidden in the outer anonymous identity (when configured)
• Server certificate validation prevents evil-twin attacks if the supplicant is configured to validate the cert and pin to a specific CA

Weaknesses:

• Password-based authentication is phishable — an attacker who obtains credentials can authenticate
• If the supplicant is misconfigured to not validate the server certificate, the TLS tunnel is established to any server presenting any certificate — PEAP becomes vulnerable to credential harvesting attacks
• MSCHAPv2 Phase 2 has known weaknesses (offline dictionary attacks against captured handshakes)

The certificate validation warning: In production, supplicants must be configured to validate the ISE server certificate and trust only the specific CA that signed it. Leaving "Validate server certificate" unchecked in Windows supplicant settings is a common misconfiguration that creates a serious security hole. Every endpoint supplicant in this lab is configured with ISE's certificate pinned.

PEAP Configuration in ISE 3.2

ISE Allowed Protocols path: Policy > Policy Elements > Results > Authentication > Allowed Protocols

In the Allowed Protocols service, ensure:

• Allow PEAP: Enabled
• Inner Methods: Allow EAP-MSCHAPv2 (and optionally EAP-GTC)
• Require Cryptobinding TLV: Recommended for production (prevents certain MITM attacks)

EAP-TLS: Certificate-Based Mutual Authentication

EAP-TLS (RFC 5216) is the strongest EAP method available. Both the server and the client present certificates. There is no password exchange — identity is proven through possession of a valid private key paired with a certificate signed by a trusted CA.

How EAP-TLS Works

Unlike PEAP, EAP-TLS has no "two-phase" design. The entire exchange is TLS mutual authentication:

1. Server (ISE) sends its certificate
2. Client (supplicant) sends its certificate
3. Each side verifies the other's certificate against its trusted CA store
4. TLS handshake completes, establishing session keys
5. ISE validates the client certificate (not expired, not revoked, signed by a trusted CA)
6. ISE extracts the identity from the certificate (Subject, SAN, or UPN in the Subject Alternative Name)
7. ISE may optionally verify the identity against Active Directory (certificate + AD account existence)

The result: both sides have authenticated each other. No credentials ever traversed the wire.

EAP-TLS Requirements

• Server certificate on ISE: Required. Same as PEAP.
• Client certificate on every endpoint: Required. This is the operational challenge of EAP-TLS. Every Windows endpoint needs a machine certificate (or user certificate) issued by a CA that ISE trusts. This typically means deploying an internal CA (Microsoft ADCS is standard in most enterprises) and using Group Policy or SCCM/Intune to auto-enroll certificates to endpoints.
• Certificate Revocation: ISE must be able to check CRL or OCSP to verify client certificates haven't been revoked. This requires connectivity to the CA's CRL distribution point or OCSP responder.

EAP-TLS Strengths and Weaknesses

Strengths:

• Strongest authentication — credentials cannot be phished (no passwords)
• Mutual authentication — client verifies server, server verifies client
• Certificate compromise is detectable and revocable via CRL/OCSP
• Preferred method for high-security environments (financial services, healthcare, government)
• Works with machine authentication without user interaction

Weaknesses:

• Requires PKI infrastructure — significant operational overhead to deploy and maintain
• Certificate lifecycle management (enrollment, renewal, revocation) must be robust
• Device certificate deployment to every endpoint (including BYOD) is operationally complex
• BYOD scenarios where you can't install machine certificates require a different approach

EAP-TLS in ISE 3.2

ISE path for EAP-TLS certificate profile: Administration > Identity Management > Identity Sources > Certificate Authentication Profile

The Certificate Authentication Profile defines:

• Which certificate field to use as the identity (Common Name, SAN UPN, etc.)
• Whether to validate the certificate in AD
• CRL/OCSP settings

EAP-TLS full configuration walkthrough is in Article 11: Configuring EAP-TLS with Certificates on Cisco ISE and IOS XE.

EAP-FAST: Cisco's Tunneled Authentication

EAP-FAST (RFC 4851) was developed by Cisco as an alternative to PEAP for environments where deploying server certificates was difficult. It uses Protected Access Credentials (PACs) instead of a server certificate to establish the tunnel.

How EAP-FAST Works

A PAC is a shared secret provisioned to the supplicant by the EAP-FAST server (ISE) during an initial provisioning phase. Once provisioned, the PAC is used to establish a TLS tunnel (the Protected Access Tunnel, or PAT) without requiring a server certificate.

Phase 0 — PAC Provisioning (one-time):
The first time a device authenticates with EAP-FAST, ISE provisions a PAC to the supplicant. This can be done in-band (during authentication) or out-of-band (manual distribution). In-band provisioning in "anonymous" mode is a known weakness — it's essentially an unauthenticated tunnel that delivers the PAC.

Phase 1 — PAT Establishment:
Supplicant uses the PAC to establish the tunnel with ISE.

Phase 2 — Inner Authentication:
Inside the tunnel, MSCHAPv2 or EAP-GTC authenticates the user.

EAP-FAST in Current Deployments

EAP-FAST is less common in new deployments. Most organizations deploying today choose PEAP (when they already have AD and don't want to manage client certs) or EAP-TLS (when security requirements mandate certificate-based auth). EAP-FAST's PAC management complexity and the security concerns around anonymous provisioning reduce its appeal.

ISE 3.2 supports EAP-FAST. It remains relevant for Cisco AnyConnect VPN clients and some legacy Cisco wireless deployments.

EAP-TTLS: Tunneled TLS

EAP-TTLS (RFC 5281) is similar to PEAP — it establishes a TLS tunnel using a server certificate, then runs an inner authentication method inside. Unlike PEAP (which uses EAP as the inner method), EAP-TTLS can use non-EAP inner methods including PAP, CHAP, and MS-CHAP.

EAP-TTLS is common in Linux environments (hostapd/wpa_supplicant) and macOS. Windows does not natively support EAP-TTLS without a third-party supplicant. For this reason, EAP-TTLS is rare in Microsoft-centric enterprise wired deployments.

ISE 3.2 supports EAP-TTLS with inner methods PAP/ASCII, CHAP, MS-CHAP, and MS-CHAPv2.

MAC Authentication Bypass (MAB)

MAB is not an EAP method — there is no EAP exchange. MAB is a fallback mechanism for devices that cannot run an 802.1X supplicant.

How MAB Works

When a port is configured for both 802.1X and MAB:

1. The authenticator sends EAPOL-Request/Identity
2. No EAPOL response arrives (the device has no supplicant)
3. After the configured timeout (default: 30 seconds on IOS XE), the authenticator attempts MAB
4. The switch sends a RADIUS Access-Request to ISE using the device's MAC address as both the username and password (in the format aabbccddeeff)
5. ISE looks up the MAC in its endpoint database and endpoint identity groups
6. If found, ISE returns policy attributes for that device type

ISE processes MAB requests like any other RADIUS request — through Policy Sets. The policy can use endpoint identity groups (e.g., "Cisco-IP-Phone"), profiling attributes, or explicit MAC address lists.

MAB Security Considerations

The fundamental weakness of MAB is MAC address spoofability. An attacker can clone a known-good MAC address and receive the same access. ISE profiling mitigates this by verifying that device behavior matches the claimed device type, but profiling is not foolproof.

For this reason, MAB is used for non-802.1X devices (printers, cameras, IoT) that are placed in restricted VLANs with limited access — not for critical users or high-value endpoints. Never use MAB as the primary authentication method for user endpoints that can run proper 802.1X.

MAB configuration is covered in Article 12: MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE.

EAP Method Selection Guide

The right EAP method depends on the device type, existing infrastructure, and security requirements:

Method Comparison Matrix

ISE Allowed Protocols Policy

ISE controls which EAP methods are permitted through the Allowed Protocols service. This is associated with authentication policies in your Policy Sets.

ISE navigation: Policy > Policy Elements > Results > Authentication > Allowed Protocols

A typical enterprise Allowed Protocols configuration enables:

• PEAP with inner EAP-MSCHAPv2
• EAP-TLS
• MAB (process as host lookup)

Disable unused methods (EAP-MD5, LEAP, EAP-FAST if not used) to reduce attack surface. LEAP in particular is cryptographically broken and should never be allowed.

In ISE 3.2, you create separate Allowed Protocols services for different policy sets — for example, one that allows PEAP for corporate endpoints and a separate one that allows only MAB for IoT device ports.

Identity Hiding and Anonymous Outer Identity

In PEAP and EAP-TTLS, the outer identity — sent before the TLS tunnel is established — is visible in plaintext. Configure supplicants to use an anonymous outer identity (e.g., anonymous@corp.com or just anonymous) to prevent username disclosure before the tunnel is up.

In Windows supplicant settings: Authentication > Settings > [EAP type] > Configure > uncheck "Automatically use my Windows logon name" and set a static outer identity.

ISE can match on the anonymous outer identity in the Authentication Policy to route to the correct identity source, then use the real inner identity from the tunnel for the Authorization Policy. This is a standard PEAP deployment pattern.

Version Considerations for IOS XE 17.9.x

Cisco IOS XE 17.9.x on the Catalyst 9300 supports all methods discussed above. Key points:

• TLS 1.3 support for EAP-TLS and PEAP is available in recent IOS XE releases — verify ISE 3.2 also supports TLS 1.3 in your environment (enabled in ISE under Administration > System > Security Settings)
• EAP session timeout and retry behavior is configurable per interface and globally — the defaults (30-second server timeout, 2 retries) work for most deployments but may need tuning in high-latency WAN scenarios where ISE is remote
• The dot1x max-reauth-req and dot1x timeout parameters on the interface affect EAP exchange behavior — do not tune these without understanding the impact on the overall authentication flow

What's Next: Article 4: EAPOL Explained: How 802.1X Traffic Moves Over the Wire — a detailed look at EAPOL frame types, the Layer 2 exchange between supplicant and authenticator, and how to capture and interpret EAPOL traffic during troubleshooting.