| blob | 554502dc91e6d23be6f6609dde0d85830c6aa2a0 |
7 Network Working Group D. Eastlake 3rd
8 Request for Comments: 4635 Motorola Laboratories
9 Category: Standards Track August 2006
12 HMAC SHA TSIG Algorithm Identifiers
14 Status of This Memo
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
22 Copyright Notice
24 Copyright (C) The Internet Society (2006).
26 Abstract
28 Use of the Domain Name System TSIG resource record requires
29 specification of a cryptographic message authentication code.
30 Currently, identifiers have been specified only for HMAC MD5 (Hashed
31 Message Authentication Code, Message Digest 5) and GSS (Generic
32 Security Service) TSIG algorithms. This document standardizes
33 identifiers and implementation requirements for additional HMAC SHA
34 (Secure Hash Algorithm) TSIG algorithms and standardizes how to
35 specify and handle the truncation of HMAC values in TSIG.
37 Table of Contents
39 1. Introduction ....................................................2
40 2. Algorithms and Identifiers ......................................2
41 3. Specifying Truncation ...........................................3
42 3.1. Truncation Specification ...................................4
43 4. TSIG Truncation Policy and Error Provisions .....................4
44 5. IANA Considerations .............................................5
45 6. Security Considerations .........................................5
46 7. Normative References ............................................6
47 8. Informative References. .........................................7
58 Eastlake 3rd Standards Track [Page 1]
59 \f
60 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
63 1. Introduction
65 [RFC2845] specifies a TSIG Resource Record (RR) that can be used to
66 authenticate DNS (Domain Name System [STD13]) queries and responses.
67 This RR contains a domain name syntax data item that names the
68 authentication algorithm used. [RFC2845] defines the
69 HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC
70 (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5
71 (Message Digest 5) [RFC1321] hash algorithm. IANA has also
72 registered "gss-tsig" as an identifier for TSIG authentication where
73 the cryptographic operations are delegated to the Generic Security
74 Service (GSS) [RFC3645].
76 Note that use of TSIG presumes prior agreement, between the resolver
77 and server involved, as to the algorithm and key to be used.
79 In Section 2, this document specifies additional names for TSIG
80 authentication algorithms based on US NIST SHA (United States,
81 National Institute of Science and Technology, Secure Hash Algorithm)
82 algorithms and HMAC and specifies the implementation requirements for
83 those algorithms.
85 In Section 3, this document specifies the effect of inequality
86 between the normal output size of the specified hash function and the
87 length of MAC (Message Authentication Code) data given in the TSIG
88 RR. In particular, it specifies that a shorter-length field value
89 specifies truncation and that a longer-length field is an error.
91 In Section 4, policy restrictions and implications related to
92 truncation are described and specified, as is a new error code to
93 indicate truncation shorter than that permitted by policy.
95 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in
96 this document are to be interpreted as described in [RFC2119].
98 2. Algorithms and Identifiers
100 TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS
101 queries and responses. They are intended to be efficient symmetric
102 authentication codes based on a shared secret. (Asymmetric
103 signatures can be provided using the SIG RR [RFC2931]. In
104 particular, SIG(0) can be used for transaction signatures.) Used
105 with a strong hash function, HMAC [RFC2104] provides a way to
106 calculate such symmetric authentication codes. The only specified
107 HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-
108 ALG.REG.INT, based on MD5 [RFC1321].
114 Eastlake 3rd Standards Track [Page 2]
115 \f
116 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
119 The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as
120 compared with the 128 bits for MD5, and additional hash algorithms in
121 the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and
122 512 bits may be preferred in some cases. This is because
123 increasingly successful cryptanalytic attacks are being made on the
124 shorter hashes.
126 Use of TSIG between a DNS resolver and server is by mutual agreement.
127 That agreement can include the support of additional algorithms and
128 criteria as to which algorithms and truncations are acceptable,
129 subject to the restriction and guidelines in Sections 3 and 4 below.
130 Key agreement can be by the TKEY mechanism [RFC2930] or some other
131 mutually agreeable method.
133 The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
134 included in the table below for convenience. Implementations that
135 support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
136 implement gss-tsig and the other algorithms listed below.
138 Mandatory HMAC-MD5.SIG-ALG.REG.INT
139 Optional gss-tsig
140 Mandatory hmac-sha1
141 Optional hmac-sha224
142 Mandatory hmac-sha256
143 Optional hamc-sha384
144 Optional hmac-sha512
146 SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
148 3. Specifying Truncation
150 When space is at a premium and the strength of the full length of an
151 HMAC is not needed, it is reasonable to truncate the HMAC output and
152 use the truncated value for authentication. HMAC SHA-1 truncated to
153 96 bits is an option available in several IETF protocols, including
154 IPsec and TLS.
156 The TSIG RR [RFC2845] includes a "MAC size" field, which gives the
157 size of the MAC field in octets. However, [RFC2845] does not specify
158 what to do if this MAC size differs from the length of the output of
159 HMAC for a particular hash function. Truncation is indicated by a
160 MAC size less than the HMAC size, as specified below.
170 Eastlake 3rd Standards Track [Page 3]
171 \f
172 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
175 3.1. Truncation Specification
177 The specification for TSIG handling is changed as follows:
179 1. If "MAC size" field is greater than HMAC output length:
181 This case MUST NOT be generated and, if received, MUST cause
182 the packet to be dropped and RCODE 1 (FORMERR) to be returned.
184 2. If "MAC size" field equals HMAC output length:
186 Operation is as described in [RFC2845], and the entire output
187 HMAC output is present.
189 3. "MAC size" field is less than HMAC output length but greater than
190 that specified in case 4, below:
192 This is sent when the signer has truncated the HMAC output to
193 an allowable length, as described in RFC 2104, taking initial
194 octets and discarding trailing octets. TSIG truncation can only
195 be to an integral number of octets. On receipt of a packet with
196 truncation thus indicated, the locally calculated MAC is similarly
197 truncated and only the truncated values are compared for
198 authentication. The request MAC used when calculating the TSIG
199 MAC for a reply is the truncated request MAC.
201 4. "MAC size" field is less than the larger of 10 (octets) and half
202 the length of the hash function in use:
204 With the exception of certain TSIG error messages described in
205 RFC 2845, Section 3.2, where it is permitted that the MAC size be
206 zero, this case MUST NOT be generated and, if received, MUST cause
207 the packet to be dropped and RCODE 1 (FORMERR) to be returned.
208 The size limit for this case can also, for the hash functions
209 mentioned in this document, be stated as less than half the hash
210 function length for hash functions other than MD5 and less than 10
211 octets for MD5.
213 4. TSIG Truncation Policy and Error Provisions
215 Use of TSIG is by mutual agreement between a resolver and server.
216 Implicit in such "agreement" are criterion as to acceptable keys and
217 algorithms and, with the extensions in this document, truncations.
218 Note that it is common for implementations to bind the TSIG secret
219 key or keys that may be in place at a resolver and server to
220 particular algorithms. Thus, such implementations only permit the
226 Eastlake 3rd Standards Track [Page 4]
227 \f
228 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
231 use of an algorithm if there is an associated key in place. Receipt
232 of an unknown, unimplemented, or disabled algorithm typically results
233 in a BADKEY error.
235 Local policies MAY require the rejection of TSIGs, even though
236 they use an algorithm for which implementation is mandatory.
238 When a local policy permits acceptance of a TSIG with a particular
239 algorithm and a particular non-zero amount of truncation, it SHOULD
240 also permit the use of that algorithm with lesser truncation (a
241 longer MAC) up to the full HMAC output.
243 Regardless of a lower acceptable truncated MAC length specified by
244 local policy, a reply SHOULD be sent with a MAC at least as long as
245 that in the corresponding request, unless the request specified a MAC
246 length longer than the HMAC output.
248 Implementations permitting multiple acceptable algorithms and/or
249 truncations SHOULD permit this list to be ordered by presumed
250 strength and SHOULD allow different truncations for the same
251 algorithm to be treated as separate entities in this list. When so
252 implemented, policies SHOULD accept a presumed stronger algorithm and
253 truncation than the minimum strength required by the policy.
255 If a TSIG is received with truncation that is permitted under
256 Section 3 above but the MAC is too short for the local policy in
257 force, an RCODE of 22 (BADTRUNC) MUST be returned.
259 5. IANA Considerations
261 This document (1) registers the new TSIG algorithm identifiers listed
262 in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in
263 Section 4 [RFC2845].
265 6. Security Considerations
267 For all of the message authentication code algorithms listed herein,
268 those producing longer values are believed to be stronger; however,
269 while there have been some arguments that mild truncation can
270 strengthen a MAC by reducing the information available to an
271 attacker, excessive truncation clearly weakens authentication by
272 reducing the number of bits an attacker has to try to break the
273 authentication by brute force [RFC2104].
275 Significant progress has been made recently in cryptanalysis of hash
276 function of the types used herein, all of which ultimately derive
277 from the design of MD4. While the results so far should not effect
282 Eastlake 3rd Standards Track [Page 5]
283 \f
284 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
287 HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
288 mandatory due to caution.
290 See the Security Considerations section of [RFC2845]. See also the
291 Security Considerations section of [RFC2104] from which the limits on
292 truncation in this RFC were taken.
294 7. Normative References
296 [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US
297 Federal Information Processing Standard, with Change
298 Notice 1, February 2004.
300 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
301 1321, April 1992.
303 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
304 Keyed-Hashing for Message Authentication", RFC 2104,
305 February 1997.
307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
308 Requirement Levels", BCP 14, RFC 2119, March 1997.
310 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
311 Wellington, "Secret Key Transaction Authentication for
312 DNS (TSIG)", RFC 2845, May 2000.
314 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
315 1 (SHA1)", RFC 3174, September 2001.
317 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
318 RFC 3874, September 2004.
320 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
321 (SHA)", RFC 4634, July 2006.
323 [STD13] Mockapetris, P., "Domain names - concepts and
324 facilities", STD 13, RFC 1034, November 1987.
326 Mockapetris, P., "Domain names - implementation and
327 specification", STD 13, RFC 1035, November 1987.
338 Eastlake 3rd Standards Track [Page 6]
339 \f
340 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
343 8. Informative References.
345 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
346 RR)", RFC 2930, September 2000.
348 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
349 ( SIG(0)s )", RFC 2931, September 2000.
351 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
352 and R. Hall, "Generic Security Service Algorithm for
353 Secret Key Transaction Authentication for DNS (GSS-
354 TSIG)", RFC 3645, October 2003.
356 Author's Address
358 Donald E. Eastlake 3rd
359 Motorola Laboratories
360 155 Beaver Street
361 Milford, MA 01757 USA
363 Phone: +1-508-786-7554 (w)
364 EMail: Donald.Eastlake@motorola.com
394 Eastlake 3rd Standards Track [Page 7]
395 \f
396 RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
399 Full Copyright Statement
401 Copyright (C) The Internet Society (2006).
403 This document is subject to the rights, licenses and restrictions
404 contained in BCP 78, and except as set forth therein, the authors
405 retain all their rights.
407 This document and the information contained herein are provided on an
408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
415 Intellectual Property
417 The IETF takes no position regarding the validity or scope of any
418 Intellectual Property Rights or other rights that might be claimed to
419 pertain to the implementation or use of the technology described in
420 this document or the extent to which any license under such rights
421 might or might not be available; nor does it represent that it has
422 made any independent effort to identify any such rights. Information
423 on the procedures with respect to rights in RFC documents can be
424 found in BCP 78 and BCP 79.
426 Copies of IPR disclosures made to the IETF Secretariat and any
427 assurances of licenses to be made available, or the result of an
428 attempt made to obtain a general license or permission for the use of
429 such proprietary rights by implementers or users of this
430 specification can be obtained from the IETF on-line IPR repository at
431 http://www.ietf.org/ipr.
433 The IETF invites any interested party to bring to its attention any
434 copyrights, patents or patent applications, or other proprietary
435 rights that may cover technology that may be required to implement
436 this standard. Please address the information to the IETF at
437 ietf-ipr@ietf.org.
439 Acknowledgement
441 Funding for the RFC Editor function is provided by the IETF
442 Administrative Support Activity (IASA).
450 Eastlake 3rd Standards Track [Page 8]
451 \f