low-overhead encrypted telnet

[Jef Poskanzer <jef@ee.lbl.gov>]

I've been talking about entrypted telnet with Craig Leres lately, and
he came up with an interesting idea.  The background is, sysadmins want
encrypted telnet so that passwords don't fly around in the clear, but
at the same time, they don't want to spend too many extra CPU cycles.
I figured at least some sysadmins would resist installing an
encryption-capable telnetd because of this concern about overhead.

What you'd really like to do so satisfy these people is encrypt only
when actually transmitting passwords.  Problem is, that's hard to
implement.  Kerberos does it by supplying new versions of a dozen
different programs, and it still only works within your organization,
and even there it doesn't handle chained logins (telnet from host A to
host B, then from host B to host C, etc.).  It's hard because you have
different levels of software trying to talk to each other.  A solution
that worked entirely within telnet would be a lot simpler.

A compromise I thought of a while back is to encrypt the first few
kilobytes and then switch to cleartext.  This lets you log in securely,
the average overhead for the session remains low, and there's no
interaction between different software levels.  But this also doesn't
handle chained logins, if the second login comes later in your session.

So here's Craig's idea: only encrypt the client-to-server direction.
That's the only direction that passwords go, so it's secure; and it's
low overhead because you generally type far fewer characters than you
read.

Just a tidbit for anyone working on encrypted logins.
---
Jef