RFC931 日本語訳

Network Working Group                                       Mike StJohns
Request for Comments: 931                                           TPSC
Supersedes: RFC 912                                         January 1985

ネットワークワーキンググループマイクStJohnsはコメントのために以下を要求します。 931 TPSC Supersedes: RFC912 1985年1月

                         Authentication Server

認証サーバ

STATUS OF THIS MEMO

このメモの状態

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   This is the second draft of this proposal (superseding RFC 912) and
   incorporates a more formal description of the syntax for the request
   and response dialog, as well as a change to specify the type of user
   identification returned.  Distribution of this memo is unlimited.

このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 これは、この提案(RFC912に取って代わる)の第2草案であり、返されたユーザ登録名のタイプを指定するために要求と応答対話のための構文の、より正式な記述、および変化を取り入れます。 このメモの分配は無制限です。

INTRODUCTION

序論

   The Authentication Server 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.  Suggested uses include
   automatic identification and verification of a user during an FTP
   session, additional verification of a TAC dial up user, and access
   verification for a generalized network file server.

Authentication Serverプロトコルは特定のTCP接続のユーザのアイデンティティを決定する手段を提供します。 TCPポートナンバー組を考えて、それはサーバのシステムの上でその接続の所有者を特定する文字列を返します。 提案された用途はFTPセッション、TACのダイヤルアップユーザの追加検証、および一般化されたネットワークファイルサーバのためのアクセス検証の間、ユーザの自動識別と検証を含んでいます。

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 one line of data which specifies the
   connection of interest.  If it exists, the system dependent user
   identifier of the connection of interest is sent out the connection.
   The service closes the connection after sending the user identifier.

これはTCPにおける接続に基づいているアプリケーションです。 サーバはTCPポート113(小数)でTCP接続の聞こうとします。 接続がいったん確立されると、サーバは興味がある接続を指定するデータの1つの系列を読みます。 存在しているなら、接続から接続の興味があるシステムに依存するユーザ識別子を送ります。 ユーザ識別子を送った後に、サービスは接続を終えます。

RESTRICTIONS

制限

   Queries are permitted only for fully specified connections. The
   local/foreign host pair used to fully specify the connection are
   taken from the query connection.  This means a user on Host A may
   only query the server on Host B about connections between A and B.

質問は完全に指定された接続のためだけに受入れられます。 質問接続から接続を完全に指定するのに使用される地方の、または、外国人のホスト組を取ります。 これは、Host Aの上のユーザがHost Bで接続に関してAとBとの間にサーバについて質問するだけであるかもしれないことを意味します。

StJohns                                                         [Page 1]

StJohns[1ページ]

RFC 931                                                     January 1985
Authentication Server

RFC931 1985年1月の認証サーバ

QUERY/RESPONSE FORMAT

質問/応答形式

   The server accepts simple text query requests of the form

サーバは形式の簡単なテキスト質問要求を受け入れます。

      <local-port>, <foreign-port>

<の地方のポート>、<の外国ポート>。

   where <local-port> is the TCP port (decimal) on the target (server)
   system, and <foreign-port> is the TCP port (decimal) on the source
   (user) system.

<の地方のポート>が目標(サーバ)システムの上のTCPポート(小数)であり、<の外国ポート>がソース(ユーザ)システムの上のTCPポート(小数)であるところ。

      For example:

例えば:

         23, 6191

23, 6191

   The response is of the form

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

      <local-port>, <foreign-port> : <response-type> : <additional-info>

<の地方のポート>、<の外国ポート>: <応答タイプ>: <の追加インフォメーション>。

   where <local-port>,<foreign-port> are the same pair as the query,
   <response-type> is a keyword identifying the type of response, and
   <additional info> is context dependent.

<の地方のポート>、<の外国ポート>が質問と同じ組であるところでは、<応答タイプ>は応答のタイプを特定するキーワードです、そして、<の追加インフォメーション>は文脈に依存しています。

      For example:

例えば:

         23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
         23, 6193 : USERID : TAC : MCSJ-MITMUL
         23, 6195 : ERROR : NO-USER

23, 6191 : ユーザID: MULTICS: StJohns.DODCSC.a23、6193: ユーザID: TAC: MCSJ-MITMUL23、6195: 誤り: ユーザがありません。

RESPONSE TYPES

応答タイプ

   A response can be one of two types:

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

   USERID

ユーザID

      In this case, <additional-info> is a string consisting of an
      operating system name, followed by a ":", followed by user
      identification string in a format peculiar to the operating system
      indicated.  Permitted operating system names are specified in
      RFC-923, "Assigned Numbers" or its successors.  The only other
      names permitted are "TAC" to specify a BBN Terminal Access
      Controller, and "OTHER" to specify any other operating system not
      yet registered with the NIC.

