RFC1413 日本語訳

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

コメントを求めるワーキンググループのM.の聖ジョーンズの要求をネットワークでつないでください: 1413 米国国防総省は以下を時代遅れにします。 931 1993年2月

                        Identification Protocol

識別プロトコル

Status of this Memo

この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.

このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

1.  INTRODUCTION

1. 序論

   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.

Identificationプロトコル(通称、通称、"ident"と「Identは議定書の中で述べる」)は特定のTCP接続のユーザのアイデンティティを決定する手段を提供します。 TCPポートナンバー組を考えて、それはサーバのシステムの上でその接続の所有者を特定する文字列を返します。

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

Identificationプロトコルは以前、Authentication Serverプロトコルと呼ばれました。 それは、機能をよりよく反映するために改名されました。 このドキュメントはTCP Client Identityプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。

2.  OVERVIEW

2. 概要

   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.

これはTCPにおける接続に基づいているアプリケーションです。 サーバはTCPポート113(小数)でTCP接続の聞こうとします。 接続がいったん確立されると、サーバは興味がある接続を指定するデータの系列を読みます。 存在しているなら、回答として接続の興味があるシステムに依存するユーザ識別子を送ります。 そして、サーバは下にかそれが複数の質問に読み込むか、または反応し続けるかもしれない接続を閉じるかもしれません。

   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.

サーバは構成可能な時間の後に質問なしで接続を閉鎖するべきです--60-180 2番目のアイドルタイムアウトはお勧めです。 クライアントはいつでも、接続を閉鎖するかもしれません。 しかしながら、ネットワーク遅延を考慮するために、質問を捨てて、接続を終える前に、クライアントは質問の後に少なくとも30秒(より長い)待つべきです。

St. Johns                                                       [Page 1]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[1ページ]RFC1413識別プロトコル1993年2月

3.  RESTRICTIONS

3. 制限

   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.

質問は完全に指定された接続のためだけに受入れられます。 質問は地方の、または、外国人のポート組を含んでいます--接続を完全に指定するのに使用される地方の、または、外国人のアドレス組は質問接続の地方の、そして、外国のアドレスから抜粋されます。 これは、アドレスAのユーザが接続に関するアドレスBでAとBとの間にサーバについて質問するだけであるかもしれないことを意味します。

4.  QUERY/RESPONSE FORMAT

4. 質問/応答形式

   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.

<ポートオンなサーバであるところでは、>が目標("ident"サーバが稼働しているところ)システムの上のTCPポート(小数)です、そして、<のポートオンなクライアントの>がソース(クライアント)システムの上のTCPポート(小数)です。

   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.

ホストAの上のクライアントがホストBの上で23、6191(本国行きのTELNET接続)として局所的(クライアントのマシンの上で)に指定された接続に関してサーバを尋ねたいなら、クライアントが6191、23時頃に実際に尋ねなければならないという接続がホストBの上でどのように指定されるかということであるN.B。

      For example:

例えば:

                 6191, 23

6191, 23

   The response is of the form

応答はフォームのものです。

   <port-on-server> , <port-on-client> : <resp-type> : <add-info>

<のポートオンなサーバの>、<のポートオンなクライアントの>: <resp-タイプ>: インフォメーションを加えている<>。

   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.

<のポートオンなサーバの>、<のポートオンなクライアントの>が質問と同じ組であるところでは、<resp-タイプ>は応答のタイプを特定するキーワードです、そして、インフォメーションを加えている<>は文脈に依存しています。

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

返された情報は<サーバアドレス>によって特定される完全に指定されたTCP接続にそんなに関連しています、<クライアントアドレス>、<のポートオンなサーバの>、<のポートオンなクライアントの>、<サーバアドレス>と<クライアントアドレス>が質問している接続の地方の、そして、外国のIPアドレスであるところで--すなわち、IdentificationプロトコルServerとのTCP接続。(質問から<のポートオンなサーバの>と<のポートオンなクライアントの>を取ります。)

      For example:

例えば:

         6193, 23 : USERID : UNIX : stjohns
         6195, 23 : ERROR : NO-USER

