Network Working Group R. Housley
Request for Comments: 2773 P. Yee
Updates: 959 SPYRUS
Category: Experimental W. Nace
NSA
February 2000
Network Working Group R. Housley
Request for Comments: 2773 P. Yee
Updates: 959 SPYRUS
Category: Experimental W. Nace
NSA
February 2000
Encryption using KEA and SKIPJACK
使用KEA和SKIPJACK进行加密
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October 1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys. SKIPJACK is used to encrypt file data and the FTP command channel.
本文件定义了使用FTP规范STD 9、RFC 959、“文件传输协议（FTP）”（1985年10月）[3]和RFC 2228“FTP安全扩展”（1997年10月）[1]对文件传输进行加密的方法。该方法将使用密钥交换算法（KEA）进行相互认证并建立数据加密密钥。SKIPJACK用于加密文件数据和FTP命令通道。
The File Transfer Protocol (FTP) provides no protocol security except for a user authentication password which is transmitted in the clear. In addition, the protocol does not protect the file transfer session beyond the original authentication phase.
文件传输协议（FTP）除了以明文形式传输的用户身份验证密码外，不提供任何协议安全性。此外，该协议不保护原始身份验证阶段之外的文件传输会话。
The Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) Working Group has proposed security extensions to FTP. These extensions allow the protocol to use more flexible security schemes, and in particular allows for various levels of protection for the FTP command and data connections. This document describes a profile for the FTP Security Extensions by which these mechanisms may be provisioned using the Key Exchange Algorithm (KEA) in conjunction with the SKIPJACK symmetric encryption algorithm.
Internet工程任务组（IETF）通用认证技术（CAT）工作组已提议对FTP进行安全扩展。这些扩展允许协议使用更灵活的安全方案，特别是允许对FTP命令和数据连接进行不同级别的保护。本文档描述了FTP安全扩展的配置文件，通过该配置文件，可以使用密钥交换算法（KEA）和SKIPJACK对称加密算法来配置这些机制。
FTP Security Extensions [1] provides:
FTP安全扩展[1]提供：
* user authentication -- augmenting the normal password mechanism;
* 用户身份验证——增加了正常的密码机制；
* server authentication -- normally done in conjunction with user authentication;
* 服务器身份验证——通常与用户身份验证一起完成；
* session parameter negotiation -- in particular, encryption keys and attributes;
* 会话参数协商——特别是加密密钥和属性；
* command connection protection -- integrity, confidentiality, or both;
* 命令连接保护——完整性、机密性或两者兼而有之；
* data transfer protection -- same as for command connection protection.
* 数据传输保护——与命令连接保护相同。
In order to support the above security services, the two FTP entities negotiate a mechanism. This process is open-ended and completes when both entities agree on an acceptable mechanism or when the initiating party (always the client) is unable to suggest an agreeable mechanism. Once the entities agree upon a mechanism, they may commence authentication and/or parameter negotiation.
为了支持上述安全服务，两个FTP实体协商一种机制。该过程是开放式的，当两个实体就可接受的机制达成一致意见或发起方（始终是客户）无法提出一致的机制时，该过程即告完成。一旦实体同意了一种机制，他们就可以开始认证和/或参数协商。
Authentication and parameter negotiation occur within an unbounded series of exchanges. At the completion of the exchanges, the entities will either be authenticated (unilateral or mutually), and may, additionally, be ready to protect FTP commands and data.
身份验证和参数协商发生在一系列无界的交换中。交换完成后，实体将进行身份验证（单边或相互验证），此外，还可以准备好保护FTP命令和数据。
Following the exchanges, the entities negotiate the size of the buffers they will use in protecting the commands and data that follow. This process is accomplished in two steps: the client offers a suggested buffer size and the server may either refuse it, counter it, or accept it.
在交换之后，实体协商它们将用于保护随后的命令和数据的缓冲区的大小。此过程分两步完成：客户端提供建议的缓冲区大小，服务器可以拒绝、反击或接受。
At this point, the entities may issue protected commands within the bounds of the parameters negotiated through the security exchanges. Protected commands are issued by applying the protection services required to the normal commands and Base64 encoding the results. The encoded results are sent as the data field within a ENC (integrity and confidentiality) command. Base64 is an encoding for mapping binary data onto a textual character set that is able to pass through most 7-bit systems without loss. The server sends back responses in new result codes which allow the identical protections and Base64 encoding to be applied to the results. Protection of the data transfers can be specified via the PROT command which supports the
此时，实体可以在通过安全交换协商的参数范围内发出受保护的命令。通过将所需的保护服务应用于普通命令并对结果进行Base64编码来发出受保护的命令。编码结果作为ENC（完整性和机密性）命令内的数据字段发送。Base64是一种用于将二进制数据映射到文本字符集的编码，该文本字符集能够在大多数7位系统中不丢失数据。服务器以新的结果代码发回响应，允许对结果应用相同的保护和Base64编码。数据传输的保护可通过PROT命令指定，该命令支持
same protections as those afforded the other FTP commands. PROT commands may be sent on a transfer-by-transfer basis, however, the session parameters may not be changed within a session.
与其他FTP命令提供的保护相同。PROT命令可以逐个传输发送，但是会话参数不能在会话中更改。
This paper profiles KEA with SKIPJACK to achieve certain security services when used in conjunction with the FTP Security Extensions framework. FTP entities may use KEA to give mutual authentication and establish data encryption keys. We specify a simple token format and set of exchanges to deliver these services. Functions that may be performed by the Fortezza Crypto Card.
本文将使用SKIPJACK描述KEA，以便在与FTP安全扩展框架结合使用时实现某些安全服务。FTP实体可以使用KEA进行相互认证并建立数据加密密钥。我们指定了一种简单的令牌格式和一组交换来提供这些服务。可由Fortezza加密卡执行的功能。
The reader should be familiar with the extensions in order to understand the protocol steps that follow. In the context of the FTP Security Extensions, we suggest the usage of KEA with SKIPJACK for authentication, integrity, and confidentiality.
读者应该熟悉这些扩展，以便理解接下来的协议步骤。在FTP安全扩展的上下文中，我们建议将KEA与SKIPJACK结合使用，以实现身份验证、完整性和机密性。
A client may mutually authenticate with a server. What follows are the protocol steps necessary to perform KEA authentication under the FTP Security Extensions framework. Where failure modes are encountered, the return codes follow those specified in the Extensions. They are not enumerated in this document as they are invariant among the mechanisms used. The certificates are ASN.1 encoded.
客户端可以与服务器相互验证。以下是在FTP安全扩展框架下执行KEA身份验证所需的协议步骤。在遇到故障模式时，返回代码遵循扩展中指定的返回代码。由于它们在所使用的机制中是不变的，因此本文件中未列举它们。证书是ASN.1编码的。
The exchanges detailed below presume a working knowledge of the FTP Security Extensions. The notation for concatenation is " || ". Decryption of encrypted data and certification path validation is implicitly assumed, but is not shown.
下面详细介绍的交换假定您了解FTP安全扩展的工作知识。串联的符号是“| |”。隐式假设加密数据的解密和认证路径验证，但未显示。
---------------------------------------------------------------------
Client Server
---------------------------------------------------------------------
Client Server
AUTH KEA-SKIPJACK -->
<-- 334 ADAT=Base64( Certb || Rb )
ADAT Base64( Certa || Ra ||
WMEK || IV || Encrypt(
Label-Type || Label-Length ||
Label-List || pad || ICV ) ) -->
<-- 235 ADAT=Base64( IV )
---------------------------------------------------------------------
Figure 1
AUTH KEA-SKIPJACK -->
<-- 334 ADAT=Base64( Certb || Rb )
ADAT Base64( Certa || Ra ||
WMEK || IV || Encrypt(
Label-Type || Label-Length ||
Label-List || pad || ICV ) ) -->
<-- 235 ADAT=Base64( IV )
---------------------------------------------------------------------
Figure 1
The server and client certificates contain KEA public keys. The client and server use KEA to generate a shared SKIPJACK symmetric key, called the TEK. The client uses the random number generator to create a second SKIPJACK key, called the MEK. The MEK is wrapped in
服务器和客户端证书包含KEA公钥。客户端和服务器使用KEA生成一个共享的SKIPJACK对称密钥，称为TEK。客户端使用随机数生成器创建第二个SKIPJACK密钥，称为MEK。MEK被包裹在
the TEK for transfer to the server. An initialization vector (IV) associated with the MEK is generated by the client and transferred to the server. A list of security labels that the client wants to use for this FTP session may be transferred to the server encrypted in the MEK. As shown in Figure 2, the security label data is formatted as a one octet type value, a four octet label length, the security label list, padding, followed by an eight octet integrity check value (ICV). Figure 3 lists the label types. If the label type is absent (value of zero length), then the label size must be zero.
用于传输到服务器的TEK。与MEK相关联的初始化向量（IV）由客户端生成并传输到服务器。客户端希望用于此FTP会话的安全标签列表可以传输到MEK中加密的服务器。如图2所示，安全标签数据的格式为一个八位字节类型的值、四个八位字节的标签长度、安全标签列表、填充，然后是一个八位字节完整性检查值（ICV）。图3列出了标签类型。如果缺少标签类型（长度值为零），则标签大小必须为零。
In order to ensure that the length of the plain text is a multiple of the cryptographic block size, padding shall be performed as follows. The input to the SKIPJACK CBC encryption process shall be padded to a multiple of 8 octets. Let n be the length in octets of the input. Pad the input by appending 8 - (n mod 8) octets to the end of the message, each having the value 8 - (n mod 8), the number of octets being added. In hexadecimal, he possible pad strings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 0808080808080808. All input is padded with 1 to 8 octets to produce a multiple of 8 octets in length. This pad technique is used whenever SKIPJACK CBC encryption is performed.
为了确保纯文本的长度是加密块大小的倍数，应按如下方式进行填充。SKIPJACK CBC加密过程的输入应填充为8个八位字节的倍数。设n为输入的长度（以八位字节为单位）。通过在消息末尾附加8-（n mod 8）个八位字节来填充输入，每个八位字节的值为8-（n mod 8），八位字节的数量是相加的。在十六进制中，可能的填充字符串是：01、0202、030303、04040404、05050505、06060606、07070707和080808080808。所有输入用1到8个八位字节填充，以产生长度为8个八位字节的倍数。每当执行SKIPJACK CBC加密时，都会使用此pad技术。
An ICV is calculated over the plaintext security label and padding. The ICV algorithm used is the 32-bit one's complement addition of each 32-bit block followed by 32 zero bits. This ICV technique is used in conjunction with SKIPJACK CBC encryption to provide data integrity.
ICV通过明文安全标签和填充进行计算。使用的ICV算法是每个32位块的32位1的补码相加，后跟32个零位。此ICV技术与SKIPJACK CBC加密结合使用，以提供数据完整性。
---------------------------------------------------------------------
Label Type 1 Octet
Label Length 4 octets
Label List variable length
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 2
---------------------------------------------------------------------
Label Type 1 Octet
Label Length 4 octets
Label List variable length
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 2
---------------------------------------------------------------------
Label Type Label Syntax Reference
0 Absent Not applicable
1 MSP SDN.701[2]
2-255 Reserved for Future Use To Be Determined
---------------------------------------------------------------------
Label Type Label Syntax Reference
0 Absent Not applicable
1 MSP SDN.701[2]
2-255 Reserved for Future Use To Be Determined
---------------------------------------------------------------------
Figure 3
---------------------------------------------------------------------
Figure 3
FTP command channel operations are now confidentiality protected. To provide integrity, the command sequence number, padding, and ICV are appended to each command prior to encryption.
FTP命令通道操作现在受到保密保护。为了提供完整性，在加密之前将命令序列号、填充和ICV附加到每个命令。
Sequence integrity is provided by using a 16-bit sequence number which is incremented for each command. The sequence number is initialized with the least significant 16-bits of Ra. The server response will include the same sequence number as the client command.
序列完整性是通过使用16位序列号来提供的，该序列号在每个命令中递增。序列号由Ra的最低有效16位初始化。服务器响应将包含与客户端命令相同的序列号。
An ICV is calculated over the individual commands (including the carriage return and line feed required to terminate commands), the sequence number, and pad.
ICV根据单个命令（包括终止命令所需的回车和换行）、序列号和pad进行计算。
---------------------------------------------------------------------
Client Server
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt("PBSZ 65535"
|| SEQ || pad || ICV )) -->
<-- 632 Base64(Encrypt("200" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("USER yee"
|| SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("331" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("PASS
fortezza" || SEQ ||
pad || ICV)) -->
<-- 631 Base64(Sign("230"))
---------------------------------------------------------------------
Figure 4
ENC Base64(Encrypt("PBSZ 65535"
|| SEQ || pad || ICV )) -->
<-- 632 Base64(Encrypt("200" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("USER yee"
|| SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("331" ||
SEQ || pad || ICV))
ENC Base64(Encrypt("PASS
fortezza" || SEQ ||
pad || ICV)) -->
<-- 631 Base64(Sign("230"))
---------------------------------------------------------------------
Figure 4
After decryption, both parties verifying the integrity of the PBSZ commands by checking for the expected sequence number and correct ICV. The correct SKIPJACK key calculation, ICV checking, and the validation of the certificates containing the KEA public keys provides mutual identification and authentication.
解密后，双方通过检查预期序列号和正确的ICV来验证PBSZ命令的完整性。正确的SKIPJACK密钥计算、ICV检查和包含KEA公钥的证书验证提供了相互识别和身份验证。
---------------------------------------------------------------------
Client Server
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt("PROT P" ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("200" || SEQ
|| pad || ICV))
---------------------------------------------------------------------
Figure 5
ENC Base64(Encrypt("PROT P" ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("200" || SEQ
|| pad || ICV))
---------------------------------------------------------------------
Figure 5
At this point, files may be sent or received with encryption and integrity services in use. If encryption is used, then the first buffer will contain the token followed by enough encrypted file octets to completely fill the buffer (unless the file is too short to fill the buffer). Subsequent buffers contain only encrypted file octets. All buffers are completely full except the final buffer.
此时，可以使用加密和完整性服务发送或接收文件。如果使用加密，则第一个缓冲区将包含令牌，后跟足够的加密文件八位字节以完全填充缓冲区（除非文件太短而无法填充缓冲区）。后续缓冲区仅包含加密的文件八位字节。除最后一个缓冲区外，所有缓冲区都已满。
---------------------------------------------------------------------
Client Server
---------------------------------------------------------------------
Client Server
ENC Base64(Encrypt(
("RETR foo.bar") ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("150" ||
SEQ || pad || ICV))
---------------------------------------------------------------------
Figure 6
ENC Base64(Encrypt(
("RETR foo.bar") ||
SEQ || pad || ICV)) -->
<-- 632 Base64(Encrypt("150" ||
SEQ || pad || ICV))
---------------------------------------------------------------------
Figure 6
The next figure shows the header information and the file data.
下图显示了标题信息和文件数据。
---------------------------------------------------------------------
Plaintext Token IV 24 octets
WMEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octets
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 7
---------------------------------------------------------------------
Plaintext Token IV 24 octets
WMEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octets
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 7
In order to support both on-the-fly encryption and pre-encrypted files, a token is defined for carrying a file encryption key (FEK). To prevent truncation and ensure file integrity, the token also includes a hash computed on the complete file. The token also contains the security label associate with the file. This FEK is wrapped in the session TEK. The token is encrypted in the session TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, a 4 octet label length, a variable length label value, a one to 8 octet pad, and an 8 octet ICV. The first 24 octets of the token are the plaintext IV used to encrypt the remainder of the token. The token requires its own encryption IV because it is transmitted across the data channel, not the command channel, and ordering between the
为了支持动态加密和预加密文件，定义了一个令牌来携带文件加密密钥（FEK）。为了防止截断并确保文件完整性，令牌还包括对完整文件计算的哈希。令牌还包含与文件关联的安全标签。此FEK封装在会话TEK中。令牌在会话TEK中使用SKIPJACK CBC模式进行加密。该令牌包含12个八位字节的FEK、20个八位字节的文件哈希、24个八位字节的文件IV、1个八位字节的标签类型、4个八位字节的标签长度、可变长度的标签值、1到8个八位字节的pad和8个八位字节的ICV。令牌的前24个八位字节是明文IV，用于加密令牌的其余部分。令牌需要自己的加密IV，因为它是通过数据通道而不是命令通道传输的，并且在
channels cannot be guaranteed. Storage of precomputed keys and hashes for files in the file system is a local implementation matter; however, it is suggested that if a file is pre-encrypted, then the FEK be wrapped in a local storage key. When the file is needed, the FEK is unwrapped using the local storage key, and then rewrapped in the session TEK. Figure 8 shows the assembled token.
渠道无法保证。文件系统中文件的预计算密钥和散列的存储是本地实现问题；但是，建议如果对文件进行了预加密，则应将FEK包装在本地存储密钥中。当需要文件时，使用本地存储密钥打开FEK，然后在会话TEK中重写。图8显示了组装好的令牌。
---------------------------------------------------------------------
Plaintext Token IV 24 octets
Wrapped FEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octet
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 8
---------------------------------------------------------------------
Plaintext Token IV 24 octets
Wrapped FEK 12 octets
Hashvalue 20 octets
IV 24 octets
Label Type 1 octet
Label Length 4 octets
Label Label Length octets
Pad 1 to 8 octets
ICV 8 octets
---------------------------------------------------------------------
Figure 8
In order to clarify the usage of various keys in this protocol, Figure 9 summarizes key types and their usage:
为了澄清本协议中各种密钥的用法，图9总结了密钥类型及其用法：
---------------------------------------------------------------------
Key Type Usage
TEK Encryption of token at the beginning of
each file, also wraps the MEK and the FEK
MEK Encryption of command channel
FEK Encryption of the file itself (may be
done out of scope of FTP)
---------------------------------------------------------------------
Key Type Usage
TEK Encryption of token at the beginning of
each file, also wraps the MEK and the FEK
MEK Encryption of command channel
FEK Encryption of the file itself (may be
done out of scope of FTP)
---------------------------------------------------------------------
Figure 9
---------------------------------------------------------------------
Figure 9
This entire memo is about security mechanisms. For KEA to provide the authentication and key management discussed, the implementation must protect the private key from disclosure. For SKIPJACK to provide the confidentiality discussed, the implementation must protect the shared symmetric keys from disclosure.
整个备忘录都是关于安全机制的。为了让KEA提供所讨论的身份验证和密钥管理，实现必须保护私钥不被泄露。为了使SKIPJACK提供所讨论的机密性，实现必须保护共享对称密钥不被泄露。
We would like to thank Todd Horting for insights gained during implementation of this specification.
我们要感谢Todd Horting在实施本规范过程中获得的见解。
[1] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[1] Horowitz，M.和S.Lunt，“FTP安全扩展”，RFC2228，1997年10月。
[2] Message Security Protocol 4.0 (MSP), Revision A. Secure Data Network System (SDNS) Specification, SDN.701, February 6, 1997.
[2] 消息安全协议4.0（MSP），A版。安全数据网络系统（SDNS）规范，SDN.701，1997年2月6日。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[3] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA
拉塞尔·霍斯利·斯皮罗斯美国弗吉尼亚州赫恩登市埃尔登街381号1120室，邮编20170
Phone: +1 703 707-0696
EMail: housley@spyrus.com
Phone: +1 703 707-0696
EMail: housley@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara，加利福尼亚州95054
Phone: +1 408 327-1901
EMail: yee@spyrus.com
Phone: +1 408 327-1901
EMail: yee@spyrus.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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 implementation may be prepared, copied, published and 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。