The Telnet Protocol

Telnet is another of the most useful tools that make up the TCP/IP protocol suite. The "remote terminal" telnet application enables you to establish an interactive logon session with a remote computer and execute commands as if you were logged directly into that remote computer. Telnet not only can be used to establish sessions with other computers, but also is embedded in many network devices, such as print servers (or HP Jet-Direct Cards), hubs, switches, and routers. Using telnet is an easy way to manage multiple network nodes ”computer or network devices ”from a central location.

However, basic implementations of telnet suffer from a similar problem that plagues FTP. It uses a clear-text method for passing user authentication information and the remaining data transfers.

The main RFC that defines basic telnet operation is RFC 854, "Telnet Protocol Specification." In addition, many additional RFC documents have been issued to add security, provide additional functionality, or further clarify the Telnet protocol.

The protocol is based on three basic concepts:

• The Network Virtual Terminal (NVT)

• Options negotiation

• A symmetric view of terminals and processes

This protocol was designed to allow interactive sessions with terminals of many types. A basic Network Virtual Terminal is defined by the telnet protocol, but clients and servers can negotiate additional parameters using options. Because either side can initiate options negotiations, the protocol is called symmetric.

What Is a Network Virtual Terminal and NVT ASCII?

Each end of the telnet connection is called a Network Virtual Terminal. It is simply a data construct that keeps track of the current state of the terminal, keeping both ends in sync. The virtual terminal operates in a bidirectional manner, sending and receiving data from another remote NVT. The basic NVT uses a 7-bit ASCII code, stored in an 8-bit byte. The high-order bit is set to zero. Carriage-return and line-feed characters are transmitted to indicate the end of a line. The method of representing characters and delineating lines is known as NVT ASCII . You'll find that many different TCP/IP utilities use this to communicate commands to and from the client and server.

Conversion to other codes can be done at each client's end. The NVT has both a virtual terminal (or printer, as it's called in the RFC) and a keyboard.

Characters that are entered on the keyboard at one end of the connection are locally echoed, and do not have to be echoed back from the remote terminal. Usually, a buffer is set aside in the host's memory to store a line of characters for transmission. The characters are transmitted when a line is complete or until some other signal (from the user, for example) causes the line to be sent.

The basic NVT is designed to be the lowest common denominator for telnet sessions. Options can be negotiated, usually more so at the beginning of a session, that change the characteristics of the basic NVT. By a process of negotiation, both sides will always have the NVT default to fall back on if the other side of the connection does not support certain options. Thus, the NVT is the basic telnet terminal, without any extra options enabled.

Upon the initial connection, both sides are basic NVTs. Usually, options will be negotiated by both sides before the user has time to begin typing. Occasionally, option changes will be requested during the later data exchanges, but the basic setup for the session is done at the beginning.

Telnet Protocol Commands and Option Negotiations

Commands for the telnet protocol are 2 or 3 bytes in length, with the first character being the interpret as command (IAC) character. This character has the ASCII value of 255. If it is necessary to actually send this character as part of the data stream, it is sent as two successive bytes of 255. Following the IAC character, another command character usually is sent. For option negotiations, a third byte is used to indicate the option code being negotiated. In Table 26.3 you can see a list of the basic telnet protocol commands, along with descriptions of their functions.

Table 26.3. Telnet Protocol Commands

Code #	Code Name	Description
240	SE	End of subnegotiation parameters.
241	NOP	No operation.
242	Data Mark	The data stream portion of a Sync. This code should be accompanied by a TCP Urgent notification.
243	BREAK	NVT character for BREAK .
244	Interrupt Process	The IP function.
245	Abort Output	The AO function.
246	Are You There	The AYT function.
247	Erase Character	The EC function.
248	Erase Line	The EL function.
249	Go Ahead	The GA signal.
250	SB	Signals that what follows is a subnegotiation of the indicated option.
251	WILL (option code)	Indicates the desire to start performing or to continue performing an option.
252	WON'T (option code)	Nonacceptance of an option or discontinuance of an option.
253	DO (option code)	Requests that the other side perform an option.
254	DON'T (option code)	Requests that the other side stop performing an option.
255	IAC	When following an initial IAC, a second character of 255 is interpreted as a data byte instead of a command.

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 events ”for 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 26.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 chapter ”refer to the appropriate RFCs.

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

Table 26.4. Additional Option Code Definitions

RFC	Option Code #	RFC Name
856		Telnet Binary Transmission
857	1	Telnet Echo Option
858	3	Telnet Suppress Go Ahead
859	5	Telnet Status Option
860	6	Telnet Timing Mark Option
726	7	Remote-Controlled Transmission and Echo
652	10	Telnet Output Carriage-Return Disposition
653	11	Telnet Output Horizontal Tabstops Options
654	12	Telnet Output Horizontal Tab Disposition
655	13	Telnet Output Formfeed Disposition
656	14	Telnet Output Vertical Tabstops Option
657	15	Telnet Output Vertical Tab Disposition
658	16	Telnet Output Linefeed Disposition
698	17	Telnet Extended ASCII Option
727	18	Telnet Logout Option
735	19	Revised Telnet Byte Macro Option
732, 1043	20	Telnet Data Entry Terminal Option: (DODIIS Implementation)
734, 736	21	Telnet SUDUP Option
749	22	Telnet SUDUP-Output Option
779	23	Telnet Send-Location
1091	24	Telnet Terminal Type Option
885	25	Telnet End of Record Option
927	26	TACACS User Identification Telnet Option
933	27	Output Marking Telnet Option
946	28	Telnet Terminal Location Number Option
1041	29	Telnet 3270 Regime Option
1053	30	Telnet X.3 PAD Option
1073	31	Telnet Window Size Option
1079	32	Telnet Terminal Speed Option
1372	33	Telnet Remote Flow Control Option
1184	34	Telnet Linemode Option
1096	35	Telnet X Display Location Option
1416	37	Telnet Authentication Option
1572	39	Telnet Environment Option
2066	42	TELNET CHARSET Option
861	255	Telnet Extended Options: List Option

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 26.5 lists these characters.

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

Value	Name	Description
	NULL	No operation.
10	LF	Line feed. Moves the NVT printer to the next line. Does not change horizontal position.
13	CR	Carriage return. Moves the printer to the left margin. Does not change vertical position.
7	BELL	Optional code. Rings a bell. Does not advance the print head by a character.
8	BS	Optional code. Backspace. Moves print head one position to the left.
9	HT	Optional code. Horizontal tab. Moves print head to the next tab stop.
11	VT	Optional code. Vertical tab. Moves print head to the next vertical tab stop.
12	FF	Optional code. Form feed. Moves printer to the top of the next page.

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 26.6 you can see some of the codes used to specify different types of authentication.

Table 26.6. RFC 2941 Telnet Authentication Methods

Value	Description
	NULL
1	Kerberos V4
2	Kerberos V5
3	SPX
4	MINK
5	SRP
6	RSA and SRA
7	SSL
8 “9	Unassigned
10	LOKI
11	SSA
12	KEA_SJ
13	KEA_SJ_INTEG
14	DSS
15	NTLM

The RFC specifies that IANA will be responsible for maintaining the numbers associated with authentication types in the future. In addition, not all of those in the table were submitted to the Internet Engineering Task Force (IETF) as a standard, so some of the values may change.