--- 1/draft-ietf-dnsop-rfc2845bis-01.txt 2018-11-19 05:13:13.444360984 -0800 +++ 2/draft-ietf-dnsop-rfc2845bis-02.txt 2018-11-19 05:13:13.496362224 -0800 @@ -1,26 +1,26 @@ Internet Engineering Task Force F. Dupont Internet-Draft S. Morris Obsoletes: 2845, 4635 (if approved) ISC Intended status: Standards Track P. Vixie -Expires: April 18, 2019 Farsight +Expires: May 23, 2019 Farsight D. Eastlake 3rd Huawei O. Gudmundsson CloudFlare B. Wellington Akamai - October 15, 2018 + November 19, 2018 Secret Key Transaction Authentication for DNS (TSIG) - draft-ietf-dnsop-rfc2845bis-01 + draft-ietf-dnsop-rfc2845bis-02 Abstract This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved name server. No provision has been made here for distributing the shared secrets. @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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 as "work in progress." - This Internet-Draft will expire on April 18, 2019. + This Internet-Draft will expire on May 23, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -93,39 +93,39 @@ 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 6.1. TSIG generation on requests . . . . . . . . . . . . . . . 10 6.2. TSIG on Answers . . . . . . . . . . . . . . . . . . . . . 10 6.3. TSIG on TSIG Error returns . . . . . . . . . . . . . . . 11 6.4. TSIG on zone transfer over a TCP connection . . . . . . . 11 6.5. Server TSIG checks . . . . . . . . . . . . . . . . . . . 12 6.5.1. Key check and error handling . . . . . . . . . . . . 12 6.5.2. MAC check and error handling . . . . . . . . . . . . 12 6.5.3. Time check and error handling . . . . . . . . . . . . 13 6.5.4. Truncation check and error handling . . . . . . . . . 13 - 6.6. Client processing of answer . . . . . . . . . . . . . . . 13 + 6.6. Client processing of answer . . . . . . . . . . . . . . . 14 6.6.1. Key error handling . . . . . . . . . . . . . . . . . 14 6.6.2. MAC error handling . . . . . . . . . . . . . . . . . 14 6.6.3. Time error handling . . . . . . . . . . . . . . . . . 14 6.6.4. Truncation error handling . . . . . . . . . . . . . . 14 6.7. Special considerations for forwarding servers . . . . . . 15 7. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 15 8. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 16 9. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11.1. Issue fixed in this document . . . . . . . . . . . . . . 19 11.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Change History (to be removed before publication) . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The Domain Name System (DNS) [RFC1034], [RFC1035] is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name <=> address translation and mail handling information. In 2017, security problems in two nameservers strictly following [RFC2845] and [RFC4635] (i.e., TSIG and its HMAC-SHA extension) @@ -349,25 +349,27 @@ placed TSIG RR, the TSIG RR is copied to a safe location, removed from the DNS Message, and decremented out of the DNS message header's ARCOUNT. At this point the keyed hash (HMAC) computation is performed. If the algorithm name or key name is unknown to the recipient, or if the MACs do not match, the whole DNS message MUST be discarded. If the message is a query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign this message it MUST be - sent unsigned (MAC size == 0 and empty MAC). A message to the system - operations log SHOULD be generated, to warn the operations staff of a - possible security incident in progress. Care should be taken to - ensure that logging of this type of event does not open the system to - a denial of service attack. + sent unsigned (MAC size == 0 and empty MAC). Algorithm name and time + signed and fudge fields SHOULD be copied to the response to provide + off path spoof protection. A message to the system operations log + SHOULD be generated, to warn the operations staff of a possible + security incident in progress. Care should be taken to ensure that + logging of this type of event does not open the system to a denial of + service attack. Until these error checks are successfully passed, concluding that the signature is valid, the signature MUST be considered to be invalid. 5.3. Time values used in TSIG calculations The data digested includes the two timer values in the TSIG header in order to defend against replay attacks. If this were not done, an attacker could replay old messages but update the "Time Signed" and "Fudge" fields to make the message look new. This data is named @@ -1114,21 +1114,27 @@ Added text from [RFC3645] concerning the signing behavior if a secret key is added during a multi-message exchange. Added reference to [RFC6895]. Many improvements in the wording. Added RFC 2845 authors as co-authors of this document. + draft-ietf-dnsop-rfc2845bis-02 + + Added a recommendation to copy time fields in BADKEY errors. + (Mark Andrews) + Authors' Addresses + Francis Dupont Internet Software Consortium 950 Charter Street Redwood City, CA 94063 United States of America Email: Francis.Dupont@fdupont.fr Stephen Morris Internet Software Consortium