rfc1413.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 451 行 · 第 1/2 页


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: [phone]
       EMail: [e-mail]



















St. Johns                                                       [Page 8]