Wednesday, December 13, 2006

BH #1 - Telnet Protocol Explained

The Telnet Protocol Explained

Go into a computer store, and ask any family shopping for a computer if they know what telnet is. Chaces are, they'll just look at you and scratch their heads. It's sad really. Most of the people who know about it are old school, or fellow computer enthusiasts. This first paragraph is for those who don't have a clue. So skip it if you already know what I'm talking about. First of all, let me say this. There is a difference in the telnet protocol, and an application called telnet that uses the telnet protocol. In this article, When I say telnet I am refering to the protocol unless otherwise stated.

The telnet protocol was developed in the late 1960's. Back then, computers were huge, filling entire rooms. To connect to it, you had to run a dedicated data circuit from the comptuer to the users dumb terminal. (a dumb terminal is pretty much just a monitor and a keyboard. it displays what is sent to it, and sends what you type) But what if you wanted to connect to a computer in another building? Or needed to access several systems? This is why the telnet protocol was developed. It allowed computers to be placed on a TCP/IP network, and the users could telnet to any computer on the network. This saved time, money, and other various resources. This protocol was one of the first that was demonstrated on ARPANET in 1969. The first RFC wich covered the protocol was RFC 97. (an RFC is a "Request For Comments" document. These documents are used by various agencies. such as ICANN and IANA, to form internet standards.) The final version of the standard was published in RFC 854 in May of 1983. There are also a number of other RFC's wich cover many of the telnet options. (do a web search if you wish to read the RFC's)

The telnet protocol is built upon three basic concepts. They are The Network Virtual Terminal (NVT), options and option negotiation, and symetric operation. Think of the NVT as a fictional computer. All data sent must be sent according to it's format. This ensures that no matter what operating system your computer uses, any data recieved using the telnet protocol will be in the same format, no matter what. (assuming the programmer of the application follows the standard, but more on that later) The telnet protocol also defines various options and option negotiation standards to provide functionality with more advanced terminals. Once the options are negotiated, the two computers can send and recieve data as equals. They can also renegotiate options if needed later. This makes the telnet protocol extremely felxible. This flexibility has lead it to appear in many places over the years. Later protocols have adopted the use of the telnet NVT to ensure compatibility of communication. Such protocols include FTP, SMTP, NNTP, and HTTP. Those protocols do not actually establish a Telnet session or use the option negotion features, they just use it to send data in a consistant way. When most people think of telnet, they think of a remote login to a network computer. Telnet software uses the telnet protocol to establish a remote connection. If any of you have ever purchased a shell account to run an eggdrop bot on IRC, you know what I'm talking about.

Using telnet for remote login involves the client/server model. The computer you are connecting to is the server. You are the client. You use Telnet software to connect to the remote computer. Normally this is by connecting to port 23. Ex. telnet somehost.org The default port is 23, most Telnet applications assume this, unless otherwise specified. In wich case, if you are running it from a command line, it would be telnet somehost.org 23 or whatever port you want to connect to. Once a connection is established, option negotiation begins.
The NVT standard dictates that all printable characters must be displayed. (break out the ASCII chart, or search for one online to see what I'm talking about) However, there are some unprintable characters. Not all of these have to be supported, but all of them usually are now days. They are as follows: (sorry if it looks messy, there is only so much I can do in a plain text file)

ASCII value ASCII Char code ASCII char Desc Required(decimal)

0 NUL Null No operation (no effect on output). Mandatory

7 BEL Bell Produces an audible or visible signal on the output without moving the print head. This notification may be used to get the user’s attention, as in the case of an error.
Optional

8 BS Back Space Moves the print position one character to the left.
Optional

9 HT Horizontal Tab Moves the printer to the next horizontal tab stop. The standard does not specify how devices agree on tab stop positions; this can be negotiated using Telnet options.
Optional

10 LF Line Feed Moves the printer to the next line, keeping the print position the same.
Mandatory

11 VT Vertical Tab Moves the print line to the next vertical tab stop. As with the “HT” character, devices must use an option to come to an agreement on vertical tab stop positions.
Optional

12 FF Form Feed Moves the printer to the top of the next page (or on a display, clears the screen and positions the cursor at the top.)
Optional

13 CR Carriage Return Moves the printer to the left margin of the current print line.
Mandatory

Also note, that a CR (carriage return) and LF (line feed) in the NVT represents an end of line. This is because not all operating systems agree on what the end of line should be. For example, Microsoft operating systems use CR and LF, while *NIX style operating systems use LF. The older MAC operating systems used CR. Adding this to the standard has ensured that today these operating systems can still communicate using the NVT.

I have two more tables to throw at you, so bear with me. They are needed to understand the option negotiations that take place once you establish a connection.

Telnet Command Table

Code Name Description 240 SE End of subnegotiation parameters.

241 NOP No operation.
242 Data Mark The data stream portion of a Synch. This should always be accompanied by a TCPUrgent notification.
243 Break NVT character BRK.
244 Interrupt Process The function IP.
245 Abort output The function AO.
246 Are You There The function AYT.
247 Erase character The function EC.
248 Erase Line The function EL.
249 Go ahead The GA signal.
250 SB Indicates that what follows is subnegotiation of the indicated option.
251 WILL (option code) Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option.
252 WON'T (option code) Indicates the refusal to perform, or continue performing, the indicated option.
253 DO (option code) Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option.
254 DON'T (option code) Indicates the demand that the other party stop performing, or confirmation that you are no longer expecting the other party to perform, the indicated option.
255 IAC Data Byte 255.

This next table is a list of telnet options, and the RFC that covers each one.
Code Option References
0 TRANSMIT-BINARY, Binary Transmission. RFC 856 1 ECHO, Echo. RFC 857 2 Reconnection.
3 SUPPRESS-GO-AHEAD, Suppress Go Ahead. RFC 858
4 Approx Message Size Negotiation.
5 STATUS. RFC 859
6 TIMING-MARK, Timing Mark RFC 860
7 RCTE, Remote Controlled Trans and Echo. RFC 563, RFC 726
8 Output Line Width.
9 Output Page Size.
10 NAOCRD, Negotiate About Output Carriage-Return Disposition. RFC 652
11 NAOHTS, Negotiate About Output Horizontal Tabstops. RFC 653
12 NAOHTD, Negotiate About Output Horizontal Tab Disposition. RFC 654
13 NAOFFD, Negotiate About Output Formfeed Disposition. RFC 655
14 NAOVTS, Negotiate About Vertical Tabstops. RFC 656
15 NAOVTD, Negotiate About Output Vertcial Tab Disposition. RFC 657
16 NAOLFD, Negotiate About Output Linefeed Disposition. RFC 658.
17 Extended ASCII. RFC 698
18 LOGOUT, Logout. RFC 727
19 BM, Byte Macro. RFC 735
20 Data Entry Terminal. RFC 732, RFC 1043
21 SUPDUP. RFC 734, RFC 736
22 SUPDUP-OUTPUT, SUPDUP Output. RFC 749
23 SEND-LOCATION, Send Location. RFC 779
24 TERMINAL-TYPE, Terminal Type. RFC 1091
25 END-OF-RECORD, End of Record. RFC 885
26 TUID, TACACS User Identification. RFC 927
27 OUTMRK, Output Marking. RFC 933
28 TTYLOC, Terminal Location Number. RFC 946
29 Telnet 3270 Regime. RFC 1041
30 X.3 PAD. RFC 1053
31 NAWS, Negotiate About Window Size. RFC 1073
32 Terminal Speed. RFC 1079
33 Remote Flow Control. RFC 1372
34 Linemode. RFC 1184
35 X Display Location. RFC 1096
36 Environment Option. RFC 1408
37 AUTHENTICATION, Authentication Option. RFC 1416, RFC 2941, RFC 2942, RFC 2943, RFC 2951
38 Encryption Option. RFC 2946
39 New Environment Option. RFC 1572
40 TN3270E. RFC 2355
41 XAUTH.
42 CHARSET. RFC 2066
43 RSP, Telnet Remote Serial Port.
44 Com Port Control Option RFC 2217
45 Telnet Suppress Local Echo
46 Telnet Start TLS
47 KERMIT RFC 2840
48 SEND-URL
49 FORWARD_X
50 to 137 undefined
138 TELOPT PRAGMA LOGON
139 TELOPT SSPI LOGON
140 TELOPT PRAGMA HEARTBEAT
141 to 254 undefined
255 EXOPL, Extended-Options-List. RFC 861

Now your probably wondering what all that crap is. This is the part where I tell ya what most of it means. Certain bytes that are sent and recieved mean various things. All telnet commands sequences must start with the byte 255. This is the Interpret As Command byte. The byte after it is interpreted as a command. :-) The commands are listed in the telnet command chart. These follow their own special set of rules.

The first set of commands normally sent are DO's, DONT's, WILL's, and WONT's. The following are the rules for these command sequences.
Sender Receiver Implication

  • WILL DO The sender would like to use a certain option if the receiver can handle it. The receiver says it can support the option. Option is now in effect
  • WILL DONT The sender would like to use a certain option if the receiver can handle it. The receiver says it cannot support the option. Option is not in effect.
  • DO WILL The sender requests that the receiver use a certain option. The receiver says it can support the option. Option is now in effect.
  • DO WONT The sender requests that the receiver use a certain option. The receiver says it cannot support the option. Option is not in effect.
  • WONT DONT The sender will not use a certain option. Option disabled. DONT is only valid response.
  • DONT WONT The sender requests that the receiver does not use a certain option. Option disabled. WONT is only valid response.
Example:
client: IAC DO ECHOhost: IAC WILL ECHO (echo is now in effect)

That is one simple use of it. However, one of the more complicated options will look like this.

host: IAC DO TERMTYPEclient: IAC WILL TERMTYPE

They have negotiated that the terminal type will be reported. The actual terminal type is not negotiated in that data transfer. It just means that they have agreed to negotiate it at a later time. When the time comes, they use the SB command. (subnegotiation) It looks like this. (note, terminal type is the brand of terminal you are using. ex. vt100, vt220, etc. Now days, it refers to the type of emulation that your telnet program will be pretending to be. Terminal emulation is beyond the scope of this article)

host: IAC SB TERMTYPE SEND IAC SEclient: IAC SB TERMTYPE IS VT100 IAC SE
Note: SEND is the ASCII value 1, and IS is the ASCII value of 0 in this instance.(See RFC 1091 for more info)

Each telnet option has it's own method for subnegotiation, as per their RFC's. Once all of the initial negotiation is completed, everything proceeds as if you were using that computer directly. Later on in the session, certain options may be renegotiated. If you are interested in writing your own telnet application, the RFC's are very helpful. If you do decide to write one, please write it to the complete spec, as a broken telnet client is the most annoying thing in the world. Due to time restraints, I won't go into every telnet option in detail. That's what the RFC's are for. Just google for them. There are several sites out there that have all of them up.
Another thing you must remember when using the telnet protocol. The data is sent in plain text. (not including the ENCRYPTION option) It is possible for someone to intercept your traffic, and sniff your passwords. (How that is done is beyond the scope of this article as well) Most people now use SSH instead of telnet (SSH encrypts the data), unless they are in a secure network environment. I have only scratched the surface of the telnet protocol here. For more information, the following RFC's are helpful. (to find these RFC's, just search for them in your favorite internet search engine. I did not list any particular site to find them because there are many sites out there with these) If anyone would like for me to go more in depth on anything in this article, or if you have any questions, just e-mail us, and we will be happy to help.

