'svn propset -R svn:eol-style CR *' Set to UNIX-style always. Binaries are auto skipped by svn.

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

1 files changed, 1 insertions, 451 deletions

diff --git a/docs/rfc/rfc1413.txt b/docs/rfc/rfc1413.txt
index 17ede58a2..e175dcece 100644
--- a/docs/rfc/rfc1413.txt
+++ b/docs/rfc/rfc1413.txt
@@ -1,451 +1 @@
-
-
-
-
-
-
-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
+





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