Kerberos Authentication Systems

Winter 2006 Prof. R. Aviv: Kerberos 1

KerberosAuthentication 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


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?


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


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 between Kerberos Server and others

encrypted by secret short lived keys

• Little user involvement


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


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


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 ?


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

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


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: 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


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


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


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

ticketticketvv

authenticatorauthenticator

Server NameServer Name

sealed with withV keyV key

sealed withV session key


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


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]


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]


Summary of Kerberos 4 Protocol


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


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


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]


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]


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


Documents

Kerberos Authentication Systems