Kerberos

• Authentication protocol that uses symmetric key cryptography to verify user and service identities over insecure networks
• Operates on the principle of trusted third-party authentication - eliminates need to send passwords across the network
• Uses tickets (encrypted tokens) to prove identity without transmitting actual credentials
• Default authentication protocol for Windows Active Directory environments since Windows 2000

How Kerberos Works

• Three-party authentication system: Client, Authentication Server (AS), and Target Service
• Process uses two main tickets:
  • Ticket Granting Ticket (TGT): Proves user identity to the Key Distribution Center (KDC)
  • Service Ticket: Grants access to specific network services

Authentication Flow:

1. Initial Authentication: Client requests TGT from AS using username/password
2. TGT Issuance: AS verifies credentials and issues encrypted TGT (valid for 8-10 hours by default)
3. Service Request: Client presents TGT to Ticket Granting Server (TGS) requesting service access
4. Service Ticket: TGS issues service ticket encrypted with target service’s secret key
5. Service Access: Client presents service ticket to target service for authentication

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

Client      AS/KDC     Service
  |           |           |
  |--Login--->|           |
  |           |           |
  |<---TGT----|           |
  |           |           |
  |--TGT----->|           |
  |           |           |
  |<-Service--|           |
  | Ticket    |           |
  |           |           |
  |------Service Ticket-->|
  |           |           |
  |<-----Access Granted---|

Steps:
1. User login request
2. TGT issued (8-10hrs)
3. Request service access
4. Service ticket issued
5. Present ticket to service
6. Access granted

Key Components

Kerberos Versions and Ports

• Kerberos v5 (RFC 4120): Current standard, backward compatible with v4
• Uses port 88 for authentication traffic (both TCP and UDP)
• Realm: Administrative domain (similar to DNS domain, typically UPPERCASE)
• Default ticket lifetime: 8-10 hours (configurable)
• Maximum renewable lifetime: 7 days (default)

Security Features

• Mutual Authentication: Both client and server verify each other’s identity
• Time Synchronization Required: All systems must be within 5 minutes of each other (prevents replay attacks)
• Encryption: All tickets encrypted using symmetric keys (AES-256 recommended)
• Single Sign-On (SSO): One authentication provides access to multiple services
• No passwords transmitted over network after initial authentication

Network Implementation Considerations

• DNS Dependency: Requires proper DNS resolution for realm discovery
• Firewall Requirements: Must allow port 88 traffic to domain controllers
• Time Synchronization: Critical - use NTP to maintain clock accuracy
• Cross-Realm Trust: Enables authentication across different Kerberos realms
• Works with LDAP integration for directory services (port 389/636)

Vocabulary

• Realm: Kerberos administrative domain (e.g., COMPANY.COM)
• Principal: Unique identity in Kerberos (user@REALM or service/hostname@REALM)
• KDC: Key Distribution Center - central authentication server
• TGT: Ticket Granting Ticket - proves user identity to request service tickets
• SPN: Service Principal Name - identifies specific service instance
• Keytab: File containing service account credentials for automated authentication

Notes

• Time synchronization is critical - even small clock differences will cause authentication failures
• Kerberos is vulnerable to offline password attacks if weak passwords are used (attackers can crack captured tickets)
• Pre-authentication (enabled by default) prevents dictionary attacks by requiring password proof before TGT issuance
• For network troubleshooting: Check DNS resolution, time sync, and firewall rules for port 88 first
• Golden Ticket attack: If KDC’s secret key is compromised, attackers can forge any ticket - requires immediate domain controller rebuild
• Works best in trusted network environments - not ideal for internet-facing applications (use SAML/OAuth instead)
• Delegation allows services to authenticate to other services on behalf of users (useful for multi-tier applications)