-=databat=-

RFCs:------------------------------------RFC 137 TELNET Protocol.
RFC 139 Discussion of TELNET Protocol.
RFC 318 Telnet Protocol.
RFC 328 Suggested Telnet Protocol Changes.
RFC 340 PROPOSED TELNET CHANGES.
RFC 393 Comments on TELNET Protocol Changes.
RFC 435 TELNET Issues.
RFC 495 TELNET Protocol Specification.
RFC 513 COMMENTS ON THE NEW TELNET SPECIFICATIONS.
RFC 529 A Note on Protocol Synch Sequences.
RFC 559 Comments on the new TELNET Protocol and its Implementation.
RFC 563 Comments on the RCTE TELNET Option.
RFC 593 Telnet and FTP Implementation Schedule Change.
RFC 595 Some Thoughts in Defense of the TELNET Go-Ahead.
RFC 596 Second Thoughts on Telnet Go-Ahead.
RFC 652 Telnet Output Carriage-Return Disposition Option.
RFC 653 TELNET OUTPUT HORIZONTAL TABSTOPS OPTION.
RFC 654 TELNET OUTPUT HORIZONTAL TAB DISPOSITION OPTION.
RFC 655 TELNET OUTPUT FORMFEED DISPOSITION OPTION.
RFC 656 TELNET OUTPUT VERTICAL TABSTOPS OPTION.
RFC 657 TELNET OUTPUT VERTICAL TAB DISPOSITION OPTION.
RFC 658 TELNET OUTPUT LINEFEED DISPOSITION.
RFC 659 Announcing Addtional Telnet Options.
RFC 698 TELNET EXTENDED ASCII OPTION.
RFC 701 AUGUST, 1974, SURVEY OF NEW-PROTOCOL TELNET SERVERS.
RFC 702 SEPTEMBER, 1974, SURVEY OF NEW-PROTOCOL TELNET SERVERS.
RFC 703 July, 1975, Survey of New-Protocol TELNET Servers.
RFC 718 Comments on RCTE from the TENEX Implementation Experience.
RFC 719 Discussion on RCTE.
RFC 726 Remote Controlled Transmssion and Echoing Telnet Option.
RFC 727 TELNET Logout Option.
RFC 728 A Minor Pitfall in the Telnet Protocol.
RFC 732 Telnet Data Entry Terminal Option.Obsoletes: RFC 731.
RFC 734 SUPDUP Protocol.
RFC 735 Revised TELNET Byte Macro Option.Obsoletes: RFC 729. RFC 736 TELNET SUPDUP Option.
RFC 749 Telnet SUPDUP-OUTPUT Option.
RFC 779 TELNET SEND-LOCATION Option.
RFC 818 The Remote User Telnet Service.
RFC 854 TELNET Protocol Specification.
RFC 855 TELNET Option Specifications.Obsoletes: RFC 764. RFC 856 TELNET BINARY TRANSMISSION.
RFC 857 TELNET ECHO OPTION.
RFC 858 TELNET SUPPRESS GO AHEAD OPTION.
RFC 859 TELNET STATUS OPTION.Obsoletes: RFC 651.
RFC 860 TELNET TIMING MARK OPTION.
RFC 861 TELNET EXTENDED OPTIONS - LIST OPTION.
RFC 885 TELNET END OF RECORD OPTION.
RFC 927 TACACS User Identification Telnet Option.
RFC 933 OUTPUT MARKING TELNET OPTION.
RFC 946 TELNET TERMINAL LOCATION NUMBER OPTION.
RFC 1041 Telnet 3270 Regime Option.
RFC 1043 TELNET Data Entry Terminal Option DODIIS Implementation.Updates: RFC 732. RFC 1053 Telnet X.3 PAD Option.
RFC 1073 Telnet Window Size Option.
RFC 1079 Telnet Terminal Speed Option.
RFC 1091 Telnet Terminal-Type Option.Obsoletes: RFC 930. RFC 1096 Telnet X Display Location Option.
RFC 1123 Requirements for Internet Hosts -- Application and Support.
RFC 1143 The Q Method of Implementing TELNET Option Negotiation.
RFC 1184 Telnet Linemode Option.Obsoletes: RFC 1116.
RFC 1205 5250 Telnet Interface.
RFC 1372 Telnet Remote Flow Control Option.Obsoletes: RFC 1080.
RFC 1408 Telnet Environment Option.
RFC 1411 Telnet Authentication: Kerberos Version 4.
RFC 1412 Telnet Authentication: SPX.
RFC 1571 Telnet Environment Option Interoperability Issues.Updates: RFC 1408.
RFC 1572 Telnet Environment Option.
RFC 1576 TN3270 Current Practices.
RFC 1646 TN3270 Extensions for LUname and Printer Selection.
RFC 1921 TNVIP Protocol.
RFC 2066 TELNET CHARSET Option.
RFC 2217 Telnet Com Port Control Option.
RFC 2355 TN3270 Enhancements.Obsoletes: RFC 1647.
RFC 2839 Internet Kermit Service.
RFC 2840 TELNET KERMIT OPTION.
RFC 2877 5250 Telnet Enhancements.Updates: RFC 1205.
RFC 2941 Telnet Authentication Option.Obsoletes: RFC 1416.
RFC 2942 Telnet Authentication: Kerberos Version 5.
RFC 2943 TELNET Authentication Using DSA.
RFC 2944 Telnet Authentication: SRP.
RFC 2946 Telnet Data Encryption Option.
RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback.
RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback.
RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback.
RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback.
RFC 2951 TELNET Authentication Using KEA and SKIPJACK.
RFC 2952 Telnet Encryption: DES 64 bit Cipher Feedback.
RFC 2953 Telnet Encryption: DES 64 bit Output Feedback.
--------------------------------------------------------------------------------
Obsolete RFCs:
RFC 651 Revised Telnet Status Option.Obsoleted by: RFC 859.
RFC 729 TELNET Byte Macro Option.Obsoleted by: RFC 735. RFC 731] Telnet Data Entry Terminal Option.Obsoleted by: RFC 732.
RFC 764 TELNET PROTOCOL SPECIFICATION.Obsoleted by: RFC 854.
RFC 884 TELNET TERMINAL TYPE OPTION.Obsoleted by: RFC 930.
RFC 930 TELNET TERMINAL TYPE OPTION.Obsoleted by: RFC 1091. Obsoletes: RFC 884.
RFC 1080 Telnet Remote Flow Control Option.Obsoleted by: RFC 1372.
RFC 1116 Telnet Linemode Option.Obsoleted by: RFC 1184.
RFC 1409 Telnet Authentication Option.Obsoleted by: RFC 1416.
RFC 1416 Telnet Authentication Option.Obsoleted by: RFC 2941. Obsoletes: RFC 1409.
RFC 1647 TN3270 Enhancements.Obsoleted by: RFC 2355.

No comments: