180 likes | 190 Views
This lecture discusses the Needham-Schroeder and Otway-Rees protocols for mediated authentication, analyzing vulnerabilities and proposed solutions. It also covers certificate authorities and the public key infrastructure (PKI) for secure key distribution.
E N D
CMSC 414Computer and Network SecurityLecture 24 Jonathan Katz
Mediated authentication (using a KDC)
Needham-Schroeder • AKDC: N1, Alice, Bob • KDCA: EncKB{N1, “Bob”, KAB, ticket}, where ticket = EncKB{KAB, “Alice”} • AB: ticket, EncKAB{N2} • BA: EncKAB{N2-1, N3} • AB: 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 • AB: N, “Alice”, EncKA{NA, N, “Alice”, “Bob”} • BKDC: EncKA{NA, N, “Alice”, “Bob”}, EncKB{NB, N, “Alice”, “Bob”} • KDCB: N, EncKA{NA, KAB}, EncKB{NB, KAB} • BA: EncKA{NA, KAB} • AB: 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 • AKDC: N, “Bob” • KDCA: EncKA{N, “Bob”, KAB, ticket}, where ticket = EncKB{KAB, “Alice”, exp-time} • AB: ticket, EncKAB{timestamp} • BA: 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(?)
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(AB) = 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(AB) Cert(BC) 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