10.1 The AAA Framework and Architecture

The AAA Framework and Architecture

Quick Summary: The AAA security framework underpins enterprise access control by dividing network security into three discrete functions: Authentication (validating identity), Authorization (granting resource permissions), and Accounting (recording user activity). In campus LANs, this framework is operationalized through IEEE 802.1X port-based network access control, which deploys a three-party architecture consisting of the Supplicant (endpoint), the Authenticator (AOS-CX switch), and the Authentication Server (ClearPass). By bridging Layer 2 EAPOL frames at the switch edge with IP-based RADIUS datagrams upstream, enterprise switches dynamically enforce granular User Roles, micro-segmenting authenticated devices without requiring static port reconfigurations.

---

The Tripartite AAA Security Model

In modern enterprise networks, granting physical switch port connectivity must not equate to granting unrestricted network access. The AAA framework decouples identity management and policy enforcement into three structured operational pillars:

+---------------------------------------------------------------------------------------------------------+
|                                    THE AAA SECURITY FRAMEWORK PILLARS                                   |
|                                                                                                         |
|     [ 1. AUTHENTICATION ] ---------> "Who are you?"                                                     |
|                                     Validates identity using credentials, PKI digital certificates,     |
|                                     or hardware tokens before permitting Layer 2 admission.             |
|                                                                                                         |
|     [ 2. AUTHORIZATION ] ----------> "What are you allowed to do?"                                      |
|                                     Assigns dynamic network privileges: VLAN membership, ingress ACLs,   |
|                                     bandwidth contracts, and User Roles based on user context.         |
|                                                                                                         |
|     [ 3. ACCOUNTING ] -------------> "What did you do, and for how long?"                               |
|                                     Records session metrics: start/stop timestamps, framing IP,         |
|                                     packet/byte counters, and termination reasons for audit compliance.  |
+---------------------------------------------------------------------------------------------------------+

1. Authentication (AuthN)

Authentication answers the fundamental question: "Who is attempting to access the network?" The system verifies claimed identity assertions before granting admission to enterprise transport infrastructure. Authentication methods include:

• Cryptographic Credentials: Passwords, passphrases, or challenge-response hashes (MS-CHAPv2).
• Digital Certificates: X.509 certificates validating public-key cryptographic assertions (EAP-TLS).
• Layer 2 Hardware Identifiers: Media Access Control (MAC) addresses (MAC-Auth for headless IoT).
• Interactive Captive Portals: Web-based forms capturing guest sponsor details or temporary vouchers.

2. Authorization (AuthZ)

Authorization answers the conditional policy question: "What network services and assets is this authenticated identity permitted to consume?" Once identity is validated, the authentication server evaluates contextual attributes (device health, time of day, connection medium, physical location) and issues an enforcement profile to the switch. In Aruba architectures, authorization attributes dynamically program:

• Dynamic VLAN Assignment: Placing an unmanaged contractor device into a quarantine or guest VLAN.
• User Roles: Assigning an AOS-CX local or dynamic user role containing tailored access control lists (ACLs).
• Quality of Service (QoS): Enforcing rate-limiting policies or marking DSCP/802.1p priorities.
• User-Based Tunneling (UBT): Directing client traffic across a GRE tunnel to an Aruba Mobility Gateway for deep stateful packet inspection.

3. Accounting (Acct)

Accounting answers the operational audit question: "What did the user do, when did they connect, and what resources did they consume?" Accounting tracks user sessions by generating audit records transmitted via RADIUS accounting packets (RFC 2866):

• Accounting-Start: Generated the moment the client port is authorized, recording the client MAC, assigned IP address, switch port, and session identifier.
• Interim-Update: Periodically transmitted (e.g., every 600 seconds) to report elapsed connection duration, active IP configuration, and cumulative byte/packet counters.
• Accounting-Stop: Generated when the client disconnects, link flaps, or times out. This record documents total bytes sent, total bytes received, session duration, and the specific termination cause (e.g., User-Request, Lost-Carrier, Admin-Reset).

