RFC2946 日本語訳

Network Working Group                                           T. Ts'o
Request for Comments: 2946                             VA Linux Systems
Category: Standards Track                                September 2000

コメントを求めるワーキンググループT.t o要求をネットワークでつないでください: 2946年のヴァージニアリナックスシステムカテゴリ: 標準化過程2000年9月

                     Telnet Data Encryption Option

telnetデータ暗号化オプション

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This document describes a the telnet encryption option as a generic
   method of providing data confidentiality services for the telnet data
   stream.  While this document summarizes currently utilized encryption
   types and codes, it does not define a specific encryption algorithm.
   Separate documents are to be published defining implementations of
   this option for each encryption algorithm.

このドキュメントはtelnetデータ・ストリームのためのデータの機密性サービスを提供する一般的方法としてtelnet暗号化がゆだねるaを記述します。 このドキュメントが現在利用された暗号化タイプとコードをまとめている間、それは特定の暗号化アルゴリズムを定義しません。 別々のドキュメントはそれぞれの暗号化アルゴリズムのためのこのオプションの実装を定義しながら発行されることです。

1.  Command Names and Codes

1. コマンド名とコード

   ENCRYPT         38

38を暗号化してください。

       Encryption Commands
       IS               0
       SUPPORT          1
       REPLY            2
       START            3
       END              4
       REQUEST-START    5
       REQUEST-END      6
       ENC_KEYID        7
       DEC_KEYID        8

暗号化が、命令する0サポート1回答2スタート3終わり4の要求スタート5要求終わりの6ENC_KEYID7 12月_KEYID8です。

       Encryption Types
       NULL             0
       DES_CFB64        1
       DES_OFB64        2

暗号化はヌル0DES_CFB64 1DES_OFB64 2をタイプします。

Ts'o                        Standards Track                     [Page 1]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[1ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

       DES3_CFB64       3
       DES3_OFB64       4
       CAST5_40_CFB64   8
       CAST5_40_OFB64   9
       CAST128_CFB64   10
       CAST128_OFB64   11

DES3_CFB64 3DES3_OFB64 4CAST5_40_CFB64 8CAST5_40_OFB64 9CAST128_CFB64 10 CAST128_OFB64 11

       Following historical practice, future encryption type numbers
       will be assigned by the IANA under a First Come First Served
       policy as outlined by RFC 2434 [3].  Despite the fact that
       authentication type numbers are allocated out of an 8-bit number
       space (as are most values in the telnet specification) it is not
       anticipated that the number space is or will become in danger of
       being exhausted.  However, if this should become an issue, when
       over 50% of the number space becomes allocated, the IANA shall
       refer allocation requests to either the IESG or a designated
       expert for approval.

歴史的な習慣に続いて、将来の暗号化形式数はRFC2434[3]によって概説されるようにFirst Come First Served方針の下でIANAによって割り当てられるでしょう。 8ビットの数のスペース(telnet仕様によるほとんどの値のような)から認証形式数を割り当てるという事実にもかかわらず、数のスペースがあるか、または消耗するのを危険にあるようになると予期されません。 しかしながら、IANAは数のスペースの50%以上が割り当てるようになるとこれが問題になるなら承認についてIESGか指定された専門家のどちらかに配分要求について照会するものとします。

2.  Command Meanings

2. コマンド意味

   IAC WILL ENCRYPT

IACは暗号化するでしょう。

      The sender of this command is willing to send encrypted data.

このコマンドの送付者は、暗号化されたデータを送っても構わないと思っています。

   IAC WONT ENCRYPT

IAC習慣は暗号化します。

      The sender of this command refuses to send encrypted data.

このコマンドの送付者は、暗号化されたデータを送るのを拒否します。

   IAC DO ENCRYPT

IACは暗号化します。

      The sender of this command is willing to receive encrypted data.

このコマンドの送付者は、暗号化されたデータを受け取っても構わないと思っています。

   IAC DONT ENCRYPT

IACドントは暗号化します。

      The sender of this command refuses to accept encrypted data.

このコマンドの送付者は、暗号化されたデータを受け入れるのを拒否します。

   IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE

