使用KEA和SKIPJACK加密

本备忘录的状态

本备忘录具体描述了Internetcommunity的实验性协议，但不说明任何一种类型的Internet标准。它需要进一步进行讨论和建议以得到改进。发布本备忘录不受限制。

概要

本文档具体描述了一个传输文件在使用FTP规范标准9、RFC959、“文件传输协议（FTP）”(1985年10月)[3]、和RFC2228“FTP安全扩展”（1997年10月）[1]时加密的方法。该方法将使用密钥交换算法（KEA）提供相互鉴定并建立数据密钥。SKIPJACK用来加密文件数据和FTP通道指令。

1.0介绍

文件传输协议（FTP），除了传输鉴定用户身份的口令之外没有提供安全协议。另外，该协议也不能保护远程文件传输的鉴定状态。

FTP的安全扩展问题已经提交到互联网工程任务组(IETF)和通用鉴别技术工作组（CAT）。这些扩展答应该协议使用更多的柔性安全方案，并非凡答应为FTP指令和数据连接提供多种级别的保护。该文档描述了FTP安全扩展一个的轮廓，这些规则可能提供使用密钥交换算法（KEA）和SKIPJACK协同的均衡加密算法。

FTP安全扩展[1]规则：

*用户鉴定——加强一般密码机制；

*服务器鉴定——正常地连接用户鉴定；

*交换参数流通——非凡的加密要害字和特征码；

*指令连接保护——完整地，机密地，或包含以上两点；

*数据传输保护——和指令连接保护类似

为了支持上述安全服务，两个FTP实体需用一种机制沟通。这个过程是开放的和完整的，当两个实体都接受同一机制或初始的一方（通常为客户端）不能确定一个合适的机制时。一旦同意使用一个机制，它们会开始鉴定并进行参数传递。

交换和参数的传递发生在一个极大的交换组中。当交换完成，实体的任何一方（单方或双方）会进行鉴定，然后，又预备去保护FTP指令和数据。

在交换完成之后，实体会紧接着对传递的缓冲区大小进行保护。这个过程用两步完成：客户端提出一个缓冲区尺寸，服务器端会从拒绝、修改、同意三者中选一。

至此，实体会在参数传递的绑定包里发出保护指令，并始终贯穿安全交换的全过程。保护指令被申请保护服务所需的一般指令和把结果译成编码的Base64指令发出。译码的结果被一个ENC（完整的和机密的）指令以数据流形式发送出去。Base64是一个把文本字符映射成二进制数据的译码指令，它能通过大多数的7位（bit）系统而不丢失。服务器的响应在新的结果码中传回，并且同样也答应使用保护和Base64译码指令以应用于回应的结果。数据传输的保护被规定使用PROT指令，该指令支持同样提供给其他FTP指令的保护。PROT指令能在有传输功能的系统中送出，不过，交换参数在交换过程中不能改变。

2.0密钥交换算法（KEA）轮廓

本节描述KEA和SKIPJACKY在和FTP安全扩展框架联合使用时如何完成可靠的安全服务。FTP实体将使用KEA来相互鉴定，并建立数据密钥。我们具体地说明一个简单的标记格式和一组交换以陈述这些服务。相关功能会通过FortezzaCryptoCard来演示。

为了理解下面的协议，读者要熟悉这些扩展。在FTP安全扩展的文章中，我们建议使用KEA和SKIPJACK来进行鉴定、保证完整性和机密性。

客户端会与服务器相互鉴定。以下是在FTP安全扩展框架下实现KEA鉴定的协议必需的步骤。在遭遇失效状态的地方，返回码跟随在扩展功能指定的列表中。但在本文档中没有列举，因为它们在机制使用中是固定不变的。证书为ASN.1编码。

以下假定一个FTP安全扩展的应用实例进行交换的具体描述。联接符号用“”表示。加密的译码数据和鉴定路径的确认是默认假定的，但没有明示。

---------------------------------------------------------------------

客户端服务器端

AUTHKEA-SKIPJACK-->

<--334ADAT=Base64(CertbRb)

