CMSC 414 Computer and Network Security Lecture 17

CMSC 414Computer and Network SecurityLecture 17 Jonathan Katz

Authentication with password + public key • Say that only the server has a known public key (e.g., SSL) • Server sends R • Client sends Epk(R, password, session-key) • Insecure in general!!! • But secure if encryption scheme is chosen appropriately • Can be extended to give mutual authentication

Using session keys • Generally, want to provide both secrecy and integrity for subsequent conversation • Use authenticated encryption (e.g., encrypt-then-MAC) • Use sequence numbers to prevent replay attacks • Use a directionality bit • Periodically refresh the session key

Mediated authentication (using a KDC)

Mediated authentication • Simple protocol: • Alice requests to talk to Bob • KDC generates KAB and sends it to Alice and Bob, encrypted with their respective keys • No authentication here, but impostor can’t determine KAB • Other drawbacks: • KDC has to initiate session with Bob • Alice’s message to Bob may arrive before KDC’s message to Bob

Improvement… • Have KDC send to Alice the encryption of KAB under Bob’s key • Reduces communication load on KDC • Resilient to message delays in network • Bob and Alice follow with mutual authentication and key exchange

Needham-Schroeder • AKDC: N1, Alice, Bob • KDCA: KA{N1, “Bob”, KAB, ticket}, where ticket = KB{KAB, “Alice”} • AB: ticket, KAB{N2} • BA: KAB{N2-1, N3} • AB: KAB{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 flaw 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 requesting an (encrypted) nonce from Bob at the very beginning of the protocol

Otway-Rees • AB: N, “Alice”, KA{NA, N, “Alice”, “Bob”} • BKDC: KA{NA, N, “Alice”, “Bob”}, KB{NB, N, “Alice”, “Bob”} • KDCB: N, KA{NA, KAB}, KB{NB, KAB} • BA: KA{NA, KAB} • AB: KAB(timestamp)

Analysis? • Why does Alice believe she is talking to Bob? • 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

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 acceptable • 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(?)

“Dos and Don’ts of Client Authentication on the Web” (Fu, et al.)

Authentication using “cookies” • “Single sign-on” for users accessing a site • Full-fledged key-exchange not practical due to limited client (and server!) computation • No public keys, no third parties, deployability… • Idea: use “authenticators” stored as cookies • No client-side computation at all • But…must do this securely!

Minimal level of security? • Any such scheme must be secure against “interrogative attacks” • These are trivial to mount by legitimate users • In contrast to eavesdropping, server impersonation, and man-in-the-middle attacks that are more difficult • Confidentiality is an orthogonal issue… • Fine-grained vs. coarse-grained authentication • Does the system care who the user is, or just that they are legitimate?

Security model? • Existential forgery vs. selective forgery • The former may typically be sufficient; the latter is worse • (Essentially) adaptive chosen-message attack • User can sign up for different account under different names, with different levels of service • Want no existential forgery even after adaptive chosen-message attack • We have seen this before!

Security “hints”… • Use appropriate amount of security • Do you need fine-grained knowledge of the user-id or not? • Is confidentiality, etc. required or not? • Use published schemes… • No security through obscurity… • Use cryptographic tools appropriately

Example… • Using crypt( ) as a hash or MAC… • Output of crypt only depends on the first 8 characters of its input • crypt(username | key) provides no protection if the username is 8 characters long! • crypto(user | key) = crypt(user’ | key) if the first 8 chars of user match the first 8 chars of user’ • How can you determine the 8 character key using an adaptive chosen-message attack and ~211 work?

More “hints” • Be careful of composing security schemes • E.g., using same key for two purposes or schemes • E.g., different authentication schemes for account management and purchasing; break in one allowed recovery of password for the other • Protect user passwords • Don’t send in the clear, or include in URL • Only let cookies be sent over SSL • Re-authenticate before changing password • Avoid predictable session identifiers • Expiration…

A simple and secure approach… • Use secure MAC! • Compute MAC over entire cookie • Cookie = (username/data, expiration, MAC)

CMSC 414 Computer and Network Security Lecture 17