[要約] RFC 2946は、Telnetセッションのデータ暗号化オプションに関する仕様です。その目的は、Telnetセッションのデータの機密性を確保するために、暗号化を提供することです。
Network Working Group T. Ts'o
Request for Comments: 2946 VA Linux Systems
Category: Standards Track September 2000
Telnet Data Encryption Option
Telnetデータ暗号化オプション
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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 Data Streamのデータ機密性サービスを提供する一般的な方法として、Telnet暗号化オプションについて説明します。このドキュメントは、現在使用されている暗号化の種類とコードを要約していますが、特定の暗号化アルゴリズムを定義しません。各暗号化アルゴリズムのこのオプションの実装を定義する個別のドキュメントを公開します。
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
Encryption Types NULL 0 DES_CFB64 1 DES_OFB64 2 DES3_CFB64 3 DES3_OFB64 4 CAST5_40_CFB64 8 CAST5_40_OFB64 9 CAST128_CFB64 10 CAST128_OFB64 11
暗号化タイプNULL 0 DES_CFB64 1 DES_OFB64 2 DES3_CFB64 3 DES3_OFB64 4 CAST5_40_CFB64 8 CAST5_40_OFB64 9 CAST128_CFB64 10 CAST128_OFB64 11 11 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.
歴史的な慣行に続いて、RFC 2434 [3]で概説されているように、最初に提供される最初のポリシーの下で、IANAによって将来の暗号化タイプ番号が割り当てられます。認証タイプ数は8ビットの数値スペースから割り当てられているという事実にもかかわらず（Telnet仕様のほとんどの値と同様）、数値スペースが疲れ果てているか危険になるとは予想されていません。ただし、これが問題になる場合、数スペースの50％以上が割り当てられると、IANAはIESGまたは指定された専門家に割り当て要求を承認のために照会するものとします。
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は、サポート暗号化タイプリスト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].
このコマンドの送信者は、どのタイプの暗号化をサポートするかを述べています。暗号化されている接続の側面のみが、サポートコマンドを送信できます。現在のタイプの暗号化は、割り当てられた番号ドキュメント[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, 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暗号化は暗号化型です... 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.
このコマンドの送信者は、どのタイプの暗号化を使用するか、および必要な初期データを記載しています。暗号化される接続の側面のみが、暗号化型スキームを初期化するためにISコマンドを送信できます。
IAC SB ENCRYPT REPLY encryption-type ... IAC SE
IAC SB暗号化Reply Encryption-Type ... 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.
このコマンドの送信者は、暗号化型スキームを初期化するために、初期データ交換を継続しています。暗号化されている接続の側面のみが、返信コマンドを送信できます。
IAC SB ENCRYPT START keyid IAC SE
IAC SB暗号化開始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.
このコマンドの送信者は、データストリームのコマンドに続くすべてのデータは、以前に交渉されたデータ暗号化方法を介して暗号化されると述べています。暗号化される接続の側面のみが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値がデフォルトの暗号化キーを示すために予約されています（これは通常、認証オプションを使用して、認証中に導出される暗号化キーになります）。KeyIDフィールドは、少なくとも1バイトの長さでなければなりません。「keyID」の唯一の有効な値は、dec_keyIDコマンドで受信された値です。
IAC SB ENCRYPT END IAC SE
IAC SB暗号化END 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
このコマンドの送信者は、データストリームのコマンドに続くすべてのデータが暗号化されないことを述べています。暗号化される接続の側面のみが終了を送信する場合があります
IAC SB ENCRYPT REQUEST-START keyid IAC SE
IAC SB暗号化リクエストスタート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データストリームの暗号化を開始することを要求します。暗号化されている接続の側面のみが、リクエストスタートコマンドを送信できます。KeyIDはアドバイザリーのみであり、私は省略されます。
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データストリームのリモートサイドストップ暗号化を要求します。暗号化されている接続の側面のみが、リクエストエンドコマンドを送信できます。
IAC SB ENCRYPT ENC_KEYID keyid IAC SE
IAC SB暗号化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」を有効なキーにマップすることを確認することを要求します。または、dec_keyIDコマンドで受信した「keyID」が有効であることを確認します。KeyIDが省略されている場合、それは既知のKeyIDがこれ以上存在しないこと、および一般的なKeyIDを見つけようとする試みが失敗したことを意味します。暗号化される接続の側面のみがENC_KEYIDコマンドを送信できます。
IAC SB ENCRYPT DEC_KEYID keyid IAC SE
IAC SB暗号化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が省略されている場合、それは既知のKeyIDがこれ以上存在しないこと、および一般的なKeyIDを見つけようとする試みが失敗したことを意味します。暗号化されている接続の側面のみが、dec_keyidコマンドを送信できます。
The default specification for this option is
このオプションのデフォルトの仕様は次のとおりです
WONT ENCRYPT DONT ENCRYPT
暗号化しないでください
meaning there will not be any encryption of the Telnet data stream.
つまり、Telnetデータストリームの暗号化はありません。
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パケットを見ている介在するゲートウェイからの保護はありません。これは、パスワードがネットワーク上で明確なテキストとして送信される場合に特に危険です。このオプションは、データストリームを暗号化する方法を提供します。
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.
暗号化オプションが有効になると、Telnetオプションを含むネゴシエートされた方向のすべてのデータが暗号化されます。暗号化は、「IAC SB SB Encrypt Start Encryption-Type IAC SE」コマンドの直後のデータのオクテットから始まります。暗号化は、「IAC SB End IAC SE」コマンドの後に終了します。
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.
Will and Doは、接続の開始時にのみ使用され、将来の交渉の許可を取得および付与します。暗号化オプションは両方向にネゴシエートする必要があります。
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人のホストが意志とdoを交換したら、Do Encryptの送信者は暗号化サポートコマンドを送信して、リモートサイドに受け入れる意思のある暗号化の種類を知らせる必要があります。リクエストでは、サポートされている暗号化スキームのリストが送信されます。DOの送信者のみが、サポートされている暗号化タイプのリストを送信できます（IAC SB暗号化暗号化 - タイプリストIAC SE）。遺言の送信者のみが実際に暗号化されたデータを送信できます。これは、「IAC SB Encrypt Start IAC SE」コマンドを介して開始され、「IAC SB Encrypt End IAC SE」コマンドを介して終了します。スタートが受信され、その後、終了を受信する前に2回目のスタートが受信された場合、2回目のスタートは無視されます。
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.
DOの送信者がリモート側に暗号化されたデータの送信を開始することを望む場合、「IAC SB Encrypt Request-Start IAC SE」コマンドを送信できます。DOの送信者がリモート側に暗号化されたデータの送信を停止したい場合、「IAC SB SB Incrypt Request-Stop 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 SB暗号化がnull IAC SE」を送信して、暗号化タイプが共通していないことを示します。また、暗号化オプションをオフにするために、IAC Wonnt 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.
サポートコマンド内の暗号化タイプの順序は、異なる暗号化タイプの好みを示すために注文する必要があります。最初のタイプが最も優先され、最後のタイプは最も優先されません。
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 WONT DENCRYPT」の受信は、「IAC SB暗号化終了IAC SE」の受信を意味します。たとえば、Telnetデータストリームは暗号化されなくなります。
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. ]
It is expected that any implementation that supports the Telnet ENCRYPT option will support all of this specification.
Telnet暗号化オプションをサポートする実装は、この仕様のすべてをサポートすることが期待されています。
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.
単独で使用される暗号化オプションは、パッシブ攻撃に対する保護を提供しますが、アクティブな攻撃に対しては保護されません。言い換えれば、ネットワークを通過するときにIPパケットを見ている人からの保護を提供します。ただし、飛行中にパケットを変更できる攻撃者は、暗号化オプションの交渉を防ぐことができます。
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.
この欠陥は、暗号化オプションとともにTelnet認証オプションを使用して改善できます。具体的には、Authentication-Type-Pairでのencrypt_using_teloptの設定を使用して、アクティブな攻撃に直面しても暗号化を強制的に交渉できます。
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接続を終了する必要があります。
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 start_tls仕様は、秘密性、整合性、圧縮、およびTelnet暗号化の将来の作業を提供するスキームを提供します。この仕様を使用して綿密に調査する必要があります。有望なアプローチの1つは、TLSの匿名のDiffie-Hellmanモードを使用し、その後、認証メカニズムにTLS交渉中に計算されたクライアントとサーバーの完成メッセージが含まれるTelnet認証オプションが続きます。
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ワーキンググループの支援を受けて、Cray ResearchのDave Bormanによって書かれました。
[1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1] Reynolds、J。and J. Postel、「Telnet Protocol Specification」、Std 8、RFC 854、1983年5月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'o、T。およびJ. Altman、「Telnet認証オプション」、RFC 2941、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考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Theodore Ts'o, Editor VA Linux Systems 43 Pleasant St. Medford, MA 02155
Theodore TS'o、編集者VA Linux Systems 43 Pleasant St. Medford、MA 02155
Phone: (781) 391-3464 EMail: tytso@mit.edu
電話：（781）391-3464メール：tytso@mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。