As per Relevance of the word operating, we have this rfc below:
Network Working Group Mike
Request for Comments: 931
Supersedes: RFC 912 January 1985
Authentication
STATUS OF THIS
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
This is the second draft of this proposal (superseding RFC 912)
incorporates a more formal description of the syntax for the
and response dialog, as well as a change to specify the type of
identification returned. Distribution of this memo is unlimited
The Authentication Server Protocol provides a means to determine
identity of a user of a particular TCP connection. Given a TCP
number pair, it returns a character string which identifies the
of that connection on the server's system. Suggested uses
automatic identification and verification of a user during an
session, additional verification of a TAC dial up user, and
verification for a generalized network file server
This is a connection based application on TCP. A server listens
TCP connections on TCP port 113 (decimal). Once a connection
established, the server reads one line of data which specifies
connection of interest. If it exists, the system dependent
identifier of the connection of interest is sent out the connection
The service closes the connection after sending the user identifier
Queries are permitted only for fully specified connections.
local/foreign host pair used to fully specify the connection
taken from the query connection. This means a user on Host A
only query the server on Host B about connections between A and B
StJohns [Page 1]
RFC 931 January 1985
Authentication
QUERY/RESPONSE
The server accepts simple text query requests of the
,
where is the TCP port (decimal) on the target (server
system, and is the TCP port (decimal) on the
(user) system
For example
23, 6191
The response is of the
, : <response-type> : <additional-info
where , are the same pair as the query
<response-type> is a keyword identifying the type of response,
<additional info> is context dependent
For example
23, 6191 : USERID : MULTICS : StJohns.DODCSC.
23, 6193 : USERID : TAC : MCSJ-
23, 6195 : ERROR : NO-
RESPONSE
A response can be one of two types
In this case, <additional-info> is a string consisting of
operating system name, followed by a ":", followed by
identification string in a format peculiar to the operating
indicated. Permitted operating system names are specified
RFC-923, "Assigned Numbers" or its successors. The only
names permitted are "TAC" to specify a BBN Terminal
Controller, and "OTHER" to specify any other operating system
yet registered with the NIC
StJohns [Page 2]
RFC 931 January 1985
Authentication
For some reason the owner of could not be determined
<additional-info> tells why. The following are suggested
of <additional-info> and their meanings
INVALID-
Either the local or foreign port was improperly specified
NO-
The connection specified by the port pair is not currently
use
UNKNOWN-
Can't determine connection owner; reason unknown. Other
may be specified as necessary
Unfortunately, the trustworthiness of the various host systems
might implement an authentication server will vary quite a bit.
is up to the various applications that will use the server
determine the amount of trust they will place in the
information. It may be appropriate in some cases restrict the use
the server to within a locally controlled subnet
1) Automatic user authentication for
A user-FTP may send a USER command with no argument to
server-FTP to request automatic authentication. The server-
will reply with a 230 (user logged in) if it can use
authentication. It will reply with a 530 (not logged in) if
cannot authenticate the user. It will reply with a 500 or 501
(syntax or parameter problem) if it does not implement
authentication. Please note that no change is needed to
implemented servers to handle the request for authentication;
will reject it normally as a parameter problem. This is
suggested implementation for experimental use only
2) Verification for privileged network operations. For example
having the server start or stop special purpose servers
StJohns [Page 3]
RFC 931 January 1985
Authentication
3) Elimination of "double login" for TAC and other TELNET users
This will be implemented as a TELNET option
FORMAL
::=
::= ","
::=
::= |
::= ":" ERROR ":"
::= ":" USERID ":" ":"
::= INVALID-PORT | NO-USER | UNKNOWN-
::= TAC | OTHER | MULTICS | UNIX ...etc
(See "Assigned Numbers")
Notes on Syntax
1) White space (blanks and tab characters) between tokens is
important and may be ignored
2) White space, the token separator character (":"), and the
pair separator character (",") must be quoted if used within
token. The quote character is a back-slash, ASCII 92 (decimal
("\"). For example, a quoted colon is "\:". The back-slash
also be quoted if its needed to represent itself ("\\").
Notes on User Identification Format
The user identifier returned by the server should be the standard
for the system. For example, the standard Multics
consists of a PERSONID followed by a ".", followed by a PROJECTID
followed by a ".", followed by an INSTANCE TAG of one character.
instance tag of "a" identifies an interactive user, and instance
of "m" identifies an absentee job (batch job) user, and an
tag of "z" identifies a daemon (background) user
Each set of operating system users must come to a consensus as
StJohns [Page 4]
RFC 931 January 1985
Authentication
what the OFFICIAL user identification for their systems will be
Until they register this information, they must use the "OTHER"
to specify their user identification
Notes on User Identification Translation
Once you have a user identifier from a remote system, you must
have a way of translating it into an identifier that meaningful
the local system. The following is a sketchy outline of table
scheme for doing this
The table consists of four columns, the first three are used to
against, the fourth is the result
USERID Opsys Address
MCSJ-MITMUL TAC 26.*.*.*
* MULTICS 192.5.42.* =
* OTHER 10.0.0.42
MSJ ITS 10.3.0.44
The above table is a sample one for a Multics system on MILNET at
Pentagon. When an authentication is returned, the
application using the userid simply looks for the first match in
table. Notice the second line. It says that any
coming from a Multics system on Net 192.5.42 is accepted in the
format
Obviously, various users will have to be registered to use
facility, but the registration can be done at the same time the
receives his login identity from the system
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