IAC SB ENCRYPT SUPPORT暗号化型の並びIAC SE

      The sender of this command is stating which types of encryption it
      will support.  Only the side of the connection that is DO ENCRYPT
      may send the SUPPORT command.  The current types of encryption are
      listed in the current version of the Assigned Numbers document
      [1].

このコマンドの送付者は、それがどのタイプの暗号化をサポートするかを述べています。 DO ENCRYPTである接続の側面だけがSUPPORTコマンドを送るかもしれません。 暗号化の現在のタイプはAssigned民数記ドキュメント[1]の最新版で記載されています。

      The encryption-type-list may only include types which can actually
      be supported during the current session.  If ENCRYPT is negotiated
      in conjunction with AUTH the SUPPORT message MUST NOT be sent
      until after the session key has been determined.  Otherwise,

暗号化型の並びは実際に現在のセッションの間にサポートすることができるタイプを含んでいるだけであるかもしれません。 AUTHに関連してENCRYPTを交渉するなら、セッションキーが断固としている後までSUPPORTメッセージを送ってはいけません。 そうでなければ

Ts'o                        Standards Track                     [Page 2]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[2ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

      it is impossible to know if the selected encryption type can be
      properly initialized based upon the type and length of the key
      that is available."

「適切に利用可能なキーのタイプと長さに基づいた状態で選択された暗号化タイプを初期化できるかどうかを知るのは不可能です。」

   IAC SB ENCRYPT IS encryption-type ... IAC SE

IAC SB ENCRYPT ISは暗号化でタイプします… IAC SE

      The sender of this command is stating which type of encryption to
      use, and any initial data that is needed.  Only the side of the
      connection that is WILL ENCRYPT may send the IS command to
      initialize the encryption-type scheme.

このコマンドの送付者は、どのタイプの暗号化を使用するかを述べて、必要であるあらゆる初期のデータです。 WILL ENCRYPTである接続の側面だけが発信するかもしれない、コマンドは暗号化タイプ体系を初期化することになっていますか?

   IAC SB ENCRYPT REPLY encryption-type ... IAC SE

IAC SB ENCRYPT REPLYは暗号化でタイプします… IAC SE

      The sender of this command is continuing the initial data exchange
      in order to initialize the encryption-type scheme.  Only the side
      of the connection that is DO ENCRYPT may send the REPLY command.

このコマンドの送付者は、暗号化タイプ体系を初期化するために初期のデータ交換を続けています。 DO ENCRYPTである接続の側面だけがREPLYコマンドを送るかもしれません。

   IAC SB ENCRYPT START keyid IAC SE

IAC SB ENCRYPT START keyid IAC SE

      The sender of this command is stating that all data following the
      command in the data stream will be be encrypted via the previously
      negotiated method of data encryption.  Only the side of the
      connection that is WILL ENCRYPT may send the START command.

このコマンドの送付者は、データ・ストリームでコマンドに続くデータがそうするのが、データ暗号化の以前に交渉されたメソッドで暗号化されることであると述べています。 WILL ENCRYPTである接続の側面だけがSTARTコマンドを送るかもしれません。

      The keyid is a variable length field.  It is used by various
      encryption mechanisms to identify which encryption key is to be
      used, when multiple encryption keys might be known on either side
      of the connection.  The keyid field is encoded with the most
      significant byte first, and a keyid value of zero is reserved to
      indicate the default encryption key (this would typically be an
      encryption key derived during authentication, with the
      AUTHENTICATION option).  The keyid field must be at least one byte
      long.  The only valid values for "keyid" will be those that have
      been received in a DEC_KEYID command.

keyidは可変長フィールドです。 それは様々な暗号化メカニズムによって使用されて、どの暗号化キーが使用されていることになっているかを特定します、複数の暗号化キーが接続のどちらの側面でも知られているかもしれないなら。 keyid分野は最初に最も重要なバイトでコード化されます、そして、ゼロのkeyid値は、デフォルト暗号化キーを示すために予約されます(これが通常、認証の間に引き出された暗号化キーでしょう、AUTHENTICATIONオプションで)。 keyid分野は長さ少なくとも1バイトでなければなりません。 "keyid"のための唯一の有効値が12月_KEYIDコマンドで受け取られたものになるでしょう。

   IAC SB ENCRYPT END IAC SE

