Needham-Schroeder Protocol

Authentication & Key Establishment

CS 470
Introduction to Applied Cryptography
Instructor: Ali Aydin Selcuk

CS470, A.Selcuk Needham-Schroeder 1

 Key Establishment and Authentication
with KDC
A simple protocol:

Alice, Bob
KB{Alice, KAB}
KA{Bob, KAB} KDC

b
Bo
Alic
e

Problem: Potential delayed key delivery to Bob.

(besides others)

CS470, A.Selcuk Needham-Schroeder 2

Another simple protocol:

Alice, Bob

KA{Bob, KAB}, ticketB KDC

where ticketB= KB{Alice, KAB}

b
Bo
Alic
e

Alice, ticketB

Problems:
• No freshness guarantee for KAB
• Alice & Bob need to authenticate

CS470, A.Selcuk Needham-Schroeder 3

 Needham-Schroeder Protocol

N1, Alice, Bob

KA{N1, Bob, KAB, ticketB} KDC

where ticketB= KB{KAB, Alice}

ticketB, KAB{N2}

b
Bo
Alic
e

KAB{N2-1, N3}

KAB{N3-1}

CS470, A.Selcuk Needham-Schroeder 4

 Needham-Schroeder Protocol

• N1: for authenticating KDC & freshness of KAB.

• Ticket is double-encrypted. (unnecessary)
• N2, N3: for key confirmation, mutual authentication
• Why are the challenges N2, N3 encrypted?
• Problem: Bob doesn’t have freshness guarantee
for KAB (i.e., can’t detect replays).

CS470, A.Selcuk Needham-Schroeder 5

Messages should be integrity protected.
Otherwise, cut-and-paste reflection attacks possible:

replay ticketB, KAB{N2}

KAB{N2-1, N3}
Trud

b
Bo
y

KAB{N3-1}

ticketB, KAB{N3}
Trud

b
Bo
KAB{N3-1, N4}
y

CS470, A.Selcuk Needham-Schroeder 6

 Expanded Needham-Schroeder Protocol
hello

KB{NB}

N1, Alice, Bob, KB{NB}

KA{N1, Bob, KAB, ticketB} KDC

where ticketB= KB{KAB, Alice, NB}

b
Bo
Alic
e

ticketB, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

CS470, A.Selcuk Needham-Schroeder 7

 Otway-Rees Protocol

NC, “Alice”, “Bob”, KA{NA, NC, “Alice”, “Bob”}

KA{NA, NC, “Alice”, “Bob”}

KB{NB, NC, “Alice”, “Bob”}
KDC
NC, KA{NA, KAB}, KB{NB, KAB}

b
Bo
Alic
e

KA{NA, KAB}

KAB{anything recognizable}

CS470, A.Selcuk Needham-Schroeder 8

 Otway-Rees Protocol

• NA, NB: Provides freshness guarantee for A & B,

as well as authentication of KDC.

• NC: Binds Alice, Bob, and the session. Also

authenticates Bob.

• Having separate NA & NC is redundant for security,

though it’s good for functional separation of nonces
and uniformity of KDC messages.

CS470, A.Selcuk Needham-Schroeder 9

 Basic Kerboros Protocol
N1, Alice, Bob

KA{N1, Bob, KAB, ticketB} KDC

where ticketB=
KB{KAB, Alice, expiration time}

b
Bo
Alic
e

ticketB, KAB{T}

KAB{T+1}

T: timestamp

CS470, A.Selcuk Needham-Schroeder 10

KERBEROS

LtCdr Samit Mehra (05IT 6018)

 Kerberos
• DEVELOPED AT MIT IN THE MID 1980s
• Kerberos is a network authentication protocol. It
is designed to provide strong authentication for
client/server applications by using secret-key
cryptography.
• Kerberos acts as an extra layer of security for
any application which utilizes Kerberos
• Contains its own database of users and
passwords
• Transparently authenticates its users to save
time from redundant password entries
• IT IS FAST AND ALLOWS REAL TIME
AUTHENTICATION
 WHY KERBEROS?
