rfc2228.txt

RFC文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail] 
译者：fantasy_lover（ [e-mail]）
译文发布时间：2001-11-4
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                            M. Horowitz 
Request for Comments: 2228                                     Cygnus Solutions 
Updates: 959                                                          S. Lunt
Category: Standards Track                                               Bellcore
															    October 1997


FTP安全扩展
（RFC2228——FTP Security Extensions）

本备忘录的当前概况：
     本文档详述了一种标准的互连网协议,其目的是为了网际社区及其相关方面的改进或
提高 而进行的探讨等活动的需求。您可以参考当前版本的"互连网正式协议标准,(STD1)"
来获得当前关于"标准化"的信息以及本文档所述协议的情况。本文档可以任意发行及使用。

版权声明：
      Copyright ? The Internet Society (1997). All Rights Reserved. 

概述：
    本文档是对FTP 规范 STD 9, RFC 959, "文件传输协议 (FTP)" (October 1985) 
的扩展 。这一扩展为传输控制和数据信道提供了强大的认证，完整性验证，以及保
密机制，同时介绍了与这些机制相关的新的可选命令及其回应和文件传输编码方式。

本协议规范介绍了以下这些新的可选命令 。

    AUTH (认证/安全机制), 
    ADAT (认证/安全数据), 
    PROT (数据信道保护等级（level）), 
    PBSZ (保护缓冲区大小), 
    CCC (清除命令通道), 
    MIC (完整性保护命令), 
    CONF (保密性保护命令), 和 
ENC (私密性保护命令). 

同时也为被保护的回应介绍了一类新的回应类型。

 以上这些命令没有要求在实际应用中必须实现，但他们之间有些存在相互的依存性，从
命令中你就会看到。    

   另外，本文档规范与 STD 9, RFC 959是兼容的. 

目录
1.简介：	2
２.ＦＴＰ安全概览	3
3.新的FTP命令	5
4.登录核准	10
5.新的FTP回应码	10
5.1 新的独有的回应码	11
5.2 保护回应	12
6. 数据信道封装	13
7．可能的策略方面的考虑	14
8.  声明的规范	14
8.1 FTP协议安全命令及其参数	15
8.2  命令—回应 顺序	15
9 状态图	16
10  BASE 64编码	18
11. 安全考虑	20
12 鸣谢	20
13 参考资料	20
14 作者地址	20
附录I	21
附录II	22
版权声明	24

1.简介：
     文件传输协议 （FTP）目前是在 STD 9, RFC 959 中定义的。并且在互联网上，
客户是通过透明文本传送它的用户名及密码（使用 USER 和 PASS 命令）从而完成
服务器端所要求的认证的。除非服务器提供匿名登录服务，否则这意味着客户正在
冒着自己被局域网或广域网上的其他人监听，从而密码被窃取的危险。这也帮助了
这些潜在的别有用心的人通过窃取的密码并且通过不能接受内部安全隐患的FTP服
务器修改文件。
    
除了需要以某种安全的方式验证用户的问题外，还有验证服务器、保护敏感数
据以及校验其完整性等问题。攻击者通过监听网络便可访问到有价值的或敏感的数
据，也能够通过此方法删除或更改正被传送的数据从而破坏其完整性。某些活跃的
攻击者甚至能假冒其选定的某个站点向另一个其选定的站点进行文件传输活动，并
且会调用这个服务器上的命令。FTP协议当前还没有提供加密或命令、回应、以及被
传输的数据的真实性的验证机制。而这些安全机制对匿名方式的文件访问也是很有
价值。

当前正在实行的安全传送文件的方法通常有以下几种：

1 通过用人工方式发布的密钥加密文件,然后用FTP进行传输的方法，

2 通过用人工方式发布的密钥加密文件,编码后再用电子邮件传送的方法，

3 通过 PEM(保密性增强的电子邮件)通讯机制传送，或

4 通过使用 rcp( 译者注：unix类系统的"远程文件复制"命令) 命令的增强功能
"Kerberos"
(参见附录II)

上述这些方法都不能说是事实上的标准,也没有一个是真正交互式操作的。因此
现在需要以一种安全的方式通过FTP安全地传送文件，这种方式由ＦＴＰ协议本身
所支持，且与以前的FTP协议相容，并且利用当前已有的为其他安全方面的应用而
构件的基础设施和技术。如果这些安全方面的服务能被引入FTP协议中，并且与协
议中原有的其他服务和睦共处的话，那么将FTP协议扩展就成为必然的事情了。

