Network Working Group A. Keromytis
Request for Comments: 2857 University of Pennsylvania
Category: Standards Track N. Provos
Center for Information Technology Integration
June 2000
Network Working Group A. Keromytis
Request for Comments: 2857 University of Pennsylvania
Category: Standards Track N. Provos
Center for Information Technology Integration
June 2000
The Use of HMAC-RIPEMD-160-96 within ESP and AH
HMAC-RIPEMD-160-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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection.
本备忘录描述了将HMAC算法[RFC 2104]与RIPEMD-160算法[RIPEMD-160]结合使用，作为修订版IPSEC封装安全负载[ESP]和修订版IPSEC认证头[AH]内的认证机制。带有RIPEMD-160的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 RIPEMD-160 [RIPEMD-160] 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-RIPEMD-160-96 is to ensure that the packet is authentic and cannot be modified in transit.
本备忘录规定在封装安全有效载荷和认证报头的上下文中，将RIPEMD-160[RIPEMD-160]与HMAC[RFC 2104]结合使用作为密钥认证机制。HMAC-RIPEMD-160-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-RIPEMD-160-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-RIPEMD-160-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]中所述进行解释。
[RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while [RFC 2104] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as RIPEMD-160.
[RIPEMD-160]描述了底层RIPEMD-160算法，而[RFC 2104]描述了HMAC算法。HMAC算法为插入各种散列算法（如RIPEMD-160）提供了一个框架。
HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. Padding requirements are specified in [RIPEMD-160] and are part of the RIPEMD-160 algorithm. Padding bits are only necessary in computing the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in the packet.
HMAC-RIPEMD-160-96对64字节的数据块进行操作。填充要求在[RIPEMD-160]中规定，并且是RIPEMD-160算法的一部分。填充位仅在计算HMAC-RIPEMD-160验证器值时需要，不得包含在数据包中。
HMAC-RIPEMD-160-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-RIPEMD-160-96.
HMAC-RIPEMD-160-96生成160位验证器值。如RFC2104所述，可以截断该160位值。对于ESP或AH，必须支持使用前96位的截断值。发送时，截断的值存储在authenticator字段中。收到后，计算整个160位值，并将前96位与存储在验证器字段中的值进行比较。HMAC-RIPEMD-160-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". [RIPEMD-160] provides some performance analysis. As of this writing no detailed performance analysis has been done of HMAC or HMAC combined with RIPEMD-160.
[Bellare96a]指出“（HMAC）性能本质上是底层哈希函数的性能”。[RIPEMD-160]提供了一些性能分析。截至本文撰写之时，尚未对HMAC或HMAC与RIPEMD-160的组合进行详细的性能分析。
[RFC 2104] outlines an implementation modification which can improve per-packet performance without affecting interoperability.
[RFC 2104]概述了一种实现修改，它可以在不影响互操作性的情况下提高每个数据包的性能。
HMAC-RIPEMD-160-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 SHALL NOT be supported. 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-RIPEMD-160-96是一种密钥算法。虽然[RFC 2104]中未指定固定密钥长度，但对于ESP或AH，必须支持160位的固定密钥长度。不支持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. Implementors should refer to RFC 1750 for guidance on the requirements for such functions.
[RFC 2104]讨论了关键材料的要求，其中包括对强随机性要求的讨论。必须使用强伪随机函数生成所需的160位密钥。实施者应参考RFC 1750，以获取有关此类功能要求的指南。
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的一组弱密钥，则必须拒绝使用这些弱密钥，然后请求替换密钥或新协商的安全关联。
[ESP] describes the general mechanism to obtain keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manual and automatic key management mechanisms.
[ESP]描述了为ESP转换获取关键帧材质的一般机制。在手动密钥管理机制和自动密钥管理机制之间，从一定数量的密钥材料中派生密钥没有区别。
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] states that for "minimally reasonable hash functions" the "birthday attack" is impractical. For a 64-byte block hash such as HMAC-RIPEMD-160-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.) No time-based attacks are discussed in the document.
[RFC 2104]指出，对于“最小合理哈希函数”，“生日攻击”是不切实际的。对于64字节块散列（如HMAC-RIPEMD-160-96），涉及成功处理2**64块的攻击将不可行，除非在处理2**30块后发现基础散列存在冲突。（具有这种弱抗冲突特性的散列通常被认为是不可用的。）本文档中未讨论基于时间的攻击。
While it it still cryptographically prudent to perform frequent rekeying, current literature does not include any recommended key lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key lifetimes become available they will be included in a revised version of this document.
虽然在加密方面仍然谨慎地执行频繁的密钥更新，但目前的文献没有包括HMAC-RIPEMD的任何建议密钥寿命。当HMAC-RIPEMD密钥使用寿命的建议可用时，这些建议将包含在本文件的修订版本中。
As of this writing, there are no known issues which preclude the use of the HMAC-RIPEMD-160-96 algorithm with any specific cipher algorithm.
截至本文撰写之时，还没有任何已知问题阻止HMAC-RIPEMD-160-96算法与任何特定密码算法一起使用。
The security provided by HMAC-RIPEMD-160-96 is based upon the strength of HMAC, and to a lesser degree, the strength of RIPEMD-160. At the time of this writing there are no known practical cryptographic attacks against RIPEMD-160.
HMAC-RIPEMD-160-96提供的安全性基于HMAC的强度，在较小程度上基于RIPEMD-160的强度。在撰写本文时，还没有已知的针对RIPEMD-160的实用密码攻击。
It is also important to consider that while RIPEMD-160 was never developed to be used as a keyed hash algorithm, HMAC had that criteria from the onset.
同样重要的是，考虑到RIPEM-160从来没有被开发为密钥哈希算法，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 RIPEMD-160 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）代替RIPEMD-160。[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. [Kapp97] contains test vectors and example code to assist in verifying the correctness of HMAC-RIPEMD-160-96 code.
与任何加密算法一样，其部分优势在于算法实现的正确性、密钥管理机制及其实现的安全性、相关密钥的强度以及所有参与系统中实现的正确性。[Kapp97]包含测试向量和示例代码，以帮助验证HMAC-RIPEMD-160-96代码的正确性。
This document is derived from work by C. Madson and R. Glenn and 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.
本文件来源于C.Madson和R.Glenn的工作，以及Jim Hughes、与Jim合作进行DES/CBC+HMAC-MD5 ESP组合转换的人员、ANX bakeoff参与者和IPsec工作组成员之前的工作。
[RIPEMD-160] 3.ISO/IEC 10118-3:1998, "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions," International Organization for Standardization, Geneva, Switzerland, 1998.
[RIPEMD-160]3.ISO/IEC 10118-3:1998，“信息技术-安全技术-哈希函数-第3部分：专用哈希函数”，国际标准化组织，瑞士日内瓦，1998年。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, September, 1997.
[RFC 2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年9月。
[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, June 1996.
[Bellare96a]Bellare，M.，Canetti，R.，Krawczyk，H.，“用于消息认证的密钥散列函数”，密码学进展，Crypto96，1996年6月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，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月。
[Kapp97] Kapp, J., "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", RFC 2286, March 1998.
[Kapp97]Kapp，J.，“HMAC-RIPEMD160和HMAC-RIPEMD128的测试案例”，RFC 2286，1998年3月。
[RFC 1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 1750]Eastlake 3rd，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[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月。
Angelos D. Keromytis Distributed Systems Lab Computer and Information Science Department University of Pennsylvania 200 S. 33rd Street Philadelphia, PA 19104 - 6389
安吉洛斯D.克罗米特分布系统实验室计算机与信息科学系宾夕法尼亚大学200 S.第三十三街费城，PA 19104 - 6389
EMail: angelos@dsl.cis.upenn.edu
EMail: angelos@dsl.cis.upenn.edu
Niels Provos Center for Information Technology Integration University of Michigan 519 W. William Ann Arbor, Michigan 48103 USA
尼尔斯普罗沃信息技术集成中心密歇根大学519 W威廉密歇根安娜堡48103美国
EMail: provos@citi.umich.edu
EMail: provos@citi.umich.edu
The IPsec working group can be contacted through the chairs:
可通过主席与IPsec工作组联系：
Robert Moskowitz International Computer Security Association
罗伯特·莫斯科维茨国际计算机安全协会
EMail: rgm@icsa.net
EMail: rgm@icsa.net
Ted T'so VA Linux Systems
Ted T'so VA Linux系统
EMail: tytso@valinux.com
EMail: tytso@valinux.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编辑功能的资金目前由互联网协会提供。