25-802.1X-Control-Plane-(Research)

⬅️ Back to Table of Contents

Lab 25: IEEE 802.1X Control-Plane Integration & Platform Capability Validation

🔍 Research Project

Design and Empirical Evaluation of a Layered Access-Control Security Model for Enterprise Access Networks

(IP-Version Agnostic Architecture with Dual-Stack Considerations)

---

📝 Core Focus: Identity-Based Access Architecture & Control-Plane Validation

🏗️ Environment: Cisco Modeling Labs (IOSvL2) + FreeRADIUS (Ubuntu VM on VMware)

🌐 Author: RangoGM (2026 Grinding Series)

---

I. Objective

This lab evaluates the architectural deployment of IEEE 802.1X within a virtualized access-layer environment.

📍 Quick Navigation

• II. Architectural Context
• III. RADIUS Integration Validation
• IV. Expected IEEE 802.1X Authentication Flow
• V. Observed Behavior in IOSvL2 (CML Free)
• VI. Architectural Interpretation
• VII. Platform Capability Limitation
• VIII. Security Design Implications
• IX. Research Significance
• X. Forward Path

Warning

Due to platform constraints (IOSvL2 in CML Free), the goal is not full end-to-end host authorization, but to:

• Validate AAA & RADIUS integration
• Observe 802.1X control-plane behavior
• Analyze EAP authentication workflow
• Identify implementation limitations in virtual L2 environments

This experiment represents Phase II – Identity Enforcement Architecture Analysis within the overall security model.

📸 Screenshot:

---

II. Architectural Context

Components

Role	Device	Function
Authenticator	IOSvL2 Switch (CML Free)	Access port control
Authentication Server	Ubuntu FreeRADIUS	Credential validation
Supplicant (Test 1)	Kali Linux (CLI – wpa_supplicant)	EAP client
Supplicant (Test 2)	Windows (GUI 802.1X)	EAP client
Routing Layer	R1	Inter-VLAN communication

⬆ Back to Top

---

III. RADIUS Integration Validation

RADIUS Server Setup

sudo apt update && sudo apt install freeradius freeradius-utils -y

• Configure clients: sudo nano /etc/freeradius/3.0/clients.conf & scroll down to bottom add these commands:

client Cisco_Switch {
  ipaddr = <your_ip_address>
  secret = <your_password>
  nas_type = cisco
}

📸 Screenshot:

(Ctrl + 0 → Enter → Ctrl + X)

• Configure User Identify: sudo nano /etc/freeradius/3.0/users & add at the top of the file:

"<your_user_name>"  Cleartext-Password := "<your_username_password>"

📸 Screenshot:

(Ctrl + 0 → Enter → Ctrl + X)

• Use sudo freeradius -X to run as Foreground Debug mode to Analyzing/inspecting the packet line-by-line during processing

Important

Last output must be Ready to process requests this meant that Ubuntu has confirm to be an Authentication Server.

📸 Screenshot:

Check if Port 1812 & 1813 is available: ss -tulnp & use these commands to ensure:

sudo ufw allow 1812/udp
sudo ufw allow 1813/udp
sudo ufw reload

📸 Screenshot:

• Open new Terminal and keep freeradius -X running to test internal operation of the server:

radtest <your_user_name> <your_username_password> localhost 0 testing123

📸 Screenshot:

AAA Configuration

⚙️ Click to see Full Switch Running-Config and Explanation

interface Vlan1
 ip address 192.168.99.2 255.255.255.0
 no shut
exit
ip radius source-interface Vlan1

aaa new-model
radius server RADIUS_UBUNTU
  address ipv4 192.168.99.99 auth-port 1812 acct-port 1813
  key cisco123
exit

aaa group server radius RADIUS_GROUP
 server name RADIUS_UBUNTU
exit

aaa authentication dot1x default group RADIUS_GROUP
aaa authorization network default group RADIUS_GROUP
dot1x system-auth-control

interface Ethernet0/2
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator
 spanning-tree portfast
exit

📘 Configuration Breakdown (Technical Explanation)

1. Global AAA Activation

