RFC 2952 - Telnet Encryption: DES 64 bit Cipher Feedback 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2952
タイトル : RFC 2952 - Telnet暗号化：DES 64ビット暗号フィードバック
翻訳編集 : 自動生成

[要約] RFC 2952は、Telnetセッションの暗号化に使用されるDES 64ビットCipher Feedback（CFB）暗号化方式についての仕様です。このRFCの目的は、セキュアなTelnet通信を提供するために、データの機密性と完全性を確保するための暗号化手法を定義することです。

Network Working Group                                            T. Ts'o
Request for Comments: 2952                              VA Linux Systems
Category: Informational                                   September 2000

Telnet Encryption: DES 64 bit Cipher Feedback

Telnet暗号化：DES 64ビット暗号フィードバック

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option.

このドキュメントは、Telnet暗号化オプションを使用して、暗号フィードバックモードでDES暗号化アルゴリズムを使用する方法を指定します。

1. Command Names and Codes

1. コマンド名とコード

Encryption Type

暗号化の種類

DES_CFB64 1

Suboption Commands

サブオプションコマンド

CFB64_IV 1 CFB64_IV_OK 2 CFB64_IV_BAD 3

2. Command Meanings

2. コマンドの意味

IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

IAC SB暗号化はDES_CFB64 CFB64_IV <初期Vector> IAC SE

The sender of this command generates a random 8 byte initial vector, and sends it to the other side of the connection using the CFB64_IV command. The initial vector is sent in clear text. Only the side of the connection that is WILL ENCRYPT may send the CFB64_IV command.

このコマンドの送信者は、ランダムな8バイト初期ベクトルを生成し、CFB64_IVコマンドを使用して接続の反対側に送信します。初期ベクトルは明確なテキストで送信されます。暗号化される接続の側面のみがCFB64_IVコマンドを送信できます。

IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE

IAC SB暗号化REPLY DES_CFB64 CFB64_IV_OK IAC SE IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE

The sender of these commands either accepts or rejects the initial vector received in a CFB64_IV command. Only the side of the connection that is DO ENCRYPT may send the CFB64_IV_OK and CFB64_IV_BAD commands. The CFB64_IV_OK command MUST be sent for backwards compatibility with existing implementations; there really isn't any reason why a sender would need to send the CFB64_IV_BAD command except in the case of a protocol violation where the IV sent was not of the correct length (i.e., 8 bytes).

これらのコマンドの送信者は、CFB64_IVコマンドで受信した初期ベクトルを受け入れるか拒否します。暗号化されている接続の側面のみが、CFB64_IV_OKおよびCFB64_IV_BADコマンドを送信できます。CFB64_IV_OKコマンドは、既存の実装との逆方向の互換性のために送信する必要があります。送信者が送信されたプロトコル違反の場合を除き、送信者がCFB64_IV_BADコマンドを送信する必要がある理由は実際にはありません。

3. Implementation Rules

3. 実装ルール

Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side of the connection should do keyid negotiation using the ENC_KEYID command. Once the keyid negotiation has successfully identified a common keyid, then START and END commands may be sent by the side of the connection that is WILL ENCRYPT. Data will be encrypted using the DES 64 bit Cipher Feedback algorithm.

CFB64_IV_OKコマンドが受信されると、接続の[暗号化側]がENC_KEYIDコマンドを使用してKeyIDネゴシエーションを行う必要があります。KeyID交渉が共通のKeyIDを正常に識別したら、暗号化される接続の側面によって開始および終了コマンドが送信される場合があります。データは、DES 64ビット暗号フィードバックアルゴリズムを使用して暗号化されます。

If encryption (decryption) is turned off and back on again, and the same keyid is used when re-starting the encryption (decryption), the intervening clear text must not change the state of the encryption (decryption) machine.

暗号化（復号化）がオフになって再びオンになっている場合、暗号化（復号化）を再起動するときに同じKeyIDが使用されている場合、介在する明確なテキストは、暗号化（復号化）マシンの状態を変更してはなりません。

If a START command is sent (received) with a different keyid, the encryption (decryption) machine must be re-initialized immediately following the end of the START command with the new key and the initial vector sent (received) in the last CFB64_IV command.

別のkeyIDで開始コマンドが送信（受信）の場合、新しいキーと最後のCFB64_IVコマンドで送信された初期ベクトル（受信）を使用して、開始コマンドの終了後に暗号化（復号化）マシンを再開する必要があります。

If a new CFB64_IV command is sent (received), and encryption (decryption) is enabled, the encryption (decryption) machine must be re-initialized immediately following the end of the CFB64_IV command with the new initial vector, and the keyid sent (received) in the last START command.

新しいCFB64_IVコマンドが送信され（受信）、暗号化（復号化）が有効になっている場合、暗号化（復号化）マシンは、CFB64_IVコマンドの終了後に新しい初期ベクトルと送信されたKeyID（受信（受信）の直後に再独立化する必要があります。）最後の開始コマンドで。

If encryption (decryption) is not enabled when a CFB64_IV command is sent (received), the encryption (decryption) machine must be re-initialized after the next START command, with the keyid sent (received) in that START command, and the initial vector sent (received) in this CFB64_IV command.

CFB64_IVコマンドが送信された場合（受信）、暗号化（復号化）が有効になっていない場合、暗号化（復号化）マシンは次の開始コマンドの後に再開始する必要があり、その開始コマンドにkeyID（受信）、および初期このCFB64_IVコマンドで送信（受信）。

