[5658] in Kerberos
Re: Krb 5.5 Encrypted Login Sessions
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Aug 10 18:11:50 1995
Date: Thu, 10 Aug 1995 17:58:16 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: ramus@nersc.gov
Cc: Rita.Bettenhausen@quickmail.llnl.gov, hartmans@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: Joe Ramus's message of Wed, 9 Aug 95 17:36:43 PDT,
<9508100036.AA23609@windsail.nersc.gov>
OK, let me explain what's going on. The current telnet encryption
option is seriously flawed in that it's succeptible to an on-line
attack. (Although to be fair, most of the diffie-helman "quick-fix"
encrypting telnet solutions which are floating around too. Of course,
Kerberos is supposed to be a lot better than the "quick-fix" solutions,
too. :-)
The problem is that the request to turn on encryption is not actually
protected. What this means is that if you can hijack a TCP connection
(read: if you have a copy of the toolkit which Mitnick stole from LLNL)
it is possible to stop the request to turn on encryption from reaching
the server, and then send a message down the telnet stream to the client
saying "[Encryption Enabled]" and the user will be totally faked out.
The user might think that encryption has been enabled, but in fact it
has not been. This is bad.
For this reason, the Telnet Encryption option has not been published as
an RFC by the Internet Engineering Task Force, pending someone being
able to actually fix this as a problem. Similarily, work to define the
Kerberos V5 encryption option has also been stopped until this can
happen. At MIT, we are committed to working within the framework of the
Internet Engineering Task Force, and producing interoperable standards
which are appropriately documented as an RFC.
For this reason, I have chosen *not* to put any serious effort into
making -DENCRYPTION work in the telnet package for Kerberos V5 because
(a) it would take resouces that would be better spent trying to get the
1.0 release of Kerberos V5 out the door, (b) it gives users a
potentially false sense of security, and (c) the result would likely be
incompatible with the final Telnet Encryption Standard involving DES and
Kerberos V5.
If people want to work on patches that get some sort of kludgy
encryption option working, that's up to them. However, please don't be
surprised if it fails to interoperate with final, official IETF protocol
standard.
- Ted