6193, 23 : ユーザID: UNIX: stjohns6195、23: 誤り: ユーザがありません。

St. Johns                                                       [Page 2]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[2ページ]RFC1413識別プロトコル1993年2月

5.  RESPONSE TYPES

5. 応答タイプ

A response can be one of two types:

応答は2つのタイプのひとりであることができます:

USERID

ユーザID

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

「文字集合(存在しているなら)はオペレーティングシステム名と切り離される」、」 文字集合識別子は、識別ストリングの文字集合を示すのに使用されます。 省略されるなら、文字集合識別子は「米国-ASCII」をデフォルトとします(以下を見てください)。

     Permitted operating system names and character set
     names are specified in RFC 1340, "Assigned Numbers" or
     its successors.

受入れられたオペレーティングシステム名と文字集合名はRFC1340、「規定番号」またはその後継者で指定されます。

     In addition to those operating system and character set
     names specified in "Assigned Numbers" there is one
     special case operating system identifier - "OTHER".

「規定番号」で指定されたそれらのオペレーティングシステムと文字集合名に加えて、1つの特別なケースオペレーティングシステム識別子があります--「他。」です。

     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.

「他」がオペレーティングシステムタイプとして指定されない場合、サーバがこの接続の所有者の「正常な」ユーザ登録名を返すと予想されます。 システム管理者によって割り当てられて、メール識別子のようなユーザによって使用されたユーザ識別子、または1ユーザ/パスワード組の「ユーザ」部分が以前はよくシステム資源へのアクセスを得ているのに従って唯一接続所有者を特定する一連のキャラクタを意味するためにこのような関係においては「標準」を取るかもしれません。 オペレーティングシステムが指定されるとき(例えば、「他」を除いた何でも)、ユーザ識別子がすぐに多少役に立つフォームにあると予想されます--例えば「弄る」議論として、または、郵便の宛先として使用できた何か。

     "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

"OTHER"は、識別子が指定された文字集合で印刷可能なキャラクタから成る非フォーマットされた文字列であることを示します。 ユーザ識別子が前のパラグラフの規制を満たさないなら、"OTHER"は指定されるべきです。 ユーザに関して暗号化された監査トークンを送るか、または他の非ユーザID情報を返します。

St. Johns                                                       [Page 3]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[3ページ]RFC1413識別プロトコル1993年2月

     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.

識別子はそうです。非フォーマットされた八重奏ストリング----8進000(NUL)、012(LF)と015(CR)を除いて、すべての八重奏が許されています。 N.B.--コロン分離符に従う間隔文字(040)は、識別子ストリングの一部であり、無視されないかもしれません。 応答ストリングはCR/LFによってまだ通常終えられています。 N.B.五弦は印刷可能であるかもしれませんが、*は必ず印刷可能な*であるというわけではありませんか?

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.

地方の、または、外国のポートは不適切に指定されました。 ポートイドのどちらかか両方を範囲(TCPポートナンバーは1-65535から来ている)、負の整数、本物から脱していたか、または非負の整数としてどんなファッションでも認識しないなら、これを返すべきです。

          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

聖ジョーンズ[4ページ]RFC1413識別プロトコル1993年2月

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

他の値は、結局、今後の改正でこのドキュメントと指定されて、定義されるかもしれません。 implementerに標準的でないエラーコードを指定する必要があるなら、そのコードは「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".

