low-overhead encrypted telnet

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

Couple of comments:

1) Kerberos *does* work between corporate entities.  I can, for
example, go to Iastate (ISU) and get MIT Kerberos tickets, and then
rlogin -x to MIT, encrypting the session (I can, and I have).  Also,
it is possible (and I know someone who is doing it at this moment) for
someone from ISU, with ISU tickets, to log into an account here at
MIT.

2) Using your example, a user on host A telnets to host B, and from
host B they telnet to host C, if the A<->B link is encrypted, then so
long as the user trusts host B, then A<->C is secure as well (assuming
B<->C is encrypted).

3) Just encrypting from client->server will not necessarily reduce the
load on the server.  Also, doing something like DES is really not a
very high CPU operation, IMHO.  Maybe a better protocol than the one
done in rlogin -x is in order (this sends 8 characters over the link
for every successful "read", which means you can be getting anywhere
from 100% down to 12% throughput of plaintext in the cyphertext!)

4) Charon, which is based upon Kerberos, was developed exactly for
this type of problem: you want to authenticate securely over links
which may not otherwise be secure, but you trust the CPU in front of
you!  The paper describing Charon is available via anonymous ftp:
	ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z

Enjoy!

-derek

On Tue, 1 Mar 1994, Jef Poskanzer wrote:

> 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.

[Some text deleted]

Have you seen the proposals for an encryption option for TELNET?  There 
are at least two proposals.  The first is by David Borman dated April 
1990 and the second by Lawrence Brown and Gilje Jaatun dated December 
1991.  Borman's proposal focuses on the possibility of encryption of 
passwords only.  Unfortunately I don't have a pointer to an electronic 
copy of these proposals -- perhaps someone else on this list has?

I am currently working on a project which requires encrypted TELNET.  We 
will be encrypting *all* transmitted data to protect sensitive 
information -- not just passwords.  Does anybody know the current status 
of standardization of an encryption option for TELNET?

-- Rolf


----------------------------------------------------------------------
Rolf Michelsen         Phone:  +47 73 59 87 33
SINTEF DELAB           Email:  rolf.michelsen@delab.sintef.no
7034 Trondheim         Office: C339
Norway
----------------------------------------------------------------------

Rolf wrote:

| I am currently working on a project which requires encrypted TELNET.  We 
| will be encrypting *all* transmitted data to protect sensitive 
| information -- not just passwords.  Does anybody know the current status 
| of standardization of an encryption option for TELNET?


	I don't, but I would question the wisdom of putting lots of
effort into a telnet encryption scheme.  I would think it would be
much more productive to build an encryption scheme at the network
level, say, as packets are being encapsulated, so that users can
specify that they want an encrypted session for telnet or ftp, or even
sendmail could encrypt automatically when sending to certain hosts.

	By using a public key scheme to exchange session keys (much
like PGP), you could obtain the public key affiliated with your
destination IP, and know your packets are getting to the right place.

	A general framework, based on public key encryption would be a
far more flexible, powerful and useful tool for generating security on
the net than simply securing TELNET.


Adam

-- 
Adam Shostack 				       adam@bwh.harvard.edu

Politics.  From the greek "poly," meaning many, and ticks, a small,
annoying bloodsucker.

Have you signed the anti-Clipper petition?

>	   I don't, but I would question the wisdom of putting lots of
>effort into a telnet encryption scheme.  I would think it would be
>much more productive to build an encryption scheme at the network
>level

The reason that encrypted telnet is a good thing is that modification
at the network level requires kernel modification, and encrypting a
telnet does not.  Installing an encrypted telnet daemon does require
sysadmin cooperation, but it doesn't mean recompiling the kernel.

As such, encrypted telnet is a good intermediate while the long term
solution of encrypted IP gets developed and deployed.

Eric

Eric Hughes says:
> The reason that encrypted telnet is a good thing is that modification
> at the network level requires kernel modification, and encrypting a
> telnet does not.  Installing an encrypted telnet daemon does require
> sysadmin cooperation, but it doesn't mean recompiling the kernel.

Although running an encrypted IP stack does require sysadmin
cooperation, it does not require a kernel rebuild -- John Ioannidis
has built modloadable versions of most of the swIPe software.

> As such, encrypted telnet is a good intermediate while the long term
> solution of encrypted IP gets developed and deployed.

Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a
standards-compliant encrypted telnet implementation, however.

Perry

In message <9403021619.AA10508@ah.com>, Eric Hughes writes:
>The reason that encrypted telnet is a good thing is that modification
>at the network level requires kernel modification, and encrypting a
>telnet does not.  Installing an encrypted telnet daemon does require
>sysadmin cooperation, but it doesn't mean recompiling the kernel.
>
>As such, encrypted telnet is a good intermediate while the long term
>solution of encrypted IP gets developed and deployed.
>
Has anyone (other than me that is :) thought of changing just the
 library routines for setsockopt/getsockopt/send/recv ?
 It wouldnt be too hard (me thinks) to do it, but i dont know where to
 find the sockets library.
-Aggelos

-----------------------------------------------------------------------------
 Aggelos Keromitis                                       kermit@csd.uch.gr
 Heraclion, Greece                                       kermit@ics.forth.gr
            Finger kermit@calliope.ics.forth.gr for public PGP key
-----------------------------------------------------------------------------

On Wed, 2 Mar 1994, Adam Shostack wrote:

> 	I don't, but I would question the wisdom of putting lots of
> effort into a telnet encryption scheme.  I would think it would be
> much more productive to build an encryption scheme at the network
> level, say, as packets are being encapsulated, so that users can
> specify that they want an encrypted session for telnet or ftp, or even
> sendmail could encrypt automatically when sending to certain hosts.

I agree with your observation.  The Telnet protocol is however 
independent of any underlying network protocol.  In our application the 
Telnet connection can be established over a lot of different types of 
networks.  Implementing secure IP will not give us much since it does not 
cover the other possibilities for a Telnet connection.  It is also a 
question of resources (read "time") -- we require a solution *now* (and 
preferable yesterday :-)

No flame, just an observation that what seems to be a better solution is 
not always suitable...


-- Rolf



----------------------------------------------------------------------
Rolf Michelsen         Phone:  +47 73 59 87 33
SINTEF DELAB           Email:  rolf.michelsen@delab.sintef.no
7034 Trondheim         Office: C339
Norway
----------------------------------------------------------------------

The IP security program I have been working on (slowly) is a packet
redirector and cryptdec.  You ask it to encrypt packets comming in on
one socket, and pass them out to another socket (also to decrypt those
comming in on the second socket and pass them out the first socket).
Thus you can run one of these on the X server, and one on the X
client, and all the X trafic becomes encrypted over the net.  You can
telnet to the local redirector, to the forign redirector, and then to
the standard telnet port.  Or FTP, or whatever.

I am still learning about net software, and this vision may not be
easly implemented, or sockets may be the wrong level of interface to
the net, I dunno.  But I do know that my unix (SCO) and my X server
(WINDOWS) both support this stratagy.

j'

Adam Shostack <adam@bwh.harvard.edu> writes:
>
> 	A general framework, based on public key encryption would be a
> far more flexible, powerful and useful tool for generating security on
> the net than simply securing TELNET.

I sincerely doubt that such a system would be designed or implemented
before the turn of the century.  All one needs to do is take a look at the
PEM key certification authority clusterfuck to see just how difficult it
can be to implment something like this.

The additional benefits that adding encryption to telnet offer is that the
telnet protocol is used in more areas than telnet.  Many programs and
protocols use the telnet system for control channels and other bits so that
a significant change to telnet can have ramifications beyond just the
obvious ones...

jim