RFC 4635

HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers

📅 published August 2006, from ietf

HMAC SHA TSIG Algorithm Identifiers 💖

  • Network Working Group 🎀 this one lives in the IETF's working group world 🌐
  • RFC: 4635 ✨
  • Author: D. Eastlake 3rd, from Motorola Laboratories 💅
  • Category: Standards Track 👑
  • Date: August 2006 📅
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
Part 1 of 2 🦋 Part 2 picks up right at Section 4!

Status of This Memo 📜

Okay so this is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions 🫶. For where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share it far and wide 🌈.

Copyright (C) The Internet Society (2006). 💜

Abstract 🦋

Here's the tea: using the Domain Name System TSIG resource record means you have to specify a cryptographic message authentication code 🔐. So far, identifiers only exist for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This doc standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms, and it also standardizes how to specify and handle 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

1. Introduction 🌸

[RFC2845] defines the TSIG Resource Record (RR), which you can use to authenticate DNS (Domain Name System [STD13]) queries and responses 🔐. This RR has a domain name syntax data item that names the authentication algorithm being used. [RFC2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for authentication codes that use HMAC (Hashed Message Authentication Code) [RFC2104] with the MD5 (Message Digest 5) [RFC1321] hash algorithm. IANA has also registered gss-tsig as an identifier for TSIG authentication where the crypto operations get delegated to the Generic Security Service (GSS) [RFC3645] 🧚.

Heads up, though: using TSIG presumes prior agreement between the resolver and server involved, on which algorithm and key to use 🤝.

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 it 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, and so 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're 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] gives you a way to calculate these symmetric authentication codes. The only specified HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-ALG.REG.INT, based on MD5 [RFC1321] 💅.

The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, 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. That's 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 support for additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restrictions and guidelines in Sections 3 and 4 below. Key agreement can be done 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 you don't need the full strength of an HMAC, it's 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] doesn't say what to do if this MAC size differs from the length of the output of HMAC for a particular hash function. So 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 [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's permitted for the MAC size to 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 🙈💀

7. Normative References ✨

okay bestie, these are the docs the spec straight up needs to read first 📚 no cap, you can't really get the vibe without them. here they are, verbatim:

[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.

8. Informative References ✨

these ones are more like "ooh, go read this if you're curious" 🦋 they're not required, but they're iconic for extra context:

[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 🖋️

this is who to reach out to if you have questions, and she's literally the expert 💅 (Donald E. Eastlake 3rd, btw, a legend)

Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com

okay the legal stuff, but make it quick 🙈 the copyright belongs to The Internet Society (2006). and this document is subject to the rights, licenses and restrictions in BCP 78. except for what BCP 78 says, the authors keep all their rights 🫶

the warranty part is kinda serious, so here it is in full:

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 doesn't take a side on whether any IP rights apply to the tech in this doc, or whether you can get a license for it. it also doesn't claim it checked every single right out there 🙃 for the procedures on rights in RFCs, see BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, plus any license assurances, or the results of trying to get a general license for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF wants to hear about it. send that info to ietf-ipr@ietf.org 📬

Acknowledgement 🌷

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). the people behind the scenes deserve all the flowers 💐

📦 where this page comes from