CMSC 414 Computer and Network Security Lecture 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 E pk (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 K AB and sends it to Alice and Bob, encrypted with their respective keys  No authentication here, but impostor can’t determine K AB  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 K AB 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: N 1, Alice, Bob  KDC  A: K A {N 1, “Bob”, K AB, ticket}, where ticket = K B {K AB, “Alice”}  A  B: ticket, K AB {N 2 }  B  A: K AB {N 2 -1, N 3 }  A  B: K AB {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 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”, K A {N A, N, “Alice”, “Bob”}  B  KDC: K A {N A, N, “Alice”, “Bob”}, K B {N B, N, “Alice”, “Bob”}  KDC  B: N, K A {N A, K AB }, K B {N B, K AB }  B  A: K A {N A, K AB }  A  B: K AB (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 ~2 11 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)