Re: low-overhead encrypted telnet

Eric Hughes says:
	 > The reason that encrypted telnet is a good thing is that modificatio
	n
	 > 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.

Assuming, of course, that you're running a system that has modload.
(Ironically, CERT has recommended that you delete loadable device drivers
from systems that don't need them, as a way to guard against password-
sniffers.)

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

What standards?  There are no RFCs, nor any current drafts, that define
a telnet encryption option.  The last draft I saw was from 1991, and
Internet drafts expire after 6 months.  As I recall, the idea that was
being pushed then was to integrate encryption more closely with
authentication.

smb@research.att.com says:
> 	 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.
> 
> Assuming, of course, that you're running a system that has modload.
> (Ironically, CERT has recommended that you delete loadable device drivers
> from systems that don't need them, as a way to guard against password-
> sniffers.)

A short sighted view. You can't stop line monitoring -- you should
defend against it with encryption instead. In an environment like
mine, there are literally thousands of potential line monitoring
points that I cannot defend, but encryption gives me real security.

Perry

smb@research.att.com writes:
> 
> 	 Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a
> 	 standards-compliant encrypted telnet implementation, however.
> 
> What standards?  There are no RFCs, nor any current drafts, that define
> a telnet encryption option.  The last draft I saw was from 1991, and
> Internet drafts expire after 6 months.  As I recall, the idea that was
> being pushed then was to integrate encryption more closely with
> authentication.

There is currently a chunk of code in the standard 4.3/4 telnet ref
implementation that does encryption (DES in OFB, CFB, and ECB modes)
It is a part of the AUTH-ENCRYPT module that is part of the telnet option
specifications. 

There is work being done by the AUTH-ENCRYPT working group to try to get
authorization tied more closely to the encryption options (last I heard
they were slowing down and had hit a problem exchanging IVs for the
encryption.)  This work is using authorization methods (Kerberos, SPC, RSA)
to drop in the key for the encryption.

There is work being done by the IPSEC working group to add encryption to
the IP layer of the protocol stack (telnet et al work at higher levels) but
I have not read anything recent from this group in a while and last I
checked they were still hashing out design details so I would not expect
anything on this front for a while.

There are a couple of people in Austin who have a version of the telnet
ref implementation that will do a D-H exchange of 688 bits which can then
be used by the ENCRYPT option and are trying to figure out which direction
the AUTH-ENCRYPT people are going so that they can make the DHX option fit
in seamlessly with the AUTH-ENC stuff (the DHX exchange tries to be first
and start up an encrypted stream and if the AUTH-ENC option is invoked
after the DHX exchange we want to switch to the new key without
disruption.)  Unfortunately 1994 has been a busy year, but hopefully there
will be an alpha or beta for CPs to test next week...

jim