Subject: Telnet Encryption Specification

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 3 Feb 1998 16:26:36 -0500

Well, after a five year hiatus, I'm trying to get the Telnet Encryption
specifications finally published as RFC's.  It's been too long, and in
the mean time, we have a number of interoperable implementations, so we
should really document the protocol.

For example, the Kerberos V5 telnet authentication/encryption is
implemented in both the the MIT release of Kerberos, as well as in the
Cisco IOS software.  The latter was implemented due to operational
pressures a year or two ago; attackers were targeting high-value assets
in the global Internet infrastructure, and attacking them with TCP
hijacking programs.  This prevented a number of large ISP's from being
able to remotely manage their routers (which is a nice touch if you run
a global Internet backbone :-).  

Up until now, though, unless you count the sources in the MIT Kerberos
V5 1.0 release :-), the protocol that was used was never documented.

I've just sent five documents to the Internet-Drafts directory: a
revised Telnet Authentication Option document (to replace the
experimental-track RFC 1416), a Telnet Encryption Option document, two
DES cipher algorithm documents, and the Kerberos V5 telnet
authentication specification document.  

You can see the drafts by going to this URL:

	http://web.mit.edu/tytso/www/telnet/

Comments can go to me, or if people don't mind my using the old telnet
working group list (after all, these drafts were orginated out of the
telent wg lo these many years ago), to [email-masked].

							- Ted

---

From: Michael Boe <[email-masked]>
Date: Tue, 3 Feb 1998 14:41:24 -0800 (PST)

Ted,

Things being what they are, you and I will probably need to get together. I've
currently have a Telnet over TLS I-D in circulation (see
draft-ietf-tn3270e-telnet-tls-00.txt).

The proposed TLS/SSL mechanism doesn't use the RFC1416 style because that (a)
the TLS negotiation mechanism can't be shoehorned into the RFC1416-style (it
happens strictly at the binary level), and (b) TLS is really
encryption-then-optional-authentication but RFC1416 is really
authentication-then-maybe-encryption.  To summarize, the two don't mesh all
that well.

However, there's some overlap, particularly in the authentication area. I'd be
interested to here your thoughts in this area.

/msb

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 03 Feb 1998 19:24:26 -0500

>telent wg lo these many years ago), to [email-masked].

Wow, just in time ... I just saw a internet draft submitted a couple
of days ago suggesting the ditching of the AUTHENTICATE option and
using SASL (because, according to the draft author, the AUTHENTICATE
option is only used for Kerberos 4 :-/).

Comments:

Mark Eichin made a cryptic comment a little while ago that the
current CFB encryption mode used by the V5 telnet (the fact that
it just XOR's your plaintext against the encryption stream to get
the output) opens you up to an attack.  I confess that I didn't
quite understand what he was talking about, but someone smarter
than me (perhaps Mark himself) should look at this and possibly
propose a new encryption option that fixes this problem.

And while we're at it .... why not define an encryption mode for
3DES?  It'll save you the trouble of writing a new RFC later :-)

--Ken

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 4 Feb 1998 00:42:00 -0500

Date: Tue, 03 Feb 1998 19:24:26 -0500
   From: Ken Hornstein <[email-masked]>

This certainly is true of OFB, which merely runs DES in a feedback loop
and then XOR's your plaintext against the resulting "pad".  If you'll
note, I added a "security considerations" paragraph about why this is
weak, and noting that perhaps in this day and age, maybe we should drop
it.

In cipher feedback mode, though, it's more than a simple XOR plaintext
against an encryption stream.  CFB looks like this:

    key --->+-----+
         +->| DES |--+
         |  +-----+  |
	 |           v
 INPUT --(--------->(+)+---> DATA
         |             |
	 +-------------+

Given that you're still doing an XOR with the data, it's possible to do
a known-plaintext substitution attack --- if you know what the stream
is, you can diddle bits in the cipher text to cause text of your choice
to come out the other end.  This attack only works for bytes in a single
eight bytes chunk, though, since the result of the next eight bytes of
decryption will be garbaged as a result.  So while this is a real
weakness, the fact that the following eight bytes of data get garbaged
generally means that the attack can get noticed, but that of course is
no guarantee.

The fix for this would be to use CBC(*), but that has the down side of
being slower and requiring more bytes on the wire, since telnet is a
character-at-a-time protocol, and CBC requiers that you block data into
8 byte chunks.  (The advantage of CFB and OFB is that they work well
with streaming protocols.)

It would certainly be possible to write a specification for DES-CBC.
Volunteers to help out in writing a DES-CBC mode or a 3DES-CBC mode
would be greatfully received.  :-)  If you're interested, let me know...

					- Ted

(*) Note: Cryptographers would say that even using CBC isn't the best
way to protect against this; DES provides data confidentiality; data
integrity is a completely different service, and if you want data
integrity, you should be using a message authentication code service
instead.  Unfortunately, this is even more painful for streaming
applications like telnet.  You can do it, but the overhead hit starts
getting fairly high.

---

From: Marc Horowitz <[email-masked]>
Date: 04 Feb 1998 01:06:00 -0500

>> with streaming protocols.)

Just as a point of reference, I regularly use ssh (which has quite a
bit of overhead) for interactive traffic over a modem, and I can't
detect any difference in latency over a non-protected connection.  I
think the days where we need to worry about the extra overhead are
also over.

		Marc

---

From: Russ Housley <[email-masked]>
Date: Wed, 04 Feb 1998 22:04:21 -0500

Ted & Michael:

I would like to be involved in any discussions you have on this topic.

Russ