1994-03-02 - Re: low-overhead encrypted telnet

Header Data

From: smb@research.att.com
To: pmetzger@lehman.com
Message Hash: ea8c22d0b89afc9fa763eb3a2dfbde21ccc0f53f3809cea8601ad5602e802267
Message ID: <9403021646.AA21038@toad.com>
Reply To: N/A
UTC Datetime: 1994-03-02 16:46:23 UTC
Raw Date: Wed, 2 Mar 94 08:46:23 PST

Raw message

From: smb@research.att.com
Date: Wed, 2 Mar 94 08:46:23 PST
To: pmetzger@lehman.com
Subject: Re: low-overhead encrypted telnet
Message-ID: <9403021646.AA21038@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


	 
	 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.





Thread