From: Mark Andrews Date: Sat, 1 Aug 2009 06:05:45 +0000 (+0000) Subject: 4635: HMAC SHA TSIG Algorithm Identifiers X-Git-Tag: v9.7.0a2~4 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=10f35749cf81005668548374a378b7c8ac2a350c;p=thirdparty%2Fbind9.git 4635: HMAC SHA TSIG Algorithm Identifiers --- diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt deleted file mode 100644 index 00476ae507e..00000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt +++ /dev/null @@ -1,522 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: July 2006 January 2006 - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group mailing list . - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -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 the HMAC MD5 - (Message Digest) 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. - - -Copyright Notice - - Copyright (C) The Internet Society (2006). - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. Algorithms and Identifiers..............................4 - - 3. Specifying Truncation...................................5 - 3.1 Truncation Specification...............................5 - - 4. TSIG Truncation Policy and Error Provisions.............6 - - 5. IANA Considerations.....................................7 - 6. Security Considerations.................................7 - 7. Copyright and Disclaimer................................7 - - 8. Normative References....................................8 - 9. Informative References..................................8 - - Author's Address...........................................9 - Additional IPR Provisions..................................9 - Expiration and File Name...................................9 - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -1. Introduction - - [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS (Domain Name System [STD 13]) queries and responses. - This RR contains a domain name syntax data item which names the - authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG- - ALG.REG.INT name for authentication codes using the HMAC [RFC 2104] - algorithm with the MD5 [RFC 1321] 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) [RFC 3645]. - - It should be noted that use of TSIG presumes prior agreement, between - the resolver and server involved, as to the algorithm and key to be - used. - - 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. - - 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 a longer length field is an error. - - In Section 4, policy restrictions and implications related to - truncation and a new error code to indicate truncation shorter than - permitted by policy are described and specified. - - The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as - defined in [RFC 2119]. - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC 2845] 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 [RFC 2931]. In particular, SIG(0) - can be used for transaction signatures.) Used with a strong hash - function, HMAC [RFC 2104] 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 [RFC 1321]. - - The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as - compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, - and 512 bits, may be preferred in some cases particularly since - increasingly successful cryptanalytic attacks are being made on the - shorter hashes. - - 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 Section 3 and 4 below. - Key agreement can be by the TKEY mechanism [RFC 2930] or other - mutually agreeable method. - - The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are - included in the table below for convenience. Implementations which - support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY - implement gss-tsig and the other algorithms listed below. - - 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 - - SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - 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. - - The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. But [RFC 2845] 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. - - - -3.1 Truncation Specification - - The specification for TSIG handling is changed as follows: - - 1. If "MAC size" field is greater than HMAC output length: - This case MUST NOT be generated and if received MUST cause the - packet to be dropped and RCODE 1 (FORMERR) to be returned. - - 2. If "MAC size" field equals HMAC output length: - Operation is as described in [RFC 2845] with the entire output - HMAC output present. - - 3. "MAC size" field is less than HMAC output length but greater than - that specified in case 4 below: - 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 compared for - authentication. The request MAC used when calculating the TSIG MAC - for a reply is the truncated request MAC. - - 4. "MAC size" field is less than the larger of 10 (octets) and half - the length of the hash function in use: - 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. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. TSIG Truncation Policy and Error Provisions - - 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 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. - - 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. - - 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. - - 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 which is permitted under - Section 3 above but the MAC is too short for the local policy in - force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -5. IANA Considerations - - This document, on approval for publication as a standards track RFC, - (1) registers the new TSIG algorithm identifiers listed in Section 2 - with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in - Section 4. [RFC 2845] - - - -6. Security Considerations - - 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 [RFC 2104]. - - Significant progress has been made recently in cryptanalysis of hash - function of the type used herein, all of which ultimately derive from - the design of MD4. While the results so far should not effect HMAC, - the stronger SHA-1 and SHA-256 algorithms are being made mandatory - due to caution. - - See the Security Considerations section of [RFC 2845]. See also the - Security Considerations section of [RFC 2104] from which the limits - on truncation in this RFC were taken. - - - -7. Copyright and Disclaimer - - Copyright (C) The Internet Society (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. - - - 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. - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -8. Normative References - - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US - Federal Information Processing Standard, with Change Notice 1, - February 2004. - - [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", - September 2004, - - [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms - (SHA)", draft-eastlake-sha2-*.txt, work in progress. - - [STD 13] - Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - - -9. Informative References. - - [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS - (TKEY RR)", RFC 2930, September 2000. - - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction - Signatures ( SIG(0)s )", RFC 2931, September 2000. - - [RFC 3645] - 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. - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - - EMail: Donald.Eastlake@motorola.com - - - -Additional IPR Provisions - - 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. - - 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. - - 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. - - - -Expiration and File Name - - This draft expires in July 2006. - - Its file name is draft-ietf-dnsext-tsig-sha-06.txt - - - - - - - - -D. Eastlake 3rd [Page 9] - diff --git a/doc/rfc/index b/doc/rfc/index index 34c63e820bd..2c9eea95956 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -113,6 +113,7 @@ 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA) +4635: HMAC SHA TSIG Algorithm Identifiers 4641: DNSSEC Operational Practices 4648: The Base16, Base32, and Base64 Data Encodings 4701: A DNS Resource Record (RR) for Encoding diff --git a/doc/rfc/rfc4635.txt b/doc/rfc/rfc4635.txt new file mode 100644 index 00000000000..554502dc91e --- /dev/null +++ b/doc/rfc/rfc4635.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4635 Motorola Laboratories +Category: Standards Track August 2006 + + + HMAC SHA TSIG Algorithm Identifiers + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + +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 + + + + + + + + + + +Eastlake 3rd Standards Track [Page 1] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +1. Introduction + + [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]. + + Note that use of TSIG presumes prior agreement, between the resolver + and server involved, as to the algorithm and key to be used. + + 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. + + 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. + + 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. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in + this document are to be interpreted as described in [RFC2119]. + +2. Algorithms and Identifiers + + 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]. + + + + + +Eastlake 3rd Standards Track [Page 2] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + 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. + + 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. + + 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. + + 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 + + SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. + +3. Specifying Truncation + + 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. + + 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. + + + + + + + + + +Eastlake 3rd Standards Track [Page 3] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +3.1. Truncation Specification + + The specification for TSIG handling is changed as follows: + + 1. If "MAC size" field is greater than HMAC output length: + + This case MUST NOT be generated and, if received, MUST cause + the packet to be dropped and RCODE 1 (FORMERR) to be returned. + + 2. If "MAC size" field equals HMAC output length: + + Operation is as described in [RFC2845], and the entire output + HMAC output is present. + + 3. "MAC size" field is less than HMAC output length but greater than + that specified in case 4, below: + + 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. + + 4. "MAC size" field is less than the larger of 10 (octets) and half + the length of the hash function in use: + + 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. + +4. TSIG Truncation Policy and Error Provisions + + 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 + + + + + +Eastlake 3rd Standards Track [Page 4] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + 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. + + 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. + + 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. + + 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. + +5. IANA Considerations + + 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]. + +6. Security Considerations + + 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]. + + 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 + + + + +Eastlake 3rd Standards Track [Page 5] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + HMAC, the stronger SHA-1 and SHA-256 algorithms are being made + mandatory due to caution. + + 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. + +7. Normative References + + [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change + Notice 1, February 2004. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", + RFC 3874, September 2004. + + [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA)", RFC 4634, July 2006. + + [STD13] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + + + + + + + + +Eastlake 3rd Standards Track [Page 6] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +8. Informative References. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [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. + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd Standards Track [Page 7] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Eastlake 3rd Standards Track [Page 8] +