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
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.
Return to March 1994
Return to “smb@research.att.com”