RFC1413

原文：

 

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 RFCspecifies 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. 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 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 RFC1340, 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 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 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> ::= X1*63<token-characters> ; 2-64 chars beginning w/X <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 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 RFC1340, 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. 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 RFC931. References [1] St. Johns, M., Authentication Server, RFC931, TPSC, January 1985. [2] Reynolds, J., and J. Postel, Assigned Numbers, STD 2, RFC1340, 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

翻译：

 

组织：中国互动出版网（http://www.china-pub.com）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者: shenjianli (shenjianli shenjianli@263.net)
译文发布时间：2001-7-1
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group                                       M. St. Johns
Request for Comments: 1413                      US Department of Defense
Obsoletes: 931                                             February 1993

                       

鉴定协议
（Identification Protocol）

此备忘录的状态:
本标准为Internet网详细说明了架构委员会标准轨迹协议,以及需求大家讨论和建议
来进一步提高.敬请关注最新版本标准化陈述和此协议的情况的文件"IAB Official
Protocol Standards".本备忘录的发行无任何限制.
目录
1、介绍 1
2、概述 2
3、约束条件 2
4、询问/响应格式 2
5、响应类型 2
6、安全性考虑 5
7、致谢 6
参考资料 6
作者地址 6

1、介绍
本鉴定协议提供了一种测定用户的特殊的TCP连接身份的手段. 提供了TCP端口对,它
返回的字符串识别出连接在服务器系统上的用户.

此协议以前叫”the Authentication  Server Protocol”(服务器鉴定协议).改名是为了更
好的反映出其功能,本文件是因特网工程任务组的TCP身份协议工作组（TCP Identity Protocol
Working Group ）的产品,
2、概述
这是建立在TCP申请的连接,服务器在TCP的113(十进制)端口监测TCP连接,一旦连接建
立,服务器在一线路上读取重要的数据,假如存在,系统重要连接可靠性用户标识符将被发送作为
回答.然后服务器可以断开连接或者读取并回答更多的询问.
     在推荐60—180秒内如没有接收到任何信息,那么服务器将断开连接.用户可以随时断开连
接,但是,由于网络的延迟,用户必须等待至少30秒,他(她)的访问方被放弃并断开连接.
3、约束条件
询问仅仅限定在指定的连接.询问包括局部和国外端口对,他们用来详细说明连接是来自局
部或外国的询问连接.这说明关于A与B之间的连接一个用户在A地只能询问B地的服务器.
4、询问/响应格式
服务器只接受如下方式的请求:
           <port—on—server>,<port—on—client>
<port—on—server>的内容是TCP端口目标,而<port—on—client>是TCP端口来源.
     N.B—如果客户主机A在主机B申请局部连接为23, 6191的服务,客户必须访问23,
6191—也就是连接在主机B是如何被指定的.
例:
         6191, 23
响应的形式为:
<port-on-server> , <port-on-client> : <resp-type> : <add-info>
其中<port-on-server>,<port-on-client>和上面一样, <resp-type>是响应时的身份关键
字,而 <add-info>是由前后文所决定的.返回信息是被<server-address>,
<client-address>,
<port-on-server>, <port-on-client>识别关联的详细的TCP连接. <server-address>和  
<client-address>是局部和国外的询问连接(i.e)IP地址.TCP连接到鉴定协议服务器
( <port-on-server> 和 <port-on-client>来自询问.
        例:
            6193, 23 : USERID : UNIX : stjohns
            6195, 23 : ERROR : NO-USER


5、响应类型
响应有两种形式:

USERID
       既然如此, <add-info>是由操作系统名字(有随意的字符串标识符)组成,随后是
“:",最后是鉴定字符.
       字符集 (如果被提出)与操作系统名字之间用"."格开, 字符集标识符是用来显示
字符集的鉴定串. 字符集标识符,如果被忽略,将默认为"US-ASCII"(看下面).
       许可的操作系统名字和字符集名字列在清单RFC 1340中, "Assigned Numbers"或它
的继承.
        总之, 操作系统和字符集名在"Assigned Numbers"中详细说明,有一专门共开系统
标识符--"OTHER".
         除非"OTHER"是被指定的操作系统类型,服务器将返回正常的连接业主的用户鉴定,
"Normal"在这里也许意味着字符串,它们唯一详细说明了连接用户,如这样的用户标识
符,它们被管理人员分配并被用作邮件标识符,或作为用户/口令的一部分来访问系统资
源.当系统资源被指定(e.g.除"OTHER"),此用户标识符将或早或迟被期待为有用的形式
—e.g..某物可以作为论据用来感觉或作为邮件地址.
         "OTHER"显示的无规定的字符串,是由列在表单中的可打印的字符集组成.如果用
户字符串在以前的段落中没有受约束,"OTHER"可以被指定,发送加密代码,或另外返回
无用的电子用户名信息,它们都是"OTHER"将被使用时的用户(如真实的姓名或来自于文
件UNIX的口令)的例子,返回的用户字符串在指定的字符串集中将是可被打印的.
         标识符是无格式的八进制串—所有第八位必须除了000 (NUL), 012 (LF)和 015
(CR).
     N.B.—空格字符串(040)后紧跟的冒号分隔符是标识符串的一部分,不可以被忽略.响
应字符串通常是被CR/LF终止, N.B.串可以是被打印但不是必须的.
ERROR

         由于某些原因,端口的所有权并不是固定的. <add-info>指出了原因,下面是
<add-info>的形式及其具体的含义:

           INVALID-PORT
                 不管是局部或外国的端口都是不可确定的,如果它们的端口号超出
了范围(TCP端口号是1—65535)就必须返回,否则不管是整数,实数还
是其他类型,都不能被验证而作为无用的数据.

NO-USER
   被端口对指定的连接,不能被使用或不能确切的实体所承认.

HIDDEN-USER
   服务器能够鉴定使用端口的用户,但是用户要求的信息不会被返回.

UNKNOWN-ERROR
   不能测定连接的用户:原因不明.如果错误不能在上面掩盖,将返回
错误的代码值,通常,如果可能,此代码在别的场所以明确的代码反映
出来.例如,服务器要求返回的错误信息被隐藏起来.或者由于别的原
因,如果服务器执行这样的任务,它必须是规则的而且它必须认为返回
的特有错误信息是默认的.
         余下的值在本文献的最后将被详细的说明和定义,如果某工具有必要说明非规范
的错误代码,那么代码以"X"开头.
          另外,服务器可以在没有响应时自动结束询问,任何的突然中断(i.e.,客户没有
接受到EOL),不管是正确或异常的,都必须认为同样的含义: "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

       <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)>