• AUTHENTICATION IS A KEY FEATURE IN A MULTI
USER ENVIRONMENT.

• SENDING USERNAMES AND PASSWORDS IN THE

CLEAR JEOPARDIZES THE SECURITY OF THE
NETWORK.

• EACH TIME A PASSWORD IS SENT IN THE CLEAR,

THERE IS A CHANCE FOR INTERCEPTION.
 Ticket Server
Granting Server
Server
Server
Server

Kerberos
Database Workstation

Authenticatio
n
Server
Kerberos Key Distribution Service
Kerberos 4 Overview
 TICKET CONTENTS

• CLIENT NAME (USER LOGIN

NAME)
• SERVER NAME
• CLIENT HOST NETWORK
ADDRESS
• SESSION KEY FOR
CLIENT/SERVER
• TICKET LIFETIME
• CREATION TIMESTAMP
 SESSION KEY

• RANDOM NUMBER THAT IS SPECIFIC TO A

SESSION.

• SESSION KEY IS USED TO SEAL CLIENT

REQUESTS TO SERVER.

• SESSION KEY CAN BE USED TO SEAL

RESPONSES (APPLICATION SPECIFIC
USAGE).
Kerberos 4 Overview
 Kerberos Realms
• a Kerberos environment consists of:
– a Kerberos server (AS + TGS)
– a number of clients, all registered with Kerberos
server
– application servers, sharing keys with Kerberos
server
• this is termed a realm
– typically a single administrative domain
• if there are multiple realms, their Kerberos
servers must share keys and trust each other
– N realms means N.(N-1)/2 secure interrealm keys
 Inter-realm
authentication
 Hierarchy/Chain of Realms

21
 Kerberos Version 5
• developed in mid 1990’s
• specified by IETF as RFC 4120
• provides improvements over v4
– efforts to make Kerberos general-purpose
• encryption algorithm: v4 was only DES, v5 provides
flexibility
• network protocol addresses: v4 was only IP addresses,
v5 provides flexibility
• ticket lifetime: v4 was max. 1280 minutes due to length
of the lifetime field, v5 supports arbitrary lifetime
• authentication forwarding: In practice a server may
access another server on behalf of a client during a
transaction. v4 does not, but v5 allows this.
 KERBEROS SUMMARY

• EVERY SERVICE REQUEST NEEDS A

TICKET.
• TICKETS COME FROM THE TGS (EXCEPT
THE TICKET FOR THE TGS!).
• WORKSTATIONS CANNOT UNDERSTAND
TICKETS, THEY ARE ENCRYPTED USING
THE SERVER KEY.
• EVERY TICKET HAS AN ASSOCIATED
SESSION KEY.
• TICKETS ARE REUSABLE.
KERBEROS SUMMARY (cont.)

• TICKETS HAVE A FINITE LIFETIME.

• AUTHENTICATORS ARE ONLY USED ONCE
(NEW CONNECTION TO A SERVER).
• AUTHENTICATORS EXPIRE FAST !
• SERVER MAINTAINS LIST OF
AUTHENTICATORS (PREVENT STOLEN
AUTHENTICATORS).
• THERE IS A LOT MORE TO KERBEROS!!!
WEAKNESSES AND SOLUTIONS

IF TGT STOLEN, CAN BE ONLY A PROBLEM

USED TO ACCESS UNTIL TICKET
NETWORK SERVICES. EXPIRES IN A FEW
HOURS.

SUBJECT TO DICTIONARY TIMESTAMPS

ATTACK. REQUIRE HACKER
TO GUESS IN 5
MINUTES.

VERY BAD IF PHYSICAL

AUTHENTICATION SERVER PROTECTION FOR
COMPROMISED. THE SERVER.