Telnet encryption

Richard Basch <> Fri, 09 February 1996 02:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa28412; 8 Feb 96 21:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28408; 8 Feb 96 21:33 EST
Received: from by CNRI.Reston.VA.US id aa17499; 8 Feb 96 21:33 EST
Received: from ( []) by (8.6.12/CRI-gate-8-2.11) with ESMTP id UAA23638; Thu, 8 Feb 1996 20:27:20 -0600
Received: (from daemon@localhost) by (8.6.12/CRI-ccm_serv-8-2.8) id UAA27488 for telnet-ietf_list@sdiv; Thu, 8 Feb 1996 20:24:55 -0600
Received: from (root@t2 []) by (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id UAA27485 for <>; Thu, 8 Feb 1996 20:24:54 -0600
Received: from ( []) by (8.6.12/craymail-smart) with ESMTP id UAA16444 for <>; Thu, 8 Feb 1996 20:24:54 -0600
Received: from lehman.Lehman.COM (Lehman.COM []) by (8.6.12/CRI-gate-8-2.11) with ESMTP id UAA23292 for <>; Thu, 8 Feb 1996 20:24:47 -0600
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id VAA05352 for <>; Thu, 8 Feb 1996 21:24:21 -0500
Received: from by lehman via smap (V1.3) id tmp005327; Thu Feb 8 21:23:50 1996
Received: from by (4.1/LB-0.6) id AA03189; Thu, 8 Feb 96 21:23:49 EST
Received: from by (4.1/Lehman Bros. V1.6) id AA12121; Thu, 8 Feb 96 21:23:49 EST
Received: by (SMI-8.6/Lehman Bros. V1.5) id VAA06128; Thu, 8 Feb 1996 21:23:48 -0500
Message-Id: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Richard Basch <>
Subject: Telnet encryption
Date: Thu, 8 Feb 1996 12:31:11 -0500

I have been side-tracked from my work on Telnet Encryption that I was
going to try to fold into Kerberos V5 and propose to this group...

Essentially, I view the existing "encryption" option draft as adequate,
other than I disagree that DES OFB mode should be supported by default.
I understand that it was basically included for the slower PC-class
machines, such as low-end Macintosh or Intel 8086 machines.

And before anyone comments that the encryption option is subject to
active attack, I recognize that danger, too.  However, encryption and
authentication are orthogonal, and many different encryption algorithms
could be employed, including Diffie-Hellman (which offers no
authentication).  In some cases, it may employ the keys that were
negotiated during the authentication option, but a combined option
should not be designed that inhibits the use of encryption without

Additionally, there are other options that someone could actively
attack, such as suppressing the "disable echo", thereby causing
passwords to be displayed on the local screen.  For this reason, I
propose an extension to the authentication option that allows one to
encapsulate another option.  We can add this OPTION_INTEGRITY_SUPPORT as
another bitflag for the authentication-type list.  If the other side
supports it, we can use this to protect such options as ENCRYPTION or
ECHO, or whatever else is deemed necessary.

What do people think of this?  I have several pieces of paper filled
with chicken-scrawls of various ways of implementing such a solution,
and I think we should look at some of these alternatives, rather than
simply combining two orthogonal concepts (encryption and authentication)
into one option.
Richard Basch                   
Sr. Developer/Analyst           URL:
Lehman Brothers, Inc.           Email:,
101 Hudson St., 33rd Floor      Fax:   +1-201-524-5828
Jersey City, NJ 07302-3988      Voice: +1-201-524-5049