Kerberos-V4: An Authentication Service for Open Network Systems

Kerberos is third party authentication service

	Network services and clients which want to use them should register to kerberos
	Both client and service (= servers) trust its partie's identity given by kerberos

Private key encryption, DES, is used

Three different level of protections are provided

	Authentication only at connection establishment. Further messages are believed to come from the authenticated party if ip-addr is correct
	Safe message - authentication for every message, but no secrecy nor integrity
	Private message - every message is not only authenticated but also encrypted

Servers and clients are named same way in kerberos

Format: primary-name.instance@realm

	primary-name: name of the user or service ftp, root, sschang, http, etc
	instance: name of spercific instance ftp.dewey, rlogin.nova23
	realm: domain name

General

	Ticket [server, client, IP-addr of client, timestamp, life, session_key]server
	Authenticator [client, IP-addr of client, timestamp]session_key
	Authentication server has all user's private keys plus TGS's key
	TGS has all server's private keys

Procedure

	User gets a credential--ticket for ticket generating service User enters login name Client -> Authentication server: Ticket for ticket generating service [sschang, TGS.raven@cs] Authentication server -> Client: requested ticket [TGS_session_key, TGS-ticket]sschang User enters password -> Private key for sschang is generated using the password The message received above is decrypted by sschang's private key session_key is saved -- password & private key are thrown away
	User gets ticket for a specific service Client -> TGS: service request for a service, say, ssh [ssh.nova23@cs , TGS-authenticator, TGS-ticket] TGS -> Client: ticket granted [ssh_session_key, ssh-ticket]TGS_session_key
	User presents those credentials to the server Client -> Server: ticket submit -- client authentication [ssh-authenticator, ssh-ticket] Server -> Client: server authentication [timestamp + 1]ssh_session_key
	When ticket expires, user must run kinit program to get a new ticket for TGS Note that the user's password must be reentered

Two authenticator share a key for both TGSs

Client requests a TGS ticket for the other realm

Local authenticator gives a ticket encrypted by the shared key

Client gets tickets from the remote TGS

How long should lifetime of tickets be?

	Long - stolen session_key and tickets will be used for a long time
	Short - so often password reentry

Authentication forwarding

Can you truest the workstation which stashes session_key and tickets and software on the machine?

Smartcard!