---

The IEEE 802.1X Architectural Triad

The IEEE 802.1X standard defines port-based network access control (PNAC) for local area networks. It establishes a secure perimeter at the network edge by requiring client authentication prior to forwarding standard unicast or broadcast traffic. The standard mandates three distinct architectural entities:

+---------------------------------------------------------------------------------------------------------+
|                                      IEEE 802.1X ARCHITECTURAL TRIAD                                    |
|                                                                                                         |
|     [ Supplicant ]                 [ Authenticator ]                  [ Authentication Server ]          |
|   (Workstation / NIC)             (AOS-CX Access Switch)             (ClearPass Policy Manager)         |
|            |                                |                                     |                     |
|            | <==== EAPOL over Ethernet ===> | <======== EAP inside RADIUS ======> |                     |
|            |   (Layer 2 PAE Frame: 0x888E)  |          (UDP Port 1812 over IP)    |                     |
|            |                                |                                     |                     |
|            +---- Uncontrolled Port (Open) --+                                     |                     |
|            +---- Controlled Port (Closed) --+                                     |                     |
+---------------------------------------------------------------------------------------------------------+

1. The Supplicant

The Supplicant is the client software entity running on the endpoint seeking network admission (such as a laptop, workstation, smartphone, or corporate tablet). The supplicant responds to requests from the authenticator to verify identity.

• Native Supplicants: Built directly into modern operating systems (Microsoft Windows 802.1X supplicant, macOS Network framework, Apple iOS, Android, and Linux wpa_supplicant).
• Supplicant Responsibilities: Negotiates EAP types, validates server certificates against local trusted root stores, retrieves user/machine credentials, and manages cryptographic key material.

2. The Authenticator

The Authenticator is the network access device (an AOS-CX switch or Aruba wireless access point) situated at the physical or RF perimeter. The authenticator controls physical access to the network based on the authentication status of the client.

• Dual-Port Conceptual Model (PAE): Under IEEE 802.1X, each physical switch port is logically split into two Port Access Entity (PAE) communication paths:
  1. Uncontrolled Port: Always open to receive and transmit Layer 2 802.1X control frames (EAPOL). It discards all standard user data (IP packets, ARP, DHCP).
  2. Controlled Port: Remains in an unauthorized, blocked state until the authentication server verifies the supplicant's identity. Once authorized, the controlled port transitions to the forwarding state, allowing bidirectional data traffic.
• Crucial Architectural Principle: The Authenticator never validates credentials. It acts as a transparent protocol translator, bridging Layer 2 EAPOL frames from the client into Layer 4 RADIUS packets destined for the authentication server.

3. The Authentication Server

The Authentication Server is the centralized policy and identity verification engine—typically Aruba ClearPass Policy Manager (CPPM) or an enterprise RADIUS server (such as FreeRADIUS or Microsoft NPS). The server performs the actual cryptographic validation of identity assertions against enterprise directory stores (such as Microsoft Active Directory via Kerberos/LDAP, Azure AD/Entra ID, or internal certificate authorities). Following validation, the authentication server instructs the switch whether to open the controlled port and transmits authorization parameters.

---

EAP Encapsulation: EAPOL vs. RADIUS over IP

The Extensible Authentication Protocol (EAP, RFC 3748) is an authentication envelope rather than a specific authentication mechanism. To allow EAP packets to travel between the Supplicant and the Authentication Server across intermediate network switches, two distinct transport encapsulation standards are used:

Protocol Translation at the Authenticator

