[5011] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (eichin@MIT.EDU)
Fri Apr 21 12:38:53 1995
Date: Fri, 21 Apr 95 12:19:43 -0400
To: mcn@guardian.EnGarde.com (Mike Neuman)
Cc: kerberos@MIT.EDU
In-Reply-To: "[5010] in Kerberos"
From: eichin@MIT.EDU
> 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
Well, there's one :-) WIth CNS/V4 at least, the client needs *no*
access beyond their own account. In fact, we've got a single-program
solution called "cygin" which was demoed in the Usenix terminal room a
while back -- one program, gets tickets and logs in, no configuration
required *if* it can guess right [namely that kerberos.REALMNAME is
the DNS name of the KDC -- a command line argument lets you specify
the remote realm so you don't need krb.realms at all] and if it can't,
you can always create a local krb.conf and point the KRBCONF
environment variable at it. This means that you can show up at a
remote site (conference, customer, whatever) and pull cygin over the
net and you're pretty much set. (If it weren't for the ITAR, we'd
probably set things up so you could get it directly from us... right
off of the web page, at that!)
I'm ignoring the validation and signature issue here (mostly because
(1) everyone else is too (2) kerberos doesn't help with that
anyhow...)
> 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
Actually, CNS takes care of that too. There are two reasons for the
KDC to run as root: (1) to bind port 750 or 88 (2) to protect the
database from NFS attacks [note that it doesn't help much with that.]
CNS supports running the KDC and Kadmin on different ports, and adds
:port to the syntax of the krb.conf to specify them.
This was originally intended to allow the operation of multiple realms
(via multiple KDC's) on a single machine -- and had the pleasant side
effect of simplifying our automatic testsuite...
> 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.
I couldn't tell, and haven't heard back from the STEL gang about,
whether or not STEL is even based on telnet, or just "looks like"
it. In particular, I'd be very happy to see the single-command non-pty
mode (rsh emulation) become a "standard" telnet option -- so that we
could throw away the rats nest of rlogin/rsh/rcp once and for all...
_Mark_ <eichin@cygnus.com>
Cygnus Support
Cygnus Network Security <network-security@cygnus.com>
ps. If you want CNS/V4 check http://www.cygnus.com/ to find
out how to get it.