对语法的注释：
1) 为了在不同的执行中促进协同工作,同时考虑到上文中语法空白被表
达"保守发送自由接受"的规则所了解,客户和服务器不能产生不必要的
空白,但是除了没有标志的地方都能够任意的接受空白字符.在分析响应
时,空白可以出现在任何地方,但除了没有标志.通常一些空白出现在行头
或行尾是允许的,它们用来询问或响应.但这不申请容纳用户ID的响应,
因为在操作系统类型之后的冒号之后的直到中止符CR/LF间内容都看作
用户ID的部分. 中止符CR/LF不是用户ID的部分.
2) 上面的无关紧要,服务器会将发送的空白字符限制在最有效的最合理的
范围内.客户在收到1000个字符而每收到<EOL>时可以自由的中断连接.
3) 用户IDs限制在512字节而标志限制在64字节应理解为如下:a)没有
新标志(i.e., OPSYS or ERROR-TYPE)的定义可以超过64字节.b)服务器
不能发送超过512字节用户ID,一客户必须接受最少512字节的用户ID.
由于这局限,服务器必须在开头的512字节返回重要的部分.
4) 字符集和字符集标识符必须直接指向定义的,被RFC 1340引用的,
"Assigned Numbers"或它的继承. 字符集标识符只能适用于使用者辨认
的范围—别的区域只能以US-ASCII定义和发送.
5) 虽然在上面<user-id>被定义为<octet-string>,它必须跟随<opsys-field>
  约束的格式和字符集:见上面的讨论.
6) 字符集为客户提供上下文的联系来打印或存储返回的鉴定字符.如果客
户还没有实现或承认返回的字符集,它必须把返回的鉴定字符作为OCTET
来处理,但必须增加存储或汇报字符集. OCTET串必须以16进制(0—9a-f)
被打印,存储或索引,以用来陈述客户的工具—这在不同的执行中提供了
标准的陈述.
6、安全性考虑
           协议返回的信息像主人提供的一样的可信或像组织操作着主机.例如,
在研究室有极少的PC机,在上面有设备限制了此协议返回客户所需的信
息.同时,主机接受了有危害的信息,可导致完全的错误和误解.
   本协议并非有意成为特许权或访问控制协议,最多,它提供了一些有关
连接的附加审核信息,在最坏的情况下,可能提供令人误解的,不正确的或
相反的错误信息.
  此协议返回的信息在除此以外的审核作用是很无效果的,特别的,利用
此协议信息存取控制决议—不管是主要方法(i.e., no other checks)还
是作为附属的方法,都可能削弱正常主机的安全.
  鉴定服务器应能展现关于用户的信息,实体,对象或过程都被认为是私
有的, 鉴定服务器提供的服务与一些电话公司提供的CallerID服务是大
致相同的, CallerID服务的许多的秘密事项和见解同样适用于鉴定服务
器.假如你不想正常的运行"finger"服务器,你就不可能运行本协议.
7、致谢
在这里特别感谢Dan Bernstein,他在本协议中做出了重要的补充, 并且在RFC 931中
指出了一些错误.

参考资料

   [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.

作者地址

       Michael C. St. Johns
       DARPA/CSTO
       3701 N. Fairfax Dr
       Arlington, VA 22203

       Phone: (703) 696-2271
       EMail: stjohns@DARPA.MIL
RFC1413——Identification Protocol                                               鉴定协议