RFC 2228

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com 
译者：fantasy_lover（ a_ljun@263.net）
译文发布时间：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命令
及相关的回应可使客户端和服务器端协商多种安全协议。为使双方都能意识到哪些
可选安全协议对双方是可用的，双方的安全数据交换中必须包含足够多的信息。例
如如果客户端不支持数据加密，服务器必须能意识到，因此它不会发送加密的命令
回应。为确保命令不被删除，改变顺序或重发，在此强烈建议在安全机制中加入命
令信道序列化功能。
    
ADAT 命令必须在 AUTH 命令执行成功后发出，并且在安全数据交换完成之后
（无论交换成功与否）不能被使用，除非又在此后使用 AUTH 命令使服务器返回初
始安全状态。

如果服务器没有收到 AUTH 命令，或当安全数据交换完成而服务器的安全状态
还没有用 AUTH 命令复位时，它应返回回应码 503 。
    
如果服务器不能解码由base 64 编码的参数，它应返回回应码 501。
    
如果服务器拒绝客户端传来的安全数据（例如校验和错误），它应返回回应码 
535 。
 
如果服务器接受了安全数据，并且还需要额外的安全数据，则它应返回回应码
335。

如果服务器接受了安全数据，但不再需要任何额外数据的话（例如，安全数据
交换成功结束），它必须返回回应码 235。

 如果服务器返回的回应码是 235 或 335 时，那么在它回应的正文部分会包含
如上所述的安全数据。

如果 ADAT 命令返回错误，安全数据交换将失败，则此时客户端必须复位其内
部的安全状态。如果客户端变得与服务器端不同步时（例如，当服务器返回一个由 
AUTH 命令产生的回应码 234 时，但客户端此时还有更多的数据要传送），客户端必
须使服务器端的安全状态复位。

保护缓冲区尺寸（PBSZ）
此命令的参数是一个十进制整数，它表示在文件传输期间，能够发送或接收的
编码数据块的最大字节数。此数值不能超出一个32位无符号整数所能表示的范围。
    
此命令允许客户端和服务器端为连接而协商一块最大的保护缓冲区。此缓冲区
没有默认值，在客户端能使用 PROT 命令前必须先使用 PBSZ 命令。

PBSZ 命令必须在安全数据交换成功完成之后发出。

如果服务器端不能从语法上解析 PBSZ 命令的参数，或它不适应32位的二进制
值，它应返回回应码501。

如果服务器端还未完成与客户端的数据交换，它应返回回应码503。

否则服务器端必须返回回应码200。如果客户端所提出的缓冲区尺寸对服务器来
说过大，它必须在回应的正文中用“PBSZ=数值”形式的字符串指明一个小一些的缓
冲区尺寸。此时，客户端和服务器端必须使用那个较小的数值作为缓冲区尺寸值。

数据信道防护等级（PROT）

此命令参数是描述数据信道防护等级的一个由Telnet协议规定的字符代码。

此命令指示服务器，客户端与服务器端之间将使用哪种类型的数据信道保护。
如下代码被指定：

C - Clear 
S - Safe 
E - Confidential 
P - Private
    
如果其他等级没有被指定，则默认等级是 Clear 。Clear 防护级指数据信道将
传送文件的原始数据，既此文件未经任何安全处理。Safe防护级指数据将使用数据
完整性机制加以保护。Confidential 保护级指数据将使用保密机制保护。Private 
保护级指数据将同时使用数据完整性机制和和保密机制加以保护。

某一安全机制可以不必提供以上所有的数据信道防护等级。当然它也可以在某
一防护等级提供比要求中更多的数据保护机制（比如，某安全机制提供保密保护机
制，但由于API（应用程序编程接口）或其他方面的考虑，又在编码过程中加入了数
据完整性保护机制。

PROT 命令必须在客户与服务器双方商定保护缓冲区大小后才能发出。

如果服务器不理解 PROT 命令中指定的防护等级，它应返回回应码504。
   
如果当前安全机制不支持指定的防护等级，服务器返回回应码536。

如果服务器还未与客户端完成关于保护缓冲区尺寸大小的协商，它应返回回应
码503。

