CMSC 414 Computer and Network Security Lecture 24

CMSC 414Computer and Network SecurityLecture 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-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

PKA PKB 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: • If you know A’s public key (and trust its certification), you can learn B’s public key

Cert(AB) Cert(BC) PKA PKB PKC 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?

PKA PKB PKC 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 PKD PKE 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

CMSC 414 Computer and Network Security Lecture 24