さらに、応じないで、サーバは質問接続を下げることができます。 閉じてください。少しも時期尚早である、(すなわち、優雅であるか否かに関係なく、クライアントがEOLを受け取らないものかアボートには「誤り: 未知の誤り」と同じ意味があると考えられるべきです。

FORMAL SYNTAX

正式な構文

   <request> ::= <port-pair> <EOL>

<要求>:、:= <ポート組><EOL>。

   <port-pair> ::= <integer> "," <integer>

<ポート組>:、:= 「<整数>」、」 <整数>。

   <reply> ::= <reply-text> <EOL>

<回答>:、:= <回答テキスト><EOL>。

   <EOL> ::= "015 012"  ; CR-LF End of Line Indicator

<EOL>:、:= "015 012" ; CR-LF行末インディケータ

   <reply-text> ::= <error-reply> | <ident-reply>

<回答テキスト>:、:= <エラー応答>。| <ident-回答>。

   <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>

<エラー応答>:、:= 「<ポート組>」:、」 「「誤り」」:、」 <誤りタイプ>。

   <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
                     ":" <user-id>

<ident-回答>:、:= 「<ポート組>」:、」 「「ユーザID」」:、」 「<opsys-分野>」:、」 <ユーザID>。

   <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
                    | "HIDDEN-USER" |  <error-token>

<誤りタイプ>:、:= 「無効のポート」| 「ユーザがありません」| 「未知の誤り」| 「隠されたユーザ」| <誤りトークン>。

   <opsys-field> ::= <opsys> [ "," <charset>]

<opsys-分野>:、:= <opsys>。[「」、<charset>]

   <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
               ;  (See "Assigned Numbers")

<opsys>:、:= 「他」です。| 「UNIX」| <トークン>…など ; (「規定番号」を見ます)

   <charset> ::= "US-ASCII" | ...etc.
                 ;  (See "Assigned Numbers")

<charset>:、:= 「米国-ASCII」| ...など ; (「規定番号」を見ます)

   <user-id> ::= <octet-string>

<ユーザID>:、:= <八重奏ストリング>。

   <token> ::= 1*64<token-characters> ; 1-64 characters

<トークン>:、:= 1*64<トークンキャラクタ>。 1-64 キャラクタ

   <error-token> ::= "X"1*63<token-characters>
                     ; 2-64 chars beginning w/X

<誤りトークン>:、:= 「X」1*63<トークンキャラクタ>。 2-64 Xと共に始まる雑用

St. Johns                                                       [Page 5]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[5ページ]RFC1413識別プロトコル1993年2月

   <integer> ::= 1*5<digit> ; 1-5 digits.

<整数>:、:= 1*5<ケタ>。 1-5 ケタ。

   <digit> ::= "0" | "1" ... "8" | "9" ; 0-9

<ケタ>:、:= "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.

<トークンキャラクタ>:、:= <、これらのASCII文字のいずれも: '、「a-z、A-Z--. (ダッシュ)、@#$%^と*()_=+、<>/?」 '~'、[]。 >。 上側の、そして、小文字の1zのプラス。 「コロンを引いたprintables」:、」 ; キャラクタ。

   <octet-string> ::= 1*512<octet-characters>

<八重奏ストリング>:、:= 1*512<八重奏キャラクタ>。

   <octet-characters> ::=
                  <any octet from  00 to 377 (octal) except for
                   ASCII NUL (000), CR (015) and LF (012)>

<八重奏キャラクタ>:、:= 00〜377まで<はASCII NUL(000)、CR(015)、およびLF以外のあらゆる八重奏(8進)です。(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.

1) 異形実装の中で余白に関して相互運用性を促進するために、上の構文が「あなたが送るもので保守的であってください、そして、あなたが受け入れるもので寛容であってください」哲学を具体化するのが理解されています。 クライアントとサーバは、不要な余白が(スペースとタブキャラクタ)であると生成するべきではありませんが、トークンを除いて、どこでも余白を受け入れるべきです。 構文解析応答では、トークンを除いて、余白はどこでも起こるかもしれません。 明確に、どんな量の余白も始めか線の端に質問と応答のために受入れられます。 これは終わっているCR/LFまでのオペレーティングシステムタイプの後のコロン後のすべてがユーザIDの一部としてみなされるのでユーザIDを含む応答に申し込みません。 終わっているCR/LFはユーザ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>.

2) 上記では、サーバは妥当であるか、または役に立った状態でそれらが最小量に送る相互トークン余白の量を制限するべきです。 彼らが<EOL>を受けないで1000のキャラクタを受けるなら、クライアントは遠慮なく接続を中止するべきです。

   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

3) ユーザIDにおける512キャラクタ限界とトークンにおける64キャラクタ限界が、以下の通りであることを意味するのが理解されるべきです: a) SHOULD NOTがユーザIDの512以上の八重奏を送るサーバとクライアントが少なくとも512の八重奏を受け入れなければならない長さ64以上とb)を持っている新しいトークン(すなわち、OPSYSかERROR-TYPE)トークンが全く定義されないでしょう。