如果以前客户端从未发出过 PBSZ 命令，则客户端发出的 PROT 命令将被服务
器拒绝，同时返回回应码503。

如果服务器不愿接受指定的防护等级，它应返回回应码534。

如果服务器不能够接受指定的防护等级，例如如果某一所需资源不可用，它应
返回回应码431。

否则，服务器必须返回回应码200以表明它接受了客户端指定的防护等级。

清空命令信道（CCC）

    此命令无参数。

某些环境下使用某一安全机制认证及核准客户端和服务器端，但不对随后的命
令进行任何完整性检查，这种做法是可取的。它将会被使用在如下的环境中，在此
环境中的IP层安全将不被忽视，以此确保主机身份被完全确认，并且TCP协议数据
流不被干扰，而在此环境中用户身份认证还是要求的。

如果在任何的连接过程中的命令未受保护，攻击者就能在控制数据流中插入某
一命令，而服务器将没有办法知道它是无效的。为了防止此类攻击，一旦安全数据
交换成功完成，如果安全机制支持数据完整性保护，那么此完整性保护功能（通过 
MIC 或ENC 命令和相应的回应码631，或632来实现）必须被使用，直到使用CCC 命
令使命令信道失去对消息的完整性保护功能。CCC 命令本身必须在完整性保护之下
使用。

当CCC命令执行成功后，如果某一发出的命令不被完整性机制保护，那么对此
命令的回应也必定不被完整性机制保护。因为客户端发出CCC命令后将不再支持数
据完整性保护，由此显然此举是为支持客户端与服务器端的互操作性的
（interoperability）。

此命令必须在安全数据交换成功完成之后使用。
 
如果此命令没有在完整性机制保护之下使用，服务器端必须返回回应码533。

如果服务器不愿关闭完整性保护功能，它应返回回应码534。

否则，服务器必须返回回应码200以表明命令信道上将传送没有保护的命令及
回应。

数据完整性保护命令（MIC）和
保密性保护命令（CONF）和
私密性保护命令（ENC）

MIC命令的参数是一些Telnet协议中规定的字符串，此字符串是由经过base64
编码的‘安全‘信息构成，而此安全信息则由安全机制中专门进行信息完整性保护
的过程所产生。 CONF命令的参数是一些Telnet协议中规定的字符串，此字符串是
由经过base64编码的‘保密‘信息构成，而此安全信息则由安全机制中专门进行保
密性保护的过程所产生。 ENC命令的参数是一些Telnet协议中规定的字符串，此字
符串是由经过base64编码的‘私密‘信息构成，而此安全信息则由安全机制中专门
进行信息完整性保护和保密性保护的过程所产生。

服务器端将解码及校验这些经base 64 编码的信息。

这些命令必须在成功进行安全数据交换后才能使用。

某服务器可能会要求CCC命令是在成功进行数据交换后使用的第一个命令，而
在此命令使用之前全然不会理睬如上的保护性命令，此种情形下，服务器端应返回
回应码502。

如果服务器不能解码由base64方式编码的命令参数，它应返回回应码501。

如果服务器还未完成与客户端的安全数据交换，它应返回回应码503。

如果服务器在某一支持数据完整性保护的安全机制下完成了与客户端的安全数
据交换，但由于策略或某些机制实现方面的限制，它还需要收到一个CCC命令，它
应返回回应码503。

如果服务器因不支持当前的安全机制而拒绝此命令的话，它应返回回应码537。

如果服务器拒绝接受此命令（例如校验和错误），它应返回回应码535。

如果服务器不愿接受此命令（例如，由某些策略决定的私密性，或者是在收到
CCC命令之前先收到了一个CONF命令），它应返回回应码533。

否则，此命令将被作为FTP协议命令所解释。命令行上不需要包含有行结束码，
但某命令行包含了行结束码，则它必须是 Telnet协议中规定的行结束码，而非本地
（local）的行结束码。
  
某些情况下或是任何可能情况下，服务器会要求所有命令被保护。这样除了
MIC,CONF,和ENC命令外，它应对其它命令返回回应码533。