• aaa new-model: Initializes the Authentication, Authorization, and Accounting (AAA) framework. This command migrates the switch from local authentication to a centralized AAA model, enabling advanced identity-based security features.

2. RADIUS Server Definition

• radius server RADIUS_UBUNTU: Defines a logical object representing the remote Authentication Server (FreeRADIUS on Ubuntu).

• address ipv4 192.168.99.99...: Specifies the Layer 3 reachability and the standard UDP ports (1812 for Authentication, 1813 for Accounting).

• key cisco123: Configures the Shared Secret. This is the cryptographic key used to encrypt communications between the Authenticator and the RADIUS server.

3. Server Grouping

• aaa group server radius RADIUS_GROUP: Groups individual RADIUS servers into a named cluster. This abstraction allows for high availability and load balancing in enterprise environments.

4. Authentication & Authorization Policies

• aaa authentication dot1x default group RADIUS_GROUP: Instructs the switch to use the specified RADIUS group as the primary method for all IEEE 802.1X authentication requests.

• aaa authorization network default group RADIUS_GROUP: Ensures that once a user is authenticated, their network access privileges (such as VLAN assignment) are authorized by the RADIUS server.

5. System-Wide 802.1X Control

• dot1x system-auth-control: The global "master switch" for 802.1X. Without this command, the switch will not process any EAPOL frames, even if the individual ports are configured.

6. Port-Level Enforcement (Interface Ethernet 0/2)

• authentication port-control auto: Sets the port's authorization state to "Auto." The port remains in an unauthorized state (blocking data traffic) until the client successfully authenticates via RADIUS.

• dot1x pae authenticator: Configures the port as a Port Access Entity (PAE) with the role of an Authenticator. It enables the port to send and receive EAPOL (Extensible Authentication Protocol over LAN) frames to and from the Supplicant.

• spanning-tree portfast: Optimizes the transition to the forwarding state by bypassing the standard listening/learning phases, preventing DHCP timeouts during the 802.1X handshake.

Observed Behavior

• Using Wireshark and freeradius -X:

• Switch sends Access-Request

• FreeRADIUS responds with Access-Accept

• Message-Authenticator validated

• NAS-IP-Address correctly identified

• Round-trip latency < 10ms (lab environment)

📸 Screenshot:

• Test Access-Request from Switch: test aaa group radius <your_username> <your_username_password>, use debug dot1x all, debug authentication all & debug radius authentication to verify:

(Capture Packets between Switch and RADIUS Server)

(At freeradius -X)

(Use show aaa servers for more details)

This confirms:

• ✔ RADIUS server operational
• ✔ Shared secret correct
• ✔ User credentials valid
• ✔ Control-plane AAA communication functioning properly

⬆ Back to Top

---

IV. Expected IEEE 802.1X Authentication Flow

In a fully supported environment, the authentication process should follow:

1. Supplicant sends EAPOL-Start

2. Switch responds with EAP-Request/Identity

3. Supplicant replies with EAP-Response/Identity

4. Switch forwards identity to RADIUS

5. RADIUS returns Access-Accept

6. Port transitions from unauthorized to authorized

7. Data traffic permitted

⬆ Back to Top

---

V. Observed Behavior in IOSvL2 (CML Free)

Endpoint Testing (Cross-Platform Validation)

Both Kali Linux (CLI-based supplicant) and Windows (GUI-based supplicant) were tested.

Observed results:

• Supplicant transmits EAPOL frames

• ❌ No EAP-Request received from switch

• ❌ No EAPOL negotiation state transition

• Port remains in connected state

• ❌ No MAC address learned

• ❌ No access-session state table available

• Create a file to run Baseline: sudo nano wired.conf and add these commands:

network={
  key_mgmt=IEEE8021X
  eap=MD5
  identity="rango"
  password="rango123"
}

• Execute sudo wpa_supplicant -i eth0 -c wired.conf -D wired -dd to start Authenticate:

• -c wired.conf: Points to the Configuration File. This file contains the security policy, EAP method (MD5), and the identity credentials (rango/rango123) defined for the session.

