[2281] in Kerberos-V5-bugs
pending/51: telnetd...
daemon@ATHENA.MIT.EDU (schemers@stanford.edu)
Thu Oct 3 17:35:30 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: gnats-admin@rt-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, schemers@stanford.edu
Date: Thu, 3 Oct 1996 14:34:43 -0700 (PDT)
From: schemers@stanford.edu
To: krb5-bugs@MIT.EDU
>Number: 51
>Category: pending
>Synopsis: telnetd...
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Oct e 17:35:01 EDT 1996
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
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