IAC SBは終わりのIAC SEを暗号化します。

      The sender of this command is stating that all data following the
      command in the data stream will not be encrypted.  Only the side
      of the connection that is WILL ENCRYPT may send the END

このコマンドの送付者は、データ・ストリームでコマンドに続くすべてのデータが暗号化されるというわけではないと述べています。 WILL ENCRYPTである接続の側面だけがENDを送るかもしれません。

   IAC SB ENCRYPT REQUEST-START keyid IAC SE

IAC SB ENCRYPT REQUEST-START keyid IAC SE

      The sender of this command requests that the remote side begin
      encryption of the telnet data stream.  Only the side of the
      connection that is DO ENCRYPT may send the REQUEST-START command.
      The keyid is only advisory, and my be omitted.

このコマンドの送付者は、遠隔地側がtelnetデータ・ストリームの暗号化を始めるよう要求します。 DO ENCRYPTである接続の側面だけがREQUEST-STARTコマンドを送るかもしれません。 そして、keyidが唯一の状況報告である、私、省略されてください。

Ts'o                        Standards Track                     [Page 3]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[3ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

   IAC SB ENCRYPT REQUEST-END IAC SE

IAC SBは要求終わりのIAC SEを暗号化します。

      The sender of this command requests that the remote side stop
      encryption of the telnet data stream.  Only the side of the
      connection that is DO ENCRYPT may send the REQUEST-END command.

このコマンドの送付者は、遠隔地側がtelnetデータ・ストリームの暗号化を止めるよう要求します。 DO ENCRYPTである接続の側面だけがREQUEST-ENDコマンドを送るかもしれません。

   IAC SB ENCRYPT ENC_KEYID keyid IAC SE

IAC SB ENCRYPT ENC_KEYID keyid IAC SE

      The sender of this requests that the remote side verify that
      "keyid" maps to a valid key; or verifies that the "keyid" received
      in a DEC_KEYID command is valid.  If keyid is omitted, it implies
      that there are no more known keyids, and that the attempt to find
      a common keyid has failed.  Only the side of the connection that
      is WILL ENCRYPT may send the ENC_KEYID command.

この送付者は、遠隔地側がその"keyid"地図について有効なキーに確かめるよう要求します。 または、12月_KEYIDコマンドで受け取られた"keyid"が有効であることを確かめます。 keyidが省略されるなら、それはkeyidsがもう少し知られていなくて、一般的なkeyidを見つける試みが失敗したのを含意します。 WILL ENCRYPTである接続の側面だけがENC_KEYIDコマンドを送るかもしれません。

   IAC SB ENCRYPT DEC_KEYID keyid IAC SE

IAC SB ENCRYPT DEC_KEYID keyid IAC SE

      The sender of this requests that the remote side verify that
      "keyid" maps to a valid key on the remote side; or verifies that
      the "keyid" received in a ENC_KEYID command is valid.  If keyid is
      omitted, it implies that there are no more known keyids, and that
      the attempt to find a common keyid has failed.  Only the side of
      the connection that is DO ENCRYPT may send the DEC_KEYID command.

この送付者は、遠隔地側が遠隔地側でその"keyid"地図について有効なキーに確かめるよう要求します。 または、ENC_KEYIDコマンドで受け取られた"keyid"が有効であることを確かめます。 keyidが省略されるなら、それはkeyidsがもう少し知られていなくて、一般的なkeyidを見つける試みが失敗したのを含意します。 DO ENCRYPTである接続の側面だけが12月_KEYIDコマンドを送るかもしれません。

3.  Default Specification

3. デフォルト仕様

   The default specification for this option is

このオプションのためのデフォルト仕様はそうです。

      WONT ENCRYPT
      DONT ENCRYPT

習慣がドントを暗号化する、暗号化

   meaning there will not be any encryption of the Telnet data stream.

そこでの意味はTelnetデータ・ストリームのどんな暗号化にもならないでしょう。

4.  Motivation

4. 動機

   The Telnet protocol has no form of protection from some intervening
   gateway looking at IP packets as they travel through the network.
   This is especially dangerous when passwords are sent as clear text
   over the network.  This option provides a method for encrypting the
   data stream.

