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

new draft

Browse Source
This commit is contained in:
Mark Andrews 2006-02-01 23:59:00 +00:00
parent 060a947419
commit 83a27fc4a9
1 changed files with 143 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

344
doc/draft/draft-ietf-dnsext-tsig-sha-04.txt → doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
View File

@ -1,12 +1,11 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories
Expires: December 2005 June 2005
Expires: July 2006 January 2006
HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-04.txt>
<draft-ietf-dnsext-tsig-sha-06.txt>
Status of This Document
@ -28,7 +27,7 @@ Status of This Document
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 a "work in progress."
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
@ -39,18 +38,19 @@ Status of This Document
Abstract
Use of the TSIG DNS resource record requires specification of a
cryptographic message authentication code. Currently identifiers
have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
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 TSIG algorithms and standardizes
how to specify and handle the truncation of HMAC values.
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 2005. All Rights Reserved.
Copyright (C) The Internet Society (2006).
@ -75,18 +75,18 @@ Table of Contents
3. Specifying Truncation...................................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
6. Security Considerations.................................8
6. Copyright and Disclaimer................................8
5. IANA Considerations.....................................7
6. Security Considerations.................................7
7. Copyright and Disclaimer................................7
7. Normative References....................................9
8. Informative References..................................9
Author's Address..........................................10
Expiration and File Name..................................10
8. Normative References....................................8
9. Informative References..................................8
Author's Address...........................................9
Additional IPR Provisions..................................9
Expiration and File Name...................................9
@ -121,19 +121,26 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
1. Introduction
[RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
authenticate DNS 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 GSS [RFC 3645].
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 algorithms and HMAC
and specifies the implementation requirements for those algorithms.
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 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
length of MAC (message authentication code) data given in the TSIG
RR. In particular, it specifies that a shorter length field value
@ -158,13 +165,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
@ -192,29 +192,29 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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 may specify policies as to which algorithms
and truncations are acceptable subject to the restrication and
guidelines in Section 3 and 4 below.
shorter hashes.
The current HMAC-MD5.SIG-ALG.REG.INT identifier is 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.
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.
@ -271,7 +271,7 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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.
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:
@ -292,41 +292,41 @@ D. Eastlake 3rd [Page 5]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
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.
@ -350,71 +350,12 @@ D. Eastlake 3rd [Page 6]
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.
Implicit in such "agreement" are policies as to acceptable keys and
algorithms and, 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) up to the full HMAC output.
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
the corresponding request unless the request specified a MAC length
longer than the HMAC output.
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 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 policy in force, an
RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
D. Eastlake 3rd [Page 7]
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) Section 4 allocates the BADTRUNC RCODE TBA [22
suggested].
with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
Section 4. [RFC 2845]
@ -425,8 +366,8 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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 brute force
[RFC 2104].
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
@ -440,11 +381,13 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
6. Copyright and Disclaimer
7. Copyright and Disclaimer
Copyright (C) The Internet Society (2005). 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.
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
@ -459,14 +402,13 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
D. Eastlake 3rd [Page 8]
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
7. Normative References
8. Normative References
[FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
Federal Information Processing Standard, with Change Notice 1,
@ -485,40 +427,40 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
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.
8. 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
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,
J., and R. Hall, "Generic Security Service Algorithm for Secret Key
Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
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)", work in progress.
D. Eastlake 3rd [Page 9]
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers
@ -537,11 +479,37 @@ Author's Address
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 December 2005.
This draft expires in July 2006.
Its file name is draft-ietf-dnsext-tsig-sha-04.txt
Its file name is draft-ietf-dnsext-tsig-sha-06.txt
@ -550,31 +518,5 @@ Expiration and File Name
D. Eastlake 3rd [Page 10]
D. Eastlake 3rd [Page 9]