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.
