rfc2228.txt

RFC文档

      |            | 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协议中规定的有特殊意义的字符（例如“<CR>“,<LF>“”，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 "[e-mail]" 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: [phone]  
EMail: [e-mail] 

附录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文档中文翻译计划