Kerberos Authentication Systems

Winter 2006 Prof. R. Aviv: Kerberos 1

Kerberos

Authentication Systems


KERBEROS

In Greek mythology, a many headed dog, the guardian of the entrance of Hades (Hell)


Outline

• Authentication in Campus

• Kerberos 4

• Realms (Domains) under Kerberos 4

• Appendix: Kerberos 5


Authentication in Campus

• Workstations, Servers are distributed

• Users/Clients: anyone, log in at any Wstn

• Servers software: examples?

– need to authenticate and authorize users

Can we trust Workstation software to

authenticate users on behalf of servers

What are the threats?


Authentication in Campus

• Threats: actions enabling unauthorized users to gain access to services and data

– User pretend to be another user.

– User alter the network address of a workstation.

– User listens to exchanges and use a replay attack.

How Users and Servers authenticate each other?


Approaches to Authentication

• Need Mutual Authentication

– Workstation cannot hold policy for all servers,

all computers, all users (“principals”)

– Use a trusted Authentication Server -

KERBEROS Server

• Kerberos Server holds policy – which users can

access which servers, and keys for all principals

Should we use Symmetric or A-symmetric keys


KERBEROS

• Centralized Authentication Server

– authenticating users to servers and v,v

– Relies on conventional encryption

– no use of public-key encryption – unlike PKI

– Long term shared secrets between Kerberos

and Servers and Users (not with client wstn)

What are the requirements from the

Kerberos Protocol?


Kerberos Protocol Requirements

• Partners are authenticated continuously

– Partners: Client, K Servers, Server

• Messages encrypted by secret short lived keys

• Little user involvement


Kerberos Protocol: 3 phases

ServerServerServerServerServerServerServerServer

ServerServerServerServer

KerberosKerberosDatabaseDatabase

ServerServerServerServer

KerberosKerberosDatabaseDatabase

Ticket GrantingTicket Granting ServerServer

Ticket GrantingTicket Granting ServerServer

AuthenticationAuthentication ServerServer

AuthenticationAuthentication ServerServer

WorkstationWorkstationWorkstationWorkstation

1

. Authenticati

oo

2. Authorization 3. Start service


Kerberos Version 4: Notation

• C = Kerberos Client module (on the workstation)• AS = Kerberos Authentication Server• TGS = Ticket Granting Server• tgt= Ticket Granting Ticket• V = server (e.g. mail server, ftp server, print server)• IDU = identifier of user on C (e.g. name, email address)• IDv = identifier of server V (e.g. Server IP address+port)

• PU = password of user; this is known to AS

• ADc = net (IP) address of Client (user’s workstation)

• Kv = secret encryption key shared by TGS and V

• TS = timestamp


Basic Kerberos Protocol

• 1.K Client sends (User ID: IDU) and PU ?

• 2. PU is known to AS. AS sends a packet with a tgt

encrypted (DES); key derived from PU

• Kerberos Client requests password from user

• K Client decrypts packet, finding User’s ID and

its own address (ADc) inside

– ensuring password is PU ;user authenticated

What will be the usage of tgt ?


Basic Kerberos Protocol

• tgt: User authenticated, allowed to get ticket

• 3. K client sends tgt to the Ticket Granting

Server, (TGS) is it now encrypted?

• 4. K. client receives a Service Ticket, ticketv

• 5. ticketv (client credentials) sent to server V

• ticketv encrypted by secret known to V and TGS

• tgt, ticketv have some lifetime


Authenticating Phase: Once per logon

• tgt is ”sealed” cannot be read by anyone but TGS (not even by User or Client); Why?

• Could the ticket sent directly to TGS?• Timestamp - against replay

(1) C AS: IDU || IDtgs

(2) AS C: EKc [tgt] what can an attacker do?

tgt = EKtgs[IDU || ADc || IDtgs ||TS1 || Lifetime1]

What’s the meaning of the tgt


Client request and get ticketv: Once per service

• IDU appears twice (also in tgt)

• ADc appears twice (in IP header, and tgt)

Why? Problem?

(3)C TGS: IDV ||tgt ||IDU

can attacker forge IDU?

can attacker impersonate the User?

(4) TGS C: ticketv

ticketv = EKv[IDU || ADc || IDv ||TS2 || Lifetime2]


Client getting Service: Once per service session

• Server V sees its own ID --> ticketv is genuine

• V compares client address in IP header & ticketv

• V compares user ID in packet and ticketv

Problem?

