TELNET FUNCTIONALITY FOR C-KERMIT 7.0 AND KERMIT 95 1.1.19 Jeffrey Altman The Kermit Project Columbia University Most recent update: Tue Jan 30, 2000 CONTENTS 1. INTRODUCTION 2. SUPPORTED TELNET OPTIONS 3. TELNET OPTION MANAGEMENT 4. TELNET COMMAND SUMMARY 5. DIAGNOSING AND FIXING PROBLEMS CONNECTING TO TELNET SERVERS 1. INTRODUCTION The Telnet protocol is one of the original protocols developed for the ARPAnet, the precursor to today's Internet. Telnet has evolved since the early 1970s due to the extensibility provided by its "option" model. To quote RFC854: "The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation)." Not so long ago the requirements for a Telnet client were fairly minimal: support echo management, window size notification, terminal type negotiation, and perhaps the transmission of environment variables from the client to the server. Option negotiations were not time sensitive nor were they interdependent. Everyone was happy as long as each option specification was followed and infinite negotiation loops were avoided. This simplicity began to change with the introduction of telnet options that provide for mutual authentication, data encryption, transport layer security, and synchronization of remote processes. The new options have order and timing dependencies that require increased sophistication from both client and server even though the original Telnet protocol specification did not change. Prior to C-Kermit 7.0 and K95 1.1.18, Kermit implemented Telnet protocol by opening a connection to the host and then transmitting the options that it supported. What happened next was determined by how the connection was being used. If the user told Kermit to: TELNET then, immediately after the telnet options were transmitted, the terminal emulator started and began reading the incoming data. The rest of the Telnet protocol implementation was purely reactive (with minor exceptions such as window-size changes): when a Telnet option was received it would be processed and a response sent if necessary. However, if the user said: SET HOST then, after the telnet options were transmitted, Kermit would wait for the next command from the user. If a CONNECT command was next the behavior would be the same as for TELNET . However, if Kermit was executing a script containing a series of INPUT and OUTPUT commands, the incoming telnet option negotiations would be processed while waiting for INPUT. This was adequate when there were no ordering or timing requirements for the Telnet negotiations. But with the introduction of authentication, encryption, transport-layer security, and the Kermit option for managing the states of the Kermit server on both the workstation and host (see iksd.txt), it is necessary for Telnet negotiations to take place before the TELNET command enters the terminal emulator or the SET HOST command completes and allows any subsequent INPUT and OUTPUT commands to execute. The timing requirements for the telnet options supported by Kermit are as follows: . START_TLS (Transport Layer Security) must be negotiated or refused before any other option. . AUTH (Authentication) must be negotiated or refused before ENCRYPT. AUTH must also be negotiated before the login process is initiated. . ENCRYPT (Encryption) must be negotiated/refused in both directions before it is safe to transmit any data that might be considered private, including Telnet options such as terminal type, location, xdisplay, or environment variables. ENCRYPT may not be negotiated if START_TLS has been negotiated or if AUTH has not been. . KERMIT (Internet Kermit Service) must wait for a response to any request for the peer to either turn on or off the Kermit Server capabilities in order to facilitate automatic uploading or downloading of files or processing of remote commands. . NEW_ENV (Transmission of Environment Variables to the Host) must be negotiated before the login process is initiated if the USER variable is to be requested from the client. The result is that Kermit must, to the best of its ability, attempt to process all of the above options before TELNET enters CONNECT mode or SET HOST completes to process the next command. Therefore it might take Kermit longer to make a connection to a host than before. The reality is actually far different. Even if the CONNECT mode or first INPUT command was executed sooner no user data could be received until the Telnet negotiations were complete. In addition, the timing of the initial INPUT command used to require that the length of time it takes to process the Telnet negotiations be factored in. This is no longer necessary and was inappropriate in the first place. A login script should not have to be modified for different connection types; the telnet negotiations should be transparent to the script. In C-Kermit 7.0 and Kermit 95 1.1.18 they are. 2. SUPPORTED TELNET OPTIONS BINARY (Binary Transmission Mode) [RFC 856] When a telnet session is initiated, the connection is in Network Virtual Terminal (NVT) mode. NVT mode provides for special treatment of the carriage return (CR) control character to provide for deterministic parsing of the input stream. Every CR that is transmitted must be followed by a line feed (LF) control character or a NUL control character. This enables an NVT to distiguish between the Carriage Return function and the End of Line indicator. This works fine for textual data. But in transmission of random binary data there is the possibility that the sequence CR NUL might be misinterpreted. Binary mode removes the ambiguity by removing the requirement that CR be followed by either LF or NUL. It is negotiatied separately in each direction of data transmission. Binary transmission mode is not required for transferring files with Kermit protocol but it might be required when transfering files with Xmodem, Ymodem, or Zmodem. Binary mode is one of the most frequently misimplemented telnet options. Many implementation will negotiate Binary mode in only one direction but apply it in both. Kermit provides workarounds for these problems with its SET TELNET BUG BINARY-ME-MEANS-U-TOO and SET TELNET BUG BINARY-U-MEANS-ME-TOO commands. Kermit also provides the SET TELNET BINARY-TRANSFER-MODE command to automatically enter binary mode at the start of a file transfer and return to NVT mode when the transfer is completed. ECHO (Echo Mode) [RFC 857] When a telnet session is initiated, data is not echoed by the receiver. This means that a telnet client must echo each character locally as it is being sent to the host. While this reduces network traffic it can cause problems with terminal emulation and echoing of sensitive data. The echo option allows the each side to specify that it intends to echo the data that it receives. Normally this would be used to negotiate that the server should echo the data it receives from the client. While it is possible for the client to state that it will echo the data received from the server this makes no sense and if negotiatied could result in an infinite loop of a single character being echoed back and forth. As a piece of telnet trivia, the BSD 4.2 telnet client would echo incoming data sent by the server if the host requested it. Kermit will always respond WONT ECHO to a DO ECHO request when it is the client. SUPPRESS GO AHEAD (Suppress Go Ahead commands) [RFC 858] When a telnet session is initiated, all data transmitted by the sender is to be followed by a Go Ahead (GA) command sequence. This is to enable telnet to be used over half-duplex (two-way alternate) connections, and it gives the telnet partner permission to transmit. But to our knowledge, all telnet sessions used over the Internet are full duplex connections. The Suppress Go Ahead (SGA) option is negotiated in both directions to suppress the transmission of the GA commands and treat the connection as full duplex (two-way simultaneous). LOGOUT (Logout user from host) [RFC 727] Some operating systems such as VMS support the notion of a login session that can continue across separate telnet connections. If a telnet connection is prematurely interrupted by a network failure, the user may reconnect to a pre-existing session on their next login attempt. The Telnet Logout option is sent by the telnet client just before the tcp/ip socket is closed to indicate to the host that the connection is being intentionally terminated by the user and is not being closed due to a network error. SEND LOCATION (Send Terminal Location) [RFC 779] The Send Location option provides the host with a method for requesting the location of the telnet client. When a location string has been specified with the SET TELNET LOCATION command, Kermit transmits this string to the host upon request. TERMINAL TYPE (Negotiate Terminal Type) [RFC 1091] The Terminal Type option allows the client and server to agree to a common terminal type that they both support. C-Kermit reports the value of the local TERM environment variable. Since Kermit 95 supports more than 30 terminal types, it continues to offer additional terminal tyeps to the host until the host accepts one. NAWS (Negotiate About Window Size) [RFC 1073] The Negotiate About Windows Size (NAWS) lets the client report its current Window size to the host. Every time the client's window size changes, the new size is reported to the host automatically. It is not possible for the host to report a window size to the client. XDISPLOC (Report X Window Display location) [RFC 1096] The X Windows display option is used to report to the host the address of the local X Windows Server. Kermit sends the contents of the local DISPLAY environment variable or the string specified by the SET TELNET ENVIRONMENT DISPLAY command. AUTHENTICATION (Authenticate end user to host) [Internet-Draft] The AUTHENTICATION option is used to determine which if any authentication method such as Kerberos 4, Kerberos 5, Secure Remote Password, etc, should be used to authenticate the user to the host. ENCRYPTION (Encrypt session) [Internet-Draft] The ENCRYPTION option is used in conjunction with the AUTHENTICATE option to encrypt all the data transmitted during the session. The ENCRYPTION option must be negotiated separately in each direction. NEW ENVIRONMENT (Report Environment to host) [RFC 1572] The NEW ENVIRONMENT option is used by the client to reply to requests from the server for either all or specified environment variables such as DISPLAY, USERNAME, ACCOUNT, JOB, PRINTER, and SYSTEMTYPE. When the NEW ENVIRONMENT option is used to transmit the username, many telnet servers skip their login or username prompt and go directly to the password prompt. START TLS (Transmit Telnet over TLS) [Internet-Draft] The START TLS option is used by the client and server to determine whether the telnet session should be restarted after first establishing a TLSv1 session. TLS provides strong encryption and optionally authenticates the client and the server using X.509 certificates. START_TLS can be used with the AUTHENTICATE option. When negotiatied START_TLS replaces the ENCRYPTION option. KERMIT (Synchronize Kermit File Transfers) [Internet-Draft] The Kermit option (invented by the Kermit Project) is designed to allow a Kermit file-transfer client and a Kermit server to synchronize their operations. This allows a change in "mode" of the server to automatically switch the client into the complementary mode, and vice versa. FORWARD X (Transmit X Windows data over Telnet) [Internet-Draft] The FORWARD X option (invented by the Kermit Project) allows the telnet server to redirect all output from X Windows clients and transmit it across to telnet connection. The telnet client then forwards the data to the local X Windows server. When the telnet connection is encrypted, both the telnet data and X Windows session data are protected. 3. TELNET OPTION MANAGEMENT One of the benefits of processing all the Telnet options during the SET HOST and TELNET commands is that it is now possible to configure policy requirements for a valid connection. This capability is necessary when the connection must be secure (authenticated and encrypted) or else fail. Policies are specified with the new command: SET TELOPT [ ]