James Johnson

What is it?

A system of authenticating securely over open networks

Developed by MIT in 1983 Based on Needham-Schroeder

Extended to fix vulnerabilities in Needham-Schroeder

Currently widely used in industryActiveDirectory

Why do I care?

Managing users across a huge network of computers is a painIndividual users configured on each

computer? LOL

Much easier to have a single authentication source

Kerberos provides this single source of authentication

How Does It Work?

Clients authenticated using username and password

Single sign on User authenticates username-password

once per session From then on, permissions granted

using cryptographic “tickets”

Cast of Characters

Principal (you) Ticket Granting Service (TGS) Key Distribution Center (KDC)

TGS and KDC separate entities on same host

Service Server (SS)

Kerberos Authentication

Messages (User Auth)

User -> Client: User, PassKeyuser = Hash(Password)

Client -> AS: User ID AS->Client

Session key: {Sess}Keyuser

TGT: {Client ID, Client addr, validity period, Sess}Keyserver

Messages (Service Auth)

Client -> TGS{Client ID, Client addr, validity period,

Sess}Keyserver , RequestedServiceID

Authenticator: {Client ID, Timestamp}Sess

TGS -> ClientClient-Server Ticket: {ClientID,Client addr,

validitiy period, SessionClient-Server}Keyservice

{SessionClient-Server}Sess

Messages (Service Request) Client->Service

Client-Server TicketAuthenticator: {Client ID,TimestampA}

SessionClient-Server

Service->Client{TimestampA+1} SessionClient-Server

Domains/Realms

Kerberos designed to work across organizational boundaries

Each TGS constitutes a realm Organizations can share “inter-realm

keys” Local AS issues TGT for remote TGS

Encrypted with inter-realm key“Referral Ticket”

Transitive Domain Referral

Hierarchical Domains/Realms Each realm shares a key with parent Different key for each child If no shared key between two realms,

authentication path can be constructed

Typical Implementations

MIT Heimdal

Adds some functionality

Java Microsoft Active Directory

Kerberos + LDAP + RPCDoes not use MIT software

Security/Implementation Concerns Synchronize clocks

NTP server

DO NOT USE KERBEROS 4 Single point of failure

Harden servers

Consider redundancy of KDCsOne primary master, many secondary

slavesNo automatic failover

Kerberos + OpenLDAP

Kerberos can use LDAP backend instead of DB file

Eases DB replication and user management

Easy to do – Ubuntu packages, howtos

Cross-Platform Integration UNIX-only Kerberos networks are fairly

straightforwardAll use MIT software

Windows screws everything up Tools for integrating Linux/BSD into AD

SAMBALikewise OpenAspirin

SAMBA cannot act as a AD domain controller

Conclusions

Kerberos greatly eases user management in Enterprise

Allows for fine-grained control Inter-platform operation can be taxing

Resources

http://technet.microsoft.com/en-us/library/bb742516.aspx

http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html#overview

http://tools.ietf.org/html/rfc4120 http://www.kerberos.org/events/

2010conf/2010slides/2010kerberos_panel2.pdf