1 / 13

Three-Round Mutual Authentication Protocols for Secure Networks

Explore the intricacies and vulnerabilities of 3-round mutual authentication protocols in network security. Delve into issues like reflection attacks, offline password guessing, and asymmetric designs to enhance security. Understand the importance of identity proof and the risks of protocol modifications. Discover the challenges of public-key protocols, session key establishment, and the need for secure authentication methods. Learn about the subtleties of design and the significance of forward secrecy and integrity in communication.

osborn
Download Presentation

Three-Round Mutual Authentication Protocols for Secure Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMSC 414Computer and Network SecurityLecture 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 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

  6. 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)

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

  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 Epk(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 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

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

More Related