「この場合、<の追加インフォメーション>はa」があとに続いたオペレーティングシステム名から成るストリングです」、中のオペレーティングシステムに独特の形式が示したユーザ登録名ストリングが支えていて。 受入れられたオペレーティングシステム名はRFC-923、「規定番号」またはその後継者で指定されます。 受入れられた他の唯一の名前が入場管理者の、そして、まだNICに登録されていなかったいかなる他のオペレーティングシステムも指定するためには「他」のBBN端末を指定する"TAC"です。

StJohns                                                         [Page 2]

StJohns[2ページ]

RFC 931                                                     January 1985
Authentication Server

RFC931 1985年1月の認証サーバ

   ERROR

誤り

      For some reason the owner of <TCP-port> could not be determined,
      <additional-info> tells why.  The following are suggested values
      of <additional-info> and their meanings.

<TCP-ポート>の所有者が決定できなかった何らかの理由で、<の追加インフォメーション>は理由を言います。 ↓これは、<の追加インフォメーション>の提案された値とそれらの意味です。

      INVALID-PORT

無効のポート

         Either the local or foreign port was improperly specified.

地方の、または、外国のポートは不適切に指定されました。

      NO-USER

ユーザがありません。

         The connection specified by the port pair is not currently in
         use.

ポート組によって指定された接続は現在、使用中ではありません。

      UNKNOWN-ERROR

未知の誤り

         Can't determine connection owner; reason unknown.  Other values
         may be specified as necessary.

接続所有者は決定できません。 未知を推論してください。 他の値は必要に応じて指定されるかもしれません。

CAVEATS

警告

   Unfortunately, the trustworthiness of the various host systems that
   might implement an authentication server will vary quite a bit.  It
   is up to the various applications that will use the server to
   determine the amount of trust they will place in the returned
   information.  It may be appropriate in some cases restrict the use of
   the server to within a locally controlled subnet.

残念ながら、認証サーバを実装するかもしれない様々なホストシステムの信頼できることはかなり多くを変えるでしょう。 それらが返された情報に置く信頼の量を測定するのはサーバを使用する様々なアプリケーションまで達しています。 ケースがサーバの使用を局所的に制御されたサブネットに制限するのは、いくつかで適切であるかもしれません。

APPLICATIONS

アプリケーション

   1) Automatic user authentication for FTP

1) FTPのための自動ユーザー認証

      A user-FTP may send a USER command with no argument to the
      server-FTP to request automatic authentication.  The server-FTP
      will reply with a 230 (user logged in) if it can use the
      authentication.  It will reply with a 530 (not logged in) if it
      cannot authenticate the user.  It will reply with a 500 or 501
      (syntax or parameter problem) if it does not implement automatic
      authentication.  Please note that no change is needed to currently
      implemented servers to handle the request for authentication; they
      will reject it normally as a parameter problem.  This is a
      suggested implementation for experimental use only.

ユーザFTPは、自動認証を要求するために議論なしでUSERコマンドをサーバFTPに送るかもしれません。 認証を使用できると、サーバFTPは230(ログインされたユーザ)で返答するでしょう。 ユーザを認証できないと、それは530(ログインしない)で返答するでしょう。 自動認証を実装しないと、それは500か501(構文かパラメタ問題)で返答するでしょう。 認証を求める要求は現在実装しているサーバに変化が全く扱われる必要はありません。 通常、彼らはパラメタ問題としてそれを拒絶するでしょう。 これは実験用だけのための提案された実装です。

   2) Verification for privileged network operations.  For example,
   having the server start or stop special purpose servers.

2) 特権があるネットワーク操作のための検証。 例えば、サーバを持っていて、始まるか、または専用サーバを止めてください。

StJohns                                                         [Page 3]

StJohns[3ページ]

RFC 931                                                     January 1985
Authentication Server

RFC931 1985年1月の認証サーバ

   3) Elimination of "double login" for TAC and other TELNET users.

3) TACのための「二重ログイン」と他のTELNETユーザの除去。

      This will be implemented as a TELNET option.

これはTELNETオプションとして実装されるでしょう。

FORMAL SYNTAX

正式な構文

   <request>     ::= <port-pair> <CR> <LF>

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

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

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

   <reply>       ::= <reply-text> <CR> <LF>

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

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

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

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

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

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

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

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

<誤りタイプ>:、:= 無効のポート| ユーザがありません。| 未知の誤り

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

<opsys>:、:= TAC| 他| MULTICS| UNIX…など (「規定番号」を見ます)

   Notes on Syntax:

構文に関する注:

      1)  White space (blanks and tab characters) between tokens is not
      important and may be ignored.

