From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1258.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc1258.txt (limited to 'doc/rfc/rfc1258.txt') diff --git a/doc/rfc/rfc1258.txt b/doc/rfc/rfc1258.txt new file mode 100644 index 0000000..4df7a40 --- /dev/null +++ b/doc/rfc/rfc1258.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group B. Kantor +Request for Comments: 1258 Univ. of Calif San Diego + September 1991 + + + BSD Rlogin + +Status of this Memo + + This memo documents an existing protocol and common implementation + that is extensively used on the Internet. This memo provides + information for the Internet community. It does not specify an + Internet standard. Distribution of this memo is unlimited. + +Protocol Description + + The rlogin facility provides a remote-echoed, locally flow-controlled + virtual terminal with proper flushing of output. It is widely used + between Unix hosts because it provides transport of more of the Unix + terminal environment semantics than does the Telnet protocol, and + because on many Unix hosts it can be configured not to require user + entry of passwords when connections originate from trusted hosts. + + The rlogin protocol requires the use of the TCP. The contact port is + 513. An eight-bit transparent stream is assumed. + +Connection Establishment + + Upon connection establishment, the client sends four null-terminated + strings to the server. The first is an empty string (i.e., it + consists solely of a single zero byte), followed by three non-null + strings: the client username, the server username, and the terminal + type and speed. More explicitly: + + + client-user-name + server-user-name + terminal-type/speed + + For example: + + + bostic + kbostic + vt100/9600 + + The server returns a zero byte to indicate that it has received these + strings and is now in data transfer mode. Window size negotiation + + + +Kantor [Page 1] + +RFC 1258 BSD Rlogin September 1991 + + + may follow this initial exchange (see below). + +From Client to Server (and Flow Control) + + Initially, the client begins operation in "cooked" (as opposed to + to "raw") mode. In this mode, the START and STOP (usually ASCII + DC1,DC3) characters are intercepted and interpreted by the client to + start and stop output from the remote server to the local terminal, + whereas all other characters are transmitted to the remote host as + they are received. (But see below for the handling of the + local-escape character.) + + In "raw" mode, the START and STOP characters are not processed + locally, but are sent as any other character to the remote server. + The server thus determines the semantics of the START and STOP + characters when in "raw" mode; they may be used for flow control or + have quite different meanings independent of their ordinary usage on + the client. + +Screen/Window Size + + The remote server indicates to the client that it can accept window + size change information by requesting a window size message (as + described below) just after connection establishment and user + identification exchange. The client should reply to this request + with the current window size. + + If the remote server has indicated that it can accept client window + size changes and the size of the client's window or screen dimensions + changes, a 12-byte special sequence is sent to the remote server to + indicate the current dimensions of the client's window, should the + user process running on the server care to make use of that + information. + + The window change control sequence is 12 bytes in length, consisting + of a magic cookie (two consecutive bytes of hex FF), followed by two + bytes containing lower-case ASCII "s", then 8 bytes containing the + 16-bit values for the number of character rows, the number of + characters per row, the number of pixels in the X direction, and the + number of pixels in the Y direction, in network byte order. Thus: + + FF FF s s rr cc xp yp + + Other flags than "ss" may be used in future for other in-band control + messages. None are currently defined. + + + + + + +Kantor [Page 2] + +RFC 1258 BSD Rlogin September 1991 + + +From Server to Client + + Data from the remote server is sent to the client as a stream of + characters. Normal data is simply sent to the client's display, but + may be processed before actual display (tabs expanded, etc.). + + The server can imbed single-byte control messages in the data stream + by inserting the control byte in the stream of data and pointing the + TCP "urgent-data" pointer at the control byte. When a TCP urgent- + data pointer is received by the client, data in the TCP stream up to + the urgent byte is buffered for possible display after the control + byte is handled, and the control byte pointed to is received and + interpreted as follows: + + 02 A control byte of hex 02 causes the client to discard all buffered + data received from the server that has not yet been written to the + client user's screen. + + 10 A control byte of hex 10 commands the client to switch to "raw" + mode, where the START and STOP characters are no longer handled by + the client, but are instead treated as plain data. + + 20 A control byte of hex 20 commands the client to resume interception + and local processing of START and STOP flow control characters. + + All other values of the urgent-data control byte are ignored. In all + cases, the byte pointed to by the urgent data pointer is NOT written + to the client user's display. + +Connection Closure + + When the TCP connection closes in either direction, the client or + server process which notices the close should perform an orderly + shut-down, restoring terminal modes and notifying the user or + processes of the close before it closes the connection in the other + direction. + +Implementation Notes + + The client defines a client-escape character (customarily the tilde, + "~"), which is handled specially only if it is the first character to + be typed at the beginning of a line. (The beginning of a line is + defined to be the first character typed by the client user after a + new-line [CR or LF] character, after a line-cancel character, after + resumption of a suspended client session, or after initiation of the + connection.) + + The client-escape character is not transmitted to the server until + + + +Kantor [Page 3] + +RFC 1258 BSD Rlogin September 1991 + + + the character after it has been examined, and if that character is + one of the defined client escape sequences, neither the client-escape + nor the character following it are sent. Otherwise, both the + client-escape character and the character following it are sent to + the server as ordinary user input. + + If the character following the client-escape character is the dot + ".", or the client-defined end-of-file character (usually control-D), + the connection is closed. This is normally treated by the server as + a disconnection, rather than an orderly logout. + + Other characters (client-defined, usually control-Z and control-Y) + are used to temporarily suspend the rlogin client when the host has + that ability. One character suspends both remote input and output; + the other suspends remote input but allows remote output to continue + to be directed to the local client's terminal. + + Most client implementations have invocation switches that can defeat + normal output processing on the client system, and which can force + the client to remain in raw mode despite switching notification from + the server. + +A Cautionary Tale + + The rlogin protocol (as commonly implemented) allows a user to set up + a class of trusted users and/or hosts which will be allowed to log on + as himself without the entry of a password. While extremely + convenient, this represents a weakening of security that has been + successfully exploited in previous attacks on the internet. If one + wishes to use the password-bypass facilities of the rlogin service, + it is essential to realize the compromises that may be possible + thereby. + + Bypassing password authentication from trusted hosts opens ALL the + systems so configured when just one is compromised. Just as using + the same password for all systems to which you have access lets a + villain in everywhere you have access, allowing passwordless login + among all your systems gives a marauder a wide playing field once he + has entered any of your systems. One compromise that many feel + achieves a workable balance between convenience and security is to + allow password bypass from only ONE workstation to the other systems + you use, and NOT allow it between those systems. With this measure, + you may have reduced exposure to a workable minimum. + + The trusted host specification is ordinarily one of a host name. It + is possible, by compromise of your organization's domain name server, + or compromise of your network itself, for a villain to make an + untrusted host masquerade as a trusted system. There is little that + + + +Kantor [Page 4] + +RFC 1258 BSD Rlogin September 1991 + + + a user can do about this form of attack. Luckily, so far such + attacks have been rare, and often cause enough disruption of a + network that attempts are quickly noticed. + + When the file containing a user's list of trusted logins is + inadvertently left writeable by other users, untrustworthy additions + may be made to it. + + Secure authentication extensions to the rlogin protocol (Kerberos, + et al) can greatly reduce the possibility of compromise whilst still + allowing the convenience of bypassing password entry. As these become + more widely deployed in the internet community, the hazards of rlogin + will decrease. + +Security Considerations + + See the "A Cautionary Tale" section above. + +Author's Address + + Brian Kantor + University of California at San Diego + Network Operations C-024 + La Jolla, CA 92093-0214 + + Phone: (619) 534-6865 + + EMail: brian@UCSD.EDU + + + + + + + + + + + + + + + + + + + + + + + +Kantor [Page 5] + \ No newline at end of file -- cgit v1.2.3