4.登录核准

安全数据交换会在其它事情进行的同时以一种安全方式确立客户端对于服务器
端的唯一性身份，此身份将被用于用户的登录核准。

为回应FTP客户端的登录命令（AUTH ,PASS,ACCT），服务器会改变某些如[RFC959]
中所述的命令及回应顺序。以下也有一些新的可用的回应码。

如果服务器愿意准许由USER命令指定的基于安全数据交换确立的具有唯一性的
用户登录，它应返回回应码232。

如果安全机制要求 质询/回应（challenge/response ） 式的口令输入，它应
对USER命令回应336。回应的正文部分应包括质询信息。在此情况下，客户端在提
示用户输入口令之前必须将质询信息显示给用户。这一过程对于复杂的或某些提供
对话框或其它输入方式的图形用户界面的客户程序来说是尤其适宜的。用户有时可
能需要用回应336中正文部分的质询信息来构造有效口令。因此这些客户程序应避
免在将用户名发给服务器端之前就提示用户输入口令。


5.新的FTP回应码

新的回应码被分为两类。第一类是新的FTP安全扩展命令所必需的。第二类指
明被保护的回应的一种新的回应码。

5.1 新的独有的回应码
   
232 User logged in, authorized by security data exchange. 
234Security data exchange complete. 

235 [ADAT=base64数据] 
		
				；此回应指明安全数据交换成功结束。方括号不在此回应内容
				；中，它只指明回应中的安全数据是可选的。
 
334 [ADAT=base64数据] 

				；此回应指明客户端所请求的安全机制可用，并且包含了客户	
				；端发出下一个命令时所需要的安全数据。方括号不在此回应  
				；内容中，它只指明回应中的安全数据是可选的。

335 [ADAT=base64数据]

				；此回应指明服务器端接受客户传来的安全数据，并且还需要
				；额外的安全数据来完成数据交换。
				；方括号不在此回应 内容中，它只指明回应中的安全数据是	
		；可选的。
           
336 Username okay, need password. Challenge is " （用户名通过，需要口
令。质询是）

				；安全机制所选取的质询内容所代表的含义对系统的使用者来说
				；应该是有实际意义的（sensible）。

431 Need some unavailable resource to process security. 
（ 某些相关资源不可用。）

533 Command protection level denied for policy reasons. 
（由于策略方面的原因，命令保护等级被拒绝。）

534 Request denied for policy reasons. 
     （由于策略方面的原因，请求被拒绝。）

535 Failed security check (hash, sequence, etc). 
     （安全检查失败，(哈希，顺序，或其它的方式)）

536 Requested PROT level not supported by mechanism. 
     （安全机制不支持请求的保护等级。）

537 Command protection level not supported by security mechanism. 
    （安全机制不支持命令保护等级化。）
 
5.2 保护回应

一种新的保护回应介绍如下：
   		6yz   Protected reply

有三种此种类型的回应码。第一个回应码631指明一个受到数据完整性保护的
回应。第二个回应码632指明一个受保密机制及数据完整性机制保护保护的回应。
第三个回应码633指明一个受保密机制保护的回应。

回应631的正文部分是一些Telnet协议中规定的字符串，此字符串是由经过
base64编码的‘安全‘信息构成，而此安全信息则由安全机制中专门进行信息完整
性保护的过程所产生。 回应632的正文部分是一些Telnet协议中规定的字符串，
此字符串是由经过base64编码的‘私密‘信息构成，而此安全信息则由安全机制中
专门进行保密性保护和信息完整性保护的过程所产生。回应633的正文部分是一些
Telnet协议中规定的字符串，此字符串是由经过base64编码的‘保密‘信息构成，
而此安全信息则由安全机制中专门进行保密性保护的过程所产生。

客户端将解码及校验这些经过编码的回应。而如何处理解码失败或回应的校验
是实现细节问题。回应不必包括行结束码，但某命令行包含了行结束码，则它必须
是Telnet协议中规定的行结束码，而非本地（local）的行结束码。

保护回应只可以在安全数据交换成功之后发出。

