You're both right--there are two types of man-in-the-middle attacks that can occur--one is with the initial connection. DH does not provide identity validation--therefore, you might think your setting up a connection to your remote site when it is really a man-in-the-middle that you're setting it up with. To solve this, you can use a Certificate Authority to validate the remote's identity.
The second problem is when the connection is set up to the "real" destination, but there is still a "man-in-the-middle" peeking at all of your traffic. Through the DH key exchange, even though the man-in-the-middle sees the public keys that are shared, it doesn't see the private keys, nor the new "secret" key derived from the remote's public and your private. Hope this helps Happy holidays! -- ______________________________________________________________________ Richard Deal email: [EMAIL PROTECTED] web: http://pages.prodigy.net/richard.deal * Just finished a CCNA ebook available at Boson (www.boson.com): + "CCNA Secrets Revealed!" * CCNP test author for QuizWare (www.quizware.com) + CCNA #1 and #2 -- 550 questions each! + CCNP Routing #1 -- 500 questions + CCNP Switching #1 -- 500 questions + CCNP Remote Access #1 -- 500 questions + CCNP Support #1 -- 500 questions + CSS1 MCNS #1 and #2 -- 500+ questions each! * Author of the following Coriolis books: + "CCNP Switching Exam Cram" + "CCNP Remote Access Exam Prep" + "CCNP Cisco Lan Switch Configuration Exam Cram" ______________________________________________________________________ wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Ray, > > I have worked with diffie-hellman quite a bit. You have the correct gist of > it. The key to the answer is the word anonymous in the cisco excerpt. The > initial diffie-hellman public key exchange is subject to man-in-the-middle > attacts, if you run this key exchange anonymously. On the other hand if you > do a manual verification of the intitial key exchange, by having the > recieving end visually check the public key against what the sender is > sending, then its secure and subsequent key exchanges will be secure. > > > > -----Original Message----- > From: Ray Brehm [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 07, 2001 1:50 PM > To: [EMAIL PROTECTED] > Subject: diffie-hellman clarification [7:28438] > > > I need a security wizard here... > > This question is from certification zone: > > Diffie-Hellman exchange prevents what type of attack on secure > communications? > > A. > > Denial of service > > B. > > Session key cryptanalysis > > C. > > Replay > > D. > > Man-in-the-middle > > Your Answer: D > > Correct Choice: d > > Answer Explanation > > Diffie-Hellman is used in the secure exchange of information from which > session keys are generated for communications between legitimate users A > and B. It prevents man-in-the-middle attacks, in which an intruder M > lies to B, saying it is A, and lies to A, saying it is B. If A and B > accept M's statement, A and B will both send to M, and M can read or > change the information flow. > > > This excerpt is from Cisco's website and the Internet Protocol Journal > 6/98: > > * Anonymous Diffie-Hellman: The base Diffie-Hellman algorithm is > used, with no authentication. That is, each side sends its public > Diffie-Hellman parameters to the other, with no authentication. > This approach is vulnerable to man-in-the-middle attacks, in which > the attacker conducts anonymous Diffie-Hellman exchanges with both > parties. > > > I understand the way Diffie-Hellman works and exchanges public keys > using a mathematical formula and is vulnerable to man-in-the-middle > during the original D-H exchange. I also understand how further key > exchange for data encryption works after D-H is computed. What I'm > getting at here is what's the Cisco answer? D-H is vulnerable to > man-in-the-middle during the original exchange but protects the exchange > of the real key used for data encryption if it is executed successfully. > The answer to this question could quite possibly be B since once D-H is > completed successfully it protects the session key. Again, can someone > clarify what the Cisco answer would be? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=28475&t=28438 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
