CMSC 414 Computer and Network Security Lecture 24

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”, KAB, ticket}, where ticket = Enc. KB{KAB, “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{NA, N, “Alice”, “Bob”} ¨ B KDC: Enc. KA{NA, N, “Alice”, “Bob”}, Enc. KB{NB, N, “Alice”, “Bob”} ¨ KDC B: N, Enc. KA{NA, KAB}, Enc. KB{NB, KAB} ¨ B A: Enc. KA{NA, KAB} ¨ 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”, KAB, ticket}, where ticket = Enc. KB{KAB, “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”, 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