Kerberos Authentication Systems

Winter 2006 Prof. R. Aviv: Kerberos 1

KerberosAuthentication Systems

Winter 2006 Prof. R. Aviv: Kerberos 2

KERBEROS

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

Winter 2006 Prof. R. Aviv: Kerberos 3

Outline

• Authentication in Campus

• Kerberos 4

• Realms (Domains) under Kerberos 4

Winter 2006 Prof. R. Aviv: Kerberos 4

Authentication in Campus

• Workstations, Servers are distributed

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

• Servers software:

– need to authenticate and authorize usersCan we trust Workstation software to authenticate users on behalf of servers

What are the threats?

Winter 2006 Prof. R. Aviv: Kerberos 5

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?

Winter 2006 Prof. R. Aviv: Kerberos 6

Approaches to Authentication

• Need Mutual Authentication– Workstation cannot hold policy for all servers

all users why not?– 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

Winter 2006 Prof. R. Aviv: Kerberos 7

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?

Winter 2006 Prof. R. Aviv: Kerberos 8

Kerberos Protocol Requirements

• Partners are authenticated continuously

– Partners: Client, K Servers, Server

• Messages between Kerberos Server and others

encrypted by secret short lived keys

• Little user involvement

Winter 2006 Prof. R. Aviv: Kerberos 9

Kerberos Protocol: 3 phases

ServerServerServerServerServerServer

KerberosKerberosDatabaseDatabase

Print ServerPrint Server

KerberosKerberosDatabaseDatabase

Ticket GrantingTicket Granting Server (TGS)Server (TGS)

AuthenticationAuthentication Server (AS)Server (AS)

Workstation:Workstation:K ClientK Client

1. Authenticati

oo

2. Authorization 3. Start service

Assume user wants to print

Winter 2006 Prof. R. Aviv: Kerberos 10

Kerberos Version 4: Items/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, known to AS• ADc = network address of Client (user’s workstation)• Kv = secret encryption key shared by TGS and V• TS = timestamp

Winter 2006 Prof. R. Aviv: Kerberos 11

Basic Kerberos Protocol

• 1.K Client sends (User ID: IDU) and PU ?• 2. PU is known to AS. AS sends back a packet

with 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, in correct format

– ensuring user knows PU; user authenticated

What will be the usage of tgt ?

Winter 2006 Prof. R. Aviv: Kerberos 12

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

Winter 2006 Prof. R. Aviv: Kerberos 13

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|| IDU]

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

What’s the meaning of the tgt

Winter 2006 Prof. R. Aviv: Kerberos 14

Client request and get ticketv: Once per service

• IDU appears twice where?• ADc appears twice where

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]

Winter 2006 Prof. R. Aviv: Kerberos 15

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]

Winter 2006 Prof. R. Aviv: Kerberos 16

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: TGS must authenticate Client again

– 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

Winter 2006 Prof. R. Aviv: Kerberos 17

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?

Winter 2006 Prof. R. Aviv: Kerberos 18

New Message 3: Client authenticates itself to 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

Winter 2006 Prof. R. Aviv: Kerberos 19

The Lifetime of ticketv

• If lifetime is long, attacker might reuse it How?

• V must authenticate the Client again

• 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

Winter 2006 Prof. R. Aviv: Kerberos 20

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

Winter 2006 Prof. R. Aviv: Kerberos 21

• 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 authenticates itself to V, requests service

ticketticketvv

authenticatorauthenticator

Server NameServer Name

sealed with withV keyV key

sealed withV session key

Winter 2006 Prof. R. Aviv: Kerberos 22

Phase 1: User gets ticket granting ticket, and Client Authenticates the User

• Authentication Service Exchange:

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

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

Shared Session key

Winter 2006 Prof. R. Aviv: Kerberos 23

Phase 2: TGS authenticates User, User gets ticketv

• Authenticator: Info about the Client (User name, IP Address, Timestamp) encrypted with shared secret. 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]

Winter 2006 Prof. R. Aviv: Kerberos 24

Phase 3: V Server, User authenticate each other, User gets service

• 6. Client Authenticate the Server:

– 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]

Winter 2006 Prof. R. Aviv: Kerberos 25

Summary of Kerberos 4 Protocol

Winter 2006 Prof. R. Aviv: Kerberos 26

Realm (Domain)

• Organization is organized in Realms (Domains)

• A Realm (e.g. faculty) under a single admin

– Includes: AS, TGS, Clients, service Servers

• The TGS must share a secret key with each

Server in its Realm

– All Servers in a Realm register with the TGS

Winter 2006 Prof. R. Aviv: Kerberos 27

Inter-operating Realms

• Users in one realm might need access to Servers in another, interoperating realm example?

• 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

Winter 2006 Prof. R. Aviv: Kerberos 28

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]

Winter 2006 Prof. R. Aviv: Kerberos 29

User access Server RV in a remote Realm

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]

Winter 2006 Prof. R. Aviv: Kerberos 30

User access Server RV in a remote RealmClient 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

Winter 2006 Prof. R. Aviv: Kerberos 31