Mediated Authentication with KDC, and

Kerberos

• Readings

– Sections 11.4, 13.1 – 13.11

1

Distributing Authentication Keys

• Secret keys

– In a large network, it is infeasible to assume that each pair

of nodes share a secret key.

– Idea: Use a central server to distribute keys, the Key

Distribution Center (KDC).

• Analogy: In a LAN, often the password database is

stored in a single server

• Public/private keys

– Certificate authorities (CA)

2

Using a KDC

• Entity A contacts the KDC and uses KA (shared key with KDC) to authenticate herself and request a key for use with entity B.

• KDC generates a session key KAB for use between A and B.

• KDC then:– encrypts the session key and sends it securely to A (using KA).

– encrypts the session key with KDC’s shared key KB with Bob, and sends it securely to B directly or more simply to A to give to B.

• A decrypts the session key and contacts B, giving him the encryption of the session key computed by the KDC if not sent directly to B.

• Some potential pitfalls– KDC may impersonate users, so it must be entirely and completely

trusted.

– KDC is a performance bottleneck as well as a single point of failure.

3

Basic KDC Sequence without mutual

authentication between Alice and Bob

4

Alic

e

KD

C

IDA ,may I talk to Bob?

KA{KAB, KB{KAB, IDA}}

Bo

b

Hello Bob, this is Alice: KB{KAB, IDA}

KDC could alternatively send shared

session key to Bob directly

Multiple KDCs

5

Alic

e

Alic

e’s

ho

me

KD

C1

May I talk to KDC2?

KA{KA2}, K12 {KA2} B

ob

’s h

om

e K

DC

2

May I talk to Bob? K12 {KA2}

KA2{KAB}, KB {KAB} Bo

b

Hello Bob: KB {KAB}

A Global KDC infrastructure

• If each organization wishes to set up a KDC, it

becomes infeasible for each to have a key shared

with all the others

• KDCs need to authenticate other KDCs

– Hierarchical infrastructure, with root KDC

– Trust graphs, with varying trust levels

• KDC1 does NOT trust KDC2

• KDC1 trusts KDC2 to authenticate KDC2 users

• KDC1 trusts KDC2 to authenticate any users

• KDC1 trusts KDC2 to introduce trusted KDCs

6

Needham and Schroeder Protocol

• Published in 1978

– Seminal paper on cryptographic protocols

• Identified several "canonical" protocols including for

authentication

• Accidentally illustrated the first canonical protocol flaw

found

– The flaw was found two years later

– The flaw reflects a very unlikely attack

– Nonetheless, it illustrates how hard it is to produce reliable

cryptographic protocols.

7

Needham-Schroeder Secret Key Protocol

8

Alic

e

S =

KD

CKas{na, B, Kab, Kbs{Kab,A}}

Bo

b

Kbs{Kab, A}, Kab{n2}

(A, B, na)

Kab{nb-1}

Kab{n2-1, nb}

Note: a ticket is in red

Needham-Schroeder Secret Key Protocol

9

A =>S: (A,B,na)

S =>A: Kas{na, B, Kab, Kbs{Kab,A}}

A =>B: Kbs{Kab, A}, Kab{n2}

B =>A: Kab{n2-1, nb}

A =>B: Kab{nb-1}

Attack on Needham-Schroeder Protocol (Replay)

10

• Vulnerability: old (session) keys are still valuable

Initial session

A =>S: (A,B,na)

S =>A: Kas{ na, B, Kab , Kbs{Kab, A} }

A =>B: Kbs{Kab, A}, Kab{n2}

-- This message establishes the session key

B =>A: Kab{n2-1, nb}

A =>B: Kab{nb-1}

• The malicious intruder can

– captures the key interchange messages and the ensuing session.

– compromises (obtains) old key Kab ,

– initiates a new session with Bob.

Attack on Needham-Schroeder Protocol

11

Initial session

A =>S: (A,B,na)

S =>A: Kas{ na, B, Kab, Kbs{Kab,A} }

A =>B: Kbs{Kab, A}, Kab{n2}

B =>A: Kab{nb}

A =>B: Kab{nb-1}