ADATBase64(CertaRa

WMEKIVEncrypt(

Label-TypeLabel-Length

Label-ListpadICV))-->

<--235ADAT=Base64(IV)

---------------------------------------------------------------------

图1

服务器端和客户端的证实书包含KEA公共密钥。客户端和服务器端使用KEA产生一个共享的SKIPJACK均衡密钥，称为TEK。客户端使用随机数创建一个二次SKIPJACK密钥，称为MEK。为了传输到服务器，MEK被封装在TEK中。当客户端向服务器端传输时，一个初始化向量在MEK被创建时一同生成，一个客户端要使用FTP任务的安全列表将被使用MEK加密后传输到服务器。如图2所示，安全列表数据的格式是一个8位（1字节）的数值，一个4字节的列表长度，安全列表清单，补充，跟在一个8字节的完整校验值（ICV）之后。图3列出了列表的类型。假如列表的类型是缺省的（长度为0），则列表长度必须为0。

为了保证纯文本的长度是密文块大小的数倍，在完成后需要做如下补充：对SKIPJACKCBC密码化处理的输入将作8字节倍数的补充。设n是输入的字节长度。补充的输入附加8-(nmod8)字节到信息的末尾，每个信息均需附加8-(nmod8)个字节。在十六进制中，可能补充的字串是：01,0202,030303,04040404,0505050505,060606060606,07070707070707,and0808080808080808.所有的1至8字节补充输入都是为了让长度是8的倍数。只要使用SKIPJACKCBC加密技术，都要进行这样的补充。

ICV是在对无格式文本安全列表和补充的计算得到的。ICV的算法是32位的自身反码加法，每个32位块跟随32个0位。ICV算法在使用SKIPJACKCBC加密法时使用，以提供数据的完整性。

---------------------------------------------------------------------

列表类型1字节

列表长度4字节

列表清单可变长度

补充1到8字节

ICV8字节

---------------------------------------------------------------------

图2

---------------------------------------------------------------------

列表类型列表语法参考

0缺省不适用

1MSPSDN.701[2]

2-255保留保留

--------------------------------------------------------------------

图3

FTP指令通道操作现在是做为机密来保护的。为了提供完整性，指令序号、补充信息、和ICV都添加在每一个指令的前面以实现加密。

序列的完整性是通过为每个指令增加16位的序列数字来实现的。序列号初始化时是最低有效16位Ra。服务器的响应也会象客户端那样含有同样的序列号。

IVC是通过单独的指令（包括必要的回车和换行符以结束指令）、序列号、和补充信息计算出来的。

---------------------------------------------------------------------

客户端服务器端

ENCBase64(Encrypt("PBSZ65535"

SEQpadICV))-->

<--632Base64(Encrypt("200"

SEQpadICV))

ENCBase64(Encrypt("USERyee"

SEQpadICV))-->

<--632Base64(Encrypt("331"

SEQpadICV))

ENCBase64(Encrypt("PASS

fortezza"SEQ

padICV))-->

<--631Base64(Sign("230"))

---------------------------------------------------------------------

图4

译码之后，两个实体用PBSZ指令检查预知的序列号和正确的ICV来校验完整性。正确的SKIPJACK计算，ICV校验，和包含KEA公用密钥的证书，一起提供相互的辨认和鉴定。

---------------------------------------------------------------------

客户端服务器端

ENCBase64(Encrypt("PROTP"

SEQpadICV))-->

<--632Base64(Encrypt("200"SEQ

padICV))

---------------------------------------------------------------------

图5

至此，在使用中，文件将会以加密和完整性服务来发送和接收。假如应用加密技术，第一个缓冲区将包含标记，跟随足够多的译文字节以完全布满缓冲区（除非文件太短以至无法布满缓冲区）。后面的缓冲区将仅包含译文字节。除最后一个缓冲区外所有的缓冲区都会被完全布满。

---------------------------------------------------------------------

客户端服务器端

ENCBase64(Encrypt(

("RETRfoo.bar")

SEQpadICV))-->

<--632Base64(Encrypt("150"

SEQpadICV))

----------------------------------------------------------------------

图6

下图显示头信息和文件数据：

---------------------------------------------------------------------

