CMSC 414 Computer and Network Security Lecture 23

CMSC 414Computer and Network SecurityLecture 23 Jonathan Katz

HW4

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…

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

A public-key protocol • Client sends Encpks(R) • Server sends R, Encpkc(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

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

Public-key based… • Include Epk(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 Epks(R1); server sends Epkc(R2); session key is R1+R2 • Reasonable… • Why isn’t it a problem that the ciphertexts are not authenticated? • Implicit vs. explicit authentication

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

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 CCA-secure • 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 of KDC 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

CMSC 414 Computer and Network Security Lecture 23