home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.kerberos
- Path: sparky!uunet!stanford.edu!CURTA.CC.COLUMBIA.EDU!alan
- From: alan@CURTA.CC.COLUMBIA.EDU (Alan Crosswell)
- Subject: telnet encryption option vs. Clarkson TCP
- Message-ID: <CMM.0.90.0.721344901.alan@curta.cc.columbia.edu>
- Sender: news@shelby.stanford.edu (USENET News System)
- Organization: Internet-USENET Gateway at Stanford University
- Date: Mon, 9 Nov 1992 21:35:01 GMT
- Lines: 38
-
- 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
-
-