+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: July 2006 January 2006
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-06.txt>
-
-
-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 <namedroppers@ops.ietf.org>.
-
- 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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / bind9.git / commitdiff
