Network Working Group P. Hoffman
Request for Comments: 4434 VPN Consortium
Obsoletes: 3664 February 2006
Category: Standards Track
Network Working Group P. Hoffman
Request for Comments: 4434 VPN Consortium
Obsoletes: 3664 February 2006
Category: Standards Track
The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
因特网密钥交换协议（IKE）的AES-XCBC-PRF-128算法
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.
IP安全（IPsec）的某些实现可能希望使用从高级加密标准（AES）派生的伪随机函数。本文件描述了一种称为AES-XCBC-PRF-128的算法。
[AES-XCBC-MAC] describes a method to use the Advanced Encryption Standard (AES) as a message authentication code (MAC) whose output is 96 bits long. While 96 bits is considered appropriate for a MAC, it is too short to be useful as a long-lived pseudo-random function (PRF) in either IKE version 1 or version 2. Both versions of IKE use the PRF to create keys in a fashion that is dependent on the length of the output of the PRF. Using a PRF that has 96 bits of output creates keys that are easier to attack with brute force than a PRF that uses 128 bits of output.
[AES-XCBC-MAC]描述了一种将高级加密标准（AES）用作消息认证码（MAC）的方法，该码的输出长度为96位。虽然96位被认为适合MAC，但它太短，在IKE版本1或版本2中都不能用作长寿命伪随机函数（PRF）。IKE的两个版本都使用PRF以一种依赖于PRF输出长度的方式创建关键帧。使用96位输出的PRF创建的密钥比使用128位输出的PRF更容易受到暴力攻击。
Fortunately, there is a very simple method to use much of [AES-XCBC-MAC] as a PRF whose output is 128 bits: omit the step that truncates the 128-bit value to 96 bits.
幸运的是，有一种非常简单的方法可以将[AES-XCBC-MAC]的大部分用作输出为128位的PRF：省略将128位值截断为96位的步骤。
This document specifies the same algorithm as RFC 3664 except that the restriction that keys be exactly 128 bits from [AES-XCBC-MAC] is removed. Implementations of RFC 3664 will have the same bits-on-the-wire results as this algorithm; the only difference is that keys that were not equal in length to 128 bits will no longer be rejected but instead will be made 128 bits.
本文件规定了与RFC 3664相同的算法，不同之处在于取消了[AES-XCBC-MAC]中密钥为128位的限制。RFC3664的实现将具有与此算法相同的有线结果位；唯一的区别是，长度不等于128位的密钥将不再被拒绝，而是被设置为128位。
IKEv2 [IKEv2] uses PRFs for multiple purposes, most notably for generating keying material and authentication of the IKE_SA. The IKEv2 specification differentiates between PRFs with fixed key sizes and those with variable key sizes.
IKEv2[IKEv2]将PRF用于多种用途，最显著的是用于生成密钥材料和IKE_SA的身份验证。IKEv2规范区分了具有固定密钥大小的PRF和具有可变密钥大小的PRF。
When the PRF described in this document is used with IKEv2, the PRF is considered fixed-length for generating keying material but variable-length for authentication. That is, when generating keying material, "half the bits must come from Ni and half from Nr, taking the first bits of each" as described in IKEv2, section 2.14; but for authenticating with shared secrets (IKEv2, section 2.16), the shared secret does not have to be 128 bits long. This somewhat tortured logic allows IKEv2 implementations that use the fixed-length-key semantics from RFC 3664 to interoperate with implementations that use the variable-length-key semantics of this document.
当本文档中描述的PRF与IKEv2一起使用时，PRF被视为用于生成密钥材料的固定长度，但用于认证的可变长度。也就是说，在生成键控材料时，“一半的位必须来自Ni，一半来自Nr，取每个的第一位”，如IKEv2第2.14节所述；但对于使用共享机密进行身份验证（IKEv2，第2.16节），共享机密不必为128位长。这种有点扭曲的逻辑允许使用RFC3664中的固定长度键语义的IKEv2实现与使用本文档的可变长度键语义的实现进行互操作。
The AES-XCBC-PRF-128 algorithm is identical to [AES-XCBC-MAC] except for two changes. First, the key length restriction of exactly 128 bits in [AES-XCBC-MAC] is eliminated, as described below; this brings AES-XCBC-PRF-128 in alignment with HMAC-SHA1 and HMAC-MD5 when they are used as PRFs in IKE. Second, the truncation step in section 4.3 of [AES-XCBC-MAC] is *not* performed; that is, there is no processing after section 4.2 of [AES-XCBC-MAC].
AES-XCBC-PRF-128算法与[AES-XCBC-MAC]相同，只是有两处变化。首先，消除[AES-XCBC-MAC]中正好128位的密钥长度限制，如下所述；这使得AES-XCBC-PRF-128在IKE中用作PRF时与HMAC-SHA1和HMAC-MD5保持一致。第二，未执行[AES-XCBC-MAC]第4.3节中的截断步骤；也就是说，在[AES-XCBC-MAC]第4.2节之后没有处理。
The key for AES-XCBC-PRF-128 is created as follows:
AES-XCBC-PRF-128的密钥创建如下：
o If the key is exactly 128 bits long, use it as-is.
o 如果密钥长度正好为128位，请按原样使用。
o If the key has fewer than 128 bits, lengthen it to exactly 128 bits by padding it on the right with zero bits.
o 如果密钥少于128位，则通过在其右侧填充零位将其延长到正好128位。
o If the key is 129 bits or longer, shorten it to exactly 128 bits by performing the steps in AES-XCBC-PRF-128 (that is, the algorithm described in this document). In that re-application of this algorithm, the key is 128 zero bits; the message is the too-long current key.
o 如果密钥为129位或更长，则通过执行AES-XCBC-PRF-128中的步骤（即本文档中描述的算法）将其缩短为128位。在该算法的重新应用中，密钥为128个零位；消息的当前键太长。
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 000102030405060708090a0b0c0d0e0f
Key Length : 16
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 47f51b4564966215b8985c63055ed308
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 000102030405060708090a0b0c0d0e0f
Key Length : 16
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 47f51b4564966215b8985c63055ed308
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 00010203040506070809
Key Length : 10
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 0fa087af7d866e7653434e602fdde835
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 00010203040506070809
Key Length : 10
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 0fa087af7d866e7653434e602fdde835
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 000102030405060708090a0b0c0d0e0fedcb
Key Length : 18
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 8cd3c93ae598a9803006ffb67c40e9e4
Test Case AES-XCBC-PRF-128 with 20-byte input
Key : 000102030405060708090a0b0c0d0e0fedcb
Key Length : 18
Message : 000102030405060708090a0b0c0d0e0f10111213
PRF Output : 8cd3c93ae598a9803006ffb67c40e9e4
The security provided by AES-XCBC-MAC-PRF is based on the strengths of AES and HMAC. At the time of this writing, there are no known practical cryptographic attacks against AES, AES-XCBC-MAC-PRF, or HMACs.
AES-XCBC-MAC-PRF提供的安全性基于AES和HMAC的优势。在撰写本文时，还没有已知的针对AES、AES-XCBC-MAC-PRF或HMAC的实用密码攻击。
As is true with any cryptographic algorithm, part of its strength lies in the security of the key management mechanism, the strength of the associated secret key, and the correctness of the implementations in all the participating systems. [AES-XCBC-MAC] contains test vectors to assist in verifying the correctness of the AES-XCBC-MAC-PRF code. The test vectors all show the full MAC value before it is truncated to 96 bits. The PRF makes use of the full MAC value, not the truncated one.
与任何加密算法一样，它的一部分优势在于密钥管理机制的安全性、相关密钥的强度以及所有参与系统中实现的正确性。[AES-XCBC-MAC]包含测试向量，以帮助验证AES-XCBC-MAC-PRF代码的正确性。测试向量在被截断为96位之前都显示完整的MAC值。PRF使用完整的MAC值，而不是截断的MAC值。
Any reference to RFC 3664 needs to be updated to refer to this document when it is published.
需要更新对RFC 3664的任何引用，以便在发布时引用本文件。
[AES-XCBC-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AES-XCBC-MAC]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其与IPsec的使用”，RFC 3566，2003年9月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
Pasi Eronen suggested the easy method for shortening too-long keys. Saroop Mathur and John Black provided and verified the test vectors.
Pasi Eronen提出了缩短过长键的简单方法。Saroop Mathur和John Black提供并验证了测试向量。
Author's Address
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。