The Telnet Protocol

This simple command structure is used to establish a telnet session, negotiate the optional parameters, if any, and end the session. Telnet, like FTP and other client/server protocols, requires that a telnet server process listen on a well-known port, which in this case is port number 23. The server listens for incoming telnet commands from telnet clients.

Following is a short description of some of the protocol commands:

• Are You There This command is used as sort of a "keep- alive " signal. It is intended to be sent after the connection has been idle for an amount of time. The remote end should respond with some visible response.

• Erase Character Most operating systems have the capability to backspace and erase a character. Again, telnet uses a common command for this function, because not all operating systems support it or use the same numerical code for this function.

• Erase Line This is similar to the Erase Character command, but it instead maps the local keyboard's command sequence or key used to erase a line to a command that can be passed to the remote side of a connection.

• Interrupt Process This command is used to map to the typical Ctrl+C or other character sequence used on a local machine to interrupt a process. This can differ from one computer operating system to another, hence the need for a common code to pass this condition to the other end of the connection.

• Data Mark This command is sent as part of a TCP Urgent segment and is notice to the receiving end that it should look for "interesting" characters (such as IP, AO, and AYT) in the data stream. This causes an immediate action. The TCP Urgent message followed by a DM also is called a telnet sync operation. This allows out-of- band communications for important eventsfor example, an IP that results from a user entering Ctrl+C.

Options and Negotiations

The standard NVT described in RFC 854 might not be sufficient for all situations, and thus the telnet protocol allows for a process of negotiation of options. This allows for additional capabilities and services to be provided using telnet. For example, an option could be used to provide for a different character set than the standard. Either side of the telnet session can send a request to the other side for an option. The receiving end can then reply with either an acceptance or a rejection of the option. If an option is accepted, it takes effect at once.

The following are some basic rules of the negotiation process:

• Option requests are sent only to change an option. If the option is already in effect, sending out a request for the option simply to announce that it is being used is not permitted.

• Similar to the preceding rule, an option request for an option that is already in effect should not be acknowledged .

• In addition, if one side sends a request to disable an option, that request must be honored.

In Table 25.3, the DO , DON'T , WILL , and WON'T operations are used when one side of the connection wants to do something and inform the other side, or when one side wants the other side to perform an action. For example, when an NVT receives a WILL command followed by an option code, it means that the sender will start, or has started, using this option. The receiver of this message can reply with a DO if the option is acceptable or a DON'T if it doesn't support the option. If the sender sends a DO command, followed by an option, then the sender is telling the receiver that it would like for it to use a particular option. The receiver can respond with a WILL command if it does support the option, or a WON'T command if it does not.

In addition, a sender can send a WON'T command, which indicates that a particular option is disabled. The receiver should respond with a DON'T command. The sender also can send a DON'T command to indicate that it wants the receiver to disable an option. The response to this command must be a WON'T . Remember that an option cannot be used unless both sides agree to it. Instead, the basic NVT is used with any options that were negotiated.

Finally, some options will lead to subnegotiations to further identify parameters of a particular option. These are beyond the scope of this chapterrefer to the appropriate RFCs.

In Table 25.4, you can see a summary of RFCs that describe some of the more useful options for use with telnet.

Table 25.4. Additional Option Code Definitions

In addition to this summary of options, others exist that are defined in documents other than RFCs. In addition to the basic telnet commands, telnet recognizes some, but not all, of the special ASCII control code characters. Table 25.5 lists these characters.

Table 25.5. ASCII Control Characters Recognized by Telnet's NVT

Telnet and Authentication

One of the problems with applications that were developed during the early years of TCP/IP is that Internet (or ARPANET, depending on how far back you want to go) security wasn't as big an issue as it is today. Because of this, many protocols and utilities have been exploited over the past few years by hackers who know how to take advantage of this lack of foresight. Telnet is just such an application. However, with the use of options, it is possible to perform authentication using other than the traditional clear-text method.

In RFC 2941, "Telnet Authentication Option," an option to allow for more secure authentication methods, is set forth. This specification is intended to provide a mechanism that can be used by many authentication methods . The code number used for the AUTHENTICATION option is defined as 37. In Table 25.6 you can see some of the codes used to specify different types of authentication.

Table 25.6. RFC 2941 Telnet Authentication Methods