Telnetプロトコルで、ある介入しているゲートウェイからの保護のどんなフォームも、ネットワークを通って旅行するので、IPパケットを見ません。 クリアテキストとしてネットワークの上にパスワードを送るとき、これは特に危険です。 このオプションはデータ・ストリームを暗号化するためのメソッドを提供します。

5.  Implementation Rules

5. 実装規則

   Once the Encryption option is in effect, all data in the negotiated
   direction, including TELNET options, is encrypted.  Encryption begins
   with the octet of data immediately following the "IAC SB ENCRYPT
   START encryption-type IAC SE" command.  Encryption ends after the
   "IAC SB ENCRYPT END IAC SE" command.

Encryptionオプションがいったん有効になると、TELNETオプションを含む交渉された方向によるすべてのデータが暗号化されています。 データの八重奏がすぐに「IAC SB ENCRYPT START暗号化タイプIAC SE」コマンドに続いていて、暗号化は始まります。 暗号化は「IAC SBは終わりのIAC SEを暗号化する」というコマンドの後に終わります。

Ts'o                        Standards Track                     [Page 4]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[4ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

   WILL and DO are used only at the beginning of the connection to
   obtain and grant permission for future negotiations.  The ENCRYPT
   option must be negotiated in both directions.

してください。そして、単に得る接続と交付金許可の始めに今後の交渉に使用されるでしょう。 両方の方向とENCRYPTオプションを交渉しなければなりません。

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side
   know the types of encryption it is willing to accept.  In the
   request, a list of supported encryption schemes is sent.  Only the
   sender of the DO may send a list of supported encryption types (IAC
   SB ENCRYPT SUPPORT encryption-type-list IAC SE).  Only the sender of
   the WILL may actually transmit encrypted data.  This is initiated via
   the "IAC SB ENCRYPT START IAC SE" command, and terminated via the
   "IAC SB ENCRYPT END IAC SE" command.  If a START is received, and
   then a second START is received before receiving an END, the second
   START is ignored.

2人のホストがいったんウィルとaがするaを交換すると、DO ENCRYPTの送付者はそれが受け入れても構わないと思っている暗号化のタイプの遠隔地側を知らせるENCRYPT SUPPORTコマンドを送らなければなりません。 要求では、サポートしている暗号化体系のリストを送ります。 してください。送付者だけ、サポートしている暗号化タイプ(IAC SB ENCRYPT SUPPORT暗号化型の並びIAC SE)のリストを送ってもよいです。 ウィルの送付者だけが実際に暗号化されたデータを送るかもしれません。 これは、「IAC SBはスタートIAC SEを暗号化する」というコマンドで開始されて、「IAC SBは終わりのIAC SEを暗号化する」というコマンドで終えられます。 STARTが受け取られていて、次に、ENDを受ける前に第2のSTARTを受け取るなら、第2STARTを無視します。

   If the sender of the DO would like the remote side to begin sending
   encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE"
   command.  If the sender of the DO would like the remote side to stop
   sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP
   IAC SE" command.

遠隔地側に発信し始めて欲しいです。送付者である、する、暗号化されたデータ、それは「IAC SBは始めを要求しているIAC SEを暗号化する」というコマンドを送ることができます。 遠隔地側に、発信するのを止めて欲しいです。送付者である、する、暗号化されたデータ、それは「IAC SBは随時停留所IAC SEを暗号化する」というコマンドを送ることができます。

   If the receiver of the SUPPORT command does not support any of the
   encryption types listed in the SUPPORT command, it should send an
   "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there are no
   encryption types in common.  It may also send an IAC WONT ENCRYPT
   command to turn off the ENCRYPT option.

ヌルはIAC SEです。SUPPORTコマンドの受信機がSUPPORTコマンドで記載された暗号化タイプのいずれもサポートしないなら、発信するべきである、「IAC SBが暗号化する、」 暗号化が全くないのを示すのを一般的にタイプされます。 また、それはENCRYPTオプションをオフにするIAC WONT ENCRYPTコマンドを送るかもしれません。

   The order of the encryption types in a SUPPORT command must be
   ordered to indicate a preference for different encryption types, the
   first type being the most preferred, and the last type the least
   preferred.

