CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz

Mediated authentication (using a KDC)

Needham-Schroeder  A  KDC: N 1, Alice, Bob  KDC  A: Enc KB {N 1, “Bob”, K AB, ticket}, where ticket = Enc KB {K AB, “Alice”}  A  B: ticket, Enc KAB {N 2 }  B  A: Enc KAB {N 2 -1, N 3 }  A  B: Enc KAB {N 3 -1}

Analysis?  N 1 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”, Enc KA {N A, N, “Alice”, “Bob”}  B  KDC: Enc KA {N A, N, “Alice”, “Bob”}, Enc KB {N B, N, “Alice”, “Bob”}  KDC  B: N, Enc KA {N A, K AB }, Enc KB {N B, K AB }  B  A: Enc KA {N A, K AB }  A  B: Enc KAB (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: Enc KA {N, “Bob”, K AB, ticket}, where ticket = Enc KB {K AB, “Alice”, exp-time}  A  B: ticket, Enc KAB {timestamp}  B  A: Enc KAB {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-the- middle 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) = Sign SKA (“B”, PK B, info) –“info” can contain expiration time, restrictions, etc.  Can view this as a directed edge in a graph:  If you know A’s public key (and trust its certification), you can learn B’s public key PK A PK B

Transitivity/“certificate chains”  Can learn keys via multiple hops:  Semantics are slightly different here: you may trust A to certify B, but do you trust A to certify that B can certify others? PK A PK B PK C Cert(A  B) Cert(B  C)

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 PK A PK B PK C PK D PK E Public keys I already know

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