(5) C V: ticketV || IDU

ticketV = EKv[IDU|| ADC || IDV ||TS2 || Lifetime2]


The Lifetime of tgt

• If too short user will repeatedly enter password.

• If too long, an attacker might reuse message 3 (with forged IDU, ADc) before tgt expires

• Hence: Client needs to authenticate itself to TGS in its message 3

– Client adds secret authenticator to message 3

• For this Client and TGS Need a shared secret

How would they get it?

• AS to send a shared secret to both in message 2


New Message 2: AS sends to client a tgt, AND a shared

TGS-session key to be used in message 3

TGS session keyTGS session key

tgttgt::login name (IDlogin name (IDUU))TGS nameTGS namenet address (ADnet address (ADcc))TGS session keyTGS session key

Encrypted with user key Encrypted with TGS key

Who knows the session key?


New Message 3: Client authenticated by TGS, requests ticket

• 3 parts message

• tgt (previously obtained from AS), Encrypted by key known only to TGS (and AS)

• authenticator: encrypted with TGS session key

• Server (V) ID

tgttgt

authenticatorauthenticator

Server V NameServer V Name

encrypted withencrypted withTGS keyTGS key

encrypted withencrypted withTGS session keyTGS session key


The Lifetime of ticketv

• If lifetime is long, opponent might use it

– Client needs to authenticate to V in message 5

• Solution: AS gives in message 4 to both V and the

K client a one time, shared session key, Kc,v

– Client attach authenticator to its message 5


New Message 4: TGS sends to client a ticketv AND a shared

V session key to be used in message 5

V session keyV session key

ticketticketvv::login name IDlogin name IDUU

V nameV namenet address ADnet address ADcc

V session keyV session key

Encrypted with user keyEncrypted with V key


• 3 parts message

• ticketv (previously obtained from TGS),

Encrypted by key known only to V

• authenticator: encrypted with V session key

• Server (V) ID

New Message 5: Client authenticated by V, requests service

ticketticketvv

authenticatorauthenticator

Server NameServer Name

sealed with withV keyV key

sealed withV session key


Phase 1: User gets ticket granting ticket, authenticate itself to Client

• Authentication Service Exchange:

1. C AS: IDU || IDtgs ||TS1

2. AS C: EKc [Kc,tgs|| IDtgs || TS2 ||

Lifetime2 || tgt]

Shared Session key


Phase 2: User authenticated to TGS, gets ticketv

• Authenticator: Info about the Client (User name,

IP Address, Timestamp) encrypted with shared s

ecret. Expires immediately

• 3. C TGS: IDv || tgt || authenticatorc

• 4. TGS C: EKc [Kc,v|| IDv || TS4 || ticketv]

• tgt = EKtgs[Kc,tgs || IDU|| ADC || IDtgs || TS2 || Lifetime2]

• ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4]

• authenticatorc = EKc,tgs[IDU || ADc || TS3]


Phase 3: Starting Service

• 6. Server Authenticates itself to Client:

– Server reply: TS5+1, encrypted by the shared

session key (Kc,v)

5. C V: ticketv || authenticatorc

6. V C: EKc,v[TS5 +1]

ticketv = EKv[Kc,v || IDU || ADC || IDV || TS4 || Lifetime4]

authenticatorc = EKc,v[IDU || ADC || TS3]


Summary of Kerberos 4 Protocol


Realm (Domain)

• A complete system is one Realm

• Realm under a single administration

– AS, TGS, Clients, service Servers

• The TGS must share a secret key with each

Server in the Realm

– All Servers in a Realm register with the TGS


Inter-operating Realms

• Users in one realm might need access to Servers

in another, interoperating realm

• TGS in realms register with all other AS

• AS in a realm trust other AS to authenticate its

users

• Servers in one realm trust TGS of the other

realm


User access Server RV in a remote Realm

Client applies to local AS for a Tickettgs for local

TGS

• 1. CAS: IDU || IDtgs || TS1

• 2. AS C:

EKc[Kc,tgs || IDtgs || TS2 ||LT2||tgt]



Client applies to local TGS for a tgtr for (remote)

R-TGS

• 3. C TGS:

IDR-TGS || tgt || authenticatorc

• 4. TGS C:

EKc,tgs[Kc,r-tgs || IDR-TGS || TS4 || tgtr]



Client applies to RTGS for a ticketrv for RV Server

• 5. C R-TGS: IDRV || tgtr || authenticatorc