PlaintextTokenIV

24字节

WMEK

12字节

Hashvalue

20字节

24字节

LabelType

1字节

LabelLength

4字节

Label

LabelLength字节

Pad

1to8字节

ICV

8字节

---------------------------------------------------------------------

图7

2.1加密前的文件支持

为了支持加密和加密前的文件，为传输一个文件的密钥（FEK）定义一个标记。为防止残损和保证文件完整，标记也包含了一个在完成的文件里计算出的无用信号。标记也和文件联合在一起包含了安全列表。FEK封装在TEK中。标记使用SKIPJACKCBC模式加密在TEK中。标记包含一个12字节的已封装FEK，一个20字节的文件无用信息，一个24字节的文件IV，一个1字节的列表类型，一个4字节的列表长度，一个可变长度的列表数据，一个1至8字节的补充，和一个8字节的ICV。标记开始的24个字节是无格式的IV，一般用于标记的剩余内容的加密。标记需要它自己的加密IV，因为它通过数据通道传输，而不是指令通道，并且次序介于二个通道之间，但不能有保证。文件系统的文件计算前的密钥和无用信息的存储是一个本地执行问题。然而，假如一个文件在加密前被暗示，那么FEK会被在本地存储的密钥里封装起来。当文件需要，FEK被用本地存储密钥解封，然后再在TEK中封装。图8显示了装配标记。

---------------------------------------------------------------------

PlaintextTokenIV

24字节

WrappedFEK

12字节

Hashvalue

20字节

24字节

LabelType

1字节

LabelLength

4字节

Label

LabelLength字节

Pad

1to8字节

ICV

8字节

---------------------------------------------------------------------

3.0要害字术语表

为了清楚地阐明在协议中使用各种不同要害字，图9概括了要害字的类型和它们的用途：

---------------------------------------------------------------------

要害字使用

TEK每个文件开始部分的加密标记，也封装在MEK和FEK中

MEK指令加密通道

FEK文件自我加密(可能超出FTP范围)

---------------------------------------------------------------------

图9

4.0安全考虑

整个备忘录是关于安全机制的。KEA提供了鉴定和可供讨论的密钥治理，当解密私人密钥时，执行必须得到保护。SKIPJACK提供了可供讨论的机密性，当解密公共均衡密钥时执行必须得到保护。

5.0感谢

我们对在制订这个规范是作出贡献的ToddHorting表示感谢。

6.0参考书目

[1]Horowitz,M.andS.Lunt,“FTP安全扩展”，RFC2228，1997年10月。

[2]消息传输安全协议4.0（MSP），修订版A。安全数据网络系统（SDNS）SDN.701,1997年2月6日。

[3]Postel,J.andJ.Reynolds,“FTP传输协议”，STD9,RFC959,1985年10月。

7.0作者地址

RussellHousley

SPYRUS

381EldenStreet

Suite1120

Herndon,VA20170

USA

Phone:+1703707-0696

EMail:housley@spyrus.com

PeterYee

SPYRUS

5303BetsyRossDrive

SantaClara,CA95054

USA

Phone:+1408327-1901

EMail:yee@spyrus.com

本文档及其译文可以拷贝和提供给他人，且其衍生物，如评论、解释或帮助实施的作品可以全部或部分地定制、拷贝、出版和发布，对此我们不加任何限制，前提是上述版权声明，及本段内容包含在所有的拷贝和派生作品中。然而，本文档本身不答应以任何方式修改，例如删除Internet社团或其他Internet组织的版权声明或参考，除非是为了开发Internet标准的需要。即便在这种情况下，也需要添加Internet标准中定义的版权声明，或者根据需要把他翻译成英语以外的其他语言。

上述准许的有限许可是永久性的，无论是Internet社团以及其继续者或代理者都将不会废止这些许可。

本文档及其中包含的信息基于“ASIS”提供，而且INTERNET社团和IETF拒绝所有授权、表达或影射，包括但不限于任何这里使用的消息的授权将不会违反任何版权或者隐含的商业性授权或对特定的合理目的。

致谢

目前，RFC编者活动的基金由Internet社团提供。