Network Working Group C. Madson
Request for Comments: 2403 Cisco Systems Inc.
Category: Standards Track R. Glenn
NIST
November 1998
Network Working Group C. Madson
Request for Comments: 2403 Cisco Systems Inc.
Category: Standards Track R. Glenn
NIST
November 1998
The Use of HMAC-MD5-96 within ESP and AH
HMAC-MD5-96在ESP和AH中的使用
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection.
本备忘录描述了将HMAC算法[RFC-2104]与MD5算法[RFC-1321]结合使用，作为经修订的IPSEC封装安全有效负载[ESP]和经修订的IPSEC认证头[AH]内的认证机制。带有MD5的HMAC提供数据源身份验证和完整性保护。
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].
[Thayer97a]提供了ESP和AH实施所需的其他组件的更多信息。
This memo specifies the use of MD5 [RFC-1321] combined with HMAC [RFC-2104] as a keyed authentication mechanism within the context of the Encapsulating Security Payload and the Authentication Header. The goal of HMAC-MD5-96 is to ensure that the packet is authentic and cannot be modified in transit.
本备忘录规定了MD5[RFC-1321]与HMAC[RFC-2104]结合使用，作为封装安全有效载荷和认证头上下文中的密钥认证机制。HMAC-MD5-96的目标是确保数据包是真实的，并且在传输过程中不能修改。
HMAC is a secret key authentication algorithm. Data integrity and data origin authentication as provided by HMAC are dependent upon the scope of the distribution of the secret key. If only the source and destination know the HMAC key, this provides both data origin authentication and data integrity for packets sent between the two parties; if the HMAC is correct, this proves that it must have been added by the source.
HMAC是一种密钥认证算法。HMAC提供的数据完整性和数据源身份验证取决于密钥的分发范围。如果只有源和目的地知道HMAC密钥，这将为双方之间发送的数据包提供数据源身份验证和数据完整性；如果HMAC是正确的，这证明它一定是由源添加的。
In this memo, HMAC-MD5-96 is used within the context of ESP and AH. For further information on how the various pieces of ESP - including the confidentiality mechanism -- fit together to provide security services, refer to [ESP] and [Thayer97a]. For further information on AH, refer to [AH] and [Thayer97a].
在本备忘录中，HMAC-MD5-96用于ESP和AH。有关ESP的各个部分（包括保密机制）如何组合在一起提供安全服务的更多信息，请参阅[ESP]和[Thayer97a]。有关AH的更多信息，请参阅[AH]和[Thayer97a]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
[RFC-1321] describes the underlying MD5 algorithm, while [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as MD5.
[RFC-1321]描述了底层MD5算法，而[RFC-2104]描述了HMAC算法。HMAC算法为插入各种散列算法（如MD5）提供了一个框架。
HMAC-MD5-96 operates on 64-byte blocks of data. Padding requirements are specified in [RFC-1321] and are part of the MD5 algorithm. If MD5 is built according to [RFC-1321], there is no need to add any additional padding as far as HMAC-MD5-96 is concerned. With regard to "implicit packet padding" as defined in [AH], no implicit packet padding is required.
HMAC-MD5-96对64字节的数据块进行操作。填充要求在[RFC-1321]中规定，是MD5算法的一部分。如果MD5是根据[RFC-1321]建造的，就HMAC-MD5-96而言，不需要添加任何额外的填充。关于[AH]中定义的“隐式数据包填充”，不需要隐式数据包填充。
HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit value can be truncated as described in RFC 2104. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-MD5-96.
HMAC-MD5-96生成128位验证器值。如RFC 2104所述，可截断该128位值。对于ESP或AH，必须支持使用前96位的截断值。发送时，截断的值存储在authenticator字段中。收到后，计算整个128位值，并将前96位与存储在验证器字段中的值进行比较。HMAC-MD5-96不支持其他验证器值长度。
The length of 96 bits was selected because it is the default authenticator length as specified in [AH] and meets the security requirements described in [RFC-2104].
选择96位的长度是因为它是[AH]中指定的默认验证器长度，并且符合[RFC-2104]中描述的安全要求。
[Bellare96a] states that "(HMAC) performance is essentially that of the underlying hash function". [RFC-1810] provides some performance analysis and recommendations of the use of MD5 with Internet protocols. As of this writing no performance analysis has been done of HMAC or HMAC combined with MD5.
[Bellare96a]指出“（HMAC）性能本质上是底层哈希函数的性能”。[RFC-1810]提供了一些关于MD5与互联网协议结合使用的性能分析和建议。截至本文撰写之时，尚未对HMAC或HMAC与MD5的组合进行性能分析。
[RFC-2104] outlines an implementation modification which can improve per-packet performance without affecting interoperability.
[RFC-2104]概述了一种实现修改，它可以在不影响互操作性的情况下提高每个数据包的性能。
HMAC-MD5-96 is a secret key algorithm. While no fixed key length is specified in [RFC-2104], for use with either ESP or AH a fixed key length of 128-bits MUST be supported. Key lengths other than 128- bits MUST NOT be supported (i.e. only 128-bit keys are to be used by HMAC-MD5-96). A key length of 128-bits was chosen based on the recommendations in [RFC-2104] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength).
HMAC-MD5-96是一种密钥算法。虽然[RFC-2104]中未指定固定密钥长度，但对于ESP或AH，必须支持128位的固定密钥长度。不能支持128位以外的密钥长度（即HMAC-MD5-96只能使用128位密钥）。根据[RFC-2104]中的建议选择128位的密钥长度（即，小于认证器长度的密钥会降低安全强度，而大于认证器长度的密钥不会显著提高安全强度）。
[RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudo-random function MUST be used to generate the required 128-bit key.
[RFC-2104]讨论了关键材料的要求，其中包括对强随机性要求的讨论。必须使用强伪随机函数生成所需的128位密钥。
At the time of this writing there are no specified weak keys for use with HMAC. This does not mean to imply that weak keys do not exist. If, at some point, a set of weak keys for HMAC are identified, the use of these weak keys must be rejected followed by a request for replacement keys or a newly negotiated Security Association.
在撰写本文时，没有指定用于HMAC的弱键。这并不意味着弱键不存在。如果在某个时刻识别出HMAC的一组弱密钥，则必须拒绝使用这些弱密钥，然后请求替换密钥或新协商的安全关联。
[ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication).
[ARCH]描述了当单个SA需要多个密钥时（例如，当ESP SA需要一个密钥进行保密和一个密钥进行身份验证时），获取密钥材料的一般机制。
In order to provide data origin authentication, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication.
为了提供数据源身份验证，密钥分发机制必须确保分配唯一密钥，并且仅将其分发给参与通信的各方。
[RFC-2104] makes the following recommendation with regard to rekeying. Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, reduces the information avaliable to a cryptanalyst, and limits the damage of an exposed key.
[RFC-2104]就密钥更新提出以下建议。当前的攻击并未指明关键更改的具体建议频率，因为这些攻击实际上是不可行的。然而，定期密钥刷新是一种基本的安全实践，它有助于防止功能和密钥的潜在弱点，减少密码分析师可获得的信息，并限制公开密钥的损坏。
As of this writing, there are no known issues which preclude the use of the HMAC-MD5-96 algorithm with any specific cipher algorithm.
截至本文撰写之时，还没有任何已知问题阻止HMAC-MD5-96算法与任何特定密码算法一起使用。
The security provided by HMAC-MD5-96 is based upon the strength of HMAC, and to a lesser degree, the strength of MD5. [RFC-2104] claims that HMAC does not depend upon the property of strong collision resistance, which is important to consider when evaluating the use of MD5, an algorithm which has, under recent scrutiny, been shown to be much less collision-resistant than was first thought. At the time of this writing there are no practical cryptographic attacks against HMAC-MD5-96.
HMAC-MD5-96提供的安全性基于HMAC的强度，在较小程度上基于MD5的强度。[RCF-2104]声称HMAC不依赖于强碰撞抵抗性的性质，这在评估MD5的使用时是很重要的考虑，一种在最近的审查中已经被证明比最初想到的抗碰撞性要小得多的算法。在撰写本文时，还没有针对HMAC-MD5-96的实际加密攻击。
[RFC-2104] states that for "minimally reasonable hash functions" the "birthday attack", the strongest attack know against HMAC, is impractical. For a 64-byte block hash such as HMAC-MD5-96, an attack involving the successful processing of 2**64 blocks would be infeasible unless it were discovered that the underlying hash had collisions after processing 2**30 blocks. A hash with such weak collision-resistance characteristics would generally be considered to be unusable.
[RFC-2104]指出，对于“最小合理哈希函数”，已知针对HMAC的最强攻击“生日攻击”是不切实际的。对于64字节块散列（如HMAC-MD5-96），除非在处理2**30块后发现基础散列存在冲突，否则涉及成功处理2**64块的攻击将不可行。具有这种弱抗碰撞特性的散列通常被认为是不可用的。
It is also important to consider that while MD5 was never developed to be used as a keyed hash algorithm, HMAC had that criteria from the onset. While the use of MD5 in the context of data security is undergoing reevaluation, the combined HMAC with MD5 algorithm has held up to cryptographic scrutiny.
还需要考虑的是，虽然MD5从来没有被开发用作密钥哈希算法，但HMAC从发病起就有这个标准。虽然MD5在数据安全环境中的使用正在进行重新评估，但HMAC与MD5算法的结合经受住了密码审查。
[RFC-2104] also discusses the potential additional security which is provided by the truncation of the resulting hash. Specifications which include HMAC are strongly encouraged to perform this hash truncation.
[RFC-2104]还讨论了截断结果散列所提供的潜在附加安全性。强烈建议包含HMAC的规范执行此哈希截断。
As [RFC-2104] provides a framework for incorporating various hash algorithms with HMAC, it is possible to replace MD5 with other algorithms such as SHA-1. [RFC-2104] contains a detailed discussion on the strengths and weaknesses of HMAC algorithms.
由于[RFC-2104]提供了将各种散列算法与HMAC相结合的框架，因此可以用其他算法（如SHA-1）代替MD5。[RFC-2104]详细讨论了HMAC算法的优缺点。
As is true with any cryptographic algorithm, part of its strength lies in the correctness of the algorithm implementation, the security of the key management mechanism and its implementation, the strength of the associated secret key, and upon the correctness of the implementation in all of the participating systems. [RFC-2202] contains test vectors and example code to assist in verifying the correctness of HMAC-MD5-96 code.
与任何加密算法一样，其部分优势在于算法实现的正确性、密钥管理机制及其实现的安全性、相关密钥的强度以及所有参与系统中实现的正确性。[RFC-2202]包含测试向量和示例代码，以帮助验证HMAC-MD5-96代码的正确性。
This document is derived in part from previous works by Jim Hughes, those people that worked with Jim on the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the members of the IPsec working group.
本文件部分来源于Jim Hughes之前的工作、与Jim合作进行DES/CBC+HMAC-MD5 ESP组合转换的人员、ANX bakeoff参与者以及IPsec工作组成员。
We would also like to thank Hugo Krawczyk for his comments and recommendations regarding some of the cryptographic specific text in this document.
我们还要感谢Hugo Krawczyk对本文件中某些特定密码文本的评论和建议。
[RFC-1321] Rivest, R., "MD5 Digest Algorithm", RFC 1321, April 1992.
[RFC-1321]Rivest，R.，“MD5摘要算法”，RFC 13211992年4月。
[RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC-1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[RFC-1810]Touch，J.，“MD5性能报告”，RFC 1810，1995年6月。
[Bellare96a] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, June 1996.
[Bellare96a]Bellare，M.，Canetti，R.，和H.Krawczyk，“为消息身份验证键入哈希函数”，密码学进展，Crypto96，1996年6月。
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效载荷”，RFC 2406，1998年11月。
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[Thayer97a] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Thayer97a]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC-2202] Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, March 1997.
[RFC-2202]Cheng，P.和R.Glenn，“HMAC-MD5和HMAC-SHA-1的测试案例”，RFC 2202，1997年3月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Cheryl Madson Cisco Systems, Inc.
谢丽尔·马德森思科系统公司。
EMail: cmadson@cisco.com
EMail: cmadson@cisco.com
Rob Glenn NIST
罗伯·格伦
EMail: <rob.glenn@nist.gov>
EMail: <rob.glenn@nist.gov>
The IPsec working group can be contacted through the chairs:
可通过主席与IPsec工作组联系：
Robert Moskowitz ICSA
罗伯特·莫斯科维茨ICSA
EMail: rgm@icsa.net
EMail: rgm@icsa.net
Ted T'so Massachusetts Institute of Technology
麻省理工学院特德·特索
EMail: tytso@mit.edu
EMail: tytso@mit.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。