draft-ietf-dnsext-tsig-sha-02.txt   draft-ietf-dnsext-tsig-sha-03.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories UPDATES RFC 2845 Motorola Laboratories
Expires: September 2005 March 2005 Expires: October 2005 April 2005
HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- ----------- ---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-02.txt> <draft-ietf-dnsext-tsig-sha-03.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 2, line 20 skipping to change at page 2, line 20
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
4. TSIG Policy Provisions and Truncation Error.............6 4. TSIG Policy Provisions and Truncation Error.............7
5. IANA Considerations.....................................7 5. IANA Considerations.....................................8
6. Security Considerations.................................7 6. Security Considerations.................................8
6. Copyright and Disclaimer................................7 6. Copyright and Disclaimer................................8
7. Normative References....................................8 7. Normative References....................................9
8. Informative References..................................8 8. Informative References..................................9
Author's Address...........................................9 Author's Address..........................................10
Expiration and File Name...................................9 Expiration and File Name..................................10
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
[RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
identifier for TSIG authentication where the cryptographic operations identifier for TSIG authentication where the cryptographic operations
are delegated to GSS [RFC 3645]. are delegated to GSS [RFC 3645].
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 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 ans 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
defined in [RFC 2119]. 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
skipping to change at page 5, line 9 skipping to change at page 5, line 9
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
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
3. Specifying Truncation 3. Specifying Truncation
In some cases, it is reasonable to truncate the output of HMAC and 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 use the truncated value for authentication. HMAC SHA-1 truncated to
96 bits is an optional available in several IETF protocols including 96 bits is an option 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. 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: The specification for TSIG handling is changed as follows:
1. If "MAC size" field is greater than HMAC output length: 1. If "MAC size" field is greater than HMAC output length:
This case MUST NOT be generated and if received MUST cause the This case MUST NOT be generated and if received MUST cause the
packet to be dropped and RCODE 1 (FORMERR) to be returned. packet to be dropped and RCODE 1 (FORMERR) to be returned.
2. If "MAC size" field equals HMAC output length: 2. If "MAC size" field equals HMAC output length:
Operation is as described in [RFC 2845] with the entire output Operation is as described in [RFC 2845] with the entire output
HMAC output present. HMAC output present.
3. "MAC size" field is less than the larger of 10 (octets) and half 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 trucated request MAC.
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.
4. "MAC size" field is less than HMAC output length but greater than INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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 SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
octets) and MAY implement any or all other truncations valid under
case 4 above.
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
4. TSIG Policy Provisions and Truncation Error 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 policies as to acceptable keys and
algorithms and now, with the extensions in this doucment, algorithms and, with the extensions in this doucment, truncations. In
truncations. In particular note the following: particular note the following:
Such policies MAY require the rejection of TSIGs even though they Such 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 policy calls for the 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 trunction 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). longer MAC) up to the full HMAC output.
Regardless of lower minimum MAC lengths specified by policy, a Regardless of a lower acceptable truncated MAC length specified by
reply SHOULD be sent with a MAC at least as long as that in the policy, a reply SHOULD be sent with a MAC at least as long as that in
corresponding request. the corresponding request unless the request specified a MAC length
longer than the HMAC output.
Implementations permitting policies with multiple acceptable Implementations permitting policies with multiple acceptable
algorithms and/or truncations SHOULD permit this list to be ordered algorithms and/or truncations SHOULD permit this list to be ordered
by presumed strength and SHOULD allow different truncations for the by presumed strength and SHOULD allow different truncations for the
same algorithm to be treatred as spearate entities in this list. When same algorithm to be treatred as spearate entities in this list. When
so implemented, policies SHOULD accept a presumed stronger algorithm so implemented, policies SHOULD accept a presumed stronger algorithm
and truncation than the minimum required by the policy. and 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 policy in force, an
RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. 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) allocates the BADTRUNC RCODE TBA [22 suggested].. with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
suggested].
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 are some arguments that mild truncation can strengthen a while there have been some arguments that mild truncation can
MAC by reducing the information available to an attacker, excessive strengthen a MAC by reducing the information available to an
truncation clearly weakens authentication by reducing the number of attacker, excessive truncation clearly weakens authentication by
bits an attacker has to try to force [RFC 2104]. reducing the number of bits an attacker has to try to 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 also the Security Considerations section of [RFC 2845]. See also the Security Considerations section of [RFC 2845] from which
the limits on truncation in this RFC were taken.
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
"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
skipping to change at page 9, line 20 skipping to change at page 10, line 20
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)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires in September 2005. This draft expires in October 2005.
Its file name is draft-ietf-dnsext-tsig-sha-02.txt Its file name is draft-ietf-dnsext-tsig-sha-03.txt
 End of changes. 

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