異なった暗号化タイプ、大部分であることが好んだ最初のタイプ、および最少が好んだ最後のタイプのために優先を示すようにSUPPORTコマンドにおける、暗号化タイプの注文を注文しなければなりません。

   If the ENCRYPT option has been enabled, and encrypted data is being
   received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of
   an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no
   longer encrypted.

「IAC SBは終わりのIAC SEを暗号化する」例えばtelnetデータが流れます。ENCRYPTオプションが可能にされたなら、暗号化されたデータが受け取る領収書である、「IAC習慣は暗号化する」、領収書を含意する、もう暗号化されません。

Ts'o                        Standards Track                     [Page 5]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[5ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

   The following example demonstrates the use of the option:

以下の例はオプションの使用を示します:

      Host1                            Host2

Host1 Host2

      [ Host1 requests Host2 negotiate the encryption of data that
        Host2 sends to Host1.  Host2 agrees to negotiate the encryption
        of data that it sends to Host1.  ]
      DO ENCRYPT
                                           WILL ENCRYPT
      [ Host1 requests that Host2 enable encryption as soon as the
        initialization is completed, and informs Host2 that is supports
        DES_CFB64.  ]
      IAC SB ENCRYPT REQUEST-START IAC
      SE
      IAC SB ENCRYPT SUPPORT DES_CFB64
      IAC SE
      [ Host2 sends the initial feed to Host1.  Host1 acknowledges
        receipt of the IV.  ]
                                       IAC SB ENCRYPT IS DES_CFB64
                                       CFB64_IV  144 146 63 229 237 148
                                       81 143 IAC SE
      IAC SB ENCRYPT REPLY DES_CFB64
      CFB64_IV_OK  103 207 181 71 224
      55 229 98 IAC SE
      [ Host2 is now free to start sending encrypted data, and since a
        REQUEST-START was received, it enables encryption.  ]
                                       IAC SB ENCRYPT START IAC SE
      [ All data from Host2 to Host1 is now encrypted.  ]
                                       IAC SB ENCRYPT END IAC SE
      [ All data from Host2 to Host1 is now in clear text again.  ]

Host1要求Host2はHost2がHost1に送るデータの暗号化を交渉します。[Host2は、それがHost1に送るデータの暗号化を交渉するのに同意します。] DO ENCRYPT WILL ENCRYPT[Host1は初期化が終了しているとすぐに、Host2が暗号化を可能にするよう要求して、サポートDES_CFB64であるHost2に知らせます。] Host2は初期の給送をHost1に送ります。IAC SB ENCRYPT REQUEST-START IAC SE IAC SB ENCRYPT SUPPORT DES_CFB64 IAC SE[Host1はIVの領収書を受け取ったことを知らせます。] IAC SB ENCRYPT IS DES_CFB64 CFB64_IV144 146 63 229 237 148 81 143IAC SE IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK103 207 181 71、224、55、229、98IAC SE[Host2は、現在、自由に暗号化されたデータを送り始めることができて、REQUEST-STARTを受け取ったので、暗号化を可能にします。] IAC SB ENCRYPT START IAC SE[すべてのHost2からHost1までのデータが現在、暗号化されます。] IAC SBは終わりのIAC SEを暗号化します。[すべてのHost2からHost1までのデータが再び現在、クリアテキストにあります。]

   It is expected that any implementation that supports the Telnet
   ENCRYPT option will support all of this specification.

Telnet ENCRYPTがオプションであるとサポートするどんな実装もこの仕様のすべてをサポートすると予想されます。

6.  Security Considerations

6. セキュリティ問題

   The ENCRYPT option used in isolation provides protection against
   passive attacks, but not against active attacks.  In other words, it
   will  provide protection from someone who is just watching the IP
   packets as they pass through the network.  However, an attacker who
   is able to modify packets in flight could prevent the ENCRYPT option
   from being negotiated.

