Jonathan:
Hello! Quick two comments:
> If someone can give me a SINGLE example of a protocol which is NOT
> susceptible to the above attack (which can be practised by any host
> capable of both listening to and modifying the packet stream, eg. a
> rogue or compromised router or firewall), I'd be very interested to hear
> how it works.
As 'jknapka' mentioned in his reply, Bruce Schneier's
book _Applied Cryptography_ has almost a whole chapter discussing
key-exchange and MITM attacks on them. Two strategies discussed
which leap to my mind are "Key Exchange with Digital Signature"
(a trusted 3rd party signs the data before it's sent...which is
hard to do on the fly) and "Interlock Protocol" (where both
sides take turns sending half of the key-exchange data rather
than all of it at once...surprisingly effective).
However...the end of this chapter has the most
illuminating sentence, IMO: in general, MITM attacks are
effective against any protocol that does not involve a 'secret'
(eg, pre-shared secret, SecureID card, etc) of some kind. Which
is as you described later:
> The answer may be to have the server send the key in an encrypted form
> which can only be decrypted using the VNC server password, or a separate
> "key password". And then only to have that done on a "once only" basis -
> the key should be stored locally as far as humanly possible.
Right, exactly, the pre-shared "key password". Again,
though, using a SecureID one-time password card for this is
even better. Then the data security of the system is as secure
as the physical security of the system, which is the goal. Well,
I think it's the goal. :) Just went thru this design process for
a peer-to-peer VPN app, and you're right that there's *always*
one more thing to worry about...especially if you ever want to
solve revoking a known-compromised key-pair. Oh my.
IMO, you add layers, transparent to the user experience,
until the easiest way to break the security model is for someone to
come into the office after hours and just take the server.
cheers,
Scott
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
