CMSC 414 Computer and Network Security Lecture 18 Jonathan Katz

One-way authentication  If 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 extend to give mutual authentication

Authenticated Diffie-Hellman  Add signatures/MACs and nonces to Diffie- Hellman protocol –Note: achieves forward secrecy –What if we had used encryption instead?

Using session keys  Generally, want to provide both secrecy and integrity for subsequent conversation –Use encrypt-then-MAC –Use sequence numbers to prevent replay attacks –Use a directionality bit –Periodically refresh the session key

“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…  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  Eavesdropping, server impersonation, and man-in-the-middle attacks are more difficult  Confidentiality is an orthogonal issue…

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 –E.g., don’t use crypt( ) as a MAC…

More “hints”  Be careful of composing security schemes –E.g., using two authentication systems…  Protect user passwords –Don’t send in the clear –Don’t include in cookie  Re-authenticate before changing password  Avoid predictable session identifiers  Expiration…

A simple and secure approach…  Cookie = (username/data, expiration, MAC)

Mediated authentication

 E.g., using KDC  Simple protocol: –Alice requests to talk to Bob –KDC generates K AB and sends it to Alice and Bob, encrypted with their respective keys –Note: no authentication here, but impostor can’t determine K AB

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

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  Important: authenticate “Bob” in message 2, and “Alice” in ticket  Uses encryption to authenticate…  –Leads to actual flaw if, e.g., ECB mode is used!  Vulnerable if Alice’s key is compromised –Bob’s ticket is always valid –Use timestamps, or request (encrypted) nonce from Bob at the very beginning of the protocol