As per Relevance of the word identifier, we have this rfc below:
Network Working Group M. St.
Request for Comments: 1413 US Department of
Obsoletes: 931 February 1993
Identification
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
1.
The Identification Protocol (a.k.a., "ident", a.k.a., "the
Protocol") provides a means to determine the identity of a user of
particular TCP connection. Given a TCP port number pair, it
a character string which identifies the owner of that connection
the server's system
The Identification Protocol was formerly called the
Server Protocol. It has been renamed to better reflect its function
This document is a product of the TCP Client Identity
Working Group of the Internet Engineering Task Force (IETF).
2.
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 a line of data which specifies
connection of interest. If it exists, the system dependent
identifier of the connection of interest is sent as the reply.
server may then either shut the connection down or it may continue
read/respond to multiple queries
The server should close the connection down after a
amount of time with no queries - a 60-180 second idle timeout
recommended. The client may close the connection down at any time
however to allow for network delays the client should wait at
30 seconds (or longer) after a query before abandoning the query
closing the connection
St. Johns [Page 1]
RFC 1413 Identification Protocol February 1993
3.
Queries are permitted only for fully specified connections.
query contains the local/foreign port pair -- the local/
address pair used to fully specify the connection is taken from
local and foreign address of query connection. This means a user
address A may only query the server on address B about
between A and B
4. QUERY/RESPONSE
The server accepts simple text query requests of the form
,
where is the TCP port (decimal) on the target (
the "ident" server is running) system, and is
TCP port (decimal) on the source (client) system
N.B - If a client on host A wants to ask a server on host B about
connection specified locally (on the client's machine) as 23, 6191
(an inbound TELNET connection), the client must actually ask
6191, 23 - which is how the connection would be specified on host B
For example
6191, 23
The response is of the
, : :
where , are the same pair as
query, is a keyword identifying the type of response,
is context dependent
The information returned is that associated with the fully
TCP connection identified by , ,
, , where
are the local and foreign IP addresses of
querying connection -- i.e., the TCP connection to the
Protocol Server. ( and are
from the query.)
For example
6193, 23 : USERID : UNIX :
6195, 23 : ERROR : NO-
St. Johns [Page 2]
RFC 1413 Identification Protocol February 1993
5. RESPONSE
A response can be one of two types
In this case, is a string consisting of
operating system name (with an optional character
identifier), followed by ":", followed by
identification string
The character set (if present) is separated from
operating system name by ",". The character
identifier is used to indicate the character set of
identification string. The character set identifier
if omitted, defaults to "US-ASCII" (see below).
Permitted operating system names and character
names are specified in RFC 1340, "Assigned Numbers"
its successors
In addition to those operating system and character
names specified in "Assigned Numbers" there is
special case operating system identifier - "OTHER".
Unless "OTHER" is specified as the operating
type, the server is expected to return the "normal
user identification of the owner of this connection
"Normal" in this context may be taken to mean a
of characters which uniquely identifies the
owner such as a user identifier assigned by the
administrator and used by such user as a
identifier, or as the "user" part of a user/
pair used to gain access to system resources. When
operating system is specified (e.g., anything
"OTHER"), the user identifier is expected to be in
more or less immediately useful form - e.g.,
that could be used as an argument to "finger" or as
mail address
"OTHER" indicates the identifier is an
character string consisting of printable characters
the specified character set. "OTHER" should
specified if the user identifier does not meet
constraints of the previous paragraph. Sending
encrypted audit token, or returning other non-
information about a user (such as the real name
phone number of a user from a UNIX passwd file)
St. Johns [Page 3]
RFC 1413 Identification Protocol February 1993
both examples of when "OTHER" should be used
Returned user identifiers are expected to be
in the character set indicated
The identifier is an unformatted octet string - -
octets are permissible EXCEPT octal 000 (NUL), 012 (LF
and 015 (CR). N.B. - space characters (040) following
colon separator ARE part of the identifier string
may not be ignored. A response string is
terminated normally by a CR/LF. N.B. A string may
printable, but is not *necessarily* printable
For some reason the port owner could not be determined,
tells why. The following are the permitted values of
their meanings
INVALID-
Either the local or foreign port was
specified. This should be returned if either
both of the port ids were out of range (TCP
numbers are from 1-65535), negative integers, reals
in any fashion not recognized as a non-
integer
NO-
The connection specified by the port pair is
currently in use or currently not owned by
identifiable entity
HIDDEN-
The server was able to identify the user of
port, but the information was not returned at
request of the user
UNKNOWN-
Can't determine connection owner; reason unknown
Any error not covered above should return
error code value. Optionally, this code MAY
returned in lieu of any other specific error
if, for example, the server desires to
information implied by the return of that
St. Johns [Page 4]
RFC 1413 Identification Protocol February 1993
code, or for any other reason. If a
implements such a feature, it MUST be
and it MUST default to returning the proper
message
Other values may eventually be specified and defined in
revisions to this document. If an implementer has a need to
a non-standard error code, that code must begin with "X".
In addition, the server is allowed to drop the query
without responding. Any premature close (i.e., one where the
does not receive the EOL, whether graceful or an abort should
considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
FORMAL
::=
::= ","
::=
::= "015 012" ; CR-LF End of Line
::= |
::= ":" "ERROR" ":"
::= ":" "USERID" ":"
":"
::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR
| "HIDDEN-USER" |
::= [ "," ]
::= "OTHER" | "UNIX" | ...etc
; (See "Assigned Numbers")
::= "US-ASCII" | ...etc
; (See "Assigned Numbers")
::=
::= 1*64 ; 1-64
::= "X"1*63
; 2-64 chars beginning w/
St. Johns [Page 5]
RFC 1413 Identification Protocol February 1993
::= 1*5 ; 1-5 digits
::= "0" | "1" ... "8" | "9" ; 0-9
::=
- (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
; upper and lowercase a-z
; printables minus the colon ":"
; character
::= 1*512
::=
ASCII NUL (000), CR (015) and LF (012)>
Notes on Syntax
1) To promote interoperability among
implementations, with respect to white space the
syntax is understood to embody the "be conservative
what you send and be liberal in what you accept
philosophy. Clients and servers should not
unnecessary white space (space and tab characters)
should accept white space anywhere except within
token. In parsing responses, white space may
anywhere, except within a token. Specifically,
amount of white space is permitted at the beginning
end of a line both for queries and responses.
does not apply for responses that contain a user
because everything after the colon after the
system type until the terminating CR/LF is taken
part of the user ID. The terminating CR/LF is
considered part of the user ID
2) The above notwithstanding, servers should restrict
amount of inter-token white space they send to
smallest amount reasonable or useful. Clients
feel free to abort a connection if they receive 1000
characters without receiving an .
3) The 512 character limit on user IDs and the 64
character limit on tokens should be understood to
as follows: a) No new token (i.e., OPSYS or ERROR-TYPE
token will be defined that has a length greater than 64
and b) a server SHOULD NOT send more than 512 octets
user ID and a client MUST accept at least 512 octets
St. Johns [Page 6]
RFC 1413 Identification Protocol February 1993
user ID. Because of this limitation, a server
return the most significant portion of the user ID
the first 512 octets
4) The character sets and character set identifiers
map directly to those defined in or referenced by RFC 1340,
"Assigned Numbers" or its successors. Character
identifiers only apply to the user identification
- all other fields will be defined in and must be
as US-ASCII
5) Although is defined as an
above, it must follow the format and character
constraints implied by the ; see
discussion above
6) The character set provides context for the client
print or store the returned user identification string
If the client does not recognize or implement
returned character set, it should handle the
identification string as OCTET, but should in
store or report the character set. An OCTET
should be printed, stored or handled in hex
(0-9a-f) in addition to any other representation
client implements - this provides a
representation among differing implementations
6. Security
The information returned by this protocol is at most as
as the host providing it OR the organization operating the host.
example, a PC in an open lab has few if any controls on it to
a user from having this protocol return any identifier the
wants. Likewise, if the host has been compromised the
returned may be completely erroneous and misleading
The Identification Protocol is not intended as an authorization
access control protocol. At best, it provides some
auditing information with respect to TCP connections. At worst,
can provide misleading, incorrect, or maliciously
information
The use of the information returned by this protocol for other
auditing is strongly discouraged. Specifically, using
Protocol information to make access control decisions - either as
primary method (i.e., no other checks) or as an adjunct to
methods may result in a weakening of normal host security
St. Johns [Page 7]
RFC 1413 Identification Protocol February 1993
An Identification server may reveal information about users
entities, objects or processes which might normally be
private. An Identification server provides service which is a
analog of the CallerID services provided by some phone companies
many of the same privacy considerations and arguments that apply
the CallerID service apply to Identification. If you wouldn't run
"finger" server due to privacy considerations you may not want to
this protocol
7.
Acknowledgement is given to Dan Bernstein who is
responsible for renewing interest in this protocol and for
out some annoying errors in RFC 931.
[1] St. Johns, M., "Authentication Server", RFC 931, TPSC,
1985.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
Author's
Michael C. St.
DARPA/
3701 N. Fairfax
Arlington, VA 22203
Phone: (703) 696-2271
EMail: stjohns@DARPA.
St. Johns [Page 8]
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