• 6. R-TGSC: EKc,rtgs[Kc,rv || IDrv || TS6 ||

ticketrv]

Client connect to remote server

• 7. C --> RV: ticketrv || authenticatorc



Appendix

Kerberos Version 5


Kerberos Version 5: increased flexibility

• V4: Encryption system dependence (DES)

• Internet protocol dependence (IP addresses)

– Flexible protocols, addresses (using tags)

• V4: various Message byte ordering

– V5: standard (ASN.1)

• V4: Ticket lifetime limited field

– V5: arbitrary start/end times


Kerberos V: Delegation of Rights

• Client1 requests forwardble tgt with client2 addr.

– Client1 sent tgt to client2

– Client 2 requests a tgt, as if it is client1

– Client2 requests tickets to resources of client1

– E.g. print server request access to network file

• Client1 requests proxiable tgt with client2 addr.

– Client1 requests tickets on behalf of client2

– Client1 send tickets to client2


Kerberos V: Key in authenticator

• V4: same session key can be used in two parallel

sessions between client and server

– attacker may replay/mix message of sessions

• V5: client suggests in the authenticator a sub-

session key

– Server decrypts authenticator with old key,

but from there on will use new key


The forgetful Server: X Windows

• User on workstation, with local X Server that

draws on the screen

• Remote application (client) commands X server

• Remote & workst’n need mutual authentication:

• both get tgt, then will get ticket with session key

– But User password deleted from workstation

– workstation can’t decrypt packet with new tgt

– can’t get ticket with new session keys


Double TGT authentication

• Workstation has new tgt, & previous session key

– But no password to decrypt tgt packet

• Remote computer requests the new tgt packet

from workstation, sends both tgts to the TGS

• TGS decrypts tgts, by the known passwords

– Verify that 2 parties got authenticated before

– re-issues the tgt packet to the workstation, this

time encrypted with its old session key

• Workstation decrypts, gets ticket with session key


Kerberos V5: Evading dictionary attacks

• V4: Actual authentication by client after receiving tgt (encrypted by user password)

– Attacker gets tgt, tries all dictionary passwords

• V5: request for tgt accompanied by preauthentication-data

– Data: time stamp encrypted by user password

• V4: Attacker request ticket for a real user

– as if it is a server

– Then guessing password of that user

• V5: not allowing tickets for real user


Version 5: Authentication Service exchange

Client request tgt. It includes realm of user,

optional flags, from/till/renew times, nonce:

1. C --> AS: Options||IDc||Realmc||IDtgs||Times||

Nonce1

AS sends tgt & block encrypted by function of

password:

2. AS > C: Realmc ||IDc|| tgt ||

EKc[Kc,tgs||Times||Nonce1||

Realmtgs||IDtgs||]


Version 5: Authentication Service exchange

Block: session key, same nonce, realm of TGS &

ID

Nonce (encrypted) guarantees no replay

Client info also in the clear

tgt = EKtgs[Flags||Kc,tgs||Realmc||IDc||ADc|| Times]

Flags: status of ticket and options


Version5: Getting Service Ticket phase

• Client requests from TGS a ticketv

– 3. C TGS: Options||IDv||Times||Nonce2||tgt||

MACc

– 4. TGS C: Realmc||IDc||ticketv||

EKc,tgs [Kc,v||Times||Nonce2|| Realmv ||IDv]

– Session key is carried in both ticket and block

– Realm v is provided to C

– block encrypted by the session key EKc,tgs


Version5: Getting Service Ticket phase

• Tickettgs = EKtgs[Flags||Kc,tgs||Realmc||IDc||ADc||

Times]

• ticketv = EKv[Flags||Kc,v||Realmc||IDc||ADc||

Times]

• MACc = EKc,tgs[IDc|| Realmc ||TS1]


Version 5: starting Service phase

• 5. CV: Options||ticketv||MACc

• 6. VC: EKc,v[TS2||Subkey||Seq#]

– One-session sub-key may be created by client, carried to server in MAC

– Similarly for sequence number that will be used by server

• ticketv = EKv[Flags||Kc,v||Realmc||IDc||ADc|| Times]

• MACc = EKc,v[IDc|| Realmc ||TS2||Subkey||Seq#]


Summary

• Authentication in Campus provided by a central

authority

• Authentication is integrated with Authorization

• Authentication is provided by reusable series of

tickets

• Protocol exchanges are protected by

authenticators using one time session keys

• System provides for delegation of authentication

Documents

Kerberos Authentication Systems