1. The Supplicant connects and sends an EAPOL-Start or responds to an EAP-Request/Identity with an EAP-Response/Identity over Ethernet.
2. The AOS-CX switch intercepts the Layer 2 EAPOL frame on the uncontrolled port.
3. The switch extracts the inner EAP message and encapsulates it into a standard RADIUS Access-Request UDP datagram. It appends RADIUS attributes:
   • User-Name (Attribute 1): The client's claimed identity string.
   • NAS-IP-Address (Attribute 4): The switch's management or loopback IP address.
   • NAS-Port / NAS-Port-Id (Attribute 5/87): Physical switch port identifier (e.g., 1/1/10).
   • Calling-Station-Id (Attribute 31): Endpoint MAC address.
   • Called-Station-Id (Attribute 30): Switch MAC address or port identifier.
   • EAP-Message (Attribute 79): The raw EAP packet.
   • Message-Authenticator (Attribute 80): An HMAC-MD5 cryptographic signature verifying packet integrity between the switch and ClearPass using the shared secret.
4. When ClearPass returns a RADIUS Access-Challenge, the switch strips the RADIUS headers, places the EAP payload into an EAPOL-Packet frame, and delivers it to the client.
5. Upon final validation, ClearPass sends a RADIUS Access-Accept containing authorization VSAs. The switch unlocks the controlled port and sends an EAP-Success frame to the endpoint.

---

AOS-CX Port-Access Client Modes and State Machine

In enterprise environments, multiple devices frequently connect through a single physical switch port (for example, a VoIP desktop telephone with an integrated PC pass-through switch port). AOS-CX switches provide configurable port-access client modes to manage these topologies:

+---------------------------------------------------------------------------------------------------------+
|                                    AOS-CX PORT-ACCESS CLIENT MODES                                      |
|                                                                                                         |
|     [ CLIENT-MODE ] -------------> Multi-Client Authentication (Standard Enterprise Default)            |
|                                    Each connected MAC address authenticates independently.              |
|                                    Phone (VoIP role/VLAN) + PC (Corporate role/VLAN) on same port.      |
|                                                                                                         |
|     [ DEVICE-MODE ] -------------> Single-Client Authentication (Legacy/High-Security Port)             |
|                                    The first authenticated MAC unlocks the physical port.               |
|                                    Additional devices piggyback without separate authentication.        |
+---------------------------------------------------------------------------------------------------------+

AOS-CX sets the mode per port with aaa authentication port-access auth-mode {client-mode | device-mode | multi-domain}; client-mode is the default. Multi-domain mode allows one voice device plus a configured number of data devices.

Detailed Analysis of Client Modes

• Client-Mode (client-mode): Each connected device must authenticate independently via its own MAC address. The switch maintains separate authorization states, User Roles, and accounting sessions for every MAC address learned on the interface. A VoIP phone authenticates via 802.1X/MAC-Auth and receives the Voice VLAN role, while the tethered PC authenticates and receives an Employee role on the Data VLAN.
• Device-Mode (device-mode): Only the initial connecting client authenticates. Once that device is authorized, the controlled port opens for all traffic arriving on that physical interface. This mode creates severe security risks in modern multi-device environments and is reserved for specialized single-device containment.

The AOS-CX Port-Access Client State Machine

An endpoint navigating port authentication on AOS-CX transitions through formal lifecycle states:

1. Connecting: The switch detects physical link-up and transmits an EAP-Request/Identity frame. If no response arrives, the switch retransmits according to configured retry counters.
2. Authenticating: The client responds with identity credentials. The switch exchanges EAPOL/RADIUS challenge messages with the authentication server.
3. Authenticated: The authentication server transmits an Access-Accept. The switch applies the assigned User Role, opens the controlled port, and initiates RADIUS accounting.
4. Held / Quiet Period: If authentication fails (bad credentials or server reject) after the allowed retries (max-retries, default 2), the switch holds the client for the quiet-period (default 60 seconds). During this interval, authentication attempts from that MAC are not processed, which slows brute-force attempts and avoids locking out directory accounts.

---

Role-Based Enforcement on AOS-CX

Traditional network architectures relied solely on dynamic VLAN assignment (RADIUS RFC 2868/3580 attributes: Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID) to segment users. Aruba AOS-CX elevates this through User Roles.

