draft-ietf-dnsext-tsig-sha-01.txt   draft-ietf-dnsext-tsig-sha-02.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories UPDATES RFC 2845 Motorola Laboratories
Expires: August 2005 February 2005 Expires: September 2005 March 2005
HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- ----------- ---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-01.txt> <draft-ietf-dnsext-tsig-sha-02.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
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 1, line 45 skipping to change at page 1, line 45
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 TSIG DNS resource record requires specification of a
cryptographic message authentication code. Currently identifiers cryptographic message authentication code. Currently identifiers
have been specified only for the HMAC-MD5 and GSS TSIG algorithms. have been specified only for the HMAC-MD5 and GSS 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 TSIG algorithms and standardizes
how to specify the truncation of HMAC values. how to specify and handle the truncation of HMAC values.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. All Rights Reserved. Copyright (C) The Internet Society 2005. All Rights Reserved.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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
4. IANA Considerations.....................................6 4. TSIG Policy Provisions and Truncation Error.............6
5. Security Considerations.................................6
6. Copyright and Disclaimer................................6
7. Normative References....................................7 5. IANA Considerations.....................................7
8. Informative References..................................7 6. Security Considerations.................................7
6. Copyright and Disclaimer................................7
Author's Address...........................................8 7. Normative References....................................8
Expiration and File Name...................................8 8. Informative References..................................8
Author's Address...........................................9
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 queries and responses. This RR contains a domain
name syntax data item which names the authentication algorithm used. name syntax data item which names the authentication algorithm used.
[RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
authentication codes using the HMAC [RFC 2104] algorithm with the MD5 authentication codes using the HMAC [RFC 2104] algorithm with the MD5
skipping to change at page 4, line 5 skipping to change at page 3, line 28
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 algorithms and HMAC
and specifies the implementation requirements for those algorithms. 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 meaning 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
truncation and a new error code to indicate truncation shorter than
permitted by policy are described ans specified.
The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
defined in [RFC 2119].
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
2. Algorithms and Identifiers 2. Algorithms and Identifiers
TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
queries and responses. They are intended to be efficient symmetric queries and responses. They are intended to be efficient symmetric
authentication codes based on a shared secret. (Asymmetric signatures authentication codes based on a shared secret. (Asymmetric signatures
can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
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-1, RFC 3174], which is a 160 bit hash, as The use of SHA-1 [FIPS 180-1, 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] with 224, 256, 384, and 512 the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512
bits, may be preferred in some case particularly since increasingly bits, may be preferred in some cases particularly since increasingly
successful cryptanalytic attacks are being made on the shorter successful cryptanalytic attacks are being made on the shorter
hashes. Use of TSIG between a DNS resolver and server is by mutual hashes. Use of TSIG between a DNS resolver and server is by mutual
agreement. That agreement can include the support of additional agreement. That agreement can include the support of additional
algorithms and may specify policies as to which algorithms are algorithms and may specify policies as to which algorithms and
acceptable. 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 The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
table below for convenience. Implementations which support TSIG MUST table below for convenience. Implementations which support TSIG MUST
also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
and the other algorithms listed below. and the other algorithms listed below.
Mandatory HMAC-MD5.SIG-ALG.REG.INT Mandatory HMAC-MD5.SIG-ALG.REG.INT
Mandatory hmac-sha1 Mandatory hmac-sha1
Optional hmac-sha224 Optional hmac-sha224
Mandatory hmac-sha256 Mandatory hmac-sha256
skipping to change at page 5, line 21 skipping to change at page 5, line 21
96 bits is an optional available in several IETF protocols including 96 bits is an optional available in several IETF protocols including
IPSEC and TLS. IPSEC and TLS.
The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the 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 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 to do if this MAC size differs from the length of the output of HMAC
for a particular hash function. for a particular hash function.
The specification for TSIG handling is changed as follows: The specification for TSIG handling is changed as follows:
1. If The "MAC size" field is larger than the HMAC output length or 1. If "MAC size" field is greater than HMAC output length:
is zero: This case MUST NOT be generated and if received MUST This case MUST NOT be generated and if received MUST cause the
cause the packet to be dropped and RCODE 1 (FORMERR) to be packet to be dropped and RCODE 1 (FORMERR) to be returned.
returned.
2. If the "MAC size" field equals the HMAC output length: Operation 2. If "MAC size" field equals HMAC output length:
is as described in [RFC 2845]. Operation is as described in [RFC 2845] with the entire output
HMAC output present.
3. If the "MAC size" field is less than the HMAC output length but is 3. "MAC size" field is less than the larger of 10 (octets) and half
not zero: This is sent when the signer has truncated the HMAC the length of the hash function in use:
output as described in RFC 2104, taking initial octets and With the exception of certain TSIG error messages described in
discarding trailing octets. TSIG truncation can only be to an RFC 2845 section 3.2 where it is permitted that the MAC size be
integral number of octets. On receipt of a packet with truncation zero, this case MUST NOT be generated and if received MUST cause
thus indicated, the locally calculated MAC is similarly truncated the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
and only the truncated values compared for authentication. 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. "MAC size" field is less than HMAC output length but greater than
that specified in case 3 above:
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 trucated request MAC.
TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12 TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12
octets) and MAY implement any or all other truncations valid under octets) and MAY implement any or all other truncations valid under
case 3 above. case 4 above.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
4. IANA Considerations 4. TSIG Policy Provisions and Truncation Error
Use of TSIG is by mutual agreement between a resolver and server.
Implicit in such "agreement" are policies as to acceptable keys and
algorithms and now, with the extensions in this doucment,
truncations. In particular note the following:
Such policies MAY require the rejection of TSIGs even though they
use an algorithm for which implementation is mandatory.
When a policy calls for the acceptance of a TSIG with a particular
algorithm and a particular non-zero amount of trunction it SHOULD
also permit the use of that algorithm with lesser truncation (a
longer MAC).
Regardless of lower minimum MAC lengths specified by policy, a
reply SHOULD be sent with a MAC at least as long as that in the
corresponding request.
Implementations permitting policies with 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 treatred as spearate entities in this list. When
so implemented, policies SHOULD accept a presumed stronger algorithm
and truncation than the minimum 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 policy in force, an
RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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,
registers the new TSIG algorithm identifiers listed in Section 2 with (1) registers the new TSIG algorithm identifiers listed in Section 2
IANA. with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested]..
5. 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 are some arguments that mild truncation can strengthen a while there are some arguments that mild truncation can strengthen a
MAC by reducing the information available to an attacker, excessive MAC by reducing the information available to an attacker, excessive
truncation clearly weakens authentication by reducing the number of truncation clearly weakens authentication by reducing the number of
bits an attacker has to try to force. See [RFC 2104] which recommends bits an attacker has to try to force [RFC 2104].
that an HMAC never be truncated to less than half its length nor to
less than 80 bits (10 octets).
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. While the results so far should not function of the type used herein, all of which ultimately derive from
effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made the design of MD4. While the results so far should not effect HMAC,
mandatory due to caution. the stronger SHA-1 and SHA-256 algorithms are being made mandatory
due to caution.
See also the Security Considerations section of [RFC 2845]. See also the Security Considerations section of [RFC 2845].
6. Copyright and Disclaimer 6. Copyright and Disclaimer
Copyright (C) The Internet Society 2005. This document is subject to Copyright (C) The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights. as set forth therein, the authors 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
skipping to change at page 7, line 19 skipping to change at page 8, line 19
[FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
Federal Information Processing Standard, with Change Notice 1, Federal Information Processing Standard, with Change Notice 1,
February 2004. February 2004.
[RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992. 1321, April 1992.
[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 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 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.
8. Informative References. 8. Informative References.
[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.
skipping to change at page 8, line 15 skipping to change at page 9, line 15
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)
+1-508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires in August 2005. This draft expires in September 2005.
Its file name is draft-ietf-dnsext-tsig-sha-01.txt Its file name is draft-ietf-dnsext-tsig-sha-02.txt
 End of changes. 

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