Network Working Group C. Madson
Request for Comments: 2404 Cisco Systems Inc.
Category: Standards Track R. Glenn
NIST
November 1998
Network Working Group C. Madson
Request for Comments: 2404 Cisco Systems Inc.
Category: Standards Track R. Glenn
NIST
November 1998
The Use of HMAC-SHA-1-96 within ESP and AH
HMAC-SHA-1-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 SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection.
本备忘录描述了HMAC算法[RFC-2104]与SHA-1算法[FIPS-180-1]结合使用，作为修订版IPSEC封装安全负载[ESP]和修订版IPSEC认证头[AH]内的认证机制。带有SHA-1的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 SHA-1 [FIPS-180-1] 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-SHA-1-96 is to ensure that the packet is authentic and cannot be modified in transit.
本备忘录规定在封装安全有效载荷和认证头的上下文中，将SHA-1[FIPS-180-1]与HMAC[RFC-2104]结合使用作为密钥认证机制。HMAC-SHA-1-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
HMAC是一种密钥认证算法。HMAC提供的数据完整性和数据源身份验证取决于密钥的分发范围。如果只有源和目标知道HMAC密钥，则这将提供两个数据源
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是正确的，这证明它一定是由源添加的。
In this memo, HMAC-SHA-1-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-SHA-1-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]中所述进行解释。
[FIPS-180-1] describes the underlying SHA-1 algorithm, while [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as SHA-1.
[FIPS-180-1]描述了基础SHA-1算法，而[RFC-2104]描述了HMAC算法。HMAC算法为插入各种散列算法（如SHA-1）提供了一个框架。
HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding requirements are specified in [FIPS-180-1] and are part of the SHA-1 algorithm. If you build SHA-1 according to [FIPS-180-1] you do not need to add any additional padding as far as HMAC-SHA-1-96 is concerned. With regard to "implicit packet padding" as defined in [AH] no implicit packet padding is required.
HMAC-SHA-1-96对64字节的数据块进行操作。填充要求在[FIPS-180-1]中规定，是SHA-1算法的一部分。如果您根据[FIPS-180-1]构建SHA-1，就HMAC-SHA-1-96而言，您不需要添加任何额外的填充。关于[AH]中定义的“隐式数据包填充”，不需要隐式数据包填充。
HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit value can be truncated as described in RFC2104. 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 160-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-SHA-1-96.
HMAC-SHA-1-96生成160位验证器值。如RFC2104所述，可以截断该160位值。对于ESP或AH，必须支持使用前96位的截断值。发送时，截断的值存储在authenticator字段中。收到后，计算整个160位值，并将前96位与存储在验证器字段中的值进行比较。HMAC-SHA-1-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". As of this writing no detailed performance analysis has been done of SHA-1, HMAC or HMAC combined with SHA-1.
[Bellare96a]指出“（HMAC）性能本质上是底层哈希函数的性能”。截至本文撰写之时，尚未对SHA-1、HMAC或HMAC与SHA-1的组合进行详细的性能分析。
[RFC-2104] outlines an implementation modification which can improve per-packet performance without affecting interoperability.
[RFC-2104]概述了一种实现修改，它可以在不影响互操作性的情况下提高每个数据包的性能。
HMAC-SHA-1-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 160-bits MUST be supported. Key lengths other than 160- bits MUST NOT be supported (i.e. only 160-bit keys are to be used by HMAC-SHA-1-96). A key length of 160-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-SHA-1-96是一种密钥算法。虽然[RFC-2104]中未规定固定密钥长度，但对于ESP或AH，必须支持160位的固定密钥长度。不得支持160位以外的密钥长度（即HMAC-SHA-1-96仅使用160位密钥）。根据[RFC-2104]中的建议选择160位的密钥长度（即，小于认证器长度的密钥会降低安全强度，而大于认证器长度的密钥不会显著增加安全强度）。
[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 160-bit key.
[RFC-2104]讨论了关键材料的要求，其中包括对强随机性要求的讨论。必须使用强伪随机函数生成所需的160位密钥。
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-SHA-1-96 algorithm with any specific cipher algorithm.
截至本文撰写之时，还没有任何已知的问题阻止HMAC-SHA-1-96算法与任何特定密码算法一起使用。
The security provided by HMAC-SHA-1-96 is based upon the strength of HMAC, and to a lesser degree, the strength of SHA-1. At the time of this writing there are no practical cryptographic attacks against HMAC-SHA-1-96.
HMAC-SHA-1-96提供的安全性基于HMAC的强度，在较小程度上基于SHA-1的强度。在撰写本文时，还没有针对HMAC-SHA-1-96的实际加密攻击。
[RFC-2104] states that for "minimally reasonable hash functions" the "birthday attack" is impractical. For a 64-byte block hash such as HMAC-SHA-1-96, an attack involving the successful processing of 2**80 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]指出，对于“最小合理哈希函数”，“生日攻击”是不切实际的。对于64字节块散列（如HMAC-SHA-1-96），涉及成功处理2**80块的攻击将不可行，除非在处理2**30块后发现基础散列存在冲突。具有这种弱抗碰撞特性的散列通常被认为是不可用的。
It is also important to consider that while SHA-1 was never developed to be used as a keyed hash algorithm, HMAC had that criteria from the onset.
同样重要的是，考虑到SHA-1从来没有被用作密钥哈希算法，HMAC从发病起就有这个标准。
[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 SHA-1 with other algorithms such as MD5. [RFC-2104] contains a detailed discussion on the strengths and weaknesses of HMAC algorithms.
由于[RFC-2104]提供了将各种散列算法与HMAC相结合的框架，因此可以用其他算法（如MD5）代替SHA-1。[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-SHA-1-96 code.
与任何加密算法一样，其部分优势在于算法实现的正确性、密钥管理机制及其实现的安全性、相关密钥的强度以及所有参与系统中实现的正确性。[RFC-2202]包含测试向量和示例代码，以帮助验证HMAC-SHA-1-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对本文件中某些特定密码文本的评论和建议。
[FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,
April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
[FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,
April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
[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月。
[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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。