Kerberos Part 1 CNS 4650 Fall 2004 Rev. 2

The Name Greek Mythology Cerberus Gatekeeper of Hates Only allowed in dead Prevented dead from leaving Spelling different so there is no confusion

Time Share Computing One large computer Account information in one location NO encryption (dumb terminals) No shared media for communication Dedicated serial lines No need to trust (since admin owns everything)

Time Share Computing

Client/Server Shared medium (network) Nodes can be unknown Power shifted from administrators to users Trust no one, admin know only controls half

Client/Server

Project Athena May year charter of a consortium of computer vendors Notable technologies from Athena Kerberos X Windows Hesiod name service Moira distributed network administration

Basic of Kerberos Secure Single-sign-on Trusted third party Mutual authentication

What happened to version 1, 2, 3? Used internally by MIT Never released into the wild Various limitations Mostly for testing

Three A’s Authentication Authorization Auditing

Authentication Process of verifying the identity of a user. User is required to give information Factors of authentication What the user knows What the users has What the user is

Example: Drivers License Authentication is that it is issued from an authoritative source State Country Your Picture

What the User Knows Most common Secret password User defined password Random password

What the User Has Less common Some type of device RSA SecurID Randomly generates key Key matches key on authentication server Smart Cards

What the User Is Less common Biometrics Fingerprint scanning Retina scanning Voiceprint recognition Face recognition

Authorization Granting or denying access to specific resources based on identity Access Control Lists Authorization is dependent on solid authentication! NFS Server trusts client, user “authenticated” by UID Easy to spoof, ACLs are almost worthless

Example: Drivers License Authorization is what you have rights to drive Standard Commercial Motorcycle Etc.

Auditing Records authentication and authorization Reactive system (does not stop attacks, just records them ;-)

Privacy and Integrity Encryption Protect data from unwanted parties Message Integrity Ensure the message was not tampered MD5 SHA1 CRC-32

Terminology Realms, Principles, Instances Keys, Salts, Passwords Key Distribution Center Tickets

Realms, Principles, Instances Realms Administrative control unique to each Kerberos installation Convention is DNS domain in uppercase REALM.ORG EXAMPLE.COM Realm names are case sensititive

Realms, Principles, Instances Principles Every user and service has a principle Every principle has a long term key associated with it Password or passphrase Global unique name User or service name combined with realm name Three components [username].[optional (Kerberos 4) (Kerberos 5)

Realms, Principles, Instances Principles Kerberos 4 Examples Kerberos 5 Examples smb/server.differentrealm.org/REALM.ORG

Realms, Principles, Instances Instances Used in two situations Service principles Special principles for administrative purposes Example Admins can have two principles One for day to day One for administrative tasks

Keys, Salts, Passwords Keys Are shared between at least two parties End user, service, or KDC String2key converts password to encryption key Salt is added before password is hashed Kerberos 5 default “salt” is realm name

The Key Distribution Center (KDC) Three components Principle database Authentication server Ticket Granting Server

The Key Distribution Center (KDC) Principle Database Stores principles and associated keys Stores other information Password lifetimes Last password change MIT stores in lightweight database

The Key Distribution Center (KDC) Authentication Server Issues Ticket Granting Ticket (TGT) Passwords never cross wire TGT encrypted with users password TGT can then be used to request service tickets TGT provides “single-sign-on”

The Key Distribution Center (KDC)

Ticket Granting Server (TGS) Takes two pieces of data Principle name of service requested Users Ticket Granting Ticket (TGT) TGS verifies TGT, then issues a service ticket to the user

Tickets Encrypted data structure Requesting principle name Service principle name Ticket lifetime IP Addresses the ticket can be used from Session key (shared secret) for user/service communication

Tickets Service Tickets User requests from TGS Session Key for communication Data encrypted with service key, which contains the Session key All is encrypted with user key

Tickets