10.2 802.1X Authentication and EAP Methods

802.1X Authentication and EAP Methods

Quick Summary: The Extensible Authentication Protocol (EAP) is an architectural framework that enables diverse authentication algorithms to operate over 802.1X network links without modifying switch hardware. Modern enterprise networks rely primarily on two EAP methods: EAP-TLS, which enforces mutual certificate authentication using Public Key Infrastructure (PKI) to eliminate password-based vulnerabilities, and PEAP-MSCHAPv2, which establishes an encrypted TLS tunnel using a server certificate to protect transmitted Active Directory credentials. Securing EAP requires implementing anonymous outer identities to protect user privacy and configuring AOS-CX special roles (reject-role and critical-role) to maintain business continuity during authentication failures.

---

The Extensible Authentication Protocol (EAP) Framework

Traditional authentication protocols (such as PAP and CHAP) hardcoded specific challenge-response mechanisms directly into network access servers. The Extensible Authentication Protocol (EAP, RFC 3748) revolutionized access security by creating a modular envelope layer:

+---------------------------------------------------------------------------------------------------------+
|                                         EAP PACKET ARCHITECTURE                                         |
|                                                                                                         |
|     0                   1                   2                   3                                       |
|     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                                     |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    |
|    |     Code      |  Identifier   |            Length             |                                    |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    |
|    |     Type      |  Type-Data ...                                                                     |
|    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    |
+---------------------------------------------------------------------------------------------------------+

EAP Core Packet Fields

• Code (8 bits): Indicates the fundamental message type:
  • 1 = Request: Issued by the authenticator/server to solicit information.
  • 2 = Response: Sent by the supplicant answering a request.
  • 3 = Success: Issued by the authentication server upon positive authorization.
  • 4 = Failure: Issued by the authentication server when verification fails.
• Identifier (8 bits): A sequence number matching requests with corresponding responses, preventing replay attacks.
• Length (16 bits): Total byte length of the EAP frame, including Code, Identifier, Length, and Type-Data.
• Type (8 bits): Present only in Request and Response codes. Specifies the authentication method requested (e.g., 1 = Identity, 13 = EAP-TLS, 25 = PEAP, 21 = EAP-TTLS).
• Type-Data (Variable): Carries the specific cryptographic payload for the designated EAP method.

Decoupling the Edge from the Identity Store

Because EAP is encapsulated inside EAPOL between the endpoint and switch, and inside RADIUS between the switch and ClearPass, the AOS-CX access switch never inspects the inner Type-Data. An enterprise can introduce a brand-new authentication method (such as FIDO2 WebAuthn or quantum-resistant cryptography) across thousands of access switches without upgrading switch ASICs or software images—only the endpoint supplicant and ClearPass Policy Manager require the update.

---

Enterprise EAP Methods Compared

Enterprise campus deployments leverage three dominant EAP variants, each representing distinct operational architectures and security guarantees:

+---------------------------------------------------------------------------------------------------------+
|                                      ENTERPRISE EAP METHODS COMPARED                                    |
|                                                                                                         |
|     [ EAP-TLS ] --------------> MUTUAL CERTIFICATE AUTHENTICATION (Highest Security)                    |
|                                 Server presents X.509 cert; Client presents X.509 cert.                 |
|                                 No passwords transmitted. Requires enterprise PKI (ClearPass Onboard).  |
|                                                                                                         |
|     [ PEAP-MSCHAPv2 ] --------> TUNNELED PASSWORD AUTHENTICATION (Standard Corporate Access)            |
|                                 Phase 1: Server validates via cert; builds encrypted TLS tunnel.        |
|                                 Phase 2: Client sends username/password inside tunnel to Active Dir.   |
|                                                                                                         |
|     [ EAP-TTLS ] -------------> TUNNELED EXTENSIBLE AUTHENTICATION (Cross-Platform/Legacy)              |
|                                 Phase 1: Encrypted TLS tunnel built using server certificate.           |
|                                 Phase 2: Flexible inner protocol (PAP, CHAP, MSCHAPv2, or EAP).        |
+---------------------------------------------------------------------------------------------------------+

1. EAP-TLS (RFC 5216 - Transport Layer Security)

EAP-TLS is universally recognized as the gold standard in enterprise network access security:

