組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：安智平（fivestar   anzp@xanet.edu.cn）
譯文發布時間：2001－4－12
版權：本翻譯文檔可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及組織信息。

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

RFC2946 Telnet 數據加密選項
(RFC2946  Telnet Data Encryption Option)

本備忘錄狀態
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
版權聲明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.

摘要
本文檔描述了倘若telnet數據流需要機密服務時作為一種普通方法的telnet加密選項。本文檔摘要普遍使用了加密類型和代碼，但并沒專門定義一種特定的加密算法。對每一種加密算法有專門的文檔來定義實現并發布。

目錄
1．命令名稱和編碼	2
2．命令的含義	2
3．缺省配置	4
4．動機	4
5．實施規則	4
6. 安全考慮	5
7. telnet 加密的發展方向	6
8．感謝	6
9．參考資料	6
10．作者聯系方法	6
11．版權說明	7
12．鳴謝	7

1．命令名稱和編碼

   ENCRYPT         38

       加密命令
       IS                 0
       SUPPORT          1
       REPLY             2

       START             3
       END               4
       REQUEST-START    5
       REQUEST-END      6
       ENC_KEYID        7
       DEC_KEYID        8

       加密類型
       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

根據以前的實踐，今后的加密類型號將由IANA機構按照RFC 2434中描述的先來先服務策略進行分配。盡管認證類型號分配的空間已經超出8位空間（并且telnet規范中多數值都超過了8位空間），但它并不被認為已經或將要處于被耗盡的處境。并且，如果這將成為一個問題，當超過50％以上的空間被分配后，IANA將把分配請求提交至IESG或一個指定的專家以得到批準。
2．命令的含義
IAC WILL ENCRYPT
此命令的發送者同意發送已經加密的數據。
IAC WONT ENCRYPT


此命令的發送者拒絕發送已加密的數據。
IAC DO ENCRYPT
此命令的發送者同意接收已加密的數據。
IAC DONT ENCRYPT
此命令的發送者拒絕接收已加密的數據。
IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
此命令指出發送者支持何種加密類型。僅當連接的一方為DO ENCRYPT時才可能發送SUPPORT命令。目前的加密類型the Assigned Numbers document【1】的當前版本中有詳細說明。
加密類型列表中僅包括在當前會話中所實際支持的類型。如果ENCRYPT帶有AUTH選項，在此次會話鍵確定之前，絕對不能發送SUPPORT信息。否則，將無法確定所選擇的加密類型能否根據有效鍵的類型和長度進行正確初始化。
IAC SB ENCRYPT IS encryption-type ... IAC SE
此命令指出命令的發送者將使用何種加密類型及所有需要的初始化數據。僅當連接方處于WILL ENCRYPT時才能發送IS命令來初始化該加密類型的配置方案。
IAC SB ENCRYPT REPLY encryption-type ... IAC SE
此命令為初始化加密類型方案配置進一步進行初始化數據的交換。僅當連接方處于DO ENCRYPT時才能發送REPLY命令。
IAC SB ENCRYPT START keyid IAC SE
此命令指出數據流中此命令后的所有數據將通過事先協商好的數據加密方法進行加密。僅當連接方處于WILL ENCRYPT時才能發送START命令。
Keyid是一個可變長字段。當連接的某一端被告知多個密鑰時，加密機制使用keyid來標識具體使用哪一個密鑰。Keyid字段作為最重要的一項進行編碼，并且值0d被保留作為出缺省的密鑰（一般地，密鑰是在帶有AUTHENTICATION選項時的認證階段派生出來的）。Keyid字段最少為一個字節長。"keyid"的所有有效值僅為那些由DEC_KEYID命令收到的值。
IAC SB ENCRYPT END IAC SE
此命令指出數據流中此命令后的所有數據將不進行加密。僅當連接方處于WILL ENCRYPT時才能發送END命令。
IAC SB ENCRYPT REQUEST-START keyid IAC SE
此命令請求遠端開始對telnet數據流進行加密。僅當連接方為DO ENCRYPT時才能發送REQUEST-START命令。Keyid為可選項{advisory}，可以省略。
IAC SB ENCRYPT REQUEST-END IAC SE
此命令請求遠端停止對telnet數據流進行加密。僅當連接方為DO ENCRYPT時才能發送REQUEST-END命令。
IAC SB ENCRYPT ENC_KEYID keyid IAC SE
此命令請求遠端對"keyid"是否映射到一個有效密鑰進行校驗，或對由DEC_KEYID命令接收的"keyid"是否有效進行校驗。如果keyid被省略，說明不知道其它可用的keyid，試圖找到一個通用keyid的作法將會失敗。  僅當連接方WILL ENCRYPT時才能發送ENC_KEYID命令。
IAC SB ENCRYPT DEC_KEYID keyid IAC SE
此命令請求遠端對keyid是否映射到遠端的一個有效密鑰進行校驗，或對由ENC_KEYID命令收到的"keyid"是否正確進行校驗。如果keyid被省略，說明不知道其它可用的keyid，試圖找到一個通用keyid的作法將會失敗。  僅當連接方DO ENCRYPT時才能發送ENC_KEYID命令。
3．缺省配置
本選項的缺省配置是
WONT ENCRYPT
DON'T ENCRYPT
即對Telnet 數據流不作任何加密。
4．動機
Telnet協議在由某個網關以IP包形式穿越網段時沒有任何保護。對于密碼在網絡間以明文傳送將尤其危險。本選項提供一種對數據流進行加密的方法。
5．實施規則
一旦加密選項被激活，在協商階段的所有數據，包括TELNET選項，都將被加密。"IAC SB ENCRYPT START encryption-type IAC SE"命令之后的數據以8位字節形式開始加密，并以"IAC SB ENCRYPT END IAC SE"命令結束加密。
只能在連接開始時用WILL和DO為以后的連接獲得權限。ENCRYPT選項必須在雙方均聲學明。
一旦兩端主機交換了一個WILL和一個DO，發送DO ENCRYPT方必須再發送一個ENCRYPT SUPPORT命令通知遠端它所能夠接收的加密類型。在發送請求時，將其所支持的加密方案列出。只有DO命令發送者才能發送所支持的加密類型列表（IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE）。只有WILL命令發送者才能實際傳送加密數據。加密將以"IAC SB ENCRYPT START IAC SE"命令開始，以"IAC SB ENCRYPT END IAC SE"命令結束。如果收到一個START命令后，在還沒有收到一個END命令之前又收到了一個START，那么收到的第二個START將被忽略。
如果DO命令發送者希望對方開始傳送加密數據，它可發一個"IAC SB ENCRYPT REQUEST-START IAC SE"命令。如果DO命令發送者希望對方停止傳送加密數據，它可發一個"IAC SB ENCRYPT REQUEST-STOP IAC SE"命令。
如果SUPPORT命令接收者并不支持SUPPORT命令所列出的任何一個加密類型，它將發送一個"IAC SB ENCRYPT IS NULL IAC SE"命令來指出沒有共有的加密類型。同時發送一個"IAC WONT ENCRYPT"命令來關閉加密選項。
SUPPORT命令中的加密類型必須根據不同加密類型的優先權進行排序，優先權最大的應排在第一位，排在最后一位的是優先權最低的。
如果ENCRYPT選項有效，并正在接收加密數據時，接收到一個"IAC WONT ENCRYPT"同時也意味著"IAC SB ENCRYPT END IAC SE"，此后面Telnet數據流將不再加密。
以下面的例子來說明該選項的用法：

      Host1                            Host2