回应632也许是包含多行的回应。鉴于此，回应的纯文本部分必须被分成一定
数量的段，每段都要受到保护，然后还要采用 base 64方式编码，目的是为了能放
入包含多行的回应的分开的行中。在纯文本的回应和经过编码的和经过编码的回应
中的行间不需要任何联系。Telnet 协议中规定的行结束码必须出现在经过编码的回
应的纯文本部分，在文本最后对如上的行结束码的使用是可选的。

多行回应的格式必须比[RFC959]的续文中所描述的还要严格。在最后一行之前
的每一行必须由一个回应码紧跟一个连字符“-”，然后接一个回应的base 64 编码
段。

 例如，如果纯文本回应是
	123-First line 
	Second line 
	234 A line beginning with numbers 
	123 The last line 
 
那么最终的受保护回应可以是下列的任一形式， （由于单行字数限制，某些
例子可能要占去两行。）
       
       631 base64(protect("123-First line\r\nSecond line\r\n 234 A line 
631-base64
        (protect("123-First line\r\n")) 
       631-base64(protect("Second line\r\n")) 
       631-base64(protect(" 234 A line beginning with numbers\r\n")) 631 base64
           (protect("123 The last line")) 
       631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b")) 
631 
            base64(protect("eginning with numbers\r\n123 The last line\r\n"))

6. 数据信道封装

        当客户端和服务器端的数据传输（任一方向的传输）受到保护时，必须对数
据实施某些改变和封装，以便接收者能顺利的将传送的文件解码。

        当有关被传送文件的代表类型（representation type），文件结构，传输模
式被转变后，发送者必须对其运用所有的保护措施。通过数据通道传送的数据，基
于保护的目的，将被作为字节流对待。

        当以认证方式传送文件时，只有此文件的个别数据块被进行认证处理，而不
是整个文件。因而可能会发生如下情况，即使用将非法数据块混入数据流的攻击方
式时，认证却认为数据合法，从而导致接收者无法检测出受到的文件是不可靠的。

        为防范此类攻击，使用的安全机制在某些实现细节上应包含防止此类攻击的
机制。附录I的一些GSS-API机制和附录II的Kerberos机制可以用来做这件事。

        发送者必须取得输入的字节流，并将其拆分成许多的数据块，而这样的数据
块经过安全机制的某一具体过程编码后，其尺寸不能大于客户端和服务器端当初用
PBSZ商定的缓冲区尺寸。每一个数据块必须经过编码，并且将编码后的数据块与
其长度值一同传送，此长度值由一四字节的无符号整数表示，此四字节以高位优先
的顺序传送。

        当到达被传文件的尾部时，发送者必须将一字节值均为零的数据块编码，然
后在此数据传输结束之前将此编码数据块发送给接收者。

        接收者将读出如上的四字节长度值，再读取字节数由此长度值指定的一块数
据，然后解码并使用安全机制的某一具体过程对其进行校验，重复如上过程直到它
收到了那个编码之前字节值全为零的数据块。这表明已到了编码字节流的尾部。

        任何有关代表类型、文件结构和传输模式的转变将由接收者在如上操作过程
所生成的字节流上进行。

当使用块传输模式时，发送者的缓冲区（用于存储透明文本）尺寸与块的尺寸
无关。

如果当前保护等级与服务器为特殊的文件传输的安全需要而指定的保护等级
不一致，服务器将对 STOR,STOU,RETR, LIST, NLST, 或 APPE 命令返回回应码534。

如果在数据传输阶段，在服务器端的任一数据保护服务功能不能有效发挥作用
的话，服务器将对发自客户端的数据传输命令（无论是STOR, STOU, RETR, LIST, 
NLST, 还是 APPE）返回回应码535。

7．可能的策略方面的考虑

由于没有关于客户端和服务器端安全策略制订方面的限制，一下只是一些关于
安全机制应实现的某些功能的荐议。

--  一旦进行了安全数据交换，服务器应该要求所有的命令都被保护（数据
完整性及保密保护），并且对回应实施保护，其保护等级应与相关命令
相同。这些回应包括指明MIC, CONF, 和ENC执行失败的回应。特别，
要求 AUTH 和 ADAT 命令被保护是没意义的；要求 PROT 和PBSZ 命令
被保护是有意义且有用处的。还有在期望某功能的安全机制实现过程
中，基于互操作性的考虑 CCC命令被定义，但不推荐使用它。

--  任何条件允许的情况下，客户端都应对 PASS 命令加密。如果服务器知
道加密	 功能可用，于是它拒绝接受没有加密的 PASS 命令，这种情
况是合理的。

--  尽管没有一个有关安全的命令被要求在安全机制中实现，荐议在考虑网
络	站点的策略因素（例如输出控制）及其所能支持的机制的前提下，
尽量提供所有能被实现的命令。


8.  声明的规范
     
    此节在[RFC959]的第5.3 和5.4 节后已有示范，描述的是相同的信息，除了
标准的
FTP命令和回应外。

8.1 FTP协议安全命令及其参数

AUTH     
ADAT     
PROT     
PBSZ     
MIC     
CONF     
ENC    
       ::= 
       ::= 
              ; must be formatted as described in section 9
       ::= C | S | E | P
       ::= any decimal integer from 1 to (2^32)-1

8.2  命令―回应 顺序

安全关联设置 
AUTH  
234  
334  
502, 504, 534, 431  
500, 501, 421  
ADAT  
235  
335  
503, 501, 535  
500, 501, 421  
数据保护协商命令  
PBSZ  
200  
503  
500, 501, 421, 530  
PROT  
200  
504, 536, 503, 534, 431  
500, 501, 421, 530  
命令通道保护命令  
MIC  
535, 533  
500, 501, 421  
CONF  
535, 533  
500, 501, 421  
ENC  
535, 533  
500, 501, 421  
安全性增强的登录命令 (只有新的回应码被列出) USER  
232  
336  
数据信道命令 (只有新的回应码被列出)  
STOR  
534, 535  
STOU  
534, 535  
RETR  
534, 535 
LIST  
534, 535  
NLST  
534, 535  
APPE  
534, 535 
         除了这些回应码外，任何安全命令可以返回回应码 500，501，502，533，或 
421。一旦安全数据交换成功完成，任何 ftp命令都可以返回一个封装在 回应631，
632，或633中的回应码。
        
9 状态图

         本节演示了在一个增强了安全机制的FTP服务器上进行认证和核准的流程。
长方形块的地方显示了客户端必须发出命令那一时刻的状态，菱形块的地方显示了
服务器必须
给出命令回应那一时刻的状态。

         
,------------------, USER 
       __\|     未经认证    |_________\
      |  /|    (新的连接)   |         /|
      |   `------------------'          |
      |            |                    |
      |            | AUTH               |
      |            V                    |
      |           / \                   |
      | 4yz,5yz  /   \   234            |
      |<--------<     >------------->.  |
      |          \   /               |  |
      |           \_/                |  |
      |            |                 |  |
      |            | 334             |  |
      |            V                 |  |
      |  ,--------------------,      |  |
      |  |    需要安全数据  |<--.  |  |
      |  `--------------------'   |  |  |
      |            |              |  |  |
      |            | ADAT         |  |  |
      |            V              |  |  |
      |           / \             |  |  |
      | 4yz,5yz  /   \   335      |  |  |
      `<--------<     >-----------'  |  |
                 \   /               |  |
                  \_/                |  |
                   |                 |  |
                   | 235             |  |
                   V                 |  |
           ,---------------.         |  |
      ,--->|    已被认证  |<--------'  |  当客户端和服务器端之间完成
      |    `---------------'            |  认证后，如果完整性保护机制
      |            |                    |  可用，则命令必须受到此机制
      |            | USER               |  的保护，当然也可以使用CCC
      |            |                    |  命令来取消这种限制。
      |            |<-------------------'  
      |            V                       
      |           / \
      | 4yz,5yz  /   \   2yz
      |<--------<     >------------->.
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,---------------.         |
      |    |   需要口令  |         |
      |    `---------------'         |
      |            |                 |
      |            | PASS            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      |<--------<     >------------->|
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,--------------.          |
      |    |需要账户信息 |          |
      |    `--------------'          |
      |            |                 |
      |            | ACCT            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      `<--------<     >------------->|
                 \   /               |
                  \_/                |
                   |                 |
                   | 3yz             |
                   V                 |
             ,-------------.         |
             |     核准   |/________|
             |  (已登录)   |\
             `-------------'

10  base 64编码

               base 64 编码类似于[RFC-1421]中4.3.2.4节所描述的Printable 编码，除
了必须不含有行间中断。编码规则定义如下。
 
            由进行常规保护的安全机制所产生的位串（bitstring）从左到右经某种方式
编码后就可变成所有因特网上的站点都可以表示的ASCII字符，尽管不必使用相同
的位模式（例如，尽管字符“E“在基于ASCII的系统中用十六进制数45表示，而在
基于EBCDIC的系统中用十六进制数C5表示，但这两种表示法所代表的意义在本地
系统中是一样的。

            使用国际字母表 IA5 的一个包含64个字符的子集使得在编码时使用6位二
进制数就可以将这64个可打印字符完全表示（译者注： 2的6次方为64）（以上
的字符子集在IA5和ASCII中是完全相同的）。字符“=”用于在编码后输出的可打
印字符序列的尾部进行填充（译者注：“=”不在这个“64字符子集“中）。

          编码时以包含24位二进制的位串（3个字节）为一组作为编码程序的输入数据，
经过编码后输出4个字符（它们包含在如上字符子集中）。具体做法是，将64个可
打印字符按“[A--Z][a--z][0--9]+ / “的顺序排列并按排列的自然顺序建立它们的
索引，索引值从0--63。将一个输入的24位位串从左到右开始每六位一组，共分成
4组，每一组的值作为索引值在64个如上排列的字符序列中去查找，与索引值相同
的那个字符将作为编码程序的输出字符。（译者注：如上过程即通常的置换编码方
式），选择以上64个字符作为编码的输出字符是因为它们具有普遍可表示性，并且
Telnet协议中规定的有特殊意义的字符（例如““,“”，IAC）被排除在
64字符子集之外。

          如果在文件尾部不能凑够24位，此时需经特殊处理。首先，以24位位串作为
编码程序的输入是必须的。如果即将输入到编码程序中的位串不够24位，则以比特
“0”去填充，从而构成完整的24位位串。不需要代表其实际输入数据（译者注：即
用比特“0”填充的部分）的那个输出字符则由字符“=”来代替。常规编码方式下每
一个24位位串编码后输出的4个字符都是64字符子集中的字符。只有以下几种情
况例外。（1）如果最终输入的位串位数是24的整数倍（即在需编码数据的尾部正
好剩余一个24位串），那么编码输出的字符数是4的整数倍，且无字符“=”填充（即
输出的4个字符均含于64字符子集中）。（2）如果在需编码数据尾部只剩下一个8
位串可供输入，那么在经过16个“0”位填充后经编码输出的4个字符中最后两个将
是“=“。（3）如果在需编码的数据尾部只剩下一个16位串可供输入，那么在经过
8个“0”位填充后经编码输出的4个字符中最后一个将是“=”。

          安全机制实现者必须记住，对于ADAT, MIC, CONF,ENC命令和63z回应的base 64
编码其长度是任意的，不固定的。因此在处理之前应确保整行都被读取。对控制通
道进行一些连续读取应该是必要的。只因为一个经 base 64编码后的命令行太长，
服务器就将其拒绝，这一做法是不合适的。（假设对对方发来的上下文可以很好解
码）。

          读取经 base 64 编码的命令及回应时一定要多加小心。

11. 安全考虑

          整个文档是针对文件传输协议相关的安全问题的。由于使用本文档所述方式不
能建立起两个服务器之间的安全依赖关系，因此与第三方的文件传输安全是不能通
过此协议的扩展部分来保证的。（在服务器之间不存在用于传送 ADAT 信令的控制
链路（control connection））此方面的进一步工作将以后展开。

12 鸣谢

I would like to thank the members of the CAT WG, as well as all participants 
in discussions on the "cat-ietf@mit.edu" mailing list, for their 
contributions to this document. I would especially like to thank Sam Sjogren, 
John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, Derrick Brashear, John 
Gardiner Myers, Denis Pinkas, and Karri Balk for their contributions to this 
work. Of course, without Steve Lunt, the author of the first six revisions 
of this document, it would not exist at all. 


13 参考资料

[TELNET-SEC] Borman, D., "Telnet Authentication and Encryption Option", 
Work in Progress. 
[RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and 
Support", STD 3, RFC 1123, October 1989. 
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 
Part I: Message Encryption and Authentication Procedures", RFC 1421, 
February 1993. 

14 作者地址 
Marc Horowitz  
Cygnus Solutions  
955 Massachusetts Avenue  
Cambridge, MA 02139 
Phone: +1 617 354 7688  
EMail: marc@cygnus.com 

附录I 
 与本文档有关的GSSAPI的一些规范说明 (译者注：关于GSSAPI的详情参见RFC1508) 

        为最大限度的利用新的安全机制，新的安全机制以GSSAPI机制提供的方式而
不是FTP安全机制实现是很好的选择。由于只需修改很少的代码或根本不需修改任
何的代码，这将使得现有的FTP系统更容易地支持新机制。此外这些机制对于其他
的协议如构建于GSSAPI之上的IMAP 协议也是可用的，而机制的设计者不用为此作
额外的说明或实现方面的工作。

       使用GSSAPI接口实现的所有安全机制都应称作GSSAPI机制。如果服务器支持
一个使用GSSAPI的安全机制，它必须返回回应码334以表明它所希望收到的下一个
命令是ADAT。

客户端必须从调用GSS_Init_Sec_Context函数开始认证过程，然后传递0（开
始时）及一个targ_name给 input_context_handle函数开始认证过程。这里的
targ_name与由GSS_Import_Name 而来的output_name是等同的，GSS_Input_Name
函数是与其输入是基于主机服务的 input_name_type 函数和参数为
“ftp@hostname"的input_name_string 函数一同被调用的。而函数 
input_name_string 参数中的hostname 表示服务器端所属主机的以小写字母给出
的全名。（如果 input_name_string执行失败，则客户端应以“host@hostname“作
为函数的输入参数）由 GSS_Init_Sec_Context 产生的output_token（输出信令）
必须经base 64编码,然后作为ADAT命令的参数发送给服务器端。如果
GSS_Init_Sec_Context返回GSS_S_CONTINUE_NEEDED，那么客户端必须期待着ADAT
命令的回应中同时返回一个信令（token）。此信令将用作再次调用
GSS_Init_Sec_Context的参数。这种情况如果GSS_Init_Sec_Context没有返回
output_token那么服务器如上的ADAT命令返回的回应码就是235。
如果GSS_Init_Sec_Context 返回GSS_S_COMPLETE,客户端将不再期望服务器返回任
何信令客户端必须认为服务器已被认证。

       服务器端必须将客户端用ADAT传来的参数进行base 64解码，并将
resultant_token作为输入信令传给GSS_Accept_Sec_Context函数，设置
acceptor_cred_handle为NULL（为使用默认的某些被服务器端信任的信息）并将0
传给 input_Context_handle （最初）。如果 GSS_Accept_Sec_Context
返回一个output_token（输出信令）它必须经过 base 64 编码返回给客户，并在回
应正文中包含“ADAT=base64 编码串“如果GSS_Accept_Sec_Context返回 
GSS_S_COMPLETE,服务器对ADAT命令的回应码必须是235。并且服务器必须认为客户
端被认证。如果GSS_Accept_Sec_Context函数返回
GSS_S_CONTINUE_NEEDED,则对ADAT的回应码是335。否则回应码是535，回应正文部
分描述的是错误信息。

       对于GSS_Init_Sec_Context 和 GSS_Accept_Sec_context 的chan_binding输
入应使用客户端和服务器端各自的因特网地址作为发起者和接收者的地址，它们的
地址类型都应是GSS_C_AF_INET。没有别的应用程序数据被具体要求。

      由于GSSAPI支持建立在安全上下文（security context）上的访问，服务器对
客户端认证时可以不需要真正确立其某个身份。

      有关MIC命令，631回应及安全文件传输的函数过程是

	    			GSS_Wrap 是给发送者使用, 并且 conf_flag == FALSE

	    			GSS_Unwrap 是给接收者使用
 
      有关ENC命令，632回应秘密性文件传输的函数过程是

    			GSS_Wrap 是给发送者使用，并且 conf_flag == TRUE
         
        	GSS_Unwrap 是给发送者使用。

        CONF 命令及回应633不被支持。
    
      客户端和服务器端都应检查conf_avail 的值，以确定对方是否支持数据的保密
保护服务。

      当安全状态需要被复位时（当服务器收到了AUTH命令或者REIN 命令）需要调
用
GSS_Delete_Sec_Context函数完成此事。

附录II 
 与本文档有关的Kerberos Version4 的说明 
(译者注：Kerveros 最初是由MIT(麻省理工学院)开发的一套网络认证系统。)

      使用 Kerberos V4 协议实现的安全机制应称为 KERBEROS V4机制，如果服务器
支持KERBEROS_V4机制，它必须返回回应码334以表明它期望收到的下一个命令是
ADAT。客户端必须通过调用krb_mk_req(3)函数，并使用“ftp”的首要（principal）
名称信息作为其参数来获得对于Kerberos主“ftp.hostname@realm“的准入信息
（ticket,通常是数百个字节序列）。这里的参数“ftp"是和服务器所在主机的正规
名称（由krb_get_phost(3)返回）的第一部分及服务器的域名（由krb_realmofhost(3)
返回）和一个任意的校验和是等同的。此准入信息必须经过 base 64编码然后作为
一个ADAT命令的参数传递。

       如果主名（principal name）“ftp”没有在 Kerberos 数据库中注册，那么客
户端必须求助于主名“rcmd”（与realm相同的实例）然后服务器必须只能接受这
些主名中的一个，而不能两者均接受。一般的如果在服务器的服务表（srvtab）中
有一个关于“ftp”的键（key），那么必须只能使用主名“ftp”，否则只能使用主
名“rcmd”。

        服务器必须 base 64 解码由客户端经ADAT命令传来的参数，然后将结果作
为参数传给krb_rd_req(3)函数，服务器必须将从认证者传来的校验和加1，而后将
其转换为网络字节序（高位字节优先顺序）再用krb_mk_safe(3)将其作标记，并进
行 base 64编码。如上过程成功的话，服务器返回回应码235，并在其正文包含
“ADAT=base 64编码串“，如果失败了，服务器返回回应码535。

       收到了服务器端的回应码235后，客户端必须将其回应正文部分的 base 64 编
码串进行解码，并将其网络字节序转换过来，将结果传给函数 krb_rd_safe(3) ，
如果返回的校验和部分等于它以前发送的校验和的数值加1，客户端必须认为服务
器端已通过其认证。

       有关MIC命令631回应及安全文件传输的过程函数是

				krb_mk_safe(3) 用于发送者。
         	krb_rd_safe(3) 用于接收者。

        有关ENC命令632回应及秘密文件传输的过程函数是
     
        	krb_mk_priv(3) 用于发送者。
                krb_rd_priv(3) 用于接收者。

        没有对于 CONF 命令和633回应的支持。

       注意，对于如何进行关于数据完整性验证，保密保护等功能（备用，可选）实
现方式的协商，KerV4的规范没有相关的条文规约，还有使用ADAT命令进行交换的
安全数据，也没有对其进行传送的支持，而无论对方是否提供保密保护服务。

       为了不超过PBSZ命令所规定的缓冲区尺寸，实现者必须切记，由使用
krb_mk_safe(3)和 krb_mk_priv(3) 函数时引起的透明文本缓冲区增长量应分别在
31个字节和26个字节内。

版权声明

       Copyright ? The Internet Society (1997). 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 implmentation may be prepared, copied, published andand 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. 


RFC2228――FTP Security Extensions                                              FTP安全扩展


1
RFC文档中文翻译计划