[2362] in Kerberos
telnet encryption option vs. Clarkson TCP
daemon@ATHENA.MIT.EDU (Alan Crosswell)
Mon Nov 9 19:15:44 1992
Date: Mon, 9 Nov 92 16:35:01 EST
From: Alan Crosswell <alan@curta.cc.columbia.edu>
To: kerberos@Athena.MIT.EDU
Hello,
I wonder if you have heard of any interoperability problems between
the Kerberized (version 4) telnetd that came with the first beta of
MIT Kerberos 5 and Clarkson TCP for the PC (CUTE-2.2TN-D).
The problem I have is the telnet session "freezes" right around the
TELOPT_ENCRYPTION (option 38) negotiation. Clarkson TCP is not
capable of doing the auth or encrypt options (boy do I wish!) so it is
just something messing up in the part where the unknown option is
supposed to be rejected. If I recompile telnetd with -UENCRYPT then
Clarkson TCP is able to get in. Other telnet clients like Unix and
Kermit can get in just fine.
Tracing the connection shows the freeze up right at this point:
> = from telnetd
< = from Clarkson TCP
> IAC Do unknown option (37)
< IAC Won't unknown option (37)
> IAC Will unknown option (38)
< IAC Will terminal type
(the above is based on a sniffer trace)
The telnet client seems to ignore the Will 38 and doesn't respond,
leaving the telnet server hanging out waiting forever for it and
therefore never continuing and forking up /bin/login.
Trying this with NCSA 2.3 succeeds although it looks like it also
never responds to the 38 (at least based on the message window; we
haven't had a chance to sniff that one yet). We unfortunately can't
just switch to NCSA 2.3 as our users need TN3270.
Thanks for any light you can shed.
/a
