[2293] in Kerberos-V5-bugs
Re: telnet/51: telnetd requires auth negotiation to be complete before term set
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Oct 4 18:01:15 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, schemers@stanford.edu, krb5-bugs@MIT.EDU,
krb5-bugs-redist@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 04 Oct 1996 17:59:45 -0400
In-Reply-To: "Theodore Y. Ts'o"'s message of Fri, 4 Oct 1996 09:52:28 -0400
>>>>> "Theodore" == "Theodore Y Ts'o" <tytso@MIT.EDU> writes:
Theodore> Date: Fri, 4 Oct 1996 00:04:11 -0400 From: Sam
Theodore> Hartman <hartmans@MIT.EDU>
Theodore> However, as demonstrated by the following dump of
Theodore> telnet options, the client generally does not send the
Theodore> terminal type until prompted by the server. I suspect
Theodore> your mainframe is violating the spec in this respect but
Theodore> would have to ponder the appropriate RFCs for a while to
Theodore> be sure.
Theodore> I doubt it's a violation of the RFC. We could put in a
Theodore> explicit words into the draft standard which defines the
Theodore> new telnet "I promise I will encrypt" bit.
This would be useful. Basically, a server needs to be able to
(and should be required to) reject sensative options until it knows
whether the client will encrypt. If the server accepts a sensitive
option, it cannot then accept encryption.
Sensitive options should include X display, and both
environment options. They may also include things like terminal type,
terminal speed, etc. Also, future options like those needed for
rsh-style error redirection will almost certainly be sensitive.
As a side note, what convinced you that our current approach
is better to standardize on than Galvin's authencrypt option?
Theodore> If you're
Theodore> not encrypting, whether you assert the telnet and
Theodore> environment variables before or after the authentication
Theodore> doesn't really matter anyway.
True, if you have a client that supports the encryption
promised bit or if you know for other reasons that the client will
never encrypt.
Theodore> This has the advantage that old clients who don't know
Theodore> about the "I promise I will encrypt bit" won't lose.
I supose I could take an alternate approach to solve this and
refuse encryption once I had received a sensitive option.
Theodore> - Ted