An AOS-CX User Role is a comprehensive policy container that encapsulates:

• Assigned VLAN ID: The Layer 2 broadcast domain.
• Ingress/Egress Access Control Lists (ACLs): Layer 2 through Layer 4 packet filtering applied directly in the switch ASIC.
• Quality of Service (QoS) Policy: Bandwidth rate-limits, priority queues, and DSCP remarking.
• Captive Portal Profile: Redirection URLs for web authentication onboarding.
• User-Based Tunneling (UBT): Redirecting traffic to an Aruba gateway cluster for stateful firewall inspection.

Dynamic User Roles (DUR) vs. Local User Roles (LUR)

• Local User Role (LUR): The administrator manually configures the role and its associated ACLs directly in the AOS-CX CLI (port-access role <role-name>). When ClearPass returns the Aruba-User-Role VSA (Vendor ID 14823, VSA 1), the switch matches the string to its locally pre-configured role definition.
• Dynamic User Role (DUR): The role definition (including ACLs and VLAN parameters) is maintained exclusively in ClearPass. When a client authenticates, ClearPass pushes the role name via RADIUS, and the AOS-CX switch downloads the full policy definition dynamically via REST APIs. This centralizes policy administration across hundreds of campus switches.

---

AOS-CX Configuration and Verification

The following configuration session illustrates configuring a RADIUS server, establishing an AAA server group, enabling 802.1X globally, and securing access port 1/1/1 on an AOS-CX switch:

switch# configure terminal

! Step 1: Define the ClearPass RADIUS Server and Shared Secret
switch(config)# radius-server host 10.10.100.50 key plaintext SecretRadiusKey123
switch(config)# radius dyn-authorization enable
switch(config)# radius dyn-authorization client 10.10.100.50 secret-key plaintext SecretRadiusKey123

! Step 2: Create a RADIUS Server Group
switch(config)# aaa group server radius CPPM-RADIUS-GROUP
switch(config-sg)# server 10.10.100.50
switch(config-sg)# exit

! Step 3: Enable 802.1X Port-Access Globally and point it at the server group
switch(config)# aaa authentication port-access dot1x authenticator radius server-group CPPM-RADIUS-GROUP
switch(config)# aaa authentication port-access dot1x authenticator enable

! Step 4: Configure Local User Roles for Role-Based Enforcement
switch(config)# port-access role EMPLOYEE_ROLE
switch(config-pa-role)# vlan access 20
switch(config-pa-role)# exit

switch(config)# port-access role REJECT_ROLE
switch(config-pa-role)# vlan access 99
switch(config-pa-role)# exit

! Step 5: Configure 802.1X on Access Port 1/1/1
switch(config)# interface 1/1/1
switch(config-if)# no routing
switch(config-if)# vlan access 1
switch(config-if)# aaa authentication port-access auth-mode client-mode
switch(config-if)# aaa authentication port-access client-limit 4
switch(config-if)# aaa authentication port-access dot1x authenticator enable
switch(config-if)# aaa authentication port-access reject-role REJECT_ROLE
switch(config-if)# exit

Essential Verification Commands

---

Common Exam Traps

• Authenticator Credential Validation Myth: The exam frequently asks whether the authenticator switch evaluates client password hashes or digital certificates. The switch never evaluates credentials; it operates strictly as an EAPOL-to-RADIUS protocol relay. Only the authentication server (ClearPass) validates credentials.
• Controlled vs. Uncontrolled Ports: Confusing which port entity permits EAPOL. Unauthenticated clients can always transmit EAPOL frames because the uncontrolled port is open; standard data traffic is blocked until the controlled port is opened upon authorization.
• Client-Mode vs. Device-Mode: Changing a port that connects both an IP phone and a PC to device-mode. In device mode only the first client authenticates and the rest ride along; keep the default client-mode (and a client limit of at least 2) so each device authenticates independently.