Network Working Group L. Law
Request for Comments: 4869 J. Solinas
Category: Informational NSA
May 2007
Network Working Group L. Law
Request for Comments: 4869 J. Solinas
Category: Informational NSA
May 2007
Suite B Cryptographic Suites for IPsec
用于IPsec的套件B加密套件
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications.
本文档为IPsec提供了四个可选的加密用户界面套件（“UI套件”），类似于RFC 4308中指定的两个套件。四个新套件与美国国家安全局的套件B规范兼容。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................2
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................2
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
[RFC4308] proposes two optional cryptographic user interface suites ("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent commonly used present-day corporate VPN security choices and anticipated future choices, respectively. This document proposes four new UI suites based on implementations of the United States National Security Agency's Suite B algorithms (see [SuiteB]).
[RFC4308]为IPsec提出了两个可选的加密用户界面套件（“UI套件”）。VPN-A和VPN-B这两个套件分别代表了当前常用的企业VPN安全选择和预期的未来选择。本文档基于美国国家安全局的套件B算法（参见[SuiteB]）的实现，提出了四个新的UI套件。
As with the VPN suites, the Suite B suites are simply collections of values for some options in IPsec. Use of UI suites does not change the IPsec protocols in any way.
与VPN套件一样，套件B套件只是IPsec中某些选项的值的集合。使用UI套件不会以任何方式更改IPsec协议。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
Each of the following UI suites provides choices for ESP (see [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]). The four suites are differentiated by the choice of cryptographic algorithm strengths and a choice of whether the Encapsulating Security Payload (ESP) is to provide both confidentiality and integrity or integrity only. The suite names are based on the Advanced Encryption Standard [AES] mode and AES key length specified for ESP.
以下每个UI套件都为ESP（请参见[RFC4303]）以及IKEv1和IKEv2（请参见[RFC2409]和[RFC4306]）提供了选择。这四个套件的区别在于选择了加密算法的优势，以及选择了封装安全负载（ESP）是提供机密性和完整性还是仅提供完整性。套件名称基于为ESP指定的高级加密标准[AES]模式和AES密钥长度。
IPsec implementations that use these UI suites SHOULD use the suite names listed here. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described, and MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability.
使用这些UI套件的IPsec实现应使用此处列出的套件名称。IPsec实现不应使用与此处列出的用于所述套件的名称不同的名称，也不得使用此处列出的用于与这些值不匹配的套件的名称。这些要求对于互操作性是必要的。
This suite provides ESP integrity protection and confidentiality using 128-bit AES-GCM (see [RFC4106]). This suite or the following suite should be used when ESP integrity protection and encryption are both needed.
该套件使用128位AES-GCM（参见[RFC4106]）提供ESP完整性保护和机密性。当需要以下完整性或ESP套件时，应同时使用此套件或加密套件。
ESP: Encryption AES with 128-bit keys and 16-octet Integrity Check Value (ICV) in GCM mode [RFC4106] Integrity NULL
ESP:GCM模式下具有128位密钥和16个八位完整性检查值（ICV）的加密AES[RFC4106]完整性空值
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST support pre-shared key authentication [RFC2409] for interoperability. The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-256 [RFC4754].
对于IKEv1，阶段1应使用主模式。IKEv1实现必须支持预共享密钥身份验证[RFC2409]以实现互操作性。IKEv1使用的身份验证方法可以是预共享密钥[RFC2409]或ECDSA-256[RFC4754]。
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite.
第2阶段（针对IKEv1）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。
This suite provides ESP integrity protection and confidentiality using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding suite should be used when ESP integrity protection and encryption are both needed.
该套件使用256位AES-GCM（参见[RFC4106]）提供ESP完整性保护和机密性。当同时需要ESP完整性保护和加密时，应使用此套件或之前的套件。
ESP: Encryption AES with 256-bit keys and 16-octet ICV in GCM mode [RFC4106] Integrity NULL
ESP:GCM模式下带256位密钥和16个八位ICV的加密AES[RFC4106]完整性空值
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST support pre-shared key authentication [RFC2409] for interoperability. The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-384 [RFC4754].
对于IKEv1，阶段1应使用主模式。IKEv1实现必须支持预共享密钥身份验证[RFC2409]以实现互操作性。与IKEv1一起使用的身份验证方法可以是预共享密钥[RFC2409]或ECDSA-384[RFC4754]。
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite.
第2阶段（针对IKEv1）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。
This suite provides ESP integrity protection using 128-bit AES-GMAC (see [RFC4543]) but does not provide confidentiality. This suite or the following suite should be used only when there is no need for ESP encryption.
该套件使用128位AES-GMAC（参见[RFC4543]）提供ESP完整性保护，但不提供机密性。仅当不需要ESP加密时，才应使用此套件或以下套件。
ESP: Encryption NULL Integrity AES with 128-bit keys in GMAC mode [RFC4543]
ESP:GMAC模式下128位密钥的加密空完整性AES[RFC4543]
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Hash SHA-256 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST support pre-shared key authentication [RFC2409] for interoperability. The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-256 [RFC4754].
对于IKEv1，阶段1应使用主模式。IKEv1实现必须支持预共享密钥身份验证[RFC2409]以实现互操作性。IKEv1使用的身份验证方法可以是预共享密钥[RFC2409]或ECDSA-256[RFC4754]。
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC4753]
Authentication ECDSA-256 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite.
第2阶段（针对IKEv1）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。
This suite provides ESP integrity protection using 256-bit AES-GMAC (see [RFC4543]) but does not provide confidentiality. This suite or the preceding suite should be used only when there is no need for ESP encryption.
该套件使用256位AES-GMAC（参见[RFC4543]）提供ESP完整性保护，但不提供机密性。仅当不需要ESP加密时，才应使用此套件或之前的套件。
ESP: Encryption NULL Integrity AES with 256-bit keys in GMAC mode [RFC4543]
ESP:GMAC模式下256位密钥的加密空完整性AES[RFC4543]
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Hash SHA-384 [FIPS-180-2] [RFC4634]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST support pre-shared key authentication [RFC2409] for interoperability. The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-384 [RFC4754].
对于IKEv1，阶段1应使用主模式。IKEv1实现必须支持预共享密钥身份验证[RFC2409]以实现互操作性。与IKEv1一起使用的身份验证方法可以是预共享密钥[RFC2409]或ECDSA-384[RFC4754]。
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC4753]
Authentication ECDSA-384 [RFC4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite.
第2阶段（针对IKEv1）或创建子阶段（针对IKEv2）的密钥更新必须得到本套件中双方的支持。
This document inherits all of the security considerations of the IPsec, IKEv1, and IKEv2 documents. See [CNSSP-15] for guidance on the use of AES in these suites for the protection of U.S. Government information.
本文档继承了IPsec、IKEv1和IKEv2文档的所有安全注意事项。请参见[CNSSP-15]，了解在这些套件中使用AES保护美国政府信息的指南。
Some of the security options specified in these suites may be found in the future to have properties significantly weaker than those that were believed at the time this document was produced.
这些套件中指定的某些安全选项在将来可能会发现其属性明显弱于本文档生成时所认为的属性。
IANA has created and will maintain a registry called "Cryptographic Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]). The registry consists of a text string and an RFC number that lists the associated transforms. The four new suites in this document have been added to this registry after approval by an expert designated by the IESG.
IANA已经创建并将维护一个名为“IKEv1、IKEv2和IPsec加密套件”的注册表（请参见[IANA套件]）。注册表由一个文本字符串和一个列出关联转换的RFC编号组成。经IESG指定的专家批准后，本文件中的四个新套件已添加到此注册表中。
The new values for the registry are:
注册表的新值为：
Identifier Defined in Suite-B-GCM-128 RFC 4869 Suite-B-GCM-256 RFC 4869 Suite-B-GMAC-128 RFC 4869 Suite-B-GMAC-256 RFC 4869
在Suite-B-GCM-128 RFC 4869 Suite-B-GCM-256 RFC 4869 Suite-B-GMAC-128 RFC 4869 Suite-B-GMAC-256 RFC 4869中定义的标识符
[FIPS-180-2] FIPS 180-2 with change notice, "Secure Hash Standard", National Institute of Standards and Technology, February 2004.
[FIPS-180-2]FIPS 180-2及变更通知，“安全哈希标准”，国家标准与技术研究所，2004年2月。
[IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic Suites for IKEv1, IKEv2, and IPsec", <http://www.iana.org/assignments/crypto-suites>.
[IANA套件]互联网分配号码管理局，“IKEv1、IKEv2和IPsec的加密套件”<http://www.iana.org/assignments/crypto-suites>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308]Hoffman，P.，“IPsec加密套件”，RFC 4308，2005年12月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2", RFC 4753, November 2006.
[RFC4753]Fu，D.和J.Solinas，“IKE和IKEv2的ECP小组”，RFC 4753，2006年11月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using ECDSA", RFC 4754, November 2006.
[RFC4754]Fu，D.和J.Solinas，“使用ECDSA的IKE和IKEv2认证”，RFC 4754，2006年11月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月。
[AES] U.S. Department of Commerce/National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/index.html>.
[AES]美国商务部/国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月<http://csrc.nist.gov/publications/fips/index.html>.
[CNSSP-15] Committee on National Security Systems, "National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information", June 2003, <http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf>.
[CNSSP-15]国家安全系统委员会，“关于使用高级加密标准（AES）保护国家安全系统和国家安全信息的国家政策”，2003年6月<http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf>.
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B Cryptography", July 2005, <http://www.nsa.gov/ia/ industry/crypto_Suite_b.cfm?MenuID=10.2.7>.
[SuiteB]美国国家安全局，“NSA套件B加密概况”，2005年7月<http://www.nsa.gov/ia/ 行业/加密套件\u b.cfm？MenuID=10.2.7>。
Authors' Addresses
作者地址
Laurie E. Law National Information Assurance Research Laboratory National Security Agency
Laurie E.Law国家信息保障研究实验室国家安全局
EMail: lelaw@orion.ncsc.mil
EMail: lelaw@orion.ncsc.mil
Jerome A. Solinas National Information Assurance Research Laboratory National Security Agency
Jerome A.Solinas国家信息保障研究实验室国家安全局
EMail: jasolin@orion.ncsc.mil
EMail: jasolin@orion.ncsc.mil
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。