RFC1412 日本語訳

Network Working Group                                       K. Alagappan
Request for Comments: 1412                 Digital Equipment Corporation
                                                            January 1993

Alagappanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1412 DEC1993年1月

                       Telnet Authentication: SPX

telnet認証: SPX

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   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.

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

1. Command Names and Codes

1. コマンド名とコード

   Authentication Types

認証タイプ

      SPX          3

SPX3

   Suboption Commands

Suboptionコマンド

      AUTH         0
      REJECT       1
      ACCEPT       2

AUTH0廃棄物1は2を受け入れます。

2.  Command Meanings

2. コマンド意味

   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH
   <SPX authentication token> IAC SE

IAC SB AUTHENTICATION IS<認証タイプ組>AUTH<SPX認証トークン>IAC SE

      This is used to pass the SPX authentication token to the remote
      side of the connection.  (A document which describes the
      authentication token syntax is forthcoming.)  The first octet of
      the <authentication-type-pair> value is SPX.  The second octet is
      a modifier to the SPX authentication type.

これは、SPX認証トークンを接続の遠隔地側に向かわせるのに使用されます。 (認証トークン構文について説明するドキュメントは用意されています。) 認証タイプ組>が評価する<の最初の八重奏はSPXです。 2番目の八重奏はSPX認証タイプへの修飾語です。

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
   <mutual response> IAC SE

IAC SB AUTHENTICATION REPLY<認証組>をタイプしているACCEPT<互いの応答>IAC SE

      This command indicates that the authentication was successful.
      After an SPX authentication exchange, both sides have securely
      established a random 8-byte key to be used as the default key for
      the ENCRYPTION option.  If the AUTH_HOW_MUTUAL bit is set in the
      second octet of the authentication-type-pair, the sender includes
      the mutual response bytes.  The receiver of the ACCEPT command
      compares the "mutual response" with its expected mutual response.

このコマンドは、認証がうまくいったのを示します。 SPX認証交換の後に、両側は、ENCRYPTIONオプションに、主要なデフォルトとして使用されるためにしっかりと無作為の8バイトのキーを設立しました。 AUTH_HOW_MUTUALビットが認証タイプ組の2番目の八重奏で設定されるなら、送付者は互いの応答バイトを入れます。 ACCEPTコマンドの受信機は「互いの応答」を予想された互いの応答と比べます。

Telnet Working Group                                            [Page 1]

RFC 1412                     SPX for Telnet                 January 1993

telnet1993年1月のためのtelnetワーキンググループ[1ページ]RFC1412SPX

      (A document which describes the mutual response syntax is forth
      coming.)  If the AUTH_HOW_ONE_WAY bit is set in the second octet
      of the authentication-type-pair, the sender includes zero bytes of
      mutual response.

(互いの応答構文について説明するドキュメントが来ながら、先へあります。) AUTH_HOW_ONE_WAYビットが認証タイプ組の2番目の八重奏で設定されるなら、送付者は互いの応答のバイトを全く入れません。

   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
   <optional reason for rejection> IAC SE

IAC SB AUTHENTICATION REPLY<認証タイプ組>のREJECTの<の任意の不合格理由>IAC SE

      This command indicates that the authentication was not successful,
      and if there is any more data in the sub-option, it is an ASCII
      text message of the reason for the rejection.

このコマンドは、認証がうまくいかなかったのを示します、そして、サブオプションにそれ以上のデータがあれば、それは拒絶の理由に関するASCIIテキストメッセージです。

3.  Implementation Rules

3. 実装規則

   Every command after the first AUTHENTICATION IS must carry the same
   set of modifiers (e.g., CLIENT|MUTUAL) for subsequent AUTHENTICATION
   IS and AUTHENTICATION REPLY commands.

最初のAUTHENTICATION ISがその後のAUTHENTICATION ISとAUTHENTICATION REPLYのために、同じセットの修飾語(例えば、CLIENT| MUTUAL)を運ばなければならなかった後にあらゆるコマンドが命令します。

   If the second octet of the authentication-type-pair has the AUTH_WHO
   bit set to AUTH_WHO_CLIENT, then the client sends the initial AUTH
   command, and the server responds with either ACCEPT or REJECT.

認証タイプ組の2番目の八重奏で_AUTH_WHO CLIENTにAUTH_WHOビットを設定するなら、クライアントは初期のAUTHコマンドを送ります、そして、サーバはACCEPTかREJECTのどちらかと共に反応します。

   If the second octet of the authentication-type-pair has the AUTH_WHO
   bit set to AUTH_WHO_SERVER, then the server sends the initial AUTH
   command, and the client responds with either ACCEPT or REJECT.

認証タイプ組の2番目の八重奏で_AUTH_WHO SERVERにAUTH_WHOビットを設定するなら、サーバは初期のAUTHコマンドを送ります、そして、クライアントはACCEPTかREJECTのどちらかと共に応じます。

4.  Examples

4. 例

   User "joe" may wish to log in as user "pete" on machine "foo".  If
   "pete" has set things up on "foo" to allow "joe" access to his
   account, then the client would send IAC SB AUTHENTICATION NAME "pete"
   IAC SE IAC SB AUTHENTICATION IS SPX AUTH <joe's spx authentication
   token> IAC SE.  The server would then authenticate the user as "joe"
   from the token information, and the server would send back either
   ACCEPT or REJECT.  If mutual authentication is being used, the server
   would include in the ACCEPT message, a mutual response.  The
   authorization check to see if "pete" is allowing "joe" to use his
   account is made after the authentication exchange is complete.
   Therefore, it is possible for the client to receive an ACCEPT
   response (based on the authentication token), but for joe to be
   denied access to log in to pete's account.