• -D wired: Selects the Driver. Since we are using a standard Ethernet connection rather than a wireless one, the wired driver is specified to handle EAPOL (EAP over LAN) frames correctly.

• -dd: Enables Extra Verbose Debugging. This is the most critical flag for research purposes.

  • It provides a real-time, hexadecimal-level view of the EAPOL state machine.

  • It allows the observer to identify exactly where the handshake fails (e.g., during the Solicitation phase or Identity exchange).

📸 Screenshot:

(Freeze here and a Fail Outputs after that)

(No Mac Addresses learned even the VMWare MAC)

(Same as Windows)

Platform Indicators

• show authentication sessions not available

• ❌ No dot1x session tracking

• ❌ No port authorization state change

• ❌ No EAPOL state machine enforcement observed

• Can confirm more about this through commands sudo tcpdump -i eth0 ether proto 0x888e while execute sudo wpa_supplicant -i eth0 -c wired.conf -D wired -dd and use Wireshark to capture the packets:

📸 Screenshot:

(Supplicant successfully transmitted multiple EAPOL-Start frames but Zero response frames were observed from the switch's interface MAC. The expected EAP-Request/Identity handshake never initiated)

(No dot1x features verify commands)

⬆ Back to Top

---

VI. Architectural Interpretation

The experiment demonstrates a clear separation between:

Control-Plane AAA Functionality

• RADIUS communication works

• Access-Accept received

• Authentication logic at RADIUS validated

Data-Plane 802.1X Enforcement

• ❌ No authenticator state machine active

• ❌ No session-based authorization

• ❌ No port-level access control transition

Warning

This indicates that IOSvL2 in CML Free does not implement a full IEEE 802.1X authenticator engine.

⬆ Back to Top

---

VII. Platform Capability Limitation

Although AAA integration is successful, the following limitations were identified:

• Absence of EAPOL negotiation handling

• ❌ No access-session management

• ❌ No dynamic port authorization control

• ❌ No enforcement of unauthorized state

This highlights an important research principle:

• Platform capability must be validated before drawing conclusions about security feature behavior.

• Virtualized L2 environments may not fully replicate enterprise hardware functionality.

⬆ Back to Top

---

VIII. Security Design Implications

This lab reinforces several architectural insights:

• Identity-based access control requires a fully implemented authenticator engine.

• AAA communication alone does not guarantee enforcement.

• Virtual lab environments may simulate control-plane traffic but not data-plane policy enforcement.

• Security validation must consider implementation boundaries.

Feature	Port Security (Lab 24)	802.1X Baseline (Lab 25)
Trust Model	Trust by Port/MAC	Trust by Identity (User/Pass)
MAC Spoofing Resilience	Low (Vulnerable to Cloning)	Architecturally High (Pending Full Enforcement Validation)
Centralization	Decentralized (Local Config)	Centralized (RADIUS/Database)
Failure Result	Shutdown/Restrict	Blocked at Ingress (Expected in Fully Supported Platforms)

⬆ Back to Top

---

IX. Research Significance

Despite the absence of full port authorization enforcement, this lab successfully:

• [✔] Validated RADIUS infrastructure deployment

• [✔] Confirmed AAA communication workflow

• [✔] Demonstrated cross-platform supplicant testing

• [✔] Identified platform constraints affecting identity enforcement

This contributes to the broader research objective by:

• [✔] Distinguishing MAC-based enforcement from identity-based architecture

• [✔] Documenting validation constraints in virtualized environments

• [✔] Providing a realistic boundary condition for further research

⬆ Back to Top

---

X. Forward Path

Due to IOSvL2 limitations, future work will focus on:

• Conceptual comparison: Port Security vs MAB vs 802.1X

• Dependency risk modeling (RADIUS availability)

• Access-layer monitoring and logging integration

• Defense-in-depth hardening at Layer 2

Note

Full enterprise-grade 802.1X enforcement remains future work requiring hardware-capable platforms (e.g., Catalyst 9000 series).

⬆ Back to Top

⬅️ Previous Lab	🏠 Main Menu	[Next Lab ➡️]