B =>A: Kab{nb'} [intercepted by T]

T =>B: Kab{nb'-1}

T =>B: Kbs{Kab, A}

Replay session: (Trudy knows Kab)

Result of the Attack and Corrections

• Bob believes that he is in a secure session with Alice, but he is actually in a secure session with Trudy, i.e. Trudy has masqueraded as Alice.

• Corrections– Forcing initiator to talk to KDC first (expanded Needham-

Schroeder protocol)

– Use of a timestamp (in Kerberos)

12

Expanded Needham-Schroeder Protocol

13

Alic

e

S =

KD

CKas{na, B, Kab, Kbs{Kab,A, N1}} Bo

b

Kbs{Kab, A, N1}, Kab{n2}

(A, B, na), Kbs{N1}

Kab{nb-1}

Kab{n2-1, nb}

I want to talk to you

Kbs{N1}

Kerberos

• Trusted 3rd party authentication service

• Designed at MIT in the 1980’s

• Secret key based service providing authentication and

access control policy

• Versions 4 & 5 in use

• Based on the work by Needham and Schroeder

• Widely used

• stateless

14

KERBEROS: the name

Kerberos (demon of the pit):

Monstrous three-headed dog (sometimes said to have

fifty or one-hundred heads), (sometimes) with a

snake for a tail and innumerable snake heads on his

back.

Kerberos guarded the gate to Hades (the Greek

underworld) and ensured that the dead could not

leave and the living could not enter.

The Roman name is Cerberus

15

Kerberos Components

• Key Distribution Center (KDC)– Runs on a physically secure node

– Authenticates clients of the authentication service – called principals

– Provides session keys for principals wanting to use a network service such as a file service

• Clients and Servers– A client can be a program or a person

– A server, typically a program, provides an abstract service

– Principals are clients of authentication service – each principal is assigned a secret key (symmetric key encryption system)

• Users– Human being using a service

– Has a password that is turned into a secret key through a one way function

16

Kerberos (V4)

• Trusted Server – KDC– Shares a master key with each principal– KDC implements both an Authentication Server (AS)

and a Ticket Granting Server (TGS)

• Ticket – issued to one entity (a client) to be used to securely pass information to another entity (a server) encrypted in the master key of the server.

• Authenticator - information to prove that a client presenting a ticket is actually the one to whom the ticket was issued. – Authenticator is often the session key encrypted

information that can be compared against information in the ticket

• Authenticators and tickets are both credentials

17

The KDC

• AS (authentication server):

– Authenticates users based on their master keys, hands off

session keys for secondary authentication: ticket-granting

tickets (TGT).

• TGS (ticket granting server):

– Performs secondary authentication based on the TGT keys,

hands off tickets for principals to communicate with

kerberized network services.

18

KDC Configuration

• The KDC database is kept encrypted under KDC’s

own master key.

• Users have passwords, their master key is derived

from them

• Kerberized network servers need to store their

master key somehow.

• All master keys are stored in the KDC database

(except KDC’s own.)

19

First Step: Get a TGT

20

�Alice

Work

statio

n

KD

C

Alice,

password [AS_REQ]

Alice needs TGT

[AS_REP]:

KA{SA,TGT}

Create SA ,

Compute TGT=

KKDC{Alice,SA}

Derive KA,

Recover TGT,

SA

Getting a Service Ticket

21

�Alice

Work

statio

n

KD

Crlogin Bob

[TGS_REQ]:

Talk to Bob,

TGT, auth

[TGS_REP]:

SA{Bob,KAB,T}

SA from TGT,

Decrypt auth,

check t-stamp,

Create KAB, T =

KB{Alice, KAB}

use SA to

Decrypt

KAB, T

auth =

SA{timestamp}

Contents of a Ticket

• Alice's name

• Alice's instance

• Alice's realm

• Alice’s network layer address

• Session key (Alice –Bob)

• Ticket lifetime – units of 5 minutes

• Timestamp - when ticket made by KDC

• Bob's name

• Bob's instance

• Padding – ticket length multiples of 8 octets

22

Using the Ticket

23

�Alice

’s work

statio

n

�Bob

[AP_REQ]:

T = KB{Alice,KAB},

auth’ = KAB{timestamp}

[AP_REP]

KAB{timestamp+1}

Replicating KDCs

• To alleviate bottlenecks, replicate KDC:

– One KDC is master database, to add or remove users, and

change passwords

– Other KDCs use database as read-only

• A master KDC establishes a realm. Inter-realm

authentication supported:

– KDC1 registers KDC2 as a principal

– KDC1 enables other principals to access KDC2 as a

kerberized service.

24

Realms

25

KDC 2

KDC 1

Realm 1

Realm 2

Realm Rules

Inter-Realm Authentication: 1

26

�Alice

@W

onderla

nd

Work

statio

n

KD

C

Dorothy@Oz

[TGS_REQ]:

(for O = Oz’s KDC)

TGT, auth

[TGS_REP]:

SA{O,KAO,T}

SA from TGT,

Decrypt auth,

check t-stamp,

Create SAO, TO =

KO{Alice, SAO}use SA to

Decrypt

SAO, T

auth =

SA{timestamp}

Inter-Realm Authentication: 2

27W

ork

statio

n

Oz’s K

DC

[TGS_REQ]:

TO, auth’, Dorothy

[TGS_REP]:

SAO{Dorothy,KAD,T}

SAO from TO,

Decrypt auth’,

check t-stamp,

Create KAD, T =

KD{Alice, KAD}use SAO to

Decrypt

KAD, T

auth’ =

SAO{timestamp}

Encryption for both Privacy and Integrity

• Plaintext Cipher Block Chaining (PCBC)

– Also called propagating Cipher Block Chaining

• In Kerberos (V4), some recognizable data added at

end of message

28

PCBC Decryption

• Modification in a block cipher i will affect all plaintext

blocks starting from block i to the end

29

Kerberos V5

• More resistant to determined attacks over the

network

• More flexible

– Support for forwardable, renewable, and postdatable tickets.

– Kerberos tickets can now contain multiple IP addresses and

addresses for different types of networking protocols.

– Other encryption algorithms beside DES can be used.

– Support for replay caches, so authenticators are not

vulnerable to replay.

– Support for transitive cross-realm authentication.

30

Kerberos Operations Review

Get a TGT (initially done)

Get a ticket / session key to B

Start a session to B

Get a ticket /session to Sremote

Get a ticket /session to Bremote

Start an inter-realm session to

Bremote

A => S: AS_REQ

S => A: AS_REP

A => S: TGS_REQ

S => A: TGS_REP

A => B: AP_REQ

B => A: AP_REP

A => Slocal: TGS_REQ

Slocal => A: TGS_REP

A => Sremote: TGS_REQ

Sremote => A: TGS_REP

A => Bremote: AP_REQ

Bremote => A: AP_REP 31

Reading Assignment

• Chapter 15

32