From schemers@slapshot.stanford.edu Thu Oct 3 17:34:58 1996 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA16539 for ; Thu, 3 Oct 1996 17:34:58 -0400 Received: from slapshot.Stanford.EDU by MIT.EDU with SMTP id AA24080; Thu, 3 Oct 96 17:34:54 EDT Received: (from schemers@localhost) by slapshot.stanford.edu (8.7.6/8.7.3) id OAA05483; Thu, 3 Oct 1996 14:34:43 -0700 (PDT) Message-Id: <199610032134.OAA05483@slapshot.stanford.edu> Date: Thu, 3 Oct 1996 14:34:43 -0700 (PDT) From: schemers@stanford.edu To: krb5-bugs@MIT.EDU Subject: telnetd requires auth negotiation to be complete before term set >Number: 51 >Category: telnet >Synopsis: telnetd requires auth negotiation to be complete before term set >Confidential: no >Severity: serious >Priority: low >Responsible: hartmans >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Thu Oct e 17:35:01 EDT 1996 >Last-Modified: Thu Sep 13 21:33:39 EDT 2001 >Originator: schemers@stanford.edu >Organization: >Release: beta-7 >Environment: >Description: Hi. We are running the telnetd from v5b7 on our Solaris systems and noticed that our mainframe could not connect to any systems running this telnetd (I actually like this feature, but some people are complaining :-). They would connect, but the connection would immediately close. I tracked it down to telnetd/state.c: case TELOPT_TTYPE: { /* Yaaaay! */ static char terminalname[41]; if (his_state_is_wont(TELOPT_TTYPE)) /* Ignore if option disabled */ break; sb_auth_complete(); It turns out that the mainframe telnet client is sending the terminal type before authentication. I think I've also heard reports of other clients doing this as well. I realize why the sb_auth_complete() calls were added, but is there really any security problem with setting the terminal type before authentication? I couldn't think of one. Is this a policy decision or does some telnet RFC specify that the terminal type option can't be set before authentication? For now I just commented out the call (just this one, I left the others in). I was also curious if anyone else has reported problems with other telnet clients and the sb_auth_complete() calls. thanks, roland >How-To-Repeat: >Fix: >Audit-Trail: Responsible-Changed-From-To: gnats-admin->hartmans Responsible-Changed-By: hartmans Responsible-Changed-When: Thu Oct 3 23:51:33 1996 Responsible-Changed-Why: From: Sam Hartman To: schemers@stanford.edu Cc: krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: Fri, 4 Oct 1996 00:04:11 -0400 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. athena% add krb5 add krb5 athena% /mit/krb5/bin/telnet -xa /mit/krb5/bin/telnet -xa telnet> set options set options Will show option processing. telnet> open tertius open tertius Trying 18.245.0.72... Connected to tertius.MIT.EDU. Escape character is '^]'. SENT WILL AUTHENTICATION SENT DO ENCRYPT SENT WILL ENCRYPT SENT DO SUPPRESS GO AHEAD SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL NEW-ENVIRON SENT DO STATUS ... RCVD IAC SB AUTHENTICATION SEND KERBEROS_V4 CLIENT|MUTUAL KERBEROS_V4 CLIENT|ONE-WAY [ Trying KERBEROS4 ... ] SENT IAC SB AUTHENTICATION NAME "hartmans" ... RCVD WILL ENCRYPT SENT IAC SB ENCRYPT REQUEST-START SENT IAC SB ENCRYPT SUPPORT DES_CFB64 DES_OFB64 RCVD DO ENCRYPT ... RCVD WILL SUPPRESS GO AHEAD RCVD DO TERMINAL TYPE RCVD DO NAWS RCVD DO TSPEED RCVD DO LFLOW RCVD DONT LINEMODE RCVD DO NEW-ENVIRON RCVD WILL STATUS ... ... ... RCVD DO XDISPLOC SENT WONT XDISPLOC RCVD DO OLD-ENVIRON SENT WONT OLD-ENVIRON ... SENT IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK ... [ Kerberos V4 challenge successful ] RCVD IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK SENT IAC SB ENCRYPT ENC_KEYID 0 RCVD IAC SB ENCRYPT ENC_KEYID 0 SENT IAC SB ENCRYPT DEC_KEYID 0 RCVD IAC SB ENCRYPT DEC_KEYID 0 SENT IAC SB ENCRYPT START RCVD IAC SB ENCRYPT START RCVD IAC SB TERMINAL-SPEED SEND SENT IAC SB TERMINAL-SPEED IS 9600,9600 RCVD IAC SB NEW-ENVIRON SEND SENT IAC SB NEW-ENVIRON IS VAR "USER" VALUE "hartmans" VAR "PRINTER" VALUE "nil" RCVD IAC SB TERMINAL-TYPE SEND SENT IAC SB TERMINAL-TYPE IS "UNKNOWN" 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. --Sam From: schemers@stanford.edu To: Sam Hartman Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: Thu, 3 Oct 1996 22:20:31 -0700 (PDT) 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. Since the terminal type option came out before the authentication options (which looks like it did after a quick scan of the rfc index), I don't see how it could be violating any rfcs. Here is the dump from the mainframe to the un-modified v5b7 telnetd, which has debugging turned on: ommand> telnet slapshot Escape character (to suspend telnet) is 'Ctrl-]'. td: send do AUTHENTICATION td: recv do SUPPRESS GO AHEAD td: send will SUPPRESS GO AHEAD td: recv will SUPPRESS GO AHEAD td: send do SUPPRESS GO AHEAD td: recv do ECHO td: send will ECHO td: recv will TERMINAL TYPE td: send do TERMINAL TYPE td: recv wont AUTHENTICATION td: send will ENCRYPT td: send do ENCRYPT td: send do TSPEED td: send do XDISPLOC td: send do NEW-ENVIRON td: send do OLD-ENVIRON td: recv suboption TERMINAL-TYPE IS "VT100" An environment option was sent before authentication negotiation completed. This may create a security hazard. Connection dropped. Hum. The strange thing is the standard Solaris telnet client works with the telnetd: td: send do AUTHENTICATION td: recv do SUPPRESS GO AHEAD td: send will SUPPRESS GO AHEAD td: recv will TERMINAL TYPE td: send do TERMINAL TYPE td: recv will NAWS td: send do NAWS td: recv will TSPEED td: send do TSPEED td: recv will LFLOW td: send do LFLOW td: recv will LINEMODE td: send dont LINEMODE td: recv will NEW-ENVIRON td: send do NEW-ENVIRON td: recv do STATUS td: send will STATUS td: recv wont AUTHENTICATION td: send will ENCRYPT td: send do ENCRYPT td: send do XDISPLOC td: send do OLD-ENVIRON td: recv suboption NAWS 0 80 (80) 0 40 (40) td: recv dont ENCRYPT td: recv wont ENCRYPT td: recv wont XDISPLOC td: recv wont OLD-ENVIRON td: recv suboption TERMINAL-SPEED IS 9600,9600 td: recv suboption NEW-ENVIRON IS VAR "PRINTER" VALUE "bouquet" td: recv suboption TERMINAL-TYPE IS "VT100" td: send do ECHO td: recv wont ECHO td: send will ECHO UNIX(r) System V Release 4.0 (slapshot.stanford.edu) (pts/10) Ahhh.. I think I see what is going on. In looking at telentd.c, auth_negotiated=1 is set after encryption is negotiated. (I think :-) If you look at the mainframe client, it sends back the terminal type before it sends back "dont ENCRYPT". That seems to be the problem. Maybe "auth_negotiated" should be set to 1 after the server gets back "wont AUTHENTICATION"?? Is the client supposed to be sending back a "dont ENCRYPT" sooner? I'm not really sure, in any case, it seems little overly restrictive in the case of some options, like terminal type. > 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. I guess you mean (or should mean) before "auth and encrypt negotiation", as it looks like you can send that stuff after rejecting both authentication and encryption. I certainly don't claim to know telnet enough to know if the client is doing something wrong, but it looks to me like the client is behaving. thanks, roland From: "Theodore Y. Ts'o" To: Sam Hartman Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: Fri, 4 Oct 1996 09:52:28 -0400 Date: Fri, 4 Oct 1996 00:04:11 -0400 From: Sam Hartman 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. I doubt it's a violation of the RFC. We could put in a explicit words into the draft standard which defines the new telnet "I promise I will encrypt" bit. If you're not encrypting, whether you assert the telnet and environment variables before or after the authentication doesn't really matter anyway. This has the advantage that old clients who don't know about the "I promise I will encrypt bit" won't lose. - Ted From: Sam Hartman To: schemers@stanford.edu Cc: Sam Hartman , krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: 04 Oct 1996 17:51:15 -0400 >>>>> "schemers" == schemers 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 From: Sam Hartman To: "Theodore Y. Ts'o" Cc: Sam Hartman , schemers@stanford.edu, krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: 04 Oct 1996 17:59:45 -0400 >>>>> "Theodore" == "Theodore Y Ts'o" writes: Theodore> Date: Fri, 4 Oct 1996 00:04:11 -0400 From: Sam Theodore> Hartman 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 From: schemers@stanford.edu To: Sam Hartman Cc: krb5-bugs@MIT.EDU, krb5-bugs-redist@MIT.EDU Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set Date: Fri, 4 Oct 1996 15:30:37 -0700 (PDT) Sam Hartman writes: > >>>>> "schemers" == schemers writes: > 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. > Thanks, that is probably what is happening. I'll get a hold of someone who might have access to the telnet source on the mainframe. thanks, roland >Unformatted: