[5010] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Mike Neuman)
Fri Apr 21 12:03:09 1995
To: kerberos@MIT.EDU
Date: 21 Apr 1995 10:31:35 -0500
From: mcn@guardian.EnGarde.com (Mike Neuman)
Reply-To: mcn@EnGarde.com
In article <Pine.SUN.3.91.950420060653.5096D-100000@kerby.ocsg.com>,
Joe Kovara <joek@kerby.ocsg.com> wrote:
>On Wed, 19 Apr 1995, Mike Neuman wrote:
>> In article <Pine.SUN.3.91.950419151719.1893B-100000@kerby.ocsg.com> you write:
>> Anyway, my primary complaint with the kerberos telnets is that they
>> require the server and client to share a Krb server. It's often impossible
>> to kinit yourself from whatever random host you happen to be on, and even
>[...]
>[a cross-posting of this message is being added to comp.protocols.kerberos]
I apologize, I thought I had sent this message directly to Joe, rather
than to the Usenet as a whole.
>The configuration you describe is essentially:
> host <--> internet <--> ppp <--> you (workstation)
This configuration is essentially what I have from my 'home' machines.
However, I was also describing the broader picture of walking up to a
public access machine, or a demo machine at a convention, or a friend's
machine. These are three cases where it's not likely you can get and install
kerberos clients quickly and configure them properly. Another example
"bad" configuration is running kerberos clients from any multi-user machine.
Correct me if I'm wrong on either of these points...
1) Root access is required on the client machine in order to edit the proper
Kerberos configuration files (krb.realms, krb.conf, etc.). This is frequently
impossible. Sure, you could FTP a copy of Kerberos and install it with
a different path for krb.conf/krb.realms, but that assumes you a) have the
time and want to put out the effort, and b) Kerberos will compile on whatever
platform you're on.
2) Root access is required on the server in order to make and install a
Kerberos server (assuming we put the KDC on the machine we want to connect
to). a) There's a bootstrapping problem--how do I become root and install
stuff, then enter the Kerberos master password, then enter my kerberos
password over an insecure connection? Sure, I could break in, or go to the
console, but if my customer's console is 1500 miles away, neither of these are
good solutions. Granted STEL doesn't solve all of these problems... b) If I'm
not given the root password, do you have any idea how hard it is to convince
a sysadmin to install Kerberos? I've never seen so many sysadmins use the
phrase "I'll get back to you on that".
>I think we can assume that on your workstation you have the client code
>necesssary to use the secure telnet. I assume that STEL will have a
>special version of this client. Kerberos is the same: you need a
>"kerberized" telnet client.
Considering the reverse situation: of attempting to connect to a machine
under my complete control from a machine which isn't...
What you say is true, however, bootstrapping with something like STEL is
easier than Kerberos. If my home (now remote) machine is connected to some
dialin line, I can anonymously FTP to my machine, get a copy of the STEL
client (already having the STEL server installed there) and start communicating
securely as soon as the FTP is finished. With Kerberos, I have to get kinit,
and the kerberized telnet, and then install the configuration files (modifying
them with the current (random) dialin line I'm on). Okay, so this is a minor
complaint.
Something that neither Kerberos nor STEL will solve, but STEL comes closer to
solving is the problem of connecting from a random machine (public access,
friend's, multi-user) to another machine (controlled or otherwise). If there's
a standard for encrypted telnets, we can hope in a few years that every
client will have them installed, WITHOUT the overhead of installing Kerberos.
If D-H key exchange became "standard" (licensing aside, although the patent
expires VERY soon), sniffing and connection hijacking would be eliminated as
problems (except for one specific case, see below), all with a few hundred
additional lines of code to the already existing telnet clients & servers for
every platform known to man. Kerberos, on the other hand, won't even compile
on my Solaris machine. (Granted I haven't tried very hard, but if it has
trouble on Solaris, I can't imagine things like OS/2, VMS, Mac's, PCs,
vendor X's Unix, etc.)
The specific problems STEL won't have that Kerberos will in the situations
I described above:
1) The public access machine may be any type of hardware (at InternetWorld they
were OS/2 machines) A precompiled Kerberos may not be available for this
particular platform. (Unless someone is willing to stick up precompiled
kinit and telnet binaries with your krb.realm and krb.conf file in '.' for
free, I don't see this problem as being solved. Even if it is, it'll take
a good 5 minutes of FTPing and configuration to get it working right. Last
I checked, the people behind you in line get antsy after about 2 minutes. :-)
STEL could be dropped in and run as soon as the FTP is completed.)
2) On multi user machines, someone could simply su to you and own your
Kerberos credentials, and connect to whatever machine you have. With something
like STEL, the attacker would need to plug through /dev/mem in an attempt
at finding your current encryption key and then use that to hijack your
connection or analyze the beginning of your connection where you typed your
password to the remote machine. This is infinitely more difficult than typing
'su' and telneting again.
>The workstation requirements for Kereberos are
>minimial; clients are available for everything from big boxes to desktops
>(including both Mac and Windows).
Where can a find free precompiled binaries? So I can drop them into
whatever public access machine I'm on? If this resource were available,
the world would change. :-)
>What about the security of the authentication scheme? Diffie-Hellman was
>suggested as solving the need for secure authentication to the host
>(licensing issues aside). Nope. Diffie-Hellman allows two strangers to set
>up a secure channel.
Absolutely true. The only point of Diffie-Hellman is to establish an
encrypted, sniff-proof, hijack-proof connection, not authentication (I
never suggested it be used for authentication--now you ARE putting words
in my mouth. :-) ). Reusable passwords will be with us for a LONG time,
whether we like it or not. D-H simply allows for a more secure use of
reusable passwords. Combine D-H with something like S/Key (yet another
scheme which doesn't require tons of stuff to be installed on either
end of the connection--nothing on client, s/key program only on server),
and you have a completely secure connection which can't be hijacked, spoofed,
intercepted, reused, etc.
>This does NOT imply that the host has already
>been compromised. It simply means that someone has been able to fool you
>(using DNS/IP spoofing) into talking to them instead of the real host.
>Very doable, very probable. And it doesn't require me to compromise the
>host or your workstation.
There are more advanced, sneaky ways of doing this (see my Watcher page:
http://www.cec.wustl.edu/~dmm2/egs/watcher.html), but you're correct.
Although it should be noted that the entire kerberos connection needs to
be encrypted as well as authenticated, or else this entire conversation is
moot. Unfortunately encryption is not the default. In addition, the encryption
is not exportable, so it may or may not be possible to connect to servers
in another country/from another country. Whereas STEL was written in Italy,
which makes its encryption freely distributable.
>Ah ha! I'll use token based authentication as well. This will help. But
>then, you need cards, you need an authentication server to go with it, ...
>Remember, we're trying to keep this simple.
S/Key is a counter-example. It's very simple, and requires no hardware.
Apologies for my lengthy reply. :-)
-Mike
mcn@EnGarde.com
En Garde Sytems
--
Mike Neuman (mcn@EnGarde.com) - EN GARDE SYSTEMS - Computer Security Consulting
- http://www.cec.wustl.edu/~dmm2/egs/egs.html
"Most of these should be 'void', but the people who defined the STREAMS
data structures for S[ystem] 5 didn't understand data types." - Solaris source
