draft-ietf-dnsext-tsig-sha-05.txt   draft-ietf-dnsext-tsig-sha-06.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories UPDATES RFC 2845 Motorola Laboratories
Expires: April 2006 October 2005 Expires: July 2006 January 2006
HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- ----------- ---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-05.txt> <draft-ietf-dnsext-tsig-sha-06.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
This draft is intended to be become a Proposed Standard RFC. This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
skipping to change at page 2, line ? skipping to change at page 1, line 40
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
Use of the TSIG DNS resource record requires specification of a Use of the Domain Name System TSIG resource record requires
cryptographic message authentication code. Currently identifiers specification of a cryptographic message authentication code.
have been specified only for the HMAC-MD5 and GSS TSIG algorithms. 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 This document standardizes identifiers and implementation
requirements for additional HMAC SHA TSIG algorithms and standardizes requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
how to specify and handle the truncation of HMAC values. algorithms and standardizes how to specify and handle the truncation
of HMAC values in TSIG.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006).
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Copyright Notice...........................................1 Copyright Notice...........................................1
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. Algorithms and Identifiers..............................4 2. Algorithms and Identifiers..............................4
3. Specifying Truncation...................................5 3. Specifying Truncation...................................5
3.1 Truncation Specification...............................5 3.1 Truncation Specification...............................5
4. TSIG Policy Provisions and Truncation Error.............7 4. TSIG Truncation Policy and Error Provisions.............6
5. IANA Considerations.....................................8 5. IANA Considerations.....................................7
6. Security Considerations.................................8 6. Security Considerations.................................7
7. Copyright and Disclaimer................................8 7. Copyright and Disclaimer................................7
8. Normative References....................................9 8. Normative References....................................8
9. Informative References..................................9 9. Informative References..................................8
Author's Address..........................................10 Author's Address...........................................9
Additional IPR Provisions.................................10 Additional IPR Provisions..................................9
Expiration and File Name..................................10 Expiration and File Name...................................9
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
1. Introduction 1. Introduction
[RFC 2845] specifies a TSIG Resource Record (RR) that can be used to [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
authenticate DNS queries and responses. This RR contains a domain authenticate DNS (Domain Name System [STD 13]) queries and responses.
name syntax data item which names the authentication algorithm used. This RR contains a domain name syntax data item which names the
[RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
authentication codes using the HMAC [RFC 2104] algorithm with the MD5 ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
[RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
identifier for TSIG authentication where the cryptographic operations registered "gss-tsig" as an identifier for TSIG authentication where
are delegated to GSS [RFC 3645]. 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 In Section 2, this document specifies additional names for TSIG
authentication algorithms based on US NIST SHA algorithms and HMAC authentication algorithms based on US NIST SHA (United States,
and specifies the implementation requirements for those algorithms. 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 meaning of inequality In Section 3, this document specifies the effect of inequality
between the normal output size of the specified hash function and the between the normal output size of the specified hash function and the
length of MAC (message authentication code) data given in the TSIG length of MAC (message authentication code) data given in the TSIG
RR. In particular, it specifies that a shorter length field value RR. In particular, it specifies that a shorter length field value
specifies truncation and a longer length field is an error. specifies truncation and a longer length field is an error.
In Section 4, policy restrictions and implications related to In Section 4, policy restrictions and implications related to
truncation and a new error code to indicate truncation shorter than truncation and a new error code to indicate truncation shorter than
permitted by policy are described and specified. permitted by policy are described and specified.
The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
skipping to change at page 4, line 23 skipping to change at page 4, line 23
can be used for transaction signatures.) Used with a strong hash can be used for transaction signatures.) Used with a strong hash
function, HMAC [RFC 2104] provides a way to calculate such symmetric function, HMAC [RFC 2104] provides a way to calculate such symmetric
authentication codes. The only specified HMAC based TSIG algorithm authentication codes. The only specified HMAC based TSIG algorithm
identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. 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 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 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, the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
and 512 bits, may be preferred in some cases particularly since and 512 bits, may be preferred in some cases particularly since
increasingly successful cryptanalytic attacks are being made on the increasingly successful cryptanalytic attacks are being made on the
shorter hashes. Use of TSIG between a DNS resolver and server is by shorter hashes.
mutual agreement. That agreement can include the support of
additional algorithms and may specify policies as to which algorithms
and truncations are acceptable subject to the restrication and
guidelines in Section 3 and 4 below.
The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the Use of TSIG between a DNS resolver and server is by mutual agreement.
table below for convenience. Implementations which support TSIG MUST That agreement can include the support of additional algorithms and
also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig criteria as to which algorithms and truncations are acceptable,
and the other algorithms listed below. 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 Mandatory HMAC-MD5.SIG-ALG.REG.INT
Optional gss-tsig
Mandatory hmac-sha1 Mandatory hmac-sha1
Optional hmac-sha224 Optional hmac-sha224
Mandatory hmac-sha256 Mandatory hmac-sha256
Optional hamc-sha384 Optional hamc-sha384
Optional hmac-sha512 Optional hmac-sha512
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
3. Specifying Truncation 3. Specifying Truncation
When space is at a premium and the strength of the full length of an 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 HMAC is not needed, it is reasonable to truncate the HMAC output and
use the truncated value for authentication. HMAC SHA-1 truncated to use the truncated value for authentication. HMAC SHA-1 truncated to
96 bits is an option available in several IETF protocols including 96 bits is an option available in several IETF protocols including
IPSEC and TLS. IPSEC and TLS.
skipping to change at page 5, line 42 skipping to change at page 5, line 42
3. "MAC size" field is less than HMAC output length but greater than 3. "MAC size" field is less than HMAC output length but greater than
that specified in case 4 below: that specified in case 4 below:
This is sent when the signer has truncated the HMAC output to This is sent when the signer has truncated the HMAC output to
an allowable length, as described in RFC 2104, taking initial an allowable length, as described in RFC 2104, taking initial
octets and discarding trailing octets. TSIG truncation can only be octets and discarding trailing octets. TSIG truncation can only be
to an integral number of octets. On receipt of a packet with to an integral number of octets. On receipt of a packet with
truncation thus indicated, the locally calculated MAC is similarly truncation thus indicated, the locally calculated MAC is similarly
truncated and only the truncated values compared for truncated and only the truncated values compared for
authentication. The request MAC used when calculating the TSIG MAC authentication. The request MAC used when calculating the TSIG MAC
for a reply is the trucated request MAC. for a reply is the truncated request MAC.
4. "MAC size" field is less than the larger of 10 (octets) and half 4. "MAC size" field is less than the larger of 10 (octets) and half
the length of the hash function in use: the length of the hash function in use:
With the exception of certain TSIG error messages described in With the exception of certain TSIG error messages described in
RFC 2845 section 3.2 where it is permitted that the MAC size be 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 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 the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
size limit for this case can also, for the hash functions size limit for this case can also, for the hash functions
mentioned in this document, be stated as less than half the hash mentioned in this document, be stated as less than half the hash
function length for hash functions other than MD5 and less than 10 function length for hash functions other than MD5 and less than 10
octets for MD5. octets for MD5.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. 4. TSIG Truncation Policy and Error Provisions
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
4. TSIG Policy Provisions and Truncation Error
Use of TSIG is by mutual agreement between a resolver and server. Use of TSIG is by mutual agreement between a resolver and server.
Implicit in such "agreement" are policies as to acceptable keys and Implicit in such "agreement" are criterion as to acceptable keys and
algorithms and, with the extensions in this doucment, truncations. In algorithms and, with the extensions in this document, truncations.
particular note the following: 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.
Such policies MAY require the rejection of TSIGs even though they Local policies MAY require the rejection of TSIGs even though they
use an algorithm for which implementation is mandatory. use an algorithm for which implementation is mandatory.
When a policy calls for the acceptance of a TSIG with a particular When a local policy permits acceptance of a TSIG with a particular
algorithm and a particular non-zero amount of trunction it SHOULD algorithm and a particular non-zero amount of truncation it SHOULD
also permit the use of that algorithm with lesser truncation (a also permit the use of that algorithm with lesser truncation (a
longer MAC) up to the full HMAC output. longer MAC) up to the full HMAC output.
Regardless of a lower acceptable truncated MAC length specified by Regardless of a lower acceptable truncated MAC length specified by
policy, a reply SHOULD be sent with a MAC at least as long as that in local policy, a reply SHOULD be sent with a MAC at least as long as
the corresponding request unless the request specified a MAC length that in the corresponding request unless the request specified a MAC
longer than the HMAC output. length longer than the HMAC output.
Implementations permitting policies with multiple acceptable Implementations permitting multiple acceptable algorithms and/or
algorithms and/or truncations SHOULD permit this list to be ordered truncations SHOULD permit this list to be ordered by presumed
by presumed strength and SHOULD allow different truncations for the strength and SHOULD allow different truncations for the same
same algorithm to be treatred as spearate entities in this list. When algorithm to be treated as separate entities in this list. When so
so implemented, policies SHOULD accept a presumed stronger algorithm implemented, policies SHOULD accept a presumed stronger algorithm and
and truncation than the minimum strength required by the policy. truncation than the minimum strength required by the policy.
If a TSIG is received with truncation which is permitted under If a TSIG is received with truncation which is permitted under
Section 3 above but the MAC is too short for the policy in force, an Section 3 above but the MAC is too short for the local policy in
RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
5. IANA Considerations 5. IANA Considerations
This document, on approval for publication as a standards track RFC, This document, on approval for publication as a standards track RFC,
(1) registers the new TSIG algorithm identifiers listed in Section 2 (1) registers the new TSIG algorithm identifiers listed in Section 2
with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22 with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
suggested]. Section 4. [RFC 2845]
6. Security Considerations 6. Security Considerations
For all of the message authentication code algorithms listed herein, For all of the message authentication code algorithms listed herein,
those producing longer values are believed to be stronger; however, those producing longer values are believed to be stronger; however,
while there have been some arguments that mild truncation can while there have been some arguments that mild truncation can
strengthen a MAC by reducing the information available to an strengthen a MAC by reducing the information available to an
attacker, excessive truncation clearly weakens authentication by attacker, excessive truncation clearly weakens authentication by
reducing the number of bits an attacker has to try to brute force reducing the number of bits an attacker has to try to break the
[RFC 2104]. authentication by brute force [RFC 2104].
Significant progress has been made recently in cryptanalysis of hash Significant progress has been made recently in cryptanalysis of hash
function of the type used herein, all of which ultimately derive from 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 design of MD4. While the results so far should not effect HMAC,
the stronger SHA-1 and SHA-256 algorithms are being made mandatory the stronger SHA-1 and SHA-256 algorithms are being made mandatory
due to caution. due to caution.
See the Security Considerations section of [RFC 2845]. See also the See the Security Considerations section of [RFC 2845]. See also the
Security Considerations section of [RFC 2104] from which the limits Security Considerations section of [RFC 2104] from which the limits
on truncation in this RFC were taken. on truncation in this RFC were taken.
7. Copyright and Disclaimer 7. Copyright and Disclaimer
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 9, line 26 skipping to change at page 8, line 26
[RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997. Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000. 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. 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 [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000. Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
J., and R. Hall, "Generic Security Service Algorithm for Secret Key J., and R. Hall, "Generic Security Service Algorithm for Secret Key
Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
2003. 2003.
[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-sha1-*.txt, work in progress.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w) Telephone: +1-508-786-7554 (w)
skipping to change at page 10, line 44 skipping to change at page 9, line 44
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Expiration and File Name Expiration and File Name
This draft expires in April 2006. This draft expires in July 2006.
Its file name is draft-ietf-dnsext-tsig-sha-05.txt Its file name is draft-ietf-dnsext-tsig-sha-06.txt
 End of changes. 33 change blocks. 
73 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/