rfcrfc2773.txt

本程序为在linux下实现FTP传输文件的实现

---------------------------------------------------------------------
     客户端                            服务器端
     ENC Base64(Encrypt(
        ("RETR foo.bar") ||
        SEQ || pad || ICV))    -->
                                       <-- 632 Base64(Encrypt("150" ||
                                                SEQ || pad || ICV))
----------------------------------------------------------------------
                                      图6
下图显示头信息和文件数据：
   ---------------------------------------------------------------------
Plaintext Token IV
24 字节
WMEK 
12 字节
Hashvalue 
20 字节
IV 
24 字节
Label Type 
1 字节
Label Length 
4 字节
Label 
Label Length 字节
Pad 
1 to 8 字节
ICV 
8 字节
   ---------------------------------------------------------------------
                                      图7
2.1加密前的文件支持
为了支持加密和加密前的文件，为传输一个文件的密钥（FEK）定义一个标记。为防止残损和保证文件完整，标记也包含了一个在完成的文件里计算出的无用信号。标记也和文件联合在一起包含了安全列表。FEK封装在TEK中。标记使用SKIPJACK CBC模式加密在TEK中。标记包含一个12字节的已封装FEK，一个20字节的文件无用信息，一个24字节的文件IV，一个1字节的列表类型，一个4字节的列表长度，一个可变长度的列表数据，一个1至8字节的补充，和一个8字节的ICV。标记开始的24个字节是无格式的IV，一般用于标记的剩余内容的加密。标记需要它自己的加密IV，因为它通过数据通道传输，而不是指令通道，并且次序介于二个通道之间，但不能有保证。文件系统的文件计算前的密钥和无用信息的存储是一个本地执行问题。然而，如果一个文件在加密前被暗示，那么FEK会被在本地存储的密钥里封装起来。当文件需要，FEK被用本地存储密钥解封，然后再在TEK中封装。图8显示了装配标记。
   ---------------------------------------------------------------------
Plaintext Token IV 
24 字节
Wrapped FEK 
12 字节
Hashvalue 
20 字节
IV 
24 字节
Label Type 
1 字节
Label Length 
4 字节
Label 
Label Length 字节
Pad 
1 to 8 字节
ICV 
8 字节
   ---------------------------------------------------------------------
3.0 关键字术语表
为了清晰地阐明在协议中使用各种不同关键字，图9概括了关键字的类型和它们的用途：
   ---------------------------------------------------------------------
          关键字           使用
          TEK              每个文件开始部分的加密标记，也封装在MEK和FEK中
          MEK              指令加密通道
          FEK              文件自我加密(可能超出FTP范围)
   ---------------------------------------------------------------------
                                      图9
4.0 安全考虑
整个备忘录是关于安全机制的。KEA提供了鉴定和可供讨论的密钥管理，当解密私人密钥时，执行必须得到保护。SKIPJACK提供了可供讨论的机密性，当解密公共均衡密钥时执行必须得到保护。
5.0 感谢
我们对在制订这个规范是作出贡献的Todd Horting表示感谢。
6.0 参考书目
[1]Horowitz, M. and S. Lunt,“FTP安全扩展”，RFC 2228，1997年10月。
[2]消息传输安全协议4.0（MSP），修订版 A。安全数据网络系统（SDNS）SDN.701,1997年2月6日。
[3]Postel, J. and J. Reynolds,“FTP传输协议”，STD 9,RFC 959,1985年10月。
7.0 作者地址
Russell Housley
SPYRUS
381 Elden Street
Suite 1120
Herndon, VA 20170
USA
Phone: [phone]
EMail: [e-mail]

Peter Yee
SPYRUS
5303 Betsy Ross Drive
Santa Clara, CA 95054
USA
Phone: [phone]
EMail: [e-mail]
8.0 完整的版权声明
Copyright (C) The Internet Society (2000)。版权所有。
本文档及其译文可以拷贝和提供给他人，且其衍生物，如评论、解释或帮助实施的作品可以全部或部分地定制、拷贝、出版和发布，对此我们不加任何限制，前提是上述版权声明，及本段内容包含在所有的拷贝和派生作品中。然而，本文档本身不允许以任何方式修改，例如删除Internet社团或其他Internet组织的版权声明或参考，除非是为了开发Internet标准的需要。即便在这种情况下，也需要添加Internet标准中定义的版权声明，或者根据需要把他翻译成英语以外的其他语言。
上述准许的有限许可是永久性的， 无论是Internet社团以及其继承者或代理者都将不会废止这些许可。
本文档及其中包含的信息基于“AS IS”提供，而且INTERNET社团和IETF拒绝所有授权、表达或影射，包括但不限于任何这里使用的消息的授权将不会违背任何版权或者隐含的商业性授权或对特定的合理目的。
致谢
目前，RFC编者活动的基金由Internet社团提供。
RFC2773 ——Encryption using KEA and SKIPJACK                       使用KEA和SKIPJACK加密