draft-ietf-dnsop-rfc2845bis-04.txt   draft-ietf-dnsop-rfc2845bis-05.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: December 27, 2019 Farsight Expires: January 8, 2020 Farsight
D. Eastlake 3rd D. Eastlake 3rd
Huawei Huawei
O. Gudmundsson O. Gudmundsson
CloudFlare CloudFlare
B. Wellington B. Wellington
Akamai Akamai
June 25, 2019 July 7, 2019
Secret Key Transaction Authentication for DNS (TSIG) Secret Key Transaction Authentication for DNS (TSIG)
draft-ietf-dnsop-rfc2845bis-04 draft-ietf-dnsop-rfc2845bis-05
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 December 27, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 8 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 8
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 9 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 9
5.2. Server Processing of Request . . . . . . . . . . . . . . 10 5.2. Server Processing of Request . . . . . . . . . . . . . . 10
5.2.1. Key Check and Error Handling . . . . . . . . . . . . 10 5.2.1. Key Check and Error Handling . . . . . . . . . . . . 10
5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11 5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11
5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12 5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12
5.2.4. Truncation Check and Error Handling . . . . . . . . . 12 5.2.4. Truncation Check and Error Handling . . . . . . . . . 12
5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 12 5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 12
5.3.1. TSIG on Zone Transfer Over a TCP Connection . . . . . 13 5.3.1. TSIG on Zone Transfer Over a TCP Connection . . . . . 13
5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 13 5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14
5.4. Client Processing of Answer . . . . . . . . . . . . . . . 14 5.4. Client Processing of Answer . . . . . . . . . . . . . . . 14
5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 14 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 14
5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 14 5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15
5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15 5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15
5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 15 5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 15
5.5. Special Considerations for Forwarding Servers . . . . . . 15 5.5. Special Considerations for Forwarding Servers . . . . . . 15
6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 15 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16
7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 16 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 16
8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17 8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 19 10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 19
10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 19 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
Appendix B. Change History (to be removed before publication) . 22 Appendix B. Change History (to be removed before publication) . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. Background 1.1. Background
The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated
hierarchical distributed database system that provides information hierarchical distributed database system that provides information
fundamental to Internet operations, such as name to address fundamental to Internet operations, such as name to address
translation and mail handling information. translation and mail handling information.
skipping to change at page 12, line 18 skipping to change at page 12, line 18
request (which is: Time Signed, plus/minus Fudge), the server MUST request (which is: Time Signed, plus/minus Fudge), the server MUST
generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
(BADTIME). The server SHOULD also cache the most recent time signed (BADTIME). The server SHOULD also cache the most recent time signed
value in a message generated by a key, and SHOULD return BADTIME if a value in a message generated by a key, and SHOULD return BADTIME if a
message received later has an earlier time signed value. A response message received later has an earlier time signed value. A response
indicating a BADTIME error MUST be signed by the same key as the indicating a BADTIME error MUST be signed by the same key as the
request. It MUST include the client's current time in the time request. It MUST include the client's current time in the time
signed field, the server's current time (an unsigned 48-bit integer) signed field, the server's current time (an unsigned 48-bit integer)
in the other data field, and 6 in the other data length field. This in the other data field, and 6 in the other data length field. This
is done so that the client can verify a message with a BADTIME error is done so that the client can verify a message with a BADTIME error
without the verification failing due to another BADTIME error. The without the verification failing due to another BADTIME error. In
data signed is specified in Section 5.3.2. The server SHOULD log the addition, the fudge field MUST be set to the fudge value received
error. from the client. The data signed is specified in Section 5.3.2. The
server SHOULD log the error.
Caching the most recent time signed value and rejecting requests with
an earlier one could lead to valid messages being rejected if transit
through the network led to UDP packets arriving in a different order
to the one in which they were sent. Implementations should be aware
of this possibility and be prepared to deal with it, e.g. by
retransmitting the rejected request with a new TSIG once outstanding
requests have completed or the time given by their time signed plus
fudge value has passed.
5.2.4. Truncation Check and Error Handling 5.2.4. Truncation Check and Error Handling
If a TSIG is received with truncation that is permitted under If a TSIG is received with truncation that is permitted under
Section 5.2.2.1 above but the MAC is too short for the local policy Section 5.2.2.1 above but the MAC is too short for the local policy
in force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be in force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be
returned. The server SHOULD log the error. returned. The server SHOULD log the error.
5.3. Generation of TSIG on Answers 5.3. Generation of TSIG on Answers
skipping to change at page 15, line 43 skipping to change at page 16, line 9
available to the destination and the message is a query then, if the available to the destination and the message is a query then, if the
corresponding response has the AD flag (see [RFC4035]) set, the corresponding response has the AD flag (see [RFC4035]) set, the
forwarder MUST clear the AD flag before adding the TSIG to the forwarder MUST clear the AD flag before adding the TSIG to the
response and returning the result to the system from which it response and returning the result to the system from which it
received the query. received the query.
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]). The "HMAC-MD5" algorithm is mandatory to implement for [RFC2104]). Although a review of its security [RFC6151] concluded
interoperability. that "it may not be urgent to remove HMAC-MD5 from the existing
protocols", with the availability of more secure alternatives the
opportunity has been taken to make the implementation of this
algorithm optional.
The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
compared to the 128 bits for MD5), and additional hash algorithms in compared to the 128 bits for MD5), and additional hash algorithms in
the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384,
and 512 bits may be preferred in some cases. This is because and 512 bits may be preferred in some cases. This is because
increasingly successful cryptanalytic attacks are being made on the increasingly successful cryptanalytic attacks are being made on the
shorter hashes. shorter hashes.
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
skipping to change at page 16, line 19 skipping to change at page 16, line 36
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
listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be
implemented. implemented.
Requirement Name Requirement Name
----------- ------------------------ ----------- ------------------------
Mandatory HMAC-MD5.SIG-ALG.REG.INT Optional HMAC-MD5.SIG-ALG.REG.INT
Optional gss-tsig Optional gss-tsig
Mandatory hmac-sha1 Mandatory hmac-sha1
Optional hmac-sha224 Optional hmac-sha224
Mandatory hmac-sha256 Mandatory hmac-sha256
Optional hmac-sha384 Optional hmac-sha384
Optional hmac-sha512 Optional hmac-sha512
Table 1 Table 1
7. TSIG Truncation Policy 7. TSIG Truncation Policy
skipping to change at page 22, line 10 skipping to change at page 22, line 25
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
skipping to change at page 22, line 43 skipping to change at page 23, line 14
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 and Martin Hoffman made
extermely helpful suggestions concerning the structure and wording of extremely helpful suggestions concerning the structure and wording of
the updated document. the updated document.
Appendix B. Change History (to be removed before publication) Appendix B. Change History (to be removed 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
(Appendix A). (Appendix A).
skipping to change at page 25, line 5 skipping to change at page 25, line 22
Added a recommendation to copy time fields in BADKEY errors. Added a recommendation to copy time fields in BADKEY errors.
(Mark Andrews) (Mark Andrews)
draft-ietf-dnsop-rfc2845bis-03 draft-ietf-dnsop-rfc2845bis-03
Further changes as a result of comments by Mukund Sivaraman. Further changes as a result of comments by Mukund Sivaraman.
Miscellaneous changes to wording. Miscellaneous changes to wording.
draft-ietf-dnsop-rfc2845bis-04
Major restructing as a result of comprehensive review by Martin Major restructing as a result of comprehensive review by Martin
Hoffman. Amongst the more significant changes: Hoffman. Amongst the more significant changes:
* More comprehensive introduction. * More comprehensive introduction.
* Merged "Protocol Description" and "Protocol Details" sections. * Merged "Protocol Description" and "Protocol Details" sections.
* Reordered sections so as to follow message exchange through * Reordered sections so as to follow message exchange through
"client "sending", "server receipt", "server sending", "client "client "sending", "server receipt", "server sending", "client
receipt". receipt".
* Added miscellaneous clarifications. * Added miscellaneous clarifications.
Authors' Addresses draft-ietf-dnsop-rfc2845bis-05
Make implementation of HMAC-MD5 optional.
Require that the Fudge field in BADTIME response be equal to the
Fudge field received from the client.
Added comment concerning the handling of BADTIME messages due to
out of order packet reception.
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
Stephen Morris Stephen Morris
Internet Software Consortium Internet Software Consortium
 End of changes. 17 change blocks. 
17 lines changed or deleted 46 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/