• Mutual Authentication: Both endpoints mathematically prove their identity before access is granted. The ClearPass server presents an X.509 server certificate (which the client validates against its pre-installed Trusted Root CA). The client endpoint simultaneously presents an X.509 client certificate (which ClearPass validates against the Enterprise Issuing CA).
• Elimination of Password Vulnerabilities: EAP-TLS relies on asymmetric cryptography (RSA or ECDSA). The private key associated with the client certificate is generated locally on the endpoint and bound to a hardware security chip (Trusted Platform Module - TPM on Windows, Secure Enclave on macOS/iOS). The private key never traverses the network and cannot be exported.
• Resistance to Exploits: Because no password traverses the wire or airwaves, EAP-TLS is completely immune to offline dictionary attacks, credential harvesting, pass-the-hash attacks, and employee credential sharing.
• Operational Prerequisite: Requires an automated Public Key Infrastructure (PKI) and certificate lifecycle management solution, such as Aruba ClearPass Onboard using SCEP (Simple Certificate Enrollment Protocol) or EST (Enrollment over Secure Transport).

2. PEAP (Protected EAP - PEAPv0 with EAP-MSCHAPv2)

PEAP was developed by Microsoft, Cisco, and RSA Security to allow enterprises to deploy 802.1X without provisioning digital certificates to every client device:

• Two-Phase Architecture:
  • Phase 1 (Tunnel Establishment): The ClearPass server presents its server certificate. The client supplicant validates the certificate's digital signature, expiration, and Subject Alternative Name (SAN). If valid, the two entities perform a standard TLS handshake, establishing an encrypted, authenticated TLS tunnel.
  • Phase 2 (Inner Authentication): Inside the encrypted TLS tunnel, the client authenticates using a traditional credential mechanism—most commonly EAP-MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2). The client supplies its Active Directory username and hashed password.
• Deployment Simplicity: Leverages existing corporate user accounts in Active Directory. It requires purchasing and installing an SSL/TLS server certificate only on the ClearPass Policy Manager nodes.
• Vulnerabilities: If endpoint supplicants are not strictly configured via Mobile Device Management (MDM) or Group Policy (GPO) to validate the server certificate and verify the exact server certificate name, an attacker can deploy a rogue access point running FreeRADIUS with a self-signed certificate, fool the endpoint into establishing a tunnel, and capture the MS-CHAPv2 challenge-response hash for offline cracking (using tools like asleap or Hashcat).

3. EAP-TTLS (Tunneled Transport Layer Security, RFC 5281)

EAP-TTLS operates similarly to PEAP by creating an outer TLS tunnel via a server certificate. However, where PEAP strictly requires an EAP method inside the tunnel (such as EAP-MSCHAPv2), EAP-TTLS supports non-EAP legacy authentication protocols inside the tunnel, including PAP, CHAP, and MS-CHAP. It is commonly deployed in heterogeneous environments containing Linux, Android, and macOS clients connecting to non-Microsoft directory services (such as OpenLDAP).

---

Technical Comparison: EAP Methods

---

Inner vs. Outer Identity and User Privacy

When a supplicant begins an 802.1X exchange, the switch transmits an EAP-Request/Identity. The supplicant replies with an EAP-Response/Identity. In tunneled EAP methods (PEAP and EAP-TTLS), this initial response occurs before the encrypted TLS tunnel exists.

+---------------------------------------------------------------------------------------------------------+
|                                    INNER VS. OUTER IDENTITY ARCHITECTURE                                |
|                                                                                                         |
|     [ EAP-Response / Identity ] =====> OUTER IDENTITY: "anonymous@corp.com"                             |
|     (Transmitted in Cleartext)         Visible to network eavesdroppers & packet analyzers.              |
|                                        Protects real employee username from being harvested.             |
|                                                                                                         |
|     [ TLS Encrypted Tunnel ] ==========> INNER IDENTITY: "susan_contractor@corp.com" + Password         |
|     (Phase 2 Protected Session)        Encrypted inside TLS tunnel. Visible ONLY to ClearPass.          |
+---------------------------------------------------------------------------------------------------------+

The Privacy Threat of Cleartext Identities

If a supplicant transmits the user's actual corporate identity (e.g., john_smith@enterprise.com) in the initial unencrypted EAP-Response/Identity, any passive packet sniffer on the wired LAN or wireless RF spectrum can harvest the username. Malicious actors compile target lists of high-privilege usernames (executives, engineers, system administrators) to orchestrate spear-phishing and social engineering attacks.

