[5014] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Apr 21 15:24:45 1995
Date: Fri, 21 Apr 1995 14:31:48 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Planar <Damien.Doligez@inria.fr>
Cc: kerberos@MIT.EDU
In-Reply-To: Planar's message of 21 Apr 1995 14:22:51 GMT,
<3n8f3r$o61@news-rocq.inria.fr>
Date: 21 Apr 1995 14:22:51 GMT
From: Planar <Damien.Doligez@inria.fr>
But the solution to this problem is given in Schneier's book (and
other places as well, I would expect):
First, I'll commit to my password by sending MD5(password+session key).
Then the other guy will do the same with his password.
Then I send my password and the other guy sends his. If the hashes
don't match, then I know there's a man-in-the-middle attack going on.
No need for token-based authentification, here. The good old password
system still works.
This is poor idea; if the hashes don't match, you know there's
man-in-the-middle attack. But unfortunately, the attacker has your
password already.
The right way to do this is to establish a shared secret, and have one
side a of the shared secret plus the session key, *without* ever sending
the shared secret accross to the other side.
Note, though, that you need to have a shared secret with each server
that you wish to connect to. If you have 50 machines that you might
login to, that's 50 machines where you have to distribute that shared
secret. If you use the same shared secret, then whenever one of those
machines gets compromised, access to all of the other machines are also
compromised. If you use 50 different shared secrets, then you have to
remember 50 different passwords.
The basic message here is, "there ain't no such thing as a free lunch".
Diffie-helman systems that don't do any key management may be simpler to
set up in very simple environments. However, in more complex ones, it
will likely be much harder to administer than Kerberos, or be
significantly weaker in terms of its overall security.
- Ted
