[2292] 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 17:51:57 1996
To: schemers@stanford.edu
Cc: Sam Hartman <hartmans@MIT.EDU>, krb5-bugs@MIT.EDU,
krb5-bugs-redist@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 04 Oct 1996 17:51:15 -0400
In-Reply-To: schemers@stanford.edu's message of Thu, 3 Oct 1996 22:20:31 -0700 (PDT)
>>>>> "schemers" == schemers <schemers@stanford.edu> writes:
schemers> Sam Hartman writes:
>> The policy decision was made because no session state should
>> be established before authentication. In the case of term, I
>> cannot think of any case where it creates a security problem,
>> but in other cases it does create a security problem.
>>
>> However, as demonstrated by the following dump of telnet
>> options, the client generally does not send the terminal type
>> until prompted by the server. I suspect your mainframe is
>> violating the spec in this respect but would have to ponder the
>> appropriate RFCs for a while to be sure.
schemers> Since the terminal type option came out before the
schemers> authentication options (which looks like it did after a
schemers> quick scan of the rfc index), I don't see how it could
schemers> be violating any rfcs.
Sorry; I meant that it was violating RFCs by sending the
terminal type before the server sent the IAC SB terminal type SEND
command. See below.
schemers> Hum. The strange thing is the standard Solaris telnet
schemers> client works with the telnetd:
I think the difference you don't see here is that your debug
only includes will/won't/do/don't options, not subcommands.
Quoting from RFC1091:
Once the two hosts have exchanged a WILL and a DO, the sender of the
DO TERMINAL-TYPE (the server) is free to request type information.
Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
and only the client may transmit actual type information (within an
IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type
information may not be sent spontaneously, but only in response to a
request.
I suspect that your mainframe is spontaniously sending the
terminal type info. At any rate, I don't think our telnetd will ever
request that the client send terminal type until after authentication
negotiation is complete.
schemers> Ahhh.. I think I see what is going on. In looking at
schemers> telentd.c, auth_negotiated=1 is set after encryption is
schemers> negotiated. (I think :-) If you look at the mainframe
schemers> client, it sends back the terminal type before it sends
schemers> back "dont ENCRYPT". That seems to be the problem.
schemers> Maybe "auth_negotiated" should be set to 1 after the
schemers> server gets back "wont AUTHENTICATION"??
This is reasonable so long as you accept the won't encrypt
when it comes in. It's important to note that once you have ended
authentication negotiation, you cannot accept a will authentication or
a will encrypt without carefully examining intervening options.
schemers> Is the client
schemers> supposed to be sending back a "dont ENCRYPT" sooner? I'm
schemers> not really sure, in any case, it seems little overly
schemers> restrictive in the case of some options, like terminal
schemers> type.
Perhaps. I'll think about any possible consiquenceso of
proposed solutions.
>> Because I don't see a security issue involved in terminal type
>> being sent before authentication, I can probably be convinced
>> to remove the check from the MIT tree. However, I am somewhat
>> reluctant to do so because I do believe the client is behaving
>> improperly, and there really is no good reason to do session
>> parameter negotiation before authentication and encryption.
schemers> I guess you mean (or should mean) before "auth and
schemers> encrypt negotiation", as it looks like you can send that
schemers> stuff after rejecting both authentication and
schemers> encryption.
Correct.
schemers> thanks, roland