[主機1對主機2發出請求商議對它發送給主機1的數據進行加密問題。主機2同意對該數據進行加密來商議。]
      DO ENCRYPT
                                           WILL ENCRYPT
[Host1請求Host2一旦初始化完就使加密選項有效，并通知Host2它支持DES_CFB64.  ]
      IAC SB ENCRYPT REQUEST-START IAC
      SE
      IAC SB ENCRYPT SUPPORT DES_CFB64
      IAC SE
 [ Host2給Host1發送初始化數據.  Host1 回答接收到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 開始為發送加密數據作好準備，一旦收到REQUEST-START，就開始加密。]
IAC SB ENCRYPT START IAC SE
 [從Host2發往Host1的所有數據都已經加密。]
IAC SB ENCRYPT END IAC SE
 [從Host2發往Host1的所有數據又以明文傳送。]
支持Telnet加密選項的所有實施方法將同樣支持本規范的所有內容。
6. 安全考慮
被隔離的ENCRYPT選項提供被動攻擊的保護，但不提供主動攻擊的保護。換句話說，當別人只是查看流過網段的IP包時，它能提供一定的保護。然而，一個能夠修改數據包的攻擊者可以阻止加密選項被協商通過。
此問題可通過使用ENCRYPT選項并Telnet Authentication選項來解決。具體說，當面對主動攻擊時，在authentication-type-pair中設置為ENCRYPT_USING_TELOPT來強行進行加密協商。
另外，一個主動攻擊者可以試圖啟動或重新啟動加密選項。如果加密選項由用戶發起，并且客戶端無法進行協商使加密有效或重新生效，那么客戶端將認為這是被攻擊的，并立即終止telnet連接。
7. telnet 加密的發展方向

此規范定義了一種保證telnet數據流機密性的方法。遺憾的是此選項下提供的所有加密機制并不提供數據完整性，因為在面向流的協議中，對特定的協議要有效地提供完整性服務非常復雜。
TELNET START_TLS規范提供一種方案能夠提供機密性、完整性、壓縮及未來的工作需要的telnet加密選項。 一個可能的方法是在telnet AUTHENTICATION選項后使用TLS的匿名Diffie-Hellman方式，并且authentication 機制必須包括在TLS協商期間的client和server有關消息。
8．感謝
本文最初是由Cray Research 的Dave Borman起草的，在起草過程中得到了MIT的Theodore Ts'o the IETF Telnet Working Group的幫助。
9．參考資料
   [1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD
       8, RFC 854, May 1983.

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

   [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10．作者聯系方法
Theodore Ts'o, Editor
   VA Linux Systems
   43 Pleasant St.
   Medford, MA 02155

   Phone: (781) 391-3464
   EMail: tytso@mit.edu
11．版權說明

   Copyright (C) The Internet Society (1999).  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.

   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.

12．鳴謝
感謝Internet協會給予RFC編輯部門的資金。
RFC2946  Telnet Data Encryption Option                                RFC2946 Telnet 數據加密選項




1
RFC中文翻譯計劃