The Anonymous Outer Identity Solution

To thwart identity harvesting, modern enterprise supplicants support identity hiding:

• Outer Identity (Anonymous): The supplicant populates the cleartext initial response with a generic routing string, such as anonymous or anonymous@corp.com. The switch and RADIUS proxy servers use the domain realm (@corp.com) to route the request to the correct ClearPass cluster.
• Inner Identity (True Identity): Once Phase 1 establishes the encrypted TLS tunnel, the supplicant transmits the genuine user identity (john_smith@enterprise.com) and authentication payload exclusively inside the encrypted tunnel, completely concealed from eavesdroppers.

---

AOS-CX 802.1X Configuration Commands and Security Timers

The following configuration session illustrates enabling 802.1X authentication on an AOS-CX switch interface, configuring security timers, and defining fallback roles:

switch# configure terminal

! Step 1: Globally configure 802.1X Authenticator
switch(config)# aaa authentication port-access dot1x authenticator radius server-group CPPM-RADIUS-GROUP
switch(config)# aaa authentication port-access dot1x authenticator enable

! Step 2: Configure Local User Roles for Access and Fallback
switch(config)# port-access role CORP_USER_ROLE
switch(config-pa-role)# vlan access 10
switch(config-pa-role)# exit

switch(config)# port-access role GUEST_REJECT_ROLE
switch(config-pa-role)# vlan access 900
switch(config-pa-role)# exit

switch(config)# port-access role CRITICAL_AUTH_ROLE
switch(config-pa-role)# vlan access 950
switch(config-pa-role)# exit

! Step 3: Configure 802.1X on Interface 1/1/10
switch(config)# interface 1/1/10
switch(config-if)# no routing
switch(config-if)# vlan access 1
switch(config-if)# aaa authentication port-access client-limit 2
switch(config-if)# aaa authentication port-access dot1x authenticator enable

! Step 4: Configure Security Timers
switch(config-if)# aaa authentication port-access dot1x authenticator max-eapol-requests 3
switch(config-if)# aaa authentication port-access dot1x authenticator quiet-period 30
switch(config-if)# aaa authentication port-access dot1x authenticator reauth
switch(config-if)# aaa authentication port-access dot1x authenticator reauth-period 14400

! Step 5: Configure Reject and Critical Roles
switch(config-if)# aaa authentication port-access reject-role GUEST_REJECT_ROLE
switch(config-if)# aaa authentication port-access critical-role CRITICAL_AUTH_ROLE
switch(config-if)# exit

Detailed Analysis of Security Timers and Fallback Roles

• discovery-period <seconds> (Default: 30 s): How often the switch sends EAP-Request/Identity frames to discover a supplicant on the port.
• max-eapol-requests <count> (Default: 5): How many EAPOL requests the switch sends without a reply before giving up on the client as a supplicant.
• max-retries <count> (Default: 2): How many authentication attempts are allowed before the client is considered failed.
• quiet-period <seconds> (Default: 60 s): After the allowed attempts fail, the switch waits this long before processing authentication from that client again, slowing brute-force attempts.
• reauth-period <seconds> (Default: 3600 s): Periodic re-authentication timer (enabled with reauth), so credentials and certificates are re-checked without dropping the session.
• reject-role <role-name>: Applied when the RADIUS server rejects the client (Access-Reject), for example because of a bad password or an expired account. The client lands in a restricted role instead of being dropped entirely.
• critical-role <role-name>: Applied when the RADIUS server is unreachable or the request times out, during first authentication or re-authentication. The client gets limited access until the server returns and normal authentication applies the final role.

(Other vendors use names such as tx-period, max-requests, or "unauth VLAN"; the AOS-CX timers above are from the AOS-CX 10.14 CLI Guide.)

---

Common Exam Traps

• Client Certificate Myth in PEAP: A frequent exam trap suggests that PEAP-MSCHAPv2 requires digital certificates on both the server and the client endpoint. Only EAP-TLS requires client certificates. PEAP requires a certificate exclusively on the authentication server.
• Outer Identity Snooping: The exam often tests how to prevent username harvesting on public or branch LANs. The correct mechanism is configuring an anonymous outer identity in the endpoint supplicant configuration.
• Reject-Role vs. Critical-Role:
  • reject-role is triggered by a rejection from an online server.
  • critical-role is triggered by a timeout when no server responds.