As per Relevance of the word password, we have this rfc below:
Network Working Group B.
Request for Comments: 1258 Univ. of Calif San
September 1991
BSD
Status of this
This memo documents an existing protocol and common
that is extensively used on the Internet. This memo
information for the Internet community. It does not specify
Internet standard. Distribution of this memo is unlimited
Protocol
The rlogin facility provides a remote-echoed, locally flow-
virtual terminal with proper flushing of output. It is widely
between Unix hosts because it provides transport of more of the
terminal environment semantics than does the Telnet protocol,
because on many Unix hosts it can be configured not to require
entry of passwords when connections originate from trusted hosts
The rlogin protocol requires the use of the TCP. The contact port
513. An eight-bit transparent stream is assumed
Connection
Upon connection establishment, the client sends four null-
strings to the server. The first is an empty string (i.e.,
consists solely of a single zero byte), followed by three non-
strings: the client username, the server username, and the
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
strings and is now in data transfer mode. Window size
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 "raw") mode. In this mode, the START and STOP (usually
DC1,DC3) characters are intercepted and interpreted by the client
start and stop output from the remote server to the local terminal
whereas all other characters are transmitted to the remote host
they are received. (But see below for the handling of
local-escape character.)
In "raw" mode, the START and STOP characters are not
locally, but are sent as any other character to the remote server
The server thus determines the semantics of the START and
characters when in "raw" mode; they may be used for flow control
have quite different meanings independent of their ordinary usage
the client
Screen/Window
The remote server indicates to the client that it can accept
size change information by requesting a window size message (
described below) just after connection establishment and
identification exchange. The client should reply to this
with the current window size
If the remote server has indicated that it can accept client
size changes and the size of the client's window or screen
changes, a 12-byte special sequence is sent to the remote server
indicate the current dimensions of the client's window, should
user process running on the server care to make use of
information
The window change control sequence is 12 bytes in length,
of a magic cookie (two consecutive bytes of hex FF), followed by
bytes containing lower-case ASCII "s", then 8 bytes containing
16-bit values for the number of character rows, the number
characters per row, the number of pixels in the X direction, and
number of pixels in the Y direction, in network byte order. Thus
FF FF s s rr cc xp
Other flags than "ss" may be used in future for other in-band
messages. None are currently defined
Kantor [Page 2]
RFC 1258 BSD Rlogin September 1991
From Server to
Data from the remote server is sent to the client as a stream
characters. Normal data is simply sent to the client's display,
may be processed before actual display (tabs expanded, etc.).
The server can imbed single-byte control messages in the data
by inserting the control byte in the stream of data and pointing
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
the urgent byte is buffered for possible display after the
byte is handled, and the control byte pointed to is received
interpreted as follows
02 A control byte of hex 02 causes the client to discard all
data received from the server that has not yet been written to
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
the client, but are instead treated as plain data
20 A control byte of hex 20 commands the client to resume
and local processing of START and STOP flow control characters
All other values of the urgent-data control byte are ignored. In
cases, the byte pointed to by the urgent data pointer is NOT
to the client user's display
Connection
When the TCP connection closes in either direction, the client
server process which notices the close should perform an
shut-down, restoring terminal modes and notifying the user
processes of the close before it closes the connection in the
direction
Implementation
The client defines a client-escape character (customarily the tilde
"~"), which is handled specially only if it is the first character
be typed at the beginning of a line. (The beginning of a line
defined to be the first character typed by the client user after
new-line [CR or LF] character, after a line-cancel character,
resumption of a suspended client session, or after initiation of
connection.)
The client-escape character is not transmitted to the server
Kantor [Page 3]
RFC 1258 BSD Rlogin September 1991
the character after it has been examined, and if that character
one of the defined client escape sequences, neither the client-
nor the character following it are sent. Otherwise, both
client-escape character and the character following it are sent
the server as ordinary user input
If the character following the client-escape character is the
".", or the client-defined end-of-file character (usually control-D),
the connection is closed. This is normally treated by the server
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
that ability. One character suspends both remote input and output
the other suspends remote input but allows remote output to
to be directed to the local client's terminal
Most client implementations have invocation switches that can
normal output processing on the client system, and which can
the client to remain in raw mode despite switching notification
the server
A Cautionary
The rlogin protocol (as commonly implemented) allows a user to set
a class of trusted users and/or hosts which will be allowed to log
as himself without the entry of a password. While
convenient, this represents a weakening of security that has
successfully exploited in previous attacks on the internet. If
wishes to use the password-bypass facilities of the rlogin service
it is essential to realize the compromises that may be
thereby
Bypassing password authentication from trusted hosts opens ALL
systems so configured when just one is compromised. Just as
the same password for all systems to which you have access lets
villain in everywhere you have access, allowing passwordless
among all your systems gives a marauder a wide playing field once
has entered any of your systems. One compromise that many
achieves a workable balance between convenience and security is
allow password bypass from only ONE workstation to the other
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.
is possible, by compromise of your organization's domain name server
or compromise of your network itself, for a villain to make
untrusted host masquerade as a trusted system. There is little
Kantor [Page 4]
RFC 1258 BSD Rlogin September 1991
a user can do about this form of attack. Luckily, so far
attacks have been rare, and often cause enough disruption of
network that attempts are quickly noticed
When the file containing a user's list of trusted logins
inadvertently left writeable by other users, untrustworthy
may be made to it
Secure authentication extensions to the rlogin protocol (Kerberos
et al) can greatly reduce the possibility of compromise whilst
allowing the convenience of bypassing password entry. As these
more widely deployed in the internet community, the hazards of
will decrease
Security
See the "A Cautionary Tale" section above
Author's
Brian
University of California at San
Network Operations C-024
La Jolla, CA 92093-0214
Phone: (619) 534-6865
EMail: brian@UCSD.
Kantor [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
