1. CMSC 414 Computer and Network Security Lecture 23 Jonathan Katz

2. HW4

3. Mutual authentication in 3 rounds?  Can we compress the previous protocol to 3 rounds? –Client sends their name, R’ –Server sends f(k, R’) and R –Client sends f(k, R)  Seems ok…

4. Mutual authentication in 3 rounds  Insecure! (reflection attack using two server connections…) –Also vulnerable to off-line password guessing without eavesdropping –To improve security, make protocol asymmetric –No such attack on original protocol Security principle: let initiator prove its identity first  A good illustration that designing secure protocols is very subtle! –Another warning against modifying existing protocols even in seemingly “innocuous” ways

5. A public-key protocol  Client sends Enc pks (R)  Server sends R, Enc pkc (R’)  Client sends R’  Security? –Vulnerable to chosen-ciphertext attacks… –Seems better to use signatures  How does the client obtain pks and skc? –One option is to download “credentials” from another site using a password

6. Establishing a session key  Use the (secure) double challenge-response protocol from earlier; let the session key be F k (R+1) –Is this secure? –How to fix?  (Note: the fix suggested in the book is bad)

7. Public-key based…  Include E pk (session-key) in protocol? –No authentication of the ciphertext  Encrypt session key and sign the result? –No forward secrecy… –Potentially vulnerable to replay attacks  Client sends E pks (R 1 ); server sends E pkc (R 2 ); session key is R 1 +R 2 –Reasonable… –Why isn’t it a problem that the ciphertexts are not authenticated? –Implicit vs. explicit authentication

8. Authenticated Diffie-Hellman  Add signatures/MACs and nonces to Diffie- Hellman protocol –Note: achieves forward secrecy –A lot of subtle details involved…

9. 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 CCA-secure  Can be extended to give mutual authentication

10. 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

11. Mediated authentication (using a KDC)

12. 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 of KDC 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

13. 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