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

Header Data

From: Jim McCoy <mccoy@ccwf.cc.utexas.edu>
To: smb@research.att.com
Message Hash: 68d206941ca9c6d422a3c11de19c2e0f8f23e62912b6a4d4823e6ba3eb7c1d7a
Message ID: <199403021745.AA00455@tramp.cc.utexas.edu>
Reply To: <9403021646.AA21038@toad.com>
UTC Datetime: 1994-03-02 17:46:04 UTC
Raw Date: Wed, 2 Mar 94 09:46:04 PST

Raw message

From: Jim McCoy <mccoy@ccwf.cc.utexas.edu>
Date: Wed, 2 Mar 94 09:46:04 PST
To: smb@research.att.com
Subject: Re: low-overhead encrypted telnet
In-Reply-To: <9403021646.AA21038@toad.com>
Message-ID: <199403021745.AA00455@tramp.cc.utexas.edu>
MIME-Version: 1.0
Content-Type: text/plain


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




Thread