draft-ietf-dnsop-rfc2845bis-06.txt   draft-ietf-dnsop-rfc2845bis-07.txt 
Internet Engineering Task Force F. Dupont Internet Engineering Task Force F. Dupont
Internet-Draft S. Morris Internet-Draft S. Morris
Obsoletes: 2845, 4635 (if approved) ISC Obsoletes: 2845, 4635 (if approved) ISC
Intended status: Standards Track P. Vixie Intended status: Standards Track P. Vixie
Expires: May 4, 2020 Farsight Expires: August 23, 2020 Farsight
D. Eastlake 3rd D. Eastlake 3rd
Futurewei Futurewei
O. Gudmundsson O. Gudmundsson
CloudFlare Cloudflare
B. Wellington B. Wellington
Akamai Akamai
November 1, 2019 February 20, 2020
Secret Key Transaction Authentication for DNS (TSIG) Secret Key Transaction Authentication for DNS (TSIG)
draft-ietf-dnsop-rfc2845bis-06 draft-ietf-dnsop-rfc2845bis-07
Abstract Abstract
This document describes a protocol for transaction level This document describes a protocol for transaction level
authentication using shared secrets and one way hashing. It can be authentication using shared secrets and one way hashing. It can be
used to authenticate dynamic updates as coming from an approved used to authenticate dynamic updates as coming from an approved
client, or to authenticate responses as coming from an approved name client, or to authenticate responses as coming from an approved name
server. server.
No recommendation is made here for distributing the shared secrets: No recommendation is made here for distributing the shared secrets:
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2020. This Internet-Draft will expire on August 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 11 skipping to change at page 6, line 11
As the TSIG RRs are related to one DNS request/response, there is no As the TSIG RRs are related to one DNS request/response, there is no
value in storing or retransmitting them, thus the TSIG RR is value in storing or retransmitting them, thus the TSIG RR is
discarded once it has been used to authenticate a DNS message. discarded once it has been used to authenticate a DNS message.
4.2. TSIG Record Format 4.2. TSIG Record Format
The fields of the TSIG RR are described below. As is usual, all The fields of the TSIG RR are described below. As is usual, all
multi-octet integers in the record are sent in network byte order multi-octet integers in the record are sent in network byte order
(see [RFC1035] 2.3.2). (see [RFC1035] 2.3.2).
NAME The name of the key used in domain name syntax. The name NAME The name of the key used, in domain name syntax. The name
should reflect the names of the hosts and uniquely identify the should reflect the names of the hosts and uniquely identify the
key among a set of keys these two hosts may share at any given key among a set of keys these two hosts may share at any given
time. If hosts A.site.example and B.example.net share a key, time. For example, if hosts A.site.example and B.example.net
possibilities for the key name include <id>.A.site.example, share a key, possibilities for the key name include
<id>.B.example.net, and <id>.A.site.example.B.example.net. It <id>.A.site.example, <id>.B.example.net, and
should be possible for more than one key to be in simultaneous <id>.A.site.example.B.example.net. It should be possible for
use among a set of interacting hosts. more than one key to be in simultaneous use among a set of
interacting hosts.
The name may be used as a local index to the key involved and The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually need only be just shared between two hosts, its name actually need only be
meaningful to them but it is recommended that the key name be meaningful to them but it is recommended that the key name be
mnemonic and incorporates the names of participating agents or mnemonic and incorporates the names of participating agents or
resources as suggested above. resources as suggested above.
TYPE This MUST be TSIG (250: Transaction SIGnature) TYPE This MUST be TSIG (250: Transaction SIGnature)
skipping to change at page 16, line 31 skipping to change at page 16, line 31
6. Algorithms and Identifiers 6. Algorithms and Identifiers
The only message digest algorithm specified in the first version of The only message digest algorithm specified in the first version of
these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321],
[RFC2104]). Although a review of its security [RFC6151] concluded [RFC2104]). Although a review of its security [RFC6151] concluded
that "it may not be urgent to remove HMAC-MD5 from the existing that "it may not be urgent to remove HMAC-MD5 from the existing
protocols", with the availability of more secure alternatives the protocols", with the availability of more secure alternatives the
opportunity has been taken to make the implementation of this opportunity has been taken to make the implementation of this
algorithm optional. algorithm optional.
The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4],
compared to the 128 bits for MD5), and additional hash algorithms in [RFC3174]. SHA-1 collisions have been demonstrated so the MD5
the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, security considerations apply to SHA-1 in a similar manner. Although
and 512 bits may be preferred in some cases. This is because support for hmac-sha1 in TSIG is still mandatory for compatibility
increasingly successful cryptanalytic attacks are being made on the reasons, existing uses should be replaced with hmac-sha256 or other
shorter hashes. SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].
Use of TSIG between two DNS agents is by mutual agreement. That Use of TSIG between two DNS agents is by mutual agreement. That
agreement can include the support of additional algorithms and agreement can include the support of additional algorithms and
criteria as to which algorithms and truncations are acceptable, criteria as to which algorithms and truncations are acceptable,
subject to the restriction and guidelines in Section 5.2.2.1 above. subject to the restriction and guidelines in Section 5.2.2.1 above.
Key agreement can be by the TKEY mechanism [RFC2930] or some other Key agreement can be by the TKEY mechanism [RFC2930] or some other
mutually agreeable method. mutually agreeable method.
Implementations that support TSIG MUST also implement HMAC SHA1 and Implementations that support TSIG MUST also implement HMAC SHA1 and
HMAC SHA256 and MAY implement gss-tsig and the other algorithms HMAC SHA256 and MAY implement gss-tsig and the other algorithms
skipping to change at page 18, line 29 skipping to change at page 18, line 29
IANA maintains a registry of algorithm names to be used as "Algorithm IANA maintains a registry of algorithm names to be used as "Algorithm
Names" as defined in Section 4.2. Algorithm names are text strings Names" as defined in Section 4.2. Algorithm names are text strings
encoded using the syntax of a domain name. There is no structure encoded using the syntax of a domain name. There is no structure
required other than names for different algorithms must be unique required other than names for different algorithms must be unique
when compared as DNS names, i.e., comparison is case insensitive. when compared as DNS names, i.e., comparison is case insensitive.
Previous specifications [RFC2845] and [RFC4635] defined values for Previous specifications [RFC2845] and [RFC4635] defined values for
HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an HMAC MD5 and SHA. 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 the Generic Security Service (GSS) [RFC3645]. are delegated to the Generic Security Service (GSS) [RFC3645].
New algorithms are assigned using the IETF Consensus policy defined New algorithms are assigned using the IETF Review policy defined in
in [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a
a fully-qualified domain name for historical reasons; other algorithm fully-qualified domain name for historical reasons; other algorithm
names are simple (i.e., single-component) names. names are simple (i.e., single-component) names.
IANA maintains a registry of RCODES (error codes), including "TSIG IANA maintains a registry of RCODES (error codes), including "TSIG
Error values" to be used for "Error" values as defined in Error values" to be used for "Error" values as defined in
Section 4.2. New error codes are assigned and specified as in Section 4.2. New error codes are assigned and specified as in
[RFC6895]. [RFC6895].
10. Security Considerations 10. Security Considerations
The approach specified here is computationally much less expensive The approach specified here is computationally much less expensive
skipping to change at page 23, line 28 skipping to change at page 23, line 28
Clement Berthaux from Synacktiv. Clement Berthaux from Synacktiv.
Note for the RFC Editor (to be removed before publication): the first Note for the RFC Editor (to be removed before publication): the first
'e' in Clement is a fact a small 'e' with acute, unicode code U+00E9. 'e' in Clement is a fact a small 'e' with acute, unicode code U+00E9.
I do not know if xml2rfc supports non ASCII characters so I prefer to I do not know if xml2rfc supports non ASCII characters so I prefer to
not experiment with it. BTW I am French too so I can help if you not experiment with it. BTW I am French too so I can help if you
have questions like correct spelling... have questions like correct spelling...
Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund
Sivaraman and Ralph Dolmans participated in the discussions that Sivaraman and Ralph Dolmans participated in the discussions that
prompted this document. Mukund Sivaraman and Martin Hoffman made prompted this document. Mukund Sivaraman, Martin Hoffman and Tony
extremely helpful suggestions concerning the structure and wording of Finch made extremely helpful suggestions concerning the structure and
the updated document. wording of the updated document.
Appendix B. Change History (to be removed before publication) Appendix B. Change History (to be removed before publication)
RFC EDITOR: Please remove this appendix before publication. RFC EDITOR: Please remove this appendix before publication.
draft-dupont-dnsop-rfc2845bis-00 draft-dupont-dnsop-rfc2845bis-00
[RFC4635] was merged. [RFC4635] was merged.
Authors of original documents were moved to Acknowledgments Authors of original documents were moved to Acknowledgments
skipping to change at page 26, line 21 skipping to change at page 26, line 21
Require that the Fudge field in BADTIME response be equal to the Require that the Fudge field in BADTIME response be equal to the
Fudge field received from the client. Fudge field received from the client.
Added comment concerning the handling of BADTIME messages due to Added comment concerning the handling of BADTIME messages due to
out of order packet reception. out of order packet reception.
draft-ietf-dnsop-rfc2845bis-06 draft-ietf-dnsop-rfc2845bis-06
Wording changes and minor corrections after feedback. Wording changes and minor corrections after feedback.
draft-ietf-dnsop-rfc2845bis-07
Updated text about use of hmac-sha1 using suggestion from Tony
Finch.
Corrected name of review policy used for new algorithms.
Authors' Addresses Authors' Addresses
Francis Dupont Francis Dupont
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States of America United States of America
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
skipping to change at page 26, line 38 skipping to change at page 27, line 4
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
Stephen Morris Stephen Morris
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States of America United States of America
Email: sa.morris8@gmail.com Email: sa.morris8@gmail.com
Paul Vixie Paul Vixie
Farsight Security Inc Farsight Security Inc
177 Bovet Road, Suite 180 177 Bovet Road, Suite 180
San Mateo, CA 94402 San Mateo, CA 94402
United States of America United States of America
Email: paul@redbarn.org Email: paul@redbarn.org
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Futurewei Technologies Futurewei Technologies
155 Beaver Street 2386 Panoramic Circle
Milford, MA 01753 Apopka, FL 32703
United States of America United States of America
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Olafur Gudmundsson Olafur Gudmundsson
CloudFlare Cloudflare
San Francisco, CA 94107 San Francisco, CA 94107
United States of America United States of America
Email: olafur+ietf@cloudflare.com Email: olafur+ietf@cloudflare.com
Brian Wellington Brian Wellington
Akamai Akamai
United States of America United States of America
Email: bwelling@akamai.com Email: bwelling@akamai.com
 End of changes. 16 change blocks. 
28 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/