6.5.2. Authentication Protocols: Kerberos, RADIUS, and TACACS+

💡 First Principle: Authentication protocols define the precise sequence of messages exchanged to prove identity — and the security properties of each protocol determine what attacks are possible against it. Understanding the protocol flow reveals both the trust assumptions and the attack surface.

Kerberos

Kerberos is a ticket-based authentication protocol that avoids sending passwords over the network. The Key Distribution Center (KDC) — running on domain controllers in AD — issues encrypted tickets that prove identity.

Authentication flow:

1. AS-REQ: Client sends username to KDC (Authentication Service)
2. AS-REP: KDC returns a Ticket Granting Ticket (TGT) encrypted with the KRBTGT account hash, plus a session key encrypted with the user's password hash
3. TGS-REQ: Client presents TGT to KDC (Ticket Granting Service) requesting access to a specific service
4. TGS-REP: KDC returns a service ticket encrypted with the target service's account hash
5. AP-REQ: Client presents service ticket to the target service
6. AP-REP: Service validates the ticket and grants access

Critical security properties: The user's password is never sent over the network — only used to decrypt the initial response. Tickets are time-limited (default TGT: 10 hours). Mutual authentication is possible (service proves its identity to the client).

Kerberos weaknesses: The KRBTGT account hash is the root of all trust — compromising it enables Golden Ticket attacks (forging any TGT). Service account hashes enable Silver Ticket attacks (forging service tickets). Kerberoasting requests service tickets for offline cracking. Time synchronization is critical — Kerberos requires clocks within 5 minutes; time skew causes authentication failures.

RADIUS

Remote Authentication Dial-In User Service provides centralized AAA (Authentication, Authorization, Accounting) for network access:

TACACS+

Terminal Access Controller Access-Control System Plus is Cisco's proprietary AAA protocol:

When to use which: RADIUS for end-user network access (VPN, wireless 802.1X) where broad interoperability matters. TACACS+ for network device administration where granular command-level authorization is needed (allow this admin to run show commands but not configure terminal). Many organizations use both — RADIUS for user access, TACACS+ for infrastructure management.

⚠️ Exam Trap: RADIUS encrypts only the password field — the rest of the RADIUS packet (including username, authorization attributes, and accounting data) is sent in cleartext. TACACS+ encrypts the entire packet body. A question about "which protocol provides full packet encryption for AAA" points to TACACS+, not RADIUS. However, RADIUS is the standard for 802.1X and is far more widely deployed for network access authentication.

Reflection Question: A network engineer proposes using RADIUS for both end-user VPN authentication and router/switch administrative access. A security architect recommends TACACS+ for the network device administration use case. Explain the specific security capability that TACACS+ provides for device administration that RADIUS cannot, and why this matters for managing a network with 500 switches.