4. Algorithm

4. アルゴリズム

Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit vector, D[n] is the nth chunk of 64 bits of data to encrypt (decrypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted) data, then:

v [i]が初期の64ビットベクトルであることを考えると、v [n]はn第64ビットベクトル、d [n]は暗号化する（復号化）64ビットのデータのn第3塊であり、o [n]は64ビットの暗号化された（復号化された）データのn番目のチャンク、次に：

      V[0] = DES(V[i], key)
      O[n] = D[n] <exclusive or> V[n]
      V[n+1] = DES(O[n], key)

5. Integration with the AUTHENTICATION telnet option

5. 認証Telnetオプションとの統合

As noted in the telnet ENCRYPTION option specifications, a keyid value of zero indicates the default encryption key, as might be derived from the telnet AUTHENTICATION option. If the default encryption key negotiated as a result of the telnet AUTHENTICATION option contains less than 8 bytes, then the DES_CFB64 option must not be offered or used as a valid telnet encryption option. If the encryption key negotiated as a result of the telnet AUTHENTICATION option is greater than 16 bytes the first 8 bytes of the key should be used as keyid 0 for data sent from the telnet client to the telnet server, and the second 8 bytes of the key should be used as keyid 0 for data sent by the telnet server to the telnet client. Otherwise, the first 8 bytes of the encryption key is used as keyid zero for the telnet ENCRYPTION option in both directions (with the client as WILL ENCRYPT and the server as WILL ENCRYPT).

Telnet暗号化オプションの仕様に記載されているように、ゼロのKeyID値は、Telnet認証オプションから導出される可能性があるデフォルトの暗号化キーを示します。Telnet認証オプションの結果としてネゴシエートされたデフォルトの暗号化キーに8バイト未満が含まれている場合、DES_CFB64オプションを有効なTelnet暗号化オプションとして提供または使用する必要はありません。Telnet認証オプションの結果としてネゴシエートされた暗号化キーが16バイトを超える場合、キーの最初の8バイトは、TelnetクライアントからTelnetサーバーに送信されたデータのKeyID 0として使用する必要があります。キーは、TelnetサーバーからTelnetクライアントに送信されたデータのKeyID 0として使用する必要があります。それ以外の場合、暗号化キーの最初の8バイトは、両方向のTelnet暗号化オプションのKeyIDゼロとして使用されます（クライアントと同様に、暗号化と同様にサーバーを使用します）。

In all cases, if the key negotiated by the telnet AUTHENTICATION option was not a DES key, the key used by the DES_CFB64 must have its parity corrected after it is determined using the above algorithm.

すべての場合において、Telnet認証オプションによってネゴシエートされたキーがDESキーではない場合、DES_CFB64が使用するキーは、上記のアルゴリズムを使用して決定した後にパリティを修正する必要があります。

Note that the above algorithm assumes that it is safe to use a non-DES key (or part of a non-DES key) as a DES key. This is not necessarily true of all cipher systems, but we specify this behaviour as the default since it is true for most authentication systems in popular use today, and for compatibility with existing implementations. New telnet AUTHENTICATION mechanisms may specify alternative methods for determining the keys to be used for this cipher suite in their specification, if the session key negotiated by that authentication mechanism is not a DES key and and where this algorithm may not be safely used.

上記のアルゴリズムは、DESキー（または非DESキーの一部）をDESキーとして使用しても安全であると想定していることに注意してください。これは必ずしもすべての暗号システムに当てはまるわけではありませんが、今日の一般的な使用のほとんどの認証システムや既存の実装との互換性に当てはまるため、この動作をデフォルトとして指定します。新しいTelnet認証メカニズムは、その認証メカニズムによってネゴシエートされたセッションキーがDESキーではなく、このアルゴリズムが安全に使用されない場合、セッションキーがその仕様で使用されるキーを決定するための代替方法を指定する場合があります。

6. Security Considerations

6. セキュリティに関する考慮事項

Encryption using Cipher Feedback does not ensure data integrity; the active attacker has a limited ability to modify text, if he can predict the clear-text that was being transmitted. The limitations faced by the attacker (that only 8 bytes can be modified at a time, and the following 8-byte block of data will be corrupted, thus making detection likely) are significant, but it is possible that an active attacker still might be able to exploit this weakness.

暗号フィードバックを使用した暗号化は、データの整合性を確保しません。アクティブな攻撃者は、送信されているクリアテキストを予測できる場合、テキストを変更する能力が限られています。攻撃者が直面する制限（一度に8バイトのみを変更でき、次の8バイトのデータブロックが破損しているため、検出が可能になります）は重要ですが、アクティブな攻撃者はまだ可能性がありますこの弱さを活用することができます。

The tradeoff here is that adding a message authentication code (MAC) will significantly increase the number of bytes needed to send a single character in the telnet protocol, which will impact performance on slow (i.e. dialup) links.

ここでのトレードオフは、メッセージ認証コード（MAC）を追加すると、Telnetプロトコルで単一の文字を送信するのに必要なバイト数が大幅に増加し、Slow（つまりダイヤルアップ）リンクのパフォーマンスに影響を与えることです。

7. Acknowledgments

7. 謝辞

This document was originally written by Dave Borman of Cray Research with the assistance of the IETF Telnet Working Group.

この文書はもともと、IETF Telnetワーキンググループの支援を受けて、Cray ResearchのDave Bormanによって書かれました。

Author's Address

著者の連絡先

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

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。