CMSC 414
Computer and Network Security
Lecture 24
Jonathan Katz
Mediated authentication
(using a KDC)
Needham-Schroeder
 AKDC: N1, Alice, Bob
 KDCA: EncKB{N1, “Bob”, KAB, ticket}, where
ticket = EncKB{KAB, “Alice”}
 AB: ticket, EncKAB{N2}
 BA: EncKAB{N2-1, N3}
 AB: EncKAB{N3-1}
Analysis?
 N1 assures Alice that she is talking to KDC
– Prevents key-replay; helps prevent attack when Bob’s
key is compromised and then changed
 “Bob” authenticated in message 2, and “Alice” in ticket
 Uses encryption to authenticate… 
– Leads to reflection attack on Bob if, e.g., ECB mode is
used in round 4
 Vulnerable if Alice’s key (even an old one) compromised
– A ticket is eternally valid
– Fix using timestamps, or by Alice requesting a nonce
from Bob at the very beginning of the protocol
Otway-Rees
 Addresses the ticket invalidation problem, in
fewer rounds
Otway-Rees
 AB: N, “Alice”, EncKA{NA, N, “Alice”, “Bob”}
 BKDC: EncKA{NA, N, “Alice”, “Bob”},
EncKB{NB, N, “Alice”, “Bob”}
 KDCB: N, EncKA{NA, KAB}, EncKB{NB, KAB}
 BA: EncKA{NA, KAB}
 AB: EncKAB(timestamp)
Analysis?
 Why does Alice believe she is talking to Bob?
– (Unfortunately, relies on encryption for authentication)
 Why does Bob believe he is talking to Alice?
 Note: N should be unpredictable, not just a nonce
– Otherwise, can falsely authenticate Bob to Alice
Kerberos
 Simpler; assumes loosely coordinated clocks
 AKDC: N, “Bob”
 KDCA: EncKA{N, “Bob”, KAB, ticket},
where ticket = EncKB{KAB, “Alice”, exp-time}
 AB: ticket, EncKAB{timestamp}
 BA: EncKAB{timestamp+1}
Desiderata and summary
 This is not an exhaustive list!
 These are concerns to be aware of; in some cases
you may decide that certain threats are not a
concern
 Better to formally define a security model and
prove security (but here we will be informal)
Desiderata and summary
 Adversary initiating session as client
– (Easiest attack to carry out)
– No impersonation (obviously!)
– No off-line password guessing
– Should not learn information that will subsequently
allow impersonation of server to client
– Be aware of server decrypting/signing unauthenticated
challenges
– Splicing messages into the session
 Similar for adversary accepting connections from
client (though this is a harder attack)
Desiderata and summary
 Eavesdropping
– Should not learn information that would allow for later
impersonation (possibly to another replica of Bob)
– Messages should be encrypted
– No off-line dictionary attacks
 Server compromise
– Should not learn client’s password
– Forward secrecy
– Impersonation of client to server(?)
Certificate authorities and PKI
PKI overview
 In our discussion of public-key crypto, we have
assumed users know each others’ public keys
 But how can public keys be reliably distributed?
– Download from web page insecure against man-in-themiddle attack
– Can be obtained from CD-ROM or in person, but this is
impractical in general
 One solution: bootstrap new public keys from
public keys you already know!
– Certificates vouch for binding of public keys to names
Certificates
 One party can vouch for the public key of another
 Cert(AB) = SignSKA(“B”, PKB, info)
– “info” can contain expiration time, restrictions, etc.
 Can view this as a directed edge in a graph:
PKA
PKB
 If you know A’s public key (and trust its
certification), you can learn B’s public key
Transitivity/“certificate chains”
 Can learn keys via multiple hops:
PKA
Cert(AB)
PKB
PKC
Cert(BC)
 Semantics are slightly different here: you may
trust A to certify B, but do you trust A to certify
that B can certify others?
Transitivity
 Can also infer trust from multiple (disjoint?) paths
to the same public key for the same identity
– Edges may also have weights indicating level of trust
– A difficult problem in general
PKA
PKB
PKD
PKE
Public keys I already know
PKC
Usage of certificates
 “Trust anchors” = set of public keys already
known (and trusted to certify others)
 How to obtain certificates?
 Some possibilities:
– B “collects” certificate(s) for itself, sends these all
when starting a connection
– A finds certificates/certificate chains beginning at its
own trust anchors and terminating at B
– A tells B its trust anchors, B (finds and) sends
certificates or certificate chains beginning at those trust
anchors and terminating at itself
Certificates in the real world
 PGP keyserver
 CAs embedded in browsers