CMSC 414
Computer and Network Security
Lecture 22
Jonathan Katz
Lamport’s protocol
 Server stores Hn(pw), sends n; user sends Hn-1(pw)
– Server updates user’s entry…
 Can also add “salt” to hash
– Server sends salt to user as first flow
– Allows user to use same password on different sites
– Can use same password (but different salt) when
password “expires”
– Protects against pre-computation
 Deployed as S/Key
Some drawbacks…
 Secret expires at some point and a new secret must
be shared
 Security against active attacks?
 E.g., “low number” attack
– Can use “paper-and-pencil” method to prevent this…
– …but at that point, better solutions are also possible!
Session key establishment
 There are very few applications for which
authentication alone is sufficient!
– Can you think of any?
– What do you do once you are authenticated?
 Generally, need to establish a session key to
authenticate (and encrypt) subsequent
communication
– Also efficiency advantages to using symmetric-key
techniques even if public-key authentication is used
– Advantages even if a symmetric key is already shared…
Session keys
 Reduces effectiveness of cryptanalysis
 If key compromised, only one session affected
 Prevents replay of messages from other sessions
Basic key exchange
 Public-key based…
 Diffie-Hellman key exchange
– Secure against passive eavesdropping…
– …but insecure against a man-in-the-middle attack
Adding key exchange
 Not sufficient to simply “add on” key
establishment before/after authentication
– Splicing attack…
 Need “authenticated key exchange”
KDCs
 Key Distribution Centers
 Advantages of symmetric-key crypto, without
O(n2) keys
– But requires a trusted intermediary
– Single point of failure/attack
 Kerberos is a famous example
Basic idea
 Every user i shares a key Ki with the KDC
 When Alice wants to talk to Bob, the KDC
authenticates the request from Alice, chooses
random K, and sends EncKa(K), EncKb(K) to Alice
– Alice forwards EncKb(K) to Bob
 Alice and Bob use K to communicate
 Note that the KDC can read all communication!
Multiple intermediaries
 Allows users in different domains to communicate
securely
 Use multiple KDCs…
– Can have all pairs of KDCs share a key
– More likely, there will be a hierarchy of KDCs
Authentication Protocols
(Chapter 11, KPS)
Overview
 Protocol design is subtle
– Small changes can make a protocol insecure!
– Historically, designed in an “ad-hoc” way, by checking
protocol for known weaknesses
– Great example of where provable security helps!
Challenge-response
 Client and server share a key k
 Generically: server sends R; user sends f(k, R)
 For which f will this be secure?
 What if R is non-repeating, but predictable?
 Drawbacks
– No mutual authentication
– No key exchange
– Dictionary attack if k is low entropy
– Insecure against server compromise
“Reverse” challenge-response
 Server sends f(k, R) and client sends R
– I.e., send a ciphertext and have user decrypt it
 Mutual authentication (if decrypts “validly”)??
 Which f are suitable?
 Weaknesses?
– Uses encryption for authentication
• (Note that a MAC cannot, in general, be used)
– Vulnerable to dictionary attack just by false attempted
login (not eavesdropping)
– Authentication of server assumes no replay…
Single-flow protocol
 Use time instead of a server-generated challenge
 User sends <time, MACK(time)>
– What if she had used encryption, or a hash?
– What about just sending MACK(time)?
 No server state; single message
 Considerations?
–
–
–
–
–
Requires (loosely) synchronized clocks
Must guard against replay…
What if user has same key on multiple servers?
Clock reset attacks; clock DoS attacks!
No mutual authentication
Public-key protocol
 What if we instantiate challenge-response or
reverse challenge-response with signatures or
public-key encryption?
– Is it secure?
 Possible resistance to server compromise (as we
have seen already)
 Is it a problem that the adversary can get the client
to sign an arbitrary value?
– Use different keys for different purposes
Adding mutual authentication
 Double challenge-response in 4 rounds
1. Client sends their name
2. Server sends a nonce R
3. Client sends f(k, R) and R’
4. Server sends f(k, R’)
 Again, what f should be used?
Mutual authentication in 3 rounds?
 Can we compress the previous protocol to 3
rounds?
– Client sends their name, R’
– Server sends f(k, R’) and R
– Client sends f(k, R)
 Seems ok…
Mutual authentication in 3 rounds
 Insecure! (reflection attack using two server
connections…)
– Also vulnerable to off-line password guessing without
eavesdropping
– To improve security, make protocol asymmetric
– No such attack on original protocol
• Security principle: let initiator prove its identity first
 A good illustration that designing secure protocols
is very subtle!
– Another warning against modifying existing protocols
even in seemingly “innocuous” ways