ユーザ"joe"はマシン"foo"のユーザ"pete"としてログインしたがっているかもしれません。 "pete"が彼のアカウントへの"joe"アクセスを許すために"foo"で膳立てしたなら、クライアントはIAC SB AUTHENTICATION NAME"pete"IAC SE IAC SB AUTHENTICATION IS SPX AUTH<joeのspx認証トークン>IAC SEを送るでしょう。 そして、トークン情報、およびサーバからの"joe"がACCEPTかREJECTのどちらかを返送するようにサーバはユーザを認証するでしょう。 互いの認証が使用されているなら、サーバはメッセージ、ACCEPTの互いの応答を含んでいるでしょう。 "joe"が"pete"で彼のアカウントを使用できるなら認証交換が完全になった後に見る許可検査をします。 したがって、ACCEPT応答(認証トークンに基づいている)を受けますが、クライアントがアクセスがpeteのアカウントにログインするために拒絶されるjoeのために可能であるのは可能です。

Telnet Working Group                                            [Page 2]

RFC 1412                     SPX for Telnet                 January 1993

telnet1993年1月のためのtelnetワーキンググループ[2ページ]RFC1412SPX

       Client                           Server
                                        IAC DO AUTHENTICATION
       IAC WILL AUTHENTICATION

クライアントサーバIACは認証IACウィル認証をします。

       [ The server is now free to request authentication information.
         ]

[サーバは現在、無料で認証情報を要求できます。]

                                        IAC SB AUTHENTICATION SEND SPX
                                        CLIENT|MUTUAL SPX CLIENT|ONE_WAY
                                        IAC SE

IAC SB認証はSPXクライアントを送ります。|互いのSPXクライアント|_1つの方法IAC SE

       [ The server has requested mutual SPX authentication.  If mutual
         authentication is not supported, then the server is willing to
         do one-way SPX authentication.  ]

[ サーバは互いのSPX認証を要求しました。 互いの認証がサポートされないなら、サーバは、一方向SPX認証をしても構わないと思っています。 ]

       [ The client will now respond with the name of the user that it
         wants to log in as, and the SPX authentication token.  ]

[クライアントは現在、それがログインしたがっているユーザの名前、およびSPX認証トークンで応じるでしょう。]

       IAC SB AUTHENTICATION NAME
       "pete" IAC SE
       IAC SB AUTHENTICATION IS SPX
       CLIENT|MUTUAL AUTH <spx
       authentication token
       information> IAC SE

IAC SB認証名前"pete"IAC SE IAC SB認証はSPXクライアントです。|MUTUAL AUTH<spx認証トークン情報>IAC SE

       [ The server responds with an ACCEPT command to state that the
         authentication was successful.  ]

[サーバは認証がうまくいったと述べるACCEPTコマンドで反応します。]

       [ If AUTH_HOW_MUTUAL, the server responds with the mutual
         response so the client can verify that it is really talking to
         the right server.  ]

[AUTH_HOW_MUTUALであるなら、クライアントが、それが本当に正しいサーバと話していることを確かめることができるように、サーバは互いの応答で反応します。]

       [ If AUTH_HOW_ONE_WAY, the server responds with a NULL mutual
         response, since the client is willing to trust the server
         already.  ]

[サーバはAUTH_HOW_ONE_WAYであるなら、NULLの互いの応答で反応します、クライアントが、既にサーバを信じても構わないと思っているので。]

                                        IAC SB AUTHENTICATION REPLY SPX
                                        CLIENT|MUTUAL ACCEPT <mutual
                                        response> IAC SE

IAC SB認証回答SPXクライアント|MUTUAL ACCEPTの<の互いの応答>IAC SE

Telnet Working Group                                            [Page 3]

RFC 1412                     SPX for Telnet                 January 1993

telnet1993年1月のためのtelnetワーキンググループ[3ページ]RFC1412SPX

Security Considerations

セキュリティ問題

   The ability to negotiate a common authentication mechanism between
   client and server is a feature of the authentication option that
   should be used with caution.  When the negotiation is performed, no
   authentication has yet occurred.  Therefore, each system has no way
   of knowing whether or not it is talking to the system it intends.  An
   intruder could attempt to negotiate the use of an authentication
   system which is either weak, or already compromised by the intruder.

クライアントとサーバの間の一般的な認証機構を交渉する能力は慎重に使用されるべきである認証オプションの特徴です。 交渉が実行されるとき、認証は全くまだ起こっていません。 したがって、各システムには、それが意図するシステムと話しているかどうかを知る方法が全くありません。 侵入者は、弱い認証システムの使用を交渉するのを試みることができたか、または侵入者で既に妥協しました。

Author's Address

作者のアドレス

   Kannan Alagappan
   Digital Equipment Corporation
   550 King Street, LKG1-2/A19
   Littleton, MA 01460

キング・ストリート、Kannan Alagappan DEC550LKG1-2/A19リトルトン、MA 01460

   EMail: kannan@sejour.lkg.dec.com

メール: kannan@sejour.lkg.dec.com

   Mailing List: telnet-ietf@CRAY.COM

メーリングリスト: telnet-ietf@CRAY.COM

   The working group can be contacted via the current chair:

現在のいすを通してワーキンググループに連絡できます:

   Steve Alexander
   INTERACTIVE Systems Corporation
   1901 North Naper Boulevard
   Naperville, IL 60563-8895

北のNaper Boulevardナパービル、スティーブ・アレクサンダーINTERACTIVEのシステム社1901のIL60563-8895

   Phone: (708) 505-9100 x256
   EMail: stevea@isc.com

以下に電話をしてください。 (708) 505-9100x256 EMail: stevea@isc.com

Telnet Working Group                                            [Page 4]

telnetワーキンググループ[4ページ]