Ticket History #51: telnetd requires auth negotiation to be complete before term set

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 <bugs@RT-11.MIT.EDU>; 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

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



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 <hartmans@MIT.EDU>
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
set options
Will show option processing.
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 <hartmans@MIT.EDU>
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:

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:

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.


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" <tytso@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
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 <hartmans@MIT.EDU>

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 <hartmans@MIT.EDU>
To: schemers@stanford.edu
Cc: Sam Hartman <hartmans@MIT.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:51:15 -0400




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.


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.


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.


Perhaps. I'll think about any possible consiquenceso of
proposed solutions.



Correct.


From: Sam Hartman <hartmans@MIT.EDU>
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
Subject: Re: telnet/51: telnetd requires auth negotiation to be complete before term set
Date: 04 Oct 1996 17:59:45 -0400




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?


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.


I supose I could take an alternate approach to solve this and
refuse encryption once I had received a sensitive option.



From: schemers@stanford.edu
To: Sam Hartman <hartmans@MIT.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 15:30:37 -0700 (PDT)

Sam Hartman writes:

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