Network Working Group D. Eastlake 3rd
Request for Comments: 4635 Motorola Laboratories
Category: Standards Track August 2006
Network Working Group D. Eastlake 3rd
Request for Comments: 4635 Motorola Laboratories
Category: Standards Track August 2006
HMAC SHA TSIG Algorithm Identifiers
HMAC沙尖算法标识符
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
摘要
Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG.
使用域名系统TSIG资源记录需要指定加密消息身份验证码。目前，仅为HMAC MD5（哈希消息认证码，消息摘要5）和GSS（通用安全服务）TSIG算法指定了标识符。本文件标准化了附加HMAC SHA（安全哈希算法）TSIG算法的标识符和实现要求，并标准化了如何指定和处理TSIG中HMAC值的截断。
Table of Contents
目录
1. Introduction ....................................................2
2. Algorithms and Identifiers ......................................2
3. Specifying Truncation ...........................................3
3.1. Truncation Specification ...................................4
4. TSIG Truncation Policy and Error Provisions .....................4
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Normative References ............................................6
8. Informative References. .........................................7
1. Introduction ....................................................2
2. Algorithms and Identifiers ......................................2
3. Specifying Truncation ...........................................3
3.1. Truncation Specification ...................................4
4. TSIG Truncation Policy and Error Provisions .....................4
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Normative References ............................................6
8. Informative References. .........................................7
[RFC2845] specifies a TSIG Resource Record (RR) that can be used to authenticate DNS (Domain Name System [STD13]) queries and responses. This RR contains a domain name syntax data item that names the authentication algorithm used. [RFC2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5 (Message Digest 5) [RFC1321] hash algorithm. IANA has also registered "gss-tsig" as an identifier for TSIG authentication where the cryptographic operations are delegated to the Generic Security Service (GSS) [RFC3645].
[RFC2845]指定可用于验证DNS（域名系统[STD13]）查询和响应的TSIG资源记录（RR）。此RR包含一个域名语法数据项，用于命名所使用的身份验证算法。[RFC2845]使用HMAC（哈希消息身份验证码）[RFC2104]算法和MD5（消息摘要5）[RFC1321]哈希算法定义身份验证码的HMAC-MD5.SIG-ALG.REG.INT名称。IANA还将“gss tsig”注册为tsig认证的标识符，其中密码操作被委托给通用安全服务（gss）[RFC3645]。
Note that use of TSIG presumes prior agreement, between the resolver and server involved, as to the algorithm and key to be used.
请注意，TSIG的使用假定冲突解决程序和相关服务器之间就要使用的算法和密钥事先达成一致。
In Section 2, this document specifies additional names for TSIG authentication algorithms based on US NIST SHA (United States, National Institute of Science and Technology, Secure Hash Algorithm) algorithms and HMAC and specifies the implementation requirements for those algorithms.
在第2节中，本文件规定了基于美国NIST SHA（美国国家科学技术研究院，安全哈希算法）算法和HMAC的TSIG认证算法的其他名称，并规定了这些算法的实施要求。
In Section 3, this document specifies the effect of inequality between the normal output size of the specified hash function and the length of MAC (Message Authentication Code) data given in the TSIG RR. In particular, it specifies that a shorter-length field value specifies truncation and that a longer-length field is an error.
在第3节中，本文件规定了指定哈希函数的正常输出大小与TSIG RR中给出的MAC（消息认证码）数据长度之间不相等的影响。特别是，它指定长度较短的字段值指定截断，长度较长的字段为错误。
In Section 4, policy restrictions and implications related to truncation are described and specified, as is a new error code to indicate truncation shorter than that permitted by policy.
在第4节中，描述并指定了与截断相关的策略限制和含义，以及一个新的错误代码，用于指示短于策略允许的截断。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”、“可能”应按照[RFC2119]中的说明进行解释。
TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS queries and responses. They are intended to be efficient symmetric authentication codes based on a shared secret. (Asymmetric signatures can be provided using the SIG RR [RFC2931]. In particular, SIG(0) can be used for transaction signatures.) Used with a strong hash function, HMAC [RFC2104] provides a way to calculate such symmetric authentication codes. The only specified HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-ALG.REG.INT, based on MD5 [RFC1321].
TSIG资源记录（RRs）[RFC2845]用于验证DNS查询和响应。它们旨在成为基于共享秘密的高效对称身份验证码。（可以使用SIG RR[RFC2931]提供非对称签名。特别是，SIG（0）可以用于事务签名。）HMAC[RFC2104]与强散列函数一起使用，提供了一种计算此类对称身份验证码的方法。唯一指定的基于HMAC的TSIG算法标识符是基于MD5[RFC1321]的HMAC-MD5.SIG-ALG.REG.INT。
The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as compared with the 128 bits for MD5, and additional hash algorithms in the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and 512 bits may be preferred in some cases. This is because increasingly successful cryptanalytic attacks are being made on the shorter hashes.
与MD5的128位相比，SHA-1[FIPS180-2，RFC3174]是一个160位的散列，在某些情况下，可能会首选使用SHA系列[FIPS180-2，RFC3874，RFC4634]中224、256、384和512位的附加散列算法。这是因为越来越成功的密码分析攻击是在较短的散列上进行的。
Use of TSIG between a DNS resolver and server is by mutual agreement. That agreement can include the support of additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restriction and guidelines in Sections 3 and 4 below. Key agreement can be by the TKEY mechanism [RFC2930] or some other mutually agreeable method.
DNS解析程序和服务器之间的TSIG使用是通过双方协议进行的。该协议可包括支持其他算法和标准，以确定哪些算法和截断是可接受的，但须遵守下文第3节和第4节中的限制和指南。密钥协商可以通过TKEY机制[RFC2930]或其他双方同意的方法进行。
The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are included in the table below for convenience. Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below.
为方便起见，下表中包含了当前HMAC-MD5.SIG-ALG.REG.INT和gss tsig标识符。支持TSIG的实现还必须实现HMAC SHA1和HMAC SHA256，并且可以实现gss TSIG和下面列出的其他算法。
Mandatory HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512
强制性HMAC-MD5.SIG-ALG.REG.INT可选gss tsig强制性HMAC-sha1可选HMAC-sha224强制性HMAC-sha256可选hamc-sha384可选HMAC-sha512
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
SHA-1应被截断为96位（12个八位字节）。
When space is at a premium and the strength of the full length of an HMAC is not needed, it is reasonable to truncate the HMAC output and use the truncated value for authentication. HMAC SHA-1 truncated to 96 bits is an option available in several IETF protocols, including IPsec and TLS.
当空间非常宝贵且不需要HMAC全长的强度时，截断HMAC输出并使用截断值进行身份验证是合理的。HMAC SHA-1被截断为96位是几种IETF协议中可用的选项，包括IPsec和TLS。
The TSIG RR [RFC2845] includes a "MAC size" field, which gives the size of the MAC field in octets. However, [RFC2845] does not specify what to do if this MAC size differs from the length of the output of HMAC for a particular hash function. Truncation is indicated by a MAC size less than the HMAC size, as specified below.
其中，字段中的“MAC”的大小为“c2845”。但是，[RFC2845]没有指定如果此MAC大小与特定哈希函数的HMAC输出长度不同，该怎么办。截断由小于HMAC大小的MAC大小表示，如下所述。
The specification for TSIG handling is changed as follows:
TSIG处理规范变更如下：
1. If "MAC size" field is greater than HMAC output length:
1. 如果“MAC大小”字段大于HMAC输出长度：
This case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned.
不得生成此案例，如果收到此案例，则必须导致丢弃数据包并返回RCODE 1（FORMERR）。
2. If "MAC size" field equals HMAC output length:
2. 如果“MAC大小”字段等于HMAC输出长度：
Operation is as described in [RFC2845], and the entire output HMAC output is present.
操作如[RFC2845]所述，整个输出HMAC输出存在。
3. "MAC size" field is less than HMAC output length but greater than that specified in case 4, below:
3. “MAC大小”字段小于HMAC输出长度，但大于以下情况4中指定的长度：
This is sent when the signer has truncated the HMAC output to an allowable length, as described in RFC 2104, taking initial octets and discarding trailing octets. TSIG truncation can only be to an integral number of octets. On receipt of a packet with truncation thus indicated, the locally calculated MAC is similarly truncated and only the truncated values are compared for authentication. The request MAC used when calculating the TSIG MAC for a reply is the truncated request MAC.
当签名者将HMAC输出截断到允许的长度（如RFC 2104中所述）时，将发送此消息，获取初始八位字节并丢弃后续八位字节。TSIG截断只能是整数个八位组。在接收到具有这样指示的截断的分组时，本地计算的MAC类似地被截断，并且仅比较被截断的值以进行认证。计算应答的TSIG MAC时使用的请求MAC是截断的请求MAC。
4. "MAC size" field is less than the larger of 10 (octets) and half the length of the hash function in use:
4. “MAC大小”字段小于10（八位字节）和正在使用的哈希函数长度的一半中的较大值：
With the exception of certain TSIG error messages described in RFC 2845, Section 3.2, where it is permitted that the MAC size be zero, this case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned. The size limit for this case can also, for the hash functions mentioned in this document, be stated as less than half the hash function length for hash functions other than MD5 and less than 10 octets for MD5.
除了RFC 2845第3.2节中描述的某些TSIG错误消息（允许MAC大小为零）外，不得生成这种情况，如果接收到这种情况，则必须丢弃数据包并返回RCODE 1（FORMERR）。对于本文档中提到的哈希函数，这种情况下的大小限制也可以表示为小于MD5以外的哈希函数的哈希函数长度的一半，小于MD5的10个八位字节。
Use of TSIG is by mutual agreement between a resolver and server. Implicit in such "agreement" are criterion as to acceptable keys and algorithms and, with the extensions in this document, truncations. Note that it is common for implementations to bind the TSIG secret key or keys that may be in place at a resolver and server to particular algorithms. Thus, such implementations only permit the
TSIG的使用是通过解析器和服务器之间的相互协议进行的。在这种“协议”中隐含着关于可接受的密钥和算法的标准，以及本文档中的扩展、截断。请注意，实现通常会将TSIG密钥或可能位于解析器和服务器上的密钥绑定到特定算法。因此，这样的实现只允许
use of an algorithm if there is an associated key in place. Receipt of an unknown, unimplemented, or disabled algorithm typically results in a BADKEY error.
如果存在关联的密钥，则使用算法。接收到未知、未实现或禁用的算法通常会导致坏键错误。
Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory.
本地策略可能要求拒绝TSIGs，即使它们使用强制实施的算法。
When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full HMAC output.
当本地策略允许接受具有特定算法和特定非零截断量的TSIG时，还应允许使用具有较小截断（较长MAC）的该算法，直至完整HMAC输出。
Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request, unless the request specified a MAC length longer than the HMAC output.
无论本地策略指定的可接受的较低截断MAC长度如何，都应使用至少与相应请求中MAC长度相同的MAC发送回复，除非请求指定的MAC长度大于HMAC输出。
Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list. When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy.
允许多个可接受算法和/或截断的实现应允许此列表按假定强度排序，并应允许将同一算法的不同截断视为此列表中的单独实体。当这样实现时，策略应接受假定的比策略要求的最小强度更强的算法和截断。
If a TSIG is received with truncation that is permitted under Section 3 above but the MAC is too short for the local policy in force, an RCODE of 22 (BADTRUNC) MUST be returned.
如果接收到的TSIG具有上文第3节允许的截断，但MAC对于生效的本地策略而言太短，则必须返回RCODE 22（BADTRUNC）。
This document (1) registers the new TSIG algorithm identifiers listed in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in Section 4 [RFC2845].
本文件（1）向IANA注册第2节中列出的新TSIG算法标识符，（2）分配第4节[RFC2845]中的BADTRUNC RCODE 22。
For all of the message authentication code algorithms listed herein, those producing longer values are believed to be stronger; however, while there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104].
对于本文列出的所有消息认证码算法，产生更长值的那些被认为是更强的；然而，尽管有一些观点认为，轻微的截断可以通过减少攻击者可用的信息来增强MAC，但过度截断显然会通过减少攻击者必须尝试用暴力破坏身份验证的位数来削弱身份验证[RFC2104]。
Significant progress has been made recently in cryptanalysis of hash function of the types used herein, all of which ultimately derive from the design of MD4. While the results so far should not effect
最近在本文所用类型的哈希函数的密码分析方面取得了重大进展，所有这些最终都源自MD4的设计。虽然到目前为止的结果应该不会产生影响
HMAC, the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution.
HMAC，由于谨慎，更强的SHA-1和SHA-256算法被强制执行。
See the Security Considerations section of [RFC2845]. See also the Security Considerations section of [RFC2104] from which the limits on truncation in this RFC were taken.
请参阅[RFC2845]的安全注意事项部分。另请参见[RFC2104]中的安全注意事项部分，该部分对本RFC中的截断进行了限制。
[FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US Federal Information Processing Standard, with Change Notice 1, February 2004.
[FIPS180-2]“安全哈希标准”（SHA-1/224/256/384/512）美国联邦信息处理标准，附变更通知，2004年2月1日。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.
[RFC3874]Housley，R.，“224位单向散列函数：SHA-224”，RFC 3874，2004年9月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake，D.和T.Hansen，“美国安全哈希算法（SHA）”，RFC 46342006年7月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
8. Informative References.
8. 参考资料。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake 3rd，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 2003.
[RFC3645]Kwan，S.，Garg，P.，Gilroy，J.，Esibov，L.，Westhead，J.，和R.Hall，“DNS密钥交易认证的通用安全服务算法（GSS-TSIG）”，RFC 36452003年10月。
Author's Address
作者地址
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake 3rd Motorola Laboratories美国马萨诸塞州米尔福德市海狸街155号，邮编01757
Phone: +1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Phone: +1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
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）提供。