AAA (Authentication, Authorization, Accounting) — Explain authentication, authorization, and accounting (AAA) (conceptual)

Historical Context & Motivation

Before the emergence of formalized access-control frameworks, early multi-user systems like UNIX time-sharing hosts relied on simple password files and rudimentary privilege bits to separate users from one another. As networks expanded from isolated mainframes to interconnected enterprise environments during the 1980s and 1990s, the need for a unified model of identity verification, permission enforcement, and activity tracking became impossible to ignore. Early dial-up Internet service providers faced mounting losses from unauthorized usage, while enterprises discovered that a compromised password could cascade into a full-network breach without any audit trail to trace the intrusion.

The AAA framework — standing for Authentication, Authorization, and Accounting — crystallized from this operational necessity. It provided a conceptual and architectural scaffold that separated three logically distinct but deeply interdependent concerns into cleanly defined services. Cisco Systems, Livingston Enterprises, and the IETF played pivotal roles in standardizing protocols that embodied this model, transforming ad-hoc security checks into a principled, auditable, and scalable architecture.

The central question that the AAA framework addresses remains as relevant today as it was in the era of dial-up modems: How can a system reliably determine who is requesting access, decide what that entity is allowed to do, and maintain a tamper-evident record of everything that occurred? Understanding the answer requires examining each pillar of the triad in turn.

Core Principles & Definitions

The AAA framework decomposes secure access management into three sequentially dependent functions. Each function answers a distinct question, yet all three must operate in concert to provide a security posture that is both usable and auditable. A failure in any single pillar can undermine the guarantees provided by the other two: authentication without authorization leads to unconstrained access; authorization without accounting leaves no forensic trail; and accounting without proper authentication renders audit logs unreliable because subject identity cannot be trusted.

Two additional concepts underpin the AAA model. Identification — the act of claiming an identity (e.g., entering a username) — is sometimes listed as a precursor step, making the model 'IAAA.' Meanwhile, non-repudiation is the property that emerges when strong authentication is coupled with comprehensive accounting: a user cannot credibly deny having performed a recorded action. Together, these supplementary concepts reinforce the integrity of the triad.

Visual Explanation — The AAA Flow

The following diagram illustrates the canonical AAA transaction flow. A client (supplicant) initiates an access request to a Network Access Server (NAS), which acts as a policy enforcement point. The NAS forwards credential data to a centralized AAA Server (such as a RADIUS or TACACS+ server). The server performs authentication against an identity store, returns authorization attributes (e.g., VLAN assignment, ACLs), and later receives accounting records that document the session lifecycle.

Notice that the NAS functions as both a policy enforcement point (PEP) and a relay. It does not make authentication or authorization decisions autonomously in a centralized AAA deployment; instead, it delegates those decisions to the AAA server, which serves as the policy decision point (PDP). This separation of concerns is critical for scalability — a single RADIUS server can support thousands of NAS devices — and for security, because credentials never persist on the edge devices themselves.

How It Works — Protocols and Mechanisms

The AAA model is protocol-agnostic at the conceptual level, but two dominant protocols implement it in practice: RADIUS and TACACS+. Each takes a different architectural approach to separating the three A's, and understanding their mechanics reveals the design space of AAA implementations.

RADIUS — Combined AuthN/AuthZ, Separate Accounting

RADIUS, defined in RFC 2865/2866, operates over UDP (ports 1812 for authentication/authorization and 1813 for accounting). It combines authentication and authorization into a single Access-Request/Access-Accept exchange: the Access-Accept packet carries both the authentication verdict and the authorization attributes (such as VLAN IDs, ACL names, or session timeouts) as attribute-value pairs (AVPs). Accounting is handled by separate Accounting-Request packets with status types of Start, Interim-Update, and Stop. RADIUS encrypts only the user's password field within the Access-Request packet; the remainder of the packet (including authorization attributes) is transmitted in cleartext, a well-known limitation that modern deployments mitigate by wrapping RADIUS inside IPsec or TLS (RadSec, RFC 6614).

TACACS+ — Fully Separated AAA

TACACS+, a Cisco-proprietary protocol operating over TCP port 49, treats authentication, authorization, and accounting as three entirely independent exchanges. This granular separation allows an administrator to authenticate users against an LDAP directory while enforcing command-level authorization via a separate policy engine and shipping accounting records to a dedicated syslog collector. The entire TACACS+ packet body is encrypted (using a shared secret and MD5-based pseudo-pad), providing confidentiality for all three transaction types — a significant advantage over classic RADIUS in environments where authorization attributes themselves are sensitive.

Authentication Factor Categories

Regardless of the transport protocol, authentication relies on presenting one or more factors from distinct categories. When two or more factors from different categories are required, the system employs multi-factor authentication (MFA), dramatically reducing the probability of credential compromise because an attacker must independently defeat each factor.

Authorization Models & Accounting Detail

Once a user is authenticated, the authorization engine must determine the precise set of permissions to grant. Several formal models exist, each embodying different trade-offs between expressiveness, administrative overhead, and scalability. Understanding these models is essential because they determine how authorization policies are encoded, evaluated, and maintained across an organization.

Accounting Data Categories

The accounting component of AAA captures a range of session metadata. In RADIUS, these are conveyed through Accounting-Request packets with an Acct-Status-Type attribute that indicates Start (session begins), Interim-Update (periodic usage data), or Stop (session ends). The server typically stores these records in a relational database or forwards them to a SIEM for correlation. Key recorded attributes include session duration, octets transferred (input and output), the authenticated username, the NAS IP and port, and any vendor-specific attributes that capture command-level detail.

• Session accounting: Start/stop timestamps, session ID, termination cause.
• Usage accounting: Bytes in/out, packets in/out — essential for ISP billing.
• Command accounting: Every CLI command executed on a managed device (TACACS+ specialty).
• Event accounting: Failed login attempts, privilege escalation events, policy violations.

Worked Example — RADIUS AAA for Wi-Fi Access

Consider a university deploying WPA2-Enterprise Wi-Fi using 802.1X with a RADIUS back-end. A student, Alice, opens her laptop and attempts to connect to the 'UnivSecure' SSID. The following worked example traces the complete AAA lifecycle from association to session teardown.

RADIUS vs. TACACS+ — Strengths and Limitations

While both RADIUS and TACACS+ implement the AAA model, they differ significantly in architecture, security properties, and typical deployment contexts. The table below provides a systematic comparison across dimensions that matter most in protocol selection.

Connection to Zero Trust & Modern IAM

The traditional AAA model assumes a clear perimeter: authenticate at the edge, authorize once, and account for the session. Zero Trust Architecture (ZTA), as formalized by NIST SP 800-207, dissolves this perimeter assumption. In a Zero Trust environment, every request — not just the initial session — is subject to continuous AAA evaluation. Authentication becomes continuous and risk-adaptive, authorization is enforced at the individual resource level (micro-segmentation), and accounting must capture fine-grained telemetry from every micro-service interaction.

Modern identity platforms like OAuth 2.0 and OpenID Connect (OIDC) can be viewed through the AAA lens: OIDC handles authentication by issuing ID tokens, OAuth 2.0 handles authorization by issuing scoped access tokens, and structured logging of token grants and API calls serves as the accounting layer. Service mesh frameworks like Istio embed mutual TLS authentication and fine-grained authorization policies at the sidecar proxy level, effectively distributing AAA enforcement to every hop in a micro-service architecture. As you advance into topics like identity federation, SAML assertions, and decentralized identity (DID), you will see that the AAA triad remains the conceptual skeleton onto which all of these technologies attach.

Practice Problems

Summary