尽管ＦＴＰ协议的受控连接机制紧跟着telnet协议产生，而telnet协议的受
控连接部分随后又定义了用于认证及加密的选项[TELNET- SEC], [RFC-1123] 明确
禁止了在受控连接的时候使用telnet 选项协商功能（不同于Synch 和 IP　）。

当然，telnet协议的用于认证及加密的选项 没有提供数据完整性的保护，（没
有机密性）并且没有强调对数据信道的保护。

２.ＦＴＰ安全概览

ＦＴＰ协议的安全扩展部分从最高的起点上探寻，为用户认证（authenticating）
以及核准（authorizing）连接、数据完整性以及机密性保护命令与其相关的回应、
数据传输等提供了一种抽象的机制。

在ＦＴＰ的安全问题中，认证是一种以安全方式对客户端与服务器端身份的确
认，通常采用密码的机制，基本的ＦＴＰ协议中没有认证的概念。

认证的过程即确认一个正在登录的用户的过程，基本的认证过程包括USER, PASS, 
和　ACCT 命令。就ＦＴＰ的安全扩展来说，由某种安全机制构建起来的认证机制可
以用来做出是否接纳正在登录的用户的决定。

没有此安全扩展，就不会发生客户认证这一情况。用一个ＰＡＳＳ命令将一个
口令通过网络并采用透明文本的方式传到服务器端（server）就完成了对一个用户
的认证过程，持有此口令的某人假设被授权能够以某“用户“（此用户的名称是在认
证过程中由此人使用ＵＳＥＲ命令提供的）的身份传输文件，但是客户端(client)
的“他“的身份的合法性却永远不可能被真正确定。

ＦＴＰ安全认证的交互过程首先由客户端使用ＡＵＴＨ命令告诉服务器端他想
使用哪种认证机制开始。服务器端则接受或拒绝这种认证机制，也有可能服务器端
还没有实现安全扩展协议规定的功能，从而完全拒绝客户端的命令。客户端也可能
尝试其他的认证机制，直到有一个被服务器端接受为止。这样才可以允许进行最基
本的连接协商。（如果希望进行更复杂一些的协商的话，那只能由服务器端的安全机
制提供了。）服务器端的回应会指明客户是否必须对它所提出的安全认证机制作进一
步的解释。如果不需要的话，这意味着此种机制将会对口令（由PASS命令指定）进
行与以往不同的解释，比如标志（token）或一次性（one-time）口令系统。

如果服务器端还要求额外的安全方面的信息，那么客户端与服务器端将进入安
全数据交换阶段。客户端将用ADAT命令送出此安全数据的第一块。服务器端的回应
会指明是否数据交换阶段就此结束，或者交换有错误，或者还需要进一步的数据交
换。此时的服务器端的回应有可能包含要求客户端解译的安全数据（这种包含是可
选的）。如果服务器端还需要更多的数据的话，客户端将用ADAT命令送出下一块数
据，然后继续等待服务器端的回应。此过程可以根据需要持续任意长时间。一旦交
换完成，客户端与服务器端便建立起了安全关联，此安全关联会包括认证（对客户
端的或对服务器端的，或对双方共同进行的）和用于数据完整性／保密性的关键信
息，以上这些依赖于已使用的安全机制。  

“安全数据（security data）”这个术语并非是臆造出来的，进行安全数据交换
的目的只是在客户端与服务器端之间建立起安全关联(security associate)，就象
上面所说的那样在客户端可能不会包括任何的认证过程。例如，Diffie-Hellman 交
换产生了一个密钥，但认证过程却没有发生。如果一个FTP服务器有一个RAS公钥
对而客户端没有的话,那客户端可以确认服务器端的身份,而服务器却不能确认客户
端的身份。一旦双方建立了安全关联，作为此关联一部分的“认证”，将代替传统的
用户名/口令机制去审核并准许用户连接到服务器。同时为标识用户将在服务器上的
身份，需要用USER命令向服务器提供一个用户名。

为了防止攻击者中途篡改控制数据流中的命令，如果双方的安全关联中支持数
据完整性保护，那么客户端和服务器端必须对控制数据流实行数据完整性保护，除
非双方首先用 CCC 命令关闭了此功能。可以通过使用 MIC 和 ENC 命令及相关的
63z回应码启用数据完整性保护功能。CCC 命令必须在完整性保护下传送。如果双方
没有建立安全关联，或建立的安全关联中不支持数据完整性保护，或者某一方成功
使用了 CCC 命令，那么他们之间的用于交互的命令及回应的传送很可能就不是完整
的或稳妥的（就是说，传送的是透明数据或只是进行了加密的数据）。