分離して使用されるENCRYPTオプションは、受け身の攻撃に対する保護を提供しますが、活発な攻撃に対して提供するというわけではありません。 言い換えれば、それはそれらが通るときただIPパケットを見ているだれかからネットワークまで保護を提供するでしょう。 しかしながら、飛行でパケットを変更できる攻撃者は、ENCRYPTオプションが交渉されるのを防ぐことができました。

   This flaw can be remedied by using the Telnet Authentication option
   alongside the ENCRYPT option.  Specifically, setting
   ENCRYPT_USING_TELOPT in the authentication-type-pair can be used to
   force that Encryption be negotiated even in the face of active
   attacks.

ENCRYPTオプションと並んでTelnet Authenticationオプションを使用することによって、この欠点を改善できます。 _明確に、ENCRYPTを設定して、Encryptionが活発な攻撃に直面してさえ交渉させられるのに認証タイプ組におけるUSING_TELOPTを使用できます。

Ts'o                        Standards Track                     [Page 6]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[6ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

   In addition, an active attacker can interfere with attempts to start
   or restart encryption.  If encryption is requested by the user, and
   the client is unable to negotiate enabling or re-enabling encryption,
   the client must assume that it is being attacked, and MUST
   immediately terminate the telnet connection.

さらに、活発な攻撃者は始まるか、または暗号化を再開する試みを妨げることができます。 暗号化がユーザによって要求されていて、クライアントが可能であるか再可能な暗号化を交渉できないなら、クライアントは攻撃されていて、すぐにtelnet接続を終えなければならないと仮定しなければなりません。

7.  Future directions for Telnet Encryption

7. Telnet Encryptionのための将来の方向

   The specification defines a method for providing data confidentiality
   to the telnet data stream.  Unfortunately all of the encryption
   mechanism provided under this option do not provide data integrity,
   because of the complexity of specifying a protocol which provided
   integrity services efficiently in a stream-oriented protocol.

仕様はtelnetデータ・ストリームにデータの機密性を提供するためのメソッドを定義します。 残念ながら、このオプションで提供された暗号化メカニズムのすべてがデータ保全を提供しません、効率的にストリーム指向のプロトコルに保全サービスを提供したプロトコルを指定する複雑さのために。

   The TELNET START_TLS specification provides a scheme which provides
   confidentiality, integrity, and compression, and future work for
   telnet encryption should closely examine using this specification.
   One promising approach would use the anonymous Diffie-Hellman mode of
   TLS, followed by the telnet AUTHENTICATION option where the
   authentication mechanism would include the client and server finished
   messages computed during the TLS negotiation.

この仕様を使用する仕様が秘密性、保全、および圧縮を提供する体系を提供して、telnet暗号化のための今後の活動が密接に調べるべきであるTELNET START_TLS。 1つの有望なアプローチが認証機構がクライアントを含んで、サーバがTLS交渉の間に計算されたメッセージを終えたtelnet AUTHENTICATIONオプションがあとに続いたTLSの匿名のディフィー-ヘルマンモードを使用するでしょう。

8.  Acknowledgments

8. 承認

   This document was originally written by Dave Borman of Cray Research,
   with the assistance of Theodore Ts'o of MIT and the IETF Telnet
   Working Group.

このドキュメントは元々クレイリサーチのデーヴ・ボーマンによって書かれました、MITのセオドアTs'oの支援とIETF Telnet作業部会と共に。

9.  References

9. 参照

   [1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD
       8, RFC 854, May 1983.

[1] レイノルズとJ.とJ.ポステル、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。

   [2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941,
       September 2000.

[2] t oとT.とJ.アルトマン、「telnet認証オプション」、RFC2941、2000年9月。

   [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[3]Alvestrand、H.とT.Narten、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

10.  Author's Address

10. 作者のアドレス

   Theodore Ts'o, Editor
   VA Linux Systems
   43 Pleasant St.
   Medford, MA 02155

快い聖メドフォード、エディタヴァージニアリナックスSystems43MA セオドアTs'o、02155

   Phone: (781) 391-3464
   EMail: tytso@mit.edu

以下に電話をしてください。 (781) 391-3464 メールしてください: tytso@mit.edu

Ts'o                        Standards Track                     [Page 7]

RFC 2946             Telnet Data Encryption Option        September 2000

規格が[7ページ]RFC2946telnetデータ暗号化オプション2000年9月に追跡するt o

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Ts'o                        Standards Track                     [Page 8]

規格が追跡するt o[8ページ]