[5003] in Kerberos
Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Joe Kovara)
Thu Apr 20 23:57:26 1995
To: kerberos@MIT.EDU
Date: Thu, 20 Apr 1995 12:32:26 -0700
From: Joe Kovara <joek@kerby.ocsg.com>
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]
At the risk of putting words in Mike's mouth... his message basically
makes a plea for a simple, secure telnet that can be used from virtually
anywhere to anywhere, without requiring a lot of work to configure and
manage either end, and without requiring privileged access to the server
end of the connection. (I'll also throw ftp, rlogin, rsh and rcp into the
ring, as the following discussion applies equally to them.) Some people
have picked up on STEL as potentially offering a solution. This is not
STEL's doing (although I must say it sounds really cool), but is
indicative of the level of exasperation, frustration and misunderstanding
that exists with respect to what people need and want today, potential
solutions, such as STEL, and existing solutions, such as Kerberos.
I have to state up front that everything I know about STEL is what I read
in the call for beta testers. This isn't a lot to go on, but the
fundamental issues here have nothing to do with STEL or Kerberos
specifically, and everything to do with the fundamental complexity,
quality and ease-of-use of any security system which is going to provide
strong authentication and encryption. This is the only reason I feel
comfortable in spouting off about this (and that we-- CyberSAFE--have a
lot of experience with the real-world deployment of such systems.)
Can anything satisfy the above requirements? I doubt it. The rest of this
verbiage is an attempt to show why there isn't anything presently
available that can; that Kerberos can _today_ provide a real,
honest-to-goodness secure connection for telnet; that it is not near as
complex as most people seem to think it is; that it can satisfy those
requirements as well is anything else; and that systems which offer
equivalent capabilities are going to have equivalent levels of complexity,
due to certain fundamental laws of the universe as presently understood by
man.
While Kerberos cannot satisfy all of the requirenets, it can come quite
close (at least a good implementation :). And, while I admit I'm speaking
from ignorance, I don't see how STEL can get much closer. (Well, yes I
can, but that would require making too many assumptions/conjectures about
the way it works, and all of them imply some reduction in security or the
use of technology which is unavailable to the masses. All of which would
make this posting longer than it is, which is already too long. But I
digress.) But how much closer is very dependent on a specific
implementation, and has nothing to do with the protocol, be it Kerberos or
STEL or Fred's security system.
The configuration you describe is essentially:
host <--> internet <--> ppp <--> you (workstation)
To have secure communications between you and the host, you need to secure
the path between you and the host. That is, you need a telnet on your
workstation and a telnetd on the host which is capable of (strong)
authentication and encryption. STEL appears to satisfy that requirement.
A "kerberized" telnet satisfies that requirement. The question is then:
How difficult is it to set up and manage the necessary components?
Kerberos requires that there be a KDC (key distribution center) accessible
to both you and the host. While we (CyberSAFE) strongly suggest that KDC's
be separate, very secure machines, this is not required; many smaller
sites run their KDCs on multiple-use production machines. For purposes of
this discussion, and to satisfy our requirement of simplicity, we'll put
the KDC on the host. Note that this simplification--as with any other
system--is a potential reduction in security. This guaratees that it is
accessible to you and the host (if you can't get to the host, obviously
this is all irrelevant anyway). Yes, most Kerberos implementations are
going to require that the KDC be installed by someone having root access.
However, given the questions of key management and the telnet daemon
itself (see below), I don't think this represents a hurdle that you don't
have to jump for other reasons.
One purpose of the KDC is to manage keys. Assuming there is a shared
secret, STEL will have the same requirement. (And even if you're using
public key, you need a CA.) The question is then: What key management
facilities does STEL provide? I don't know, but something will be needed.
(All Kerberos implementations that I am aware of provide key management
capabilities.) Saying that key management is someone else's problem is
not an option.
You need to talk to a telnetd on the host which understands whatever
secure form of telnet you are using. This usually requires that you tell
inetd about it, which usually (I hope) requires root privilege (in a Unix
environment). I don't see how STEL can get around this sort of host
dependency. Kerberos has the same "problem". Then again, some
implementations may allow you to start your own special telnetd, and let
you define your own port number. While this would eliminate the need to,
e.g., tell inetd about it, something still has to start this daemon. At
any rate, STEL and Kerberos (or anything else that provides equivalent
capabilities) are not going to differ here.
So much for the host. As for the client...
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. Regardless of which you use, this client
either must be on the workstation, or you're going to have to carry a copy
around with you. Kerberos also requires that you have a program for
performing the initial authentication ("kinit"). Both of the kerberos
client programs I just described will run over the PPP link; there is no
need for the internet access provider to have either of these programs
available. Even if they were, you wouldn't want to use them, because that
would leave the PPP connection itself unsecured. Everything I just said
is going to apply to STEL as well, except that STEL probably doesn't need
something like "kinit". The workstation requirements for Kereberos are
minimial; clients are available for everything from big boxes to desktops
(including both Mac and Windows).
What about efficiency? I can't speak for STEL, but Kerberos is pretty
efficient. Initial authentication requires one message in each direction
between you and the KDC (two messages). Initiating the telnet session
will require an additional two messages (assuming you are doing mutual
authentication, which we consider mandatory). There is then the question
of efficiency of the actual encrypted data. I doubt there is significant
difference between Kerberos and STEL. There is also the question of CPU
efficiency. This is very dependent on the implementation. It looks like
the STEL authors put some energy into making their's efficient. So have
some Kerberos providers.
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. It does not authenticate either end (unless we add
certificates, CA's, etc.; but remember, we're trying to keep this simple).
Well, since I've got a secure channel, why not send my password? Ok, who
goes first? If you're talking to a bad guy, whoever goes first has just
given away their password. 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. This means you still need a strong
authentication mechanism even if you use Diffie-Hellman. 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. (And, yes, our Kerberos supports
token-based authentication.)
We can (and have) made things very simple for the Kerberos clients/users.
We can (and have) made things as simple as is reasonable (which is pretty
simple) for the Kerberos KDC and server, and the administration thereof.
Again, implementations vary _tremendously_ in their level of convenience.
(I can't speak for others, but it's not unusual for a competent sysadmin
who understands basic Kerberos concepts to be up and running "out of the
box" in a matter of hours...your mileage may vary.) However, no matter
what system you use (Kerberos, STEL, Fred's security, ...) -- all other
things being equal -- the whole package is going to have an equivalent
level of complexity, or it is going to give up something.
Building good security software is not like building good word processors
or spreadsheets. There is a certain underlying and fundamental complexity
inherent in *ANY* good security system. We didn't make the rules.
Depending on your state of mind, you can blame it on the mathematcians,
man's ignorance of the universe, or mother nature. We can hide this
complexity, but we can't get around the rules--without also letting the
bad guys get around them.
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
