[5022] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Joe Kovara)
Sat Apr 22 17:51:14 1995
To: kerberos@MIT.EDU
Date: Sat, 22 Apr 1995 00:55:06 -0700
From: Joe Kovara <joek@kerby.ocsg.com>
To try and keep from cluttering your view, I've combined responses to
three previous postings here. It's obvious that there is still much that
is misunderstood about Kerberos. While Kerberos does solve many problems,
it is not a panacea. And some people just don't want or need what
Kerberos offers and demands. What I have tried to do is show how Kerberos
can solve some problems in a much more straightforward fashion than is
commonly preceived. That still may be too much for some sites.
But don't judge Kerberos on what you've heard from others--or what you
knew of it a year ago. If you haven't looked recently, look again. If
not at us (CyberSAFE), then check out MIT's most recent distribution;
the've made significant improvements in the last few releases.
----------------------------------------------
On 21 Apr 1995, Planar wrote:
> But the solution to this problem is given in Schneier's book (and
> other places as well, I would expect):
Apologoies. I abbreviated a little too much in an attempt to keep things
short. You are correct. Keyed Diffie Hellman is a solution. But we then
get into questions of establishment of the session key, etc. All of which
have solutions, and all of which also imply some additional complexity (in
this case, some form of key management).
The point I was trying to make (and obviously didn't do well) is that
there are answers to all of these questions. As with everything in life,
it's simply a matter of what tradeoffs you're willing to make. That's not
a problem--as long as everyone understands up front that they are making
tradeoffs.
> P.S. What's the need for such looong message-IDs ? I guess some
> programmer got lazy. Or is it some kind of subliminal channel ?
Obviously not subliminal enough :)
----------------------------------------------
On 21 Apr 1995, Jeff A Licquia wrote:
> Wasn't it said in the call for beta testers that STEL uses Diffie-Hellman
> key exchange? If so, there's your key management, done without a KDC. Not
> needing a KDC may be the big feature STEL provides over Kerberos.
[...]
I addressed part of this above. DH (keyed or not) does not address "key
management". By that I mean the generation, distribution, storage and
revocation of keys (and implicitly, the credentials derived from those
keys). If you're using public key, that's X.509 and the certificate of
authority (CA) hierarchy. If you're using Kerberos, it's the KDC(s), key
tables, session keys, tickets, etc.
> Kerberos, not to mention the licensing stuff. If your threat model doesn't
> require that much security, why go through the overhead?
[...]
> That's true. The question is whether what you give up gains you other
> benefits without a big loss according to your needs. There is a place for
> rot13, after all.
Absolutely. I don't think it's any secret that we are (among other
things) a Kerberos vendor. But Kerebros is just a piece of a much larger
puzzle. It is not unusual for us (in our consulting capacity) to
encounter situations where Kerberos is unwarranted or doesn't fit, and in
those cases we don't use or recommend it. But, all in all, we like
Kerberos because it's a solution that solves a lot of problems, and is
usable today.
That said... We've found that the majority of sophisticated, modern
organizations (i.e., those that depend heavily on the ability to trust
their electronic infrastructure) demand a level of protection (as defined
by their threat models) which usually requires Kerberos, or something like
Kerberos. Again, Kerberos is one solution; I'd really like to have a few
others in my bag o' solutions, but the pickings are thin.
----------------------------------------------
On 21 Apr 1995, Mike Neuman wrote:
> I apologize, I thought I had sent this message directly to Joe, rather
> than to the Usenet as a whole.
Gives me a chance to say nice things about mutant canines (they need love
too :-)
> 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
No. This isn't necessary. I know this is getting old, but...
implementations vary _tremendously_. If you follow a few, simple, well
documented, easily understood, and very reasonable rules, YOU DON'T NEED A
REALMS OR CONF FILE ON THE CLIENT. I can't be emphatic enough about that,
so I'll put it a different way. YOU DON'T NEED TO CONFIGURE THE CLIENT.
And if the host sysadmin has screwed up the realms or conf file, there's
still a very high probability that our client will find your realm and kdc
without you having to do anything. Magic? No. Proprietary? No. Just
common sense. I believe MIT's distribution even has a form of this now
(this was discussed in a previous posting on comp.protocols.kerberos).
> 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
Ok, instead of putting the KDC on the machine you want to connect to,
we'll put it on your home machine, since that appears to be the "anchor
machine" in this picture. If the anchor machine (whatever is running the
KDC, and whatever contains your distribution) is not accessible to both
you and the target machine, then we have a problem and I can't offer a
reasonable solution.
Once again, however, the installation of the telnet daemon will present a
problem on the target machine, no matter what you use (unless, as I stated
previously, you have your own version that talks on a non-standard telnet
port that you fire up yourself on the target machine).
> 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
You can do the same to down-load the Kerberos client to your local
machine. I didn't really think this was a viable option, since this
implies that, if you don't already have a secure client on your local
machine, you are going to be accessing your home machine using unsecured
access, and the ftp is not going to be secure, which means that what you
get at your end may not be trustworthy. (Ok, I'm too paranoid, and I
wouldn't recommend it. But, to be fair, if we allow this for STEL, then
we have to allow it for Kerberos.)
> 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.
No, it's not a minor complaint. Multiply this by thousands and you have a
Really Big Complaint (as would most network/sys admins). At any rate, I
think this was addressed above (see also my remarks below concerning
custom, site-specific installation kits below).
> 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
[...]
We're hoping that most clients have secure network services before that; a
lot of people can't wait. Again, I think (I hope), we've dispensed with
the apparent complexity of setting up a Kerberos client. And, while
the DH patent expires Sep. '97 (I think that's right), that's still 2.5
years off. Way too long for most people.
>[...] 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
The additions needed to telnet to support Kerberos (assuming the core
Kerberos libraries are built) is minimal. Most of the problems people
encounter have little to do with the core libraries, and a lot to do with
all the peripheral crap that has accumulated around the libraries. It is
truly amazing how simple, small and compact the "real Kerberos" is if you
strip away all that junk.
>[...] I can't imagine things like OS/2, VMS, Mac's, PCs,
I can, and much more :-))) Most of those are already shipping, or just about
to.
>[...] 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
Bang. Ya got me. We don't give our clients away for free. But MIT is
making significant progress in improving their implementation, especially
the portability of their code, and the elimination of dependence on
behemoths such as ISODE.
Again, I think we can dispense with the realm and conf files problem.
Moreover, for large installations which do require a custom installation,
we allow the customer to preconfigure and build their own distribution
"kits". For any given site (that doesn't want to follow the rules), you
configure it once and cut a "custom master distribution kit", which you
can then use for all systems at that site. This goes a loooong way
towards solving a lot of site-specific configuration problems.
> 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.
Universal truth: if the "trusted" machine you are using (the one you typed
your password at) has been compromised, life is over. Your session is
compromised, and possibly your password. Doesn't matter whether you're
using Kerberos or STEL or whatever.
The Kerberos attack you describe is plausible, but life was over before
you started your session, so why worry? At any rate, you don't _have_ to
keep your credentials in a disk file, but that's typically the most
convenient place to keep them. Even if I do take that route, I can get a
service ticket without obtaining and storing a TGT, which means that,
while the attacker may be able to obtain my initial session key (the one I
used to authenticate with the telnet server), they won't be able to
decrypt the session unless they've recorded the initial authentication
exchange, because I'll be using a different session key after that.
The above isn't perfect since, as you describe, if you do keep a service
ticket on disk, the attacker could grab this and initiate a new session.
You can either not keep credentials on disk, or destroy them once the
session is initiated (assuming the telnet client has that option, or at
least has a shell escape that allows you to delete the cred cache). I just
described one of about a billion different combinations of threats and
countermeasures; suffice it to say that, if done properly, Kerberos is as
or more difficult to compromise than anything else I've seen.
> never suggested it be used for authentication--now you ARE putting words
> in my mouth. :-) ).
Apologies. See also previous discussion of DH.
> 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.
But encryption can be made the default (and even if not, it's trivial to
turn it on).
How well we know about the export problems. But as far as STEL's
exportability with respect to the U.S., see my original response to STEL's
posting concerning the participation by U.S. nationals in STEL's beta
test. If I get DES code from Italy and then send it back, I am breaking
the law. It gets worse. If you carry any non-Commerce approved crypto
software out of the country--say STEL on your laptop--and it uses DES (or
any number of other crypto systems including, I believe, IDEA), you are
required to register that event, or you are breaking the law. (In the
NSA's defense, they have tried to make this simple.)
mumble mumble gnash unnnnnhh !^@** [person biting tongue]. If I say any more
this is going to get really ugly. U.S. crypto export laws speak for
themselves.
> S/Key is a counter-example. It's very simple, and requires no hardware.
Agreed. S/Key is neat.
Whew!
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
