idnits 2.17.1 draft-ietf-dnsext-tsig-sha-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6648 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3645' is mentioned on line 324, but not defined == Missing Reference: 'RFC 2931' is mentioned on line 321, but not defined == Missing Reference: 'RFC 2930' is mentioned on line 318, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-2' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Downref: Normative reference to an Informational RFC: RFC 3874 -- No information found for draft-eastlake-sha2- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SHA2draft' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 UPDATES RFC 2845 Motorola Laboratories 3 Expires: July 2006 January 2006 5 HMAC SHA TSIG Algorithm Identifiers 6 ---- --- ---- --------- ----------- 7 9 Status of This Document 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This draft is intended to be become a Proposed Standard RFC. 17 Distribution of this document is unlimited. Comments should be sent 18 to the DNSEXT working group mailing list . 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 Use of the Domain Name System TSIG resource record requires 39 specification of a cryptographic message authentication code. 40 Currently identifiers have been specified only for the HMAC MD5 41 (Message Digest) and GSS (Generic Security Service) TSIG algorithms. 42 This document standardizes identifiers and implementation 43 requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG 44 algorithms and standardizes how to specify and handle the truncation 45 of HMAC values in TSIG. 47 Copyright Notice 49 Copyright (C) The Internet Society (2006). 51 Table of Contents 53 Status of This Document....................................1 54 Abstract...................................................1 55 Copyright Notice...........................................1 57 Table of Contents..........................................2 59 1. Introduction............................................3 61 2. Algorithms and Identifiers..............................4 63 3. Specifying Truncation...................................5 64 3.1 Truncation Specification...............................5 66 4. TSIG Truncation Policy and Error Provisions.............6 68 5. IANA Considerations.....................................7 69 6. Security Considerations.................................7 70 7. Copyright and Disclaimer................................7 72 8. Normative References....................................8 73 9. Informative References..................................8 75 Author's Address...........................................9 76 Additional IPR Provisions..................................9 77 Expiration and File Name...................................9 79 1. Introduction 81 [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to 82 authenticate DNS (Domain Name System [STD 13]) queries and responses. 83 This RR contains a domain name syntax data item which names the 84 authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG- 85 ALG.REG.INT name for authentication codes using the HMAC [RFC 2104] 86 algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also 87 registered "gss-tsig" as an identifier for TSIG authentication where 88 the cryptographic operations are delegated to the Generic Security 89 Service (GSS) [RFC 3645]. 91 It should be noted that use of TSIG presumes prior agreement, between 92 the resolver and server involved, as to the algorithm and key to be 93 used. 95 In Section 2, this document specifies additional names for TSIG 96 authentication algorithms based on US NIST SHA (United States, 97 National Institute of Science and Technology, Secure Hash Algorithm) 98 algorithms and HMAC and specifies the implementation requirements for 99 those algorithms. 101 In Section 3, this document specifies the effect of inequality 102 between the normal output size of the specified hash function and the 103 length of MAC (message authentication code) data given in the TSIG 104 RR. In particular, it specifies that a shorter length field value 105 specifies truncation and a longer length field is an error. 107 In Section 4, policy restrictions and implications related to 108 truncation and a new error code to indicate truncation shorter than 109 permitted by policy are described and specified. 111 The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as 112 defined in [RFC 2119]. 114 2. Algorithms and Identifiers 116 TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS 117 queries and responses. They are intended to be efficient symmetric 118 authentication codes based on a shared secret. (Asymmetric signatures 119 can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) 120 can be used for transaction signatures.) Used with a strong hash 121 function, HMAC [RFC 2104] provides a way to calculate such symmetric 122 authentication codes. The only specified HMAC based TSIG algorithm 123 identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. 125 The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as 126 compared with the 128 bits for MD5, and additional hash algorithms in 127 the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, 128 and 512 bits, may be preferred in some cases particularly since 129 increasingly successful cryptanalytic attacks are being made on the 130 shorter hashes. 132 Use of TSIG between a DNS resolver and server is by mutual agreement. 133 That agreement can include the support of additional algorithms and 134 criteria as to which algorithms and truncations are acceptable, 135 subject to the restriction and guidelines in Section 3 and 4 below. 136 Key agreement can be by the TKEY mechanism [RFC 2930] or other 137 mutually agreeable method. 139 The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are 140 included in the table below for convenience. Implementations which 141 support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY 142 implement gss-tsig and the other algorithms listed below. 144 Mandatory HMAC-MD5.SIG-ALG.REG.INT 145 Optional gss-tsig 146 Mandatory hmac-sha1 147 Optional hmac-sha224 148 Mandatory hmac-sha256 149 Optional hamc-sha384 150 Optional hmac-sha512 152 SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. 154 3. Specifying Truncation 156 When space is at a premium and the strength of the full length of an 157 HMAC is not needed, it is reasonable to truncate the HMAC output and 158 use the truncated value for authentication. HMAC SHA-1 truncated to 159 96 bits is an option available in several IETF protocols including 160 IPSEC and TLS. 162 The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the 163 size of the MAC field in octets. But [RFC 2845] does not specify what 164 to do if this MAC size differs from the length of the output of HMAC 165 for a particular hash function. Truncation is indicated by a MAC size 166 less than the HMAC size as specified below. 168 3.1 Truncation Specification 170 The specification for TSIG handling is changed as follows: 172 1. If "MAC size" field is greater than HMAC output length: 173 This case MUST NOT be generated and if received MUST cause the 174 packet to be dropped and RCODE 1 (FORMERR) to be returned. 176 2. If "MAC size" field equals HMAC output length: 177 Operation is as described in [RFC 2845] with the entire output 178 HMAC output present. 180 3. "MAC size" field is less than HMAC output length but greater than 181 that specified in case 4 below: 182 This is sent when the signer has truncated the HMAC output to 183 an allowable length, as described in RFC 2104, taking initial 184 octets and discarding trailing octets. TSIG truncation can only be 185 to an integral number of octets. On receipt of a packet with 186 truncation thus indicated, the locally calculated MAC is similarly 187 truncated and only the truncated values compared for 188 authentication. The request MAC used when calculating the TSIG MAC 189 for a reply is the truncated request MAC. 191 4. "MAC size" field is less than the larger of 10 (octets) and half 192 the length of the hash function in use: 193 With the exception of certain TSIG error messages described in 194 RFC 2845 section 3.2 where it is permitted that the MAC size be 195 zero, this case MUST NOT be generated and if received MUST cause 196 the packet to be dropped and RCODE 1 (FORMERR) to be returned. The 197 size limit for this case can also, for the hash functions 198 mentioned in this document, be stated as less than half the hash 199 function length for hash functions other than MD5 and less than 10 200 octets for MD5. 202 4. TSIG Truncation Policy and Error Provisions 204 Use of TSIG is by mutual agreement between a resolver and server. 205 Implicit in such "agreement" are criterion as to acceptable keys and 206 algorithms and, with the extensions in this document, truncations. 207 Note that it is common for implementations to bind the TSIG secret 208 key or keys that may be in place at a resolver and server to 209 particular algorithms. Thus such implementations only permit the use 210 of an algorithm if there is an associated key in place. Receipt of an 211 unknown, unimplemented, or disabled algorithm typically results in a 212 BADKEY error. 214 Local policies MAY require the rejection of TSIGs even though they 215 use an algorithm for which implementation is mandatory. 217 When a local policy permits acceptance of a TSIG with a particular 218 algorithm and a particular non-zero amount of truncation it SHOULD 219 also permit the use of that algorithm with lesser truncation (a 220 longer MAC) up to the full HMAC output. 222 Regardless of a lower acceptable truncated MAC length specified by 223 local policy, a reply SHOULD be sent with a MAC at least as long as 224 that in the corresponding request unless the request specified a MAC 225 length longer than the HMAC output. 227 Implementations permitting multiple acceptable algorithms and/or 228 truncations SHOULD permit this list to be ordered by presumed 229 strength and SHOULD allow different truncations for the same 230 algorithm to be treated as separate entities in this list. When so 231 implemented, policies SHOULD accept a presumed stronger algorithm and 232 truncation than the minimum strength required by the policy. 234 If a TSIG is received with truncation which is permitted under 235 Section 3 above but the MAC is too short for the local policy in 236 force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. 238 5. IANA Considerations 240 This document, on approval for publication as a standards track RFC, 241 (1) registers the new TSIG algorithm identifiers listed in Section 2 242 with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in 243 Section 4. [RFC 2845] 245 6. Security Considerations 247 For all of the message authentication code algorithms listed herein, 248 those producing longer values are believed to be stronger; however, 249 while there have been some arguments that mild truncation can 250 strengthen a MAC by reducing the information available to an 251 attacker, excessive truncation clearly weakens authentication by 252 reducing the number of bits an attacker has to try to break the 253 authentication by brute force [RFC 2104]. 255 Significant progress has been made recently in cryptanalysis of hash 256 function of the type used herein, all of which ultimately derive from 257 the design of MD4. While the results so far should not effect HMAC, 258 the stronger SHA-1 and SHA-256 algorithms are being made mandatory 259 due to caution. 261 See the Security Considerations section of [RFC 2845]. See also the 262 Security Considerations section of [RFC 2104] from which the limits 263 on truncation in this RFC were taken. 265 7. Copyright and Disclaimer 267 Copyright (C) The Internet Society (2006). 269 This document is subject to the rights, licenses and restrictions 270 contained in BCP 78, and except as set forth therein, the authors 271 retain all their rights. 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 276 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 277 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 278 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 8. Normative References 283 [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US 284 Federal Information Processing Standard, with Change Notice 1, 285 February 2004. 287 [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 288 1321, April 1992. 290 [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 291 Hashing for Message Authentication", RFC 2104, February 1997. 293 [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 297 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 298 RFC 2845, May 2000. 300 [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 301 1 (SHA1)", RFC 3174, September 2001. 303 [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", 304 September 2004, 306 [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms 307 (SHA)", draft-eastlake-sha2-*.txt, work in progress. 309 [STD 13] 310 Mockapetris, P., "Domain names - concepts and facilities", STD 311 13, RFC 1034, November 1987. 313 Mockapetris, P., "Domain names - implementation and 314 specification", STD 13, RFC 1035, November 1987. 316 9. Informative References. 318 [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS 319 (TKEY RR)", RFC 2930, September 2000. 321 [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction 322 Signatures ( SIG(0)s )", RFC 2931, September 2000. 324 [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, 325 J., and R. Hall, "Generic Security Service Algorithm for Secret Key 326 Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 327 2003. 329 Author's Address 331 Donald E. Eastlake 3rd 332 Motorola Laboratories 333 155 Beaver Street 334 Milford, MA 01757 USA 336 Telephone: +1-508-786-7554 (w) 338 EMail: Donald.Eastlake@motorola.com 340 Additional IPR Provisions 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed 344 to pertain to the implementation or use of the technology 345 described in this document or the extent to which any license 346 under such rights might or might not be available; nor does it 347 represent that it has made any independent effort to identify any 348 such rights. Information on the procedures with respect to 349 rights in RFC documents can be found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use 354 of such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository 356 at http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention 359 any copyrights, patents or patent applications, or other 360 proprietary rights that may cover technology that may be required 361 to implement this standard. Please address the information to the 362 IETF at ietf-ipr@ietf.org. 364 Expiration and File Name 366 This draft expires in July 2006. 368 Its file name is draft-ietf-dnsext-tsig-sha-06.txt