mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-03 08:05:21 +00:00
Code Issues Releases Wiki Activity

4635: HMAC SHA TSIG Algorithm Identifiers

Browse Source
This commit is contained in:
Mark Andrews
2009-08-01 06:05:45 +00:00
parent 33a31c5cab
commit 10f35749cf
3 changed files with 452 additions and 522 deletions
Download Patch File Download Diff File Expand all files Collapse all files

522
doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
View File

@@ -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
---- --- ---- --------- -----------
<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]
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]

1
doc/rfc/index
View File

@@ -113,6 +113,7 @@
4470: Minimally Covering NSEC Records and DNSSEC On-line Signing 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing
4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
4634: US Secure Hash Algorithms (SHA and HMAC-SHA) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA)
4635: HMAC SHA TSIG Algorithm Identifiers
4641: DNSSEC Operational Practices 4641: DNSSEC Operational Practices
4648: The Base16, Base32, and Base64 Data Encodings 4648: The Base16, Base32, and Base64 Data Encodings
4701: A DNS Resource Record (RR) for Encoding 4701: A DNS Resource Record (RR) for Encoding

451
doc/rfc/rfc4635.txt Normal file
View File

@@ -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]