From: William Stephen Kish <wk0x@ANDREW.CMU.EDU>
Date: Fri, 23 Apr 93 04:30:46 PDT
To: Derek Atkins <warlord@ATHENA.MIT.EDU>
Subject: Re: encrypted telnet
In-Reply-To: <9304231039.AA08262@snorkelwacker.MIT.EDU>
Message-ID: <YfpxBQq00axaQNkl1g@andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain


Excerpts from mail: 23-Apr-93 Re: encrypted telnet Derek
Atkins@Athena.MIT. (1442)

> Bill..  There are a couple of problems with your scheme.

> 1) You have to have this daemon already running on host B.  I.e., you
> still need to have had (at one time) access to run this daemon.
> Basically, this means that you (or someone) has to have had root
> access to BOTH hosts A and B to set this up.  Unless this becomes
> supported software, you can't guarantee that....

Well, you really don't need root to run this daemon.  You can simply
telnet (normally) to machine B, start the daemon in the background, log
off, start the daemon in the background on machine A, and go from there.
 There is only a problem if machine B kills off your process when you
log out...  To be completely safe, you should change your login password
once you are on the encrypted link since the initial telnet to set up
the daemon was in the clear...

2) How do you do key distribution? 

One possible solution is to use PGP to encrypt this telnet key and mail
it to your account on B. Your private key on B can then decrypt the
telnet key. (If B is a multi-user system, you do have the problems
associated with root having access to your private key...  But if root
is evil, he can get around any sort of encrypted telnet scheme if he
really wants...)

> 3) How do you deal with multiple encryptions?  If you have more than
> one client who wants to use this program, you have to trust a single
> process (unless you run out of inetd, which requires #1) with all the
> different keys for all the different users!

Currently, everyone would be responsible for their own encryption
process.  This really isn't meant to be a complete standard, just an
ad-hoc solution until telnet's and telnetd's that support encryption
become commonplace.

> Basically, you're better off using ktelnet/ktelnetd to do this.  In
> either case you have the same problem with modifying the workstation.

Kerberos requires a large amount of support by a site's system admins. 
Most sites don't yet support kerberos. (Also, kerberos has some problems
of its own...) My solution is one that the average person can use
without special system software.  

Thanks for the comments,
Bill