Internet Engineering Task Force (IETF) M. Baushke
Request for Comments: 8268 Juniper Networks, Inc.
Updates: 4250, 4253 December 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Baushke
Request for Comments: 8268 Juniper Networks, Inc.
Updates: 4250, 4253 December 2017
Category: Standards Track
ISSN: 2070-1721
More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
用于安全Shell（SSH）的更多模幂运算（MODP）Diffie-Hellman（DH）密钥交换（KEX）组
Abstract
摘要
This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.
本文档使用SHA-2散列为Secure Shell（SSH）协议定义了添加的模块求幂（MODP）组。本文档更新了RFC 4250。本文档通过更正有关检查对等方的DH公钥的错误来更新RFC 4253。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8268.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8268.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4
4. Checking the Peer's DH Public Key . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4
4. Checking the Peer's DH Public Key . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
Secure Shell (SSH) is a common protocol for secure communication on the Internet. Security protocols and primitives are an active area for research and help to suggest updates to SSH.
Secure Shell（SSH）是Internet上用于安全通信的通用协议。安全协议和原语是一个活跃的研究领域，有助于建议SSH的更新。
Section 8 of [RFC4253] contains a small error in point 3 regarding checking the Peer's DH Public Key. Section 4 of this document provides the correction.
[RFC4253]的第8节在第3点中包含一个关于检查对等方的DH公钥的小错误。本文件第4节提供了更正。
Due to security concerns with SHA-1 [RFC6194] and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1], implementers and users should request support for larger Diffie-Hellman (DH) MODP group sizes with data-integrity verification by using the SHA-2 family of secure hash algorithms and by having MODP groups provide more security. The use of larger MODP groups and the move to the SHA-2 family of hashes are important features to strengthen the key exchange algorithms available to the SSH client and server.
由于SHA-1[RFC6194]和小于2048位的MODP组[NIST-SP-800-131Ar1]的安全问题，实施者和用户应请求支持更大的Diffie-Hellman（DH）MODP组大小，并通过使用SHA-2系列安全哈希算法和让MODP组提供更多安全性来验证数据完整性。使用更大的MODP组和迁移到SHA-2系列散列是加强SSH客户端和服务器可用的密钥交换算法的重要特性。
DH primes being adopted by this document are all "safe primes" such that p = 2q + 1 where q is also a prime. New MODP groups are being introduced starting with the MODP 3072-bit group15. All use SHA512 as the hash algorithm.
本文件采用的DH素数均为“安全素数”，因此p=2q+1，其中q也是素数。新的MODP组从MODP 3072位组15开始引入。都使用SHA512作为哈希算法。
The DH 2048-bit MODP group14 is already present in most SSH implementations and most implementations already have a SHA256 implementation, so "diffie-hellman-group14-sha256" is provided as easy to implement.
DH 2048位MODP group14已经出现在大多数SSH实现中，并且大多数实现都已经有了SHA256实现，因此“diffie-hellman-group14-SHA256”很容易实现。
It is intended that these new MODP groups with SHA-2-based hashes update Section 6.4 of [RFC4253] and Section 4.10 of [RFC4250].
这些基于SHA-2哈希的新MODP组将更新[RFC4253]第6.4节和[RFC4250]第4.10节。
The United States Information Assurance Directorate (IAD) at the National Security Agency (NSA) has published "Commercial National Security Algorithm Suite and Quantum Computing Frequently Asked Questions". [MFQ-U-OO-815099-15] is addressed to organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS.
美国国家安全局（NSA）的美国信息保障局（IAD）发布了“商业国家安全算法套件和量子计算常见问题”。[MFQ-U-OO-815099-15]面向运行机密或非机密国家安全系统（NSS）的组织以及制造NSS中使用的产品的供应商。
This FAQ document indicates that NSS should no longer use:
此常见问题解答文档表明NSS不应再使用：
o Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) with NIST P-256. (For SSH, this would suggest avoiding [RFC5656] Key Exchange Algorithm "ecdh-sha2-nistp256" and Public Key Algorithm "ecdsa-sha2-nistp256".)
o 具有NIST P-256的椭圆曲线Diffie-Hellman（ECDH）和椭圆曲线数字签名算法（ECDSA）。（对于SSH，这建议避免[RFC5656]密钥交换算法“ecdh-sha2-nistp256”和公钥算法“ecdsa-sha2-nistp256”。）
o SHA-256 (For SSH, this would suggest avoiding any Key Exchange Method using SHA1, SHA224, or SHA256 in favor of using SHA384 or SHA512.)
o SHA-256（对于SSH，这建议避免使用任何使用SHA1、SHA224或SHA256的密钥交换方法，而使用SHA384或SHA512。）
o AES-128 (For SSH, this would suggest avoiding Encryption Algorithms [RFC4253] "aes128-cbc" and [RFC4344] "aes128-ctr".)
o AES-128（对于SSH，这建议避免使用加密算法[RFC4253]“aes128 cbc”和[RFC4344]“aes128 ctr”。）
o RSA with 2048-bit keys (For SSH, this would suggest avoiding [RFC4253] "ssh-rsa" using RSA with SHA1 as well as [RFC6187] "x509v3-rsa2048-sha256" as well as any other RSA key that has a length less than 3072-bits or uses a hash less than SHA384.)
o 带2048位密钥的RSA（对于SSH，这建议避免使用带SHA1的RSA的[RFC4253]“SSH RSA”以及[RFC6187]“x509v3-rsa2048-sha256”以及长度小于3072位或使用哈希小于SHA384的任何其他RSA密钥。）
o Diffie-Hellman with 2048-bit keys (For SSH, this would suggest avoiding use of [RFC4253] both of "diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1" as well as avoiding "diffie-hellman-group14-sha256" added by this document.)
o 具有2048位密钥的Diffie-Hellman（对于SSH，这建议避免同时使用[RFC4253]“Diffie-Hellman-group1-sha1”和“Diffie-Hellman-group14-sha1”，以及避免使用本文档添加的“Diffie-Hellman-group14-sha256”。）
The FAQ also states that NSS users should select DH groups based upon well-established and validated parameter sets that comply with the minimum required sizes. Some specific examples include:
常见问题解答还指出，NSS用户应根据符合最低要求尺寸的完善且经验证的参数集选择DH组。一些具体例子包括：
o Elliptic Curves are currently restricted to the NIST P-384 group only for both ECDH and ECDSA, in accordance with existing NIST and National Information Assurance Partnership (NIAP) standards. (For SSH, this means using [RFC5656] "ecdh-sha2-nistp384" for key exchange and "ecdsa-sha2-nistp384" for Public Key Algorithm Names.)
o 根据现有NIST和国家信息保证合作伙伴关系（NIAP）标准，椭圆曲线目前仅限于ECDH和ECDSA的NIST P-384组。（对于SSH，这意味着将[RFC5656]“ecdh-sha2-nistp384”用于密钥交换，将“ecdsa-sha2-nistp384”用于公钥算法名称。）
o RSA moduli should have a minimum size of 3072 bits (other than the noted PKI exception), and keys should be generated in accordance with all relevant NIST standards.
o RSA模块的最小大小应为3072位（注意到的PKI例外除外），密钥应根据所有相关NIST标准生成。
o For Diffie-Hellman, use a Diffie-Hellman prime modulus of at least 3072 bits. (For bit sizes as specified in [RFC3526], this would allow for any of group15, group16, group17, group18 to be used.)
o 对于Diffie-Hellman，使用至少3072位的Diffie-Hellman素数模。（对于[RFC3526]中规定的位大小，这将允许使用组15、组16、组17、组18中的任何一个。）
Although SSH may not always be used to protect Top Secret communications, this document adopts the use of the DH groups provided as an example in the FAQ as well as the use of SHA512 rather than SHA256 for the new DH groups.
尽管SSH可能并不总是用于保护绝密通信，但本文档采用了FAQ中提供的DH组的使用作为示例，以及对新DH组使用SHA512而不是SHA256。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document adds some new Key Exchange Algorithm Method Names to what originally appeared in [RFC4253] and [RFC4250].
本文档在[RFC4253]和[RFC4250]中最初出现的内容中添加了一些新的密钥交换算法方法名称。
This document adopts the style and conventions of [RFC4253] in specifying how the use of new data key exchange is indicated in SSH.
本文档采用[RFC4253]的样式和约定，指定如何在SSH中指示新数据密钥交换的使用。
The following new key exchange method algorithms are defined:
定义了以下新的密钥交换方法算法：
o diffie-hellman-group14-sha256
o diffie-hellman-group14-sha256
o diffie-hellman-group15-sha512
o diffie-hellman-group15-sha512
o diffie-hellman-group16-sha512
o diffie-hellman-group16-sha512
o diffie-hellman-group17-sha512
o diffie-hellman-group17-sha512
o diffie-hellman-group18-sha512
o diffie-hellman-group18-sha512
The SHA-2 family of secure hash algorithms is defined in [RFC6234].
[RFC6234]中定义了SHA-2系列安全哈希算法。
The method of key exchange used for the name "diffie-hellman-group14-sha256" is the same as that for "diffie-hellman-group14-sha1" except that the SHA256 hash algorithm is used. It is recommended that "diffie-hellman-group14-sha256" SHOULD be supported to smooth the transition to newer group sizes.
名称“diffie-hellman-group14-sha256”使用的密钥交换方法与“diffie-hellman-group14-sha1”相同，只是使用了sha256哈希算法。建议支持“diffie-hellman-group14-sha256”，以便顺利过渡到新的组大小。
The group15 through group18 names are the same as those specified in [RFC3526]: 3072-bit MODP group15, 4096-bit MODP group16, 6144-bit MODP group17, and 8192-bit MODP group18.
组15到组18的名称与[RFC3526]中指定的名称相同：3072位MODP组15、4096位MODP组16、6144位MODP组17和8192位MODP组18。
The SHA512 algorithm is to be used when "sha512" is specified as a part of the key exchange method name.
当“SHA512”被指定为密钥交换方法名称的一部分时，将使用SHA512算法。
Section 8 of [RFC4253] contains a small error in point 3. When checking e (client Public Key) and f (server Public Key) values, an incorrect range is provided. The erroneous text is:
[RFC4253]的第8节在第3点中包含一个小错误。检查e（客户端公钥）和f（服务器公钥）值时，提供的范围不正确。错误的文本是：
Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be sent or accepted by either side. If this condition is violated, the key exchange fails.
任何一方都不得发送或接受不在[1，p-1]范围内的“e”或“f”值。如果违反此条件，则密钥交换失败。
The problem is that the range should have been an open interval excluding the endpoint values. (i.e., "(1, p-1)"). This document amends that document text as follows:
问题在于，该范围应该是一个开放区间，不包括端点值。（即“（1，p-1）”。本文件对该文件文本进行如下修改：
DH Public Key values MUST be checked and both conditions:
必须检查DH公钥值，并且这两种情况都是：
1 < e < p-1
1<e<p-1
1 < f < p-1
1<f<p-1
MUST be true. Values not within these bounds MUST NOT be sent or accepted by either side. If either one of these conditions is violated, then the key exchange fails.
一定是真的。任何一方都不得发送或接受不在这些范围内的值。如果违反这些条件之一，则密钥交换失败。
This simple check ensures that:
此简单检查可确保：
o The remote peer behaves properly.
o 远程对等方的行为正常。
o The local system is not forced into the two-element subgroup.
o 本地系统不强制进入双元素子组。
IANA has added the following entries to the "Key Exchange Method Names" registry [IANA-KEX]:
IANA已将以下条目添加到“密钥交换方法名称”注册表[IANA-KEX]：
Method Name Reference
----------------------------- ---------
diffie-hellman-group14-sha256 RFC 8268
diffie-hellman-group15-sha512 RFC 8268
diffie-hellman-group16-sha512 RFC 8268
diffie-hellman-group17-sha512 RFC 8268
diffie-hellman-group18-sha512 RFC 8268
Method Name Reference
----------------------------- ---------
diffie-hellman-group14-sha256 RFC 8268
diffie-hellman-group15-sha512 RFC 8268
diffie-hellman-group16-sha512 RFC 8268
diffie-hellman-group17-sha512 RFC 8268
diffie-hellman-group18-sha512 RFC 8268
The security considerations of [RFC4253] apply to this document.
[RFC4253]的安全注意事项适用于本文件。
The security considerations of [RFC3526] suggest that MODP group14 through group18 have security strengths that range between 110 bits of security through 310 bits of security. They are based on "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys" [RFC3766]. Care should be taken to use sufficient entropy and/ or deterministic random-bit generator (DRBG) algorithms to maximize the true security strength of the key exchange and ciphers selected.
[RFC3526]的安全考虑表明，MODP组14到组18的安全强度介于110位到310位之间。它们基于“确定用于交换对称密钥的公钥的强度”[RFC3766]。应注意使用足够的熵和/或确定性随机位生成器（DRBG）算法，以最大化所选密钥交换和密码的真实安全强度。
Using a fixed set of Diffie-Hellman parameters makes them a high value target for pre-computation. Generating additional sets of primes to be used, or moving to larger values mitigates this issue.
使用一组固定的Diffie-Hellman参数使其成为预计算的高值目标。生成要使用的其他素数集，或移动到更大的值可以缓解此问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <https://www.rfc-editor.org/info/rfc3526>.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，DOI 10.17487/RFC3526，2003年5月<https://www.rfc-editor.org/info/rfc3526>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250]Lehtinen，S.和C.Lonvick，编辑，“安全外壳（SSH）协议分配编号”，RFC 4250，DOI 10.17487/RFC4250，2006年1月<https://www.rfc-editor.org/info/rfc4250>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters",
<http://www.iana.org/assignments/ssh-parameters/>
[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters",
<http://www.iana.org/assignments/ssh-parameters/>
[MFQ-U-OO-815099-15] National Security Agency / Central Security Service, "Commerical National Security Algorithm Suite and Quantum Computing FAQ", MFQ U/OO/815099-15 , January 2016, <https://www.iad.gov/iad/library/ia-guidance/ ia-solutions-for-classified/algorithm-guidance/assets/public/upload/ CNSA-Suite-and-Quantum-Computing-FAQ.pdf>.
[MFQ-U-OO-815099-15]国家安全局/中央安全局，“商业国家安全算法套件和量子计算常见问题”，MFQ U/OO/815099-15，2016年1月<https://www.iad.gov/iad/library/ia-guidance/ 分类的ia解决方案/算法指南/资产/公共/上传/CNSA套件和量子计算常见问题解答.pdf>。
[NIST-SP-800-131Ar1] Barker and Roginsky, "Transitions: Recommendation for the Transitioning of the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A, Revision 1, DOI 10.6028/NIST.SP.800-131Ar1, November 2015, <http://dx.doi.org/10.6028/NIST.SP.800-131Ar1>.
[NIST-SP-800-131Ar1]巴克和罗金斯基，“过渡：密码算法和密钥长度使用过渡的建议”，NIST特别出版物800-131A，第1版，DOI 10.6028/NIST.SP.800-131Ar1，2015年11月<http://dx.doi.org/10.6028/NIST.SP.800-131Ar1>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <https://www.rfc-editor.org/info/rfc3766>.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，DOI 10.17487/RFC3766，2004年4月<https://www.rfc-editor.org/info/rfc3766>.
[RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, DOI 10.17487/RFC4344, January 2006, <https://www.rfc-editor.org/info/rfc4344>.
[RFC4344]Bellare，M.，Kohno，T.，和C.Namprempre，“安全外壳（SSH）传输层加密模式”，RFC 4344，DOI 10.17487/RFC4344，2006年1月<https://www.rfc-editor.org/info/rfc4344>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.
[RFC5656]Stebila，D.和J.Green，“安全壳传输层中的椭圆曲线算法集成”，RFC 5656，DOI 10.17487/RFC5656，2009年12月<https://www.rfc-editor.org/info/rfc5656>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187]Igoe，K.和D.Stebila，“用于安全外壳身份验证的X.509v3证书”，RFC 6187，DOI 10.17487/RFC6187，2011年3月<https://www.rfc-editor.org/info/rfc6187>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <https://www.rfc-editor.org/info/rfc6194>.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 6194，DOI 10.17487/RFC6194，2011年3月<https://www.rfc-editor.org/info/rfc6194>.
Acknowledgements
致谢
Thanks to the following people for review and comments: Denis Bider, Peter Gutmann, Damien Miller, Niels Moller, Matt Johnston, Iwamoto Kouichi, Dave Dugal, Daniel Migault, Anna Johnston, Ron Frederick, Rich Salz, Travis Finkenauer, and Eric Rescorla.
感谢以下人士的评论：丹尼斯·拜德、彼得·古特曼、达米恩·米勒、尼尔斯·莫勒、马特·约翰斯顿、岩本·库伊奇、戴夫·杜格尔、丹尼尔·米高尔特、安娜·约翰斯顿、罗恩·弗雷德里克、里奇·萨尔兹、特拉维斯·芬克诺尔和埃里克·雷斯科拉。
Author's Address
作者地址
Mark D. Baushke Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, CA 94089-1228 United States of America
Mark D.Baushke Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市创新路1133号，邮编94089-1228
Phone: +1 408 745 2952
Email: mdb@juniper.net
URI: http://www.juniper.net/
Phone: +1 408 745 2952
Email: mdb@juniper.net
URI: http://www.juniper.net/