如果客户端和服务器端用 PBSZ 命令协商了一块用于对在数据通道中传输的保
护数据进行封装的缓冲区，在这之前双方协商过的安全机制也可以用来保护数据通
道的传输活动。

本文档不是在制订某些一成不变的政策。特别是在协议实现方面，客户端和服
务器端可以根据双方建立的安全关联有选择的限制那些可以被实现的活动。例如，
服务器端会要求客户端通过某安全机制而不是口令方式进行登录认证，也会要求客
户端从信令（token）中提供一个一次性口令，还有会要求命令信道的保护或对某文
件编码后传输。为确保被下载文件的有效性，如果没有数据完整性保护机制的话，
与匿名服务器连接的客户端会拒绝用户对文件传输的请求。

除了下一节将要谈到的依赖性外，安全机制中不需要有特别的功能
（functionality）。这意味着认证功能，数据完整性保护功能或保密保护功能没有
要求必须实现，尽管不包括这些功能的安全机制是没有多大用处的。以下的安全机
制的实现都是可以接受的，例如只有数据完整性保护，单向认证及加密功能，或有
加密功能而无认证或完整性保护功能，或者是从策略（policy）或技术方面考虑而
要求的任何的功能子集。当然有时基于某种策略的需要，某些实际应用可能需要更
强大的安全防护以至于超过了现在所能提供的防护水平。

3.新的FTP命令

以下的命令是可选的，但它们中的某些有相互依赖性。它们是 FTP 的访问控制
命令的扩展。

文档中所述的回应码（reply code）只是介绍性的，不是必须要求写入文档的。
只意在指明回应码信息描述存在的成功和失败模式的变动，服务器端可对返回给客
户端的回应码加以限制。例如，一个服务器实行特殊的安全机制，但使用它时却有
某些策略限制，此时服务器端会返回 回应码 534，或者当它不想泄露它支持但策略
上不允许的机制时会返回回应码 504。如果服务器端某些情况下使用的回应码不是
文档中推荐的回应码的话，它应尽量保证只有此回应码的最后一个数字与推荐的回
应码不同。任何情况下，服务器端返回的回应码必须是文档中规定的，对应它所收
到命令的所有回应中的一个，并且此回应码的第一个数字必须与此情况下推荐的回
应码第一个数字相同。

认证/安全机制（AUTH） 

此命令参数部分标识发命令端支持的一种安全机制，此部分忽略大小写，参数
值必须注册自IANA（译者注：IANA既“因特网号码指派管理局”），不包括那些以“X-”
开头的且保留由本地使用的参数值。

如果服务器端不认识 AUTH 命令，它必须返回回应码 500 。

如果服务器端认识 AUTH 命令，但没有实现安全扩展，它应返回回应码502。

如果服务器端不理解指定的安全机制，它应返回回应码504。

如果服务器端不愿接受指定的安全机制，它应返回回应码534。
    
如果服务器端不能接受指定的安全机制，例如当请求的资源不可用时它应返回
回应码431。

如果服务器端愿意接受指定的安全机制，但它还需要安全数据，它必须返回回
应码334。

如果服务器端愿意接受指定的安全机制，并且不需要任何的安全数据，它必须
返回回应码234。

如果服务器端返回回应码334，它可能会包括下一节所述的“安全数据
“（security data）。
    
有些服务器允许 AUTH 命令被再次使用，以此建立新的认证过程。如果AUTH 命
令被服务器端接受，则在此之前由于使用有关安全的命令而引起的 FTP服务器任何
状态的改变都将被复位。这种情况下，服务器也必须要求用户身份的重新核准（在
第4节有关于“核准(authorize)”的解释）（就是说重新发出AUTH，PASS，和ACCT
命令的部分或全部）。

认证/安全数据（ADAT）
  
此命令参数部分代表安全数据经 base 64 编码后的字符串（参考第九节“base 
64 编码”）。如果表示“操作成功”的回应码返回给客户端，且服务器端希望将安全
数据再传回客户端，那么服务器端应会使用“ADAT=base 64编码数据”作为回应的
正文部分。

以上情况下的安全数据是由 AUTH 命令指定的安全机制的具体体现。ADAT命令
及相关的回应可使客户端和服务器端协商多种安全协议。为使双方都能意识到哪些