Added RFCs

git-svn-id: http://svn.inspircd.org/repository/trunk/inspircd@1379 e03df62e-2008-0410-955e-edbf42e46eb7

1 files changed, 451 insertions, 0 deletions

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