St. Johns                                                       [Page 6]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[6ページ]RFC1413識別プロトコル1993年2月

        user ID.  Because of this limitation, a server MUST
        return the most significant portion of the user ID in
        the first 512 octets.

ユーザID。 この制限のために、サーバは最初の512の八重奏でユーザIDの最も重要な部分を返さなければなりません。

   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.

4) 文字集合と文字集合識別子は直接1340に定義されたか、またはRFCによって参照をつけられたものへの地図、「規定番号」またはその後継者がそうするべきです。 文字集合識別子はユーザ登録名分野に適用されるだけです--他の野原を定義されて、米国の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.

5) 上の>、<ユーザID>は<八重奏ストリングと定義されますが、書式に続けなければなりません、そして、文字集合規制は<opsysで->をさばくように含意しました。 議論が上であることを見てください。

   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) クライアントが返されたユーザ登録名ストリングを印刷するか、または保存するように、文字集合は文脈を提供します。 クライアントが返された文字集合を認めもしませんし、実装もしないなら、OCTETとして返された識別ストリングを扱うべきです、さらに、文字集合を保存するべきであるか、または報告するべきであるのを除いて。 OCTETストリングが十六進法記法で印刷されるべきであるか、保存されるべきであるか、または扱われるべきである、(0-9 1f、)、いかなる他の表現に加えたクライアント道具--これは異なる中の標準の表現に実装を提供します。

6.  Security Considerations

6. セキュリティ問題

   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.

このプロトコルによって返された情報は、ORをそれに提供しながら、ホストと高々同じくらい信頼できます。ホストを手術する組織。 例えば、ユーザにはこのプロトコルがあるのを防ぐそれにおける何かコントロールが何かユーザが欲しい識別子を返すなら、開いている研究室のPCにわずかしかありません。 同様に、ホストが感染されたなら、返された情報は、完全に誤って紛らわしいかもしれません。

   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.

Identificationプロトコルは承認かアクセス制御プロトコルとして意図しません。 せいぜい、それはTCP接続に関して何らかの追加監査の情報を提供します。 最悪の場合は、それは紛らわしいか、不正確であるか、陰湿に不正確な情報を提供できます。

   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.

監査を除いて、情報の使用がこのプロトコルで戻った、強く、がっかりしています。 明確に、プライマリメソッド(すなわち、他のチェックがない)として、または、他のメソッドへの付属物としてアクセスをコントロール決定にするプロトコル情報は正常なホストセキュリティの弱化をもたらして、Identificationを使用するかもしれません。

St. Johns                                                       [Page 7]

RFC 1413                Identification Protocol            February 1993

聖ジョーンズ[7ページ]RFC1413識別プロトコル1993年2月

   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.

Identificationサーバは通常、個人的であると考えられるかもしれないユーザ、実体、オブジェクトまたはプロセスの情報を明らかにするかもしれません。 Identificationサーバはいくつかの電話会社によって提供されたCallerIDサービスと同じプライバシー問題の多くの荒いアナログであるサービスを供給します、そして、CallerIDサービスに適用される議論はIdentificationに当てはまります。 プライバシー問題のため「指」サーバを実行しないなら、あなたはこのプロトコルを実行したがっていないかもしれません。

7.  ACKNOWLEDGEMENTS

7. 承認

   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.

主としてこのプロトコルで関心を更新して、RFC931でいくつかの煩わしい誤りを指摘するのに責任があるダン・バーンスタインに承認を与えます。

References

参照

   [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
       1985.

[1] 聖ジョーンズ、M.、「認証サーバ」、RFC931、TPSC、1985年1月。

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。

Author's Address

作者のアドレス

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

アーリントン、マイケルC.ジョーンズの聖DARPA/CSTO3701N.フェアファクスヴァージニア博士 22203

       Phone: (703) 696-2271
       EMail: stjohns@DARPA.MIL

以下に電話をしてください。 (703) 696-2271 メールしてください: stjohns@DARPA.MIL

St. Johns                                                       [Page 8]

聖ジョーンズ[8ページ]