1) トークンの間の余白(空白とタブキャラクタ)は、重要でなく、無視されるかもしれません。

      2)  White space, the token separator character (":"), and the port
      pair separator character (",") must be quoted if used within a
      token.  The quote character is a back-slash, ASCII 92 (decimal)
      ("\").  For example, a quoted colon is "\:".  The back-slash must
      also be quoted if its needed to represent itself ("\\").

2) 余白、トークン分離符キャラクタ、(「:」、)、ポート組分離符キャラクタ、(「」、)、トークンの中で使用されるなら、引用しなければなりません。 引用文字はバックスラッシュ、ASCII92(小数)です。 ("\"). 「例えば、引用されたコロンはそうです」という\:、」 また、(「\\」)と称する必要があったなら、バックスラッシュを引用しなければなりません。

Notes on User Identification Format:

ユーザ登録名形式に関する注:

   The user identifier returned by the server should be the standard one
   for the system.  For example, the standard Multics identifier
   consists of a PERSONID followed by a ".", followed by a PROJECTID,
   followed by a ".", followed by an INSTANCE TAG of one character.  An
   instance tag of "a" identifies an interactive user, and instance tag
   of "m" identifies an absentee job (batch job) user, and an instance
   tag of "z" identifies a daemon (background) user.

サーバによって返されたユーザ識別子はシステムのための標準のものであるべきです。 PROJECTIDによって続かれて、「例えば、標準のMultics識別子はa」があとに続いたPERSONIDから成ること」はa」で続きました。. 」 1つのキャラクタのインスタンスタグは支えます。 “a"のインスタンスタグは対話的なユーザを特定します、そして、「m」のインスタンスタグは欠席者仕事(バッチ・ジョブ)のユーザを特定します、そして、「z」のインスタンスタグはデーモン(バックグラウンド)ユーザを特定します。

   Each set of operating system users must come to a consensus as to

ユーザがコンセンサスに来なければならないそれぞれのセットのオペレーティングシステム

StJohns                                                         [Page 4]

StJohns[4ページ]

RFC 931                                                     January 1985
Authentication Server

RFC931 1985年1月の認証サーバ

   what the OFFICIAL user identification for their systems will be.
   Until they register this information, they must use the "OTHER" tag
   to specify their user identification.

それらのシステムのためのOFFICIALユーザ登録名は何になるでしょうか? 彼らは、それらのユーザ登録名を指定するのにこの情報を登録するまで「他」のタグを使用しなければなりません。

Notes on User Identification Translation:

ユーザ登録名翻訳に関する注:

   Once you have a user identifier from a remote system, you must then
   have a way of translating it into an identifier that meaningful on
   the local system.  The following is a sketchy outline of table driven
   scheme for doing this.

あなたには、一度、リモートシステムからのユーザ識別子があって、次にそれを識別子に翻訳する方法をローカルシステムでそんなに重要にしなければなりません。 ↓これはこれをすることのテーブルの駆動体系の不完全なアウトラインです。

   The table consists of four columns, the first three are used to match
   against, the fourth is the result.

テーブルは4つのコラムから成って、最初の3は合うのにおいて使用されていて、4番目が結果であるということです。

      USERID              Opsys     Address     Result
      MCSJ-MITMUL         TAC       26.*.*.*    StJohns
      *                   MULTICS   192.5.42.*  =
      *                   OTHER     10.0.0.42   anonymous
      MSJ                 ITS       10.3.0.44   StJohns

USERID Opsys Address Result MCSJ-MITMUL TAC 26.***StJohns*MULTICS、192.5、.42. *は*OTHER10.0.0.42匿名のMSJ ITS10.3.0.44StJohnsと等しいです。

   The above table is a sample one for a Multics system on MILNET at the
   Pentagon.  When an authentication is returned, the particular
   application using the userid simply looks for the first match in the
   table.  Notice the second line.  It says that any authentication
   coming from a Multics system on Net 192.5.42 is accepted in the same
   format.

上のテーブルはMulticsシステムのための米国国防総省のMILNETの上のサンプル1です。 認証を返すとき、単にユーザIDを使用する特定用途はテーブルで初戦を探します。 セカンドラインに注意してください。 それは、ネット192.5.42でMulticsシステムから来るどんな認証も同じ形式で受け入れられることを示します。

   Obviously, various users will have to be registered to use this
   facility, but the registration can be done at the same time the use
   receives his login identity from the system.

明らかに、この施設を使用するために様々なユーザを登録しなければならないでしょうが、使用がシステムから彼のログインのアイデンティティを受ける同時代に登録できます。

StJohns                                                         [Page 5]

StJohns[5ページ]