2.3 Authentication, Authorization & Accounting (AAA)

2.3 Authentication, Authorization & Accounting (AAA)

Quick Answer: The AAA Framework forms the operational foundation of identity governance across IT environments. Authentication confirms who a user or device is, Authorization determines what resources they can access, and Accounting logs what actions they performed. Multi-Factor Authentication (MFA) requires proof from two or more distinct factor categories (Knowledge, Possession, Inherence). Centralized network AAA relies on protocols like RADIUS (UDP ports 1812/1813) and TACACS+ (TCP port 49).

Identity management requires clear, standardized operational steps. The AAA framework provides the model utilized by network devices, operating systems, cloud portals, and firewalls to manage identity, enforce permissions, and generate audit logs.

The Three Pillars of the AAA Framework

User / Device ---> [ 1. Authentication ] ---> [ 2. Authorization ] ---> [ 3. Accounting ]
                     (Identity Verified)        (Permissions Granted)      (Actions Logged)

1. Authentication (Who are you?)

Authentication is the process of verifying the claimed identity of a subject (user, system process, or network device). Before access is granted, the system challenges the subject to present valid credentials matching an established digital identity.

• Mechanisms: Submitting a username and password, scanning a fingerprint, inserting a PIV smart card, or presenting an X.509 client digital certificate during a TLS handshake.

2. Authorization (What can you do?)

Once identity is authenticated, authorization determines the explicit rights, permissions, and privilege levels granted to the subject. It defines what resources the subject can read, write, execute, or configure.

• Mechanisms: Role-Based Access Control (RBAC) group memberships, firewall rules permitting specific destination IP/ports, or TACACS+ command authorization allowing specific CLI commands while blocking others.

3. Accounting (What did you do?)

Accounting (or Auditing) continuously tracks, records, and logs the activity of authenticated subjects while connected to system resources. It captures connection start timestamps, session durations, executed commands, accessed files, data transfer volumes, and logoff timestamps.

• Mechanisms: Centralized Syslog messages sent to a SIEM platform, Windows Security Event logs (Event ID 4624 for successful logon), RADIUS accounting packet streams, and terminal session logs.

Authentication Factor Categories & MFA Architectures

Authentication mechanisms are classified into distinct factor categories based on the type of evidence presented:

                   [ Multi-Factor Authentication (MFA) ]
                                     |
     ________________________________|________________________________
    |                                |                                |
[ Something You Know ]      [ Something You Have ]      [ Something You Are ]
 (Knowledge Factor)           (Possession Factor)         (Inherence Factor)

The Factor Categories

1. Something You Know (Knowledge Factor): Information memorized and kept secret by the user.
   • Examples: Passwords, Personal Identification Numbers (PINs), passphrases, security challenge answers.
2. Something You Have (Possession Factor): Physical or digital objects held in the user's physical possession.
   • Examples: Hardware key fobs (RSA SecurID), smart cards / CAC cards, FIDO2/WebAuthn USB hardware tokens (YubiKey), software authenticator apps (TOTP apps generating 6-digit codes like Google Authenticator), push notification mobile devices.
3. Something You Are (Inherence Factor / Biometrics): Unique biological or anatomical characteristics of the human body.
   • Examples: Fingerprint scans, facial recognition, iris scans, retina scans, voice pattern analysis.
4. Somewhere You Are (Location Factor): Contextual physical or network location data (e.g., GPS coordinates, corporate IP subnets).
5. Something You Do (Behavioral Factor): Dynamic human behavioral patterns (e.g., keystroke dynamics, mouse movement speed).

Biometric Accuracy Metrics

Biometric systems (Inherence Factor) are evaluated using three standardized error rates:

• False Acceptance Rate (FAR / Type II Error): The percentage of unauthorized impostors incorrectly accepted by the system. A false acceptance is a security failure, so a lower FAR indicates higher security.
• False Rejection Rate (FRR / Type I Error): The percentage of legitimate authorized users incorrectly rejected by the system. A false rejection is a usability failure, so a lower FRR indicates better usability.
• Crossover Error Rate (CER), also called the Equal Error Rate (EER): The point on a sensitivity graph where FAR equals FRR. CER is the standard single-number baseline for comparing biometric systems — the lower the CER, the more accurate the system.\n\nMemory aid for the exam: FRR is Type I (one R-word — rejected), FAR is Type II. FAR and FRR move inversely: raising sensitivity to cut FAR pushes FRR up, and vice versa, which is why CER exists as a neutral comparison point.

True Multi-Factor Authentication (MFA) vs. Multi-Step Authentication

To qualify as true Multi-Factor Authentication (MFA), a login sequence must require credentials from two or more DIFFERENT factor categories (e.g., a master password [Know] combined with a YubiKey token code [Have]).

Critical Distinction: Requiring two credentials from the same category (e.g., a password AND a PIN code, both Knowledge factors) is multi-step authentication, but NOT multi-factor authentication. NIST SP 800-63B explicitly deprecates SMS-based one-time passcodes due to SIM swapping and SS7 interception vulnerabilities.

Enterprise AAA Protocols: RADIUS vs. TACACS+

Enterprise organizations utilize centralized AAA servers to authenticate remote users, VPN connections, wireless 802.1X clients, and network administrators managing switches and routers.

RADIUS (Remote Authentication Dial-In User Service)

• Standard: Open IETF standard (RFC 2865 for Authentication/Authorization, RFC 2866 for Accounting).
• Transport Protocol: Operates over UDP (User Datagram Protocol), using default ports 1812 (Authentication/Authorization) and 1813 (Accounting).
• Encryption Depth: Encrypts ONLY the password field (using MD5 hashing and a shared secret). Packet headers, usernames, and accounting data remain unencrypted clear-text.
• Architecture: Combines Authentication and Authorization into single response packets (Access-Accept or Access-Reject).
• Primary Use Case: Enterprise Wi-Fi access (WPA2/WPA3 Enterprise via 802.1X), Remote Access VPN concentrators, ISP dial-in services.

TACACS+ (Terminal Access Controller Access-Control System Plus)

• Standard: Cisco proprietary protocol (released as open draft).
• Transport Protocol: Operates over TCP (Transmission Control Protocol), using port 49 (connection-oriented, reliable delivery).
• Encryption Depth: Encrypts the ENTIRE packet payload (only the raw TCP header is clear-text), providing superior secrecy.
• Architecture: Completely separates Authentication, Authorization, and Accounting into independent operational modules.
• Granular Command Control: Enables command-by-command authorization on network switches and routers (e.g., permitting an analyst to run show interface while blocking configure terminal).
• Primary Use Case: Administrative device management and command-line control of Cisco routers, switches, and firewalls.

RADIUS vs. TACACS+ Comparison Table

Non-Repudiation & PKI Digital Signatures

Non-Repudiation guarantees that the author of a message or executor of a transaction cannot deny initiating the action. It combines proof of origin with proof of integrity.

• Public Key Infrastructure (PKI) Mechanics: Non-repudiation relies on asymmetric cryptography. When an administrator signs a system change log or contract, the signing software generates a SHA-256 hash of the content and encrypts the hash using the signer's Private Key, creating a Digital Signature.
• Verification Process: Anyone possessing the signer's corresponding Public Key can decrypt the signature to reveal the original hash. If the decrypted hash matches a newly computed hash of the document, it proves two facts: (1) only the owner of the private key could have generated the signature, and (2) the document content was not tampered with.
• SOC Forensic Value: In compliance auditing, court evidence chains, and digital forensics, non-repudiation ensures audit logs and transaction records maintain legal admissibility.