--- 1/draft-ietf-dnsop-rfc2845bis-05.txt 2019-11-01 11:13:14.590914611 -0700 +++ 2/draft-ietf-dnsop-rfc2845bis-06.txt 2019-11-01 11:13:14.646916027 -0700 @@ -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: January 8, 2020 Farsight +Expires: May 4, 2020 Farsight D. Eastlake 3rd - Huawei + Futurewei O. Gudmundsson CloudFlare B. Wellington Akamai - July 7, 2019 + November 1, 2019 Secret Key Transaction Authentication for DNS (TSIG) - draft-ietf-dnsop-rfc2845bis-05 + draft-ietf-dnsop-rfc2845bis-06 Abstract This document describes a protocol 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 recommendation is made here for distributing the shared secrets: @@ -37,21 +37,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 January 8, 2020. + This Internet-Draft will expire on May 4, 2020. Copyright Notice Copyright (c) 2019 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 @@ -76,54 +76,54 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.3. Document History . . . . . . . . . . . . . . . . . . . . 4 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 5 4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 5 + 4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 6 4.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Request MAC . . . . . . . . . . . . . . . . . . . . . 8 - 4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 8 - 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 8 - 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 9 + 4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 9 + 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 9 + 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 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 . . . . . . . . . . . . 11 5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11 5.2.3. Time 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 . . . . . . . . . . . . . . 13 5.3.1. TSIG on Zone Transfer Over a TCP Connection . . . . . 13 5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14 5.4. Client Processing of Answer . . . . . . . . . . . . . . . 14 - 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 14 + 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 15 5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15 5.4.3. Time 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 . . . . . . 16 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16 - 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 16 + 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 17 8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 17 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 19 - 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 19 + 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix B. Change History (to be removed before publication) . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction 1.1. Background The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name to address translation and mail handling information. @@ -138,21 +138,21 @@ this case the data covered would be the whole zone transfer including any glue records sent. The protocol described by DNSSEC ([RFC4033], [RFC4034], [RFC4035]) does not protect glue records and unsigned records unless SIG(0) (transaction signature) is used. The authentication mechanism proposed in this document uses shared secret keys to establish a trust relationship between two entities. Such keys must be protected in a manner similar to private keys, lest a third party masquerade as one of the intended parties (by forging - the MAC). There is an urgent need to provide simple and efficient + the MAC). There was a need to provide simple and efficient authentication between clients and local servers and this proposal addresses that need. The proposal is unsuitable for general server to server authentication for servers which speak with many other servers, since key management would become unwieldy with the number of shared keys going up quadratically. But it is suitable for many resolvers on hosts that only talk to a few recursive servers. 1.2. Protocol Overview Secret Key Transaction Authentication makes use of signatures on @@ -166,35 +166,41 @@ The way that this agreement is reached is outside the scope of the document. A DNS message exchange involves the sending of a query and the receipt of one of more DNS messages in response. For the query, the MAC is calculated based on the hash of the contents and the agreed TSIG key. The MAC for the response is similar, but also includes the MAC of the query as part of the calculation. Where a response comprises multiple packets, the calculation of the MAC associated with the second and subsequent packets includes in its inputs the MAC - for the the preceding packet. In this way it is possible to detect - any interruption in the packet sequence. + for the preceding packet. In this way it is possible to detect any + interruption in the packet sequence. The MAC is contained in a TSIG resource record included in the Additional Section of the DNS message. 1.3. Document History TSIG was originally specified by [RFC2845]. In 2017, two nameservers strictly following that document (and the related [RFC4635]) were discovered to have security problems related to this feature. The implementations were fixed but, to avoid similar problems in the future, the two documents were updated and merged, producing this revised specification for TSIG. + While TSIG implemented according to this RFC provides for enhanced + security, there are no changes in interoperability. TSIG is on the + wire still the same mechanism described in [RFC2845]; only the + checking semantics have been changed. See Section 10.1 for further + details. + 2. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Assigned Numbers @@ -236,30 +242,28 @@ multi-octet integers in the record are sent in network byte order (see [RFC1035] 2.3.2). NAME The name of the key used in domain name syntax. The name 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 time. If hosts A.site.example and B.example.net share a key, possibilities for the key name include .A.site.example, .B.example.net, and .A.site.example.B.example.net. It should be possible for more than one key to be in simultaneous - use among a set of interacting hosts. The name only needs to - be meaningful to the communicating hosts but a meaningful - mnemonic name as suggested above is strongly recommended. + use among a set of interacting hosts. 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 just shared between two hosts, its name actually need only be meaningful to them but it is recommended that the key name be mnemonic and incorporates the names of participating agents or - resources. + resources as suggested above. TYPE This MUST be TSIG (250: Transaction SIGnature) CLASS This MUST be ANY TTL This MUST be 0 RdLen (variable) RDATA The RDATA for a TSIG RR consists of a number of fields, @@ -324,26 +329,26 @@ of the "Other Data" field in octets. * Other Data - this unsigned 48-bit integer field will be empty unless the content of the Error field is BADTIME, in which case it will contain the server's current time as the number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds (see Section 5.2.3). 4.3. MAC Computation - When generating or verifying the contents of a TSIG record, the the - data listed in the rest of this section are passed, in the order - listed below, as input to MAC computation. The data are passed in - network byte order or wire format, as appropriate, and are fed into - the hashing function as a continuous octet sequence with no - interfield separator or padding. + When generating or verifying the contents of a TSIG record, the data + listed in the rest of this section are passed, in the order listed + below, as input to MAC computation. The data are passed in network + byte order or wire format, as appropriate, and are fed into the + hashing function as a continuous octet sequence with no interfield + separator or padding. 4.3.1. Request MAC Only included in the computation of a MAC for a response message (or the first message in a multi-message response), the validated request MAC MUST be included in the MAC computation. If the request MAC failed to validate, an unsigned error message MUST be returned instead. (Section 5.3.2). The request's MAC, comprising the following fields, is digested in @@ -443,21 +448,21 @@ record in the additional section. Multiple TSIG records are not allowed. If multiple TSIG records are detected or a TSIG record is present in any other position, the DNS message is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a message with exactly one correctly 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. If the TSIG RR cannot be understood, the server MUST regard the message as corrupt and return a FORMERR to the server. Otherwise the - the server is REQUIRED to return a TSIG RR in the response. + server is REQUIRED to return a TSIG RR in the response. To validate the received TSIG RR, the server MUST perform the following checks in the following order: 1. Check KEY 2. Check MAC 3. Check TIME values 4. Check Truncation policy 5.2.1. Key Check and Error Handling @@ -597,29 +602,27 @@ Prior MAC (running) DNS Messages (any unsigned messages since the last TSIG) TSIG Timers (current message) The "Prior MAC" is the MAC from the TSIG attached to the last message containing a TSIG. "DNS Messages" comprises the concatenation (in message order) of all messages after the last message that included a TSIG and includes the current message. "TSIG timers" comprises the "Time Signed" and "Fudge" fields (in that order) pertaining to the message for which the TSIG is being created: this means that the - successive TSIG records in the stream will have monotonically - increasing "Time Signed" fields. Note that only the timers are - included in the second and subsequent messages, not all the TSIG - variables. + successive TSIG records in the stream will have non-decreasing "Time + Signed" fields. Note that only the timers are included in the second + and subsequent messages, not all the TSIG variables. This allows the client to rapidly detect when the session has been altered; at which point it can close the connection and retry. If a client TSIG verification fails, the client MUST close the connection. - If the client does not receive TSIG records frequently enough (as specified above) it SHOULD assume the connection has been hijacked and it SHOULD close the connection. The client SHOULD treat this the same way as they would any other interrupted transfer (although the exact behavior is not specified here). 5.3.2. Generation of TSIG on Error Returns When a server detects an error relating to the key or MAC in the incoming request, the server SHOULD send back an unsigned error @@ -1047,20 +1049,22 @@ have questions like correct spelling... Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund Sivaraman and Ralph Dolmans participated in the discussions that prompted this document. Mukund Sivaraman and Martin Hoffman made extremely helpful suggestions concerning the structure and wording of the updated document. Appendix B. Change History (to be removed before publication) + RFC EDITOR: Please remove this appendix before publication. + draft-dupont-dnsop-rfc2845bis-00 [RFC4635] was merged. Authors of original documents were moved to Acknowledgments (Appendix A). Section 2 was updated to [RFC8174] style. Spit references into normative and informative references and @@ -1172,21 +1177,26 @@ 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. + draft-ietf-dnsop-rfc2845bis-06 + + Wording changes and minor corrections after feedback. + 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 @@ -1187,32 +1197,31 @@ United States of America Email: Francis.Dupont@fdupont.fr Stephen Morris Internet Software Consortium 950 Charter Street Redwood City, CA 94063 United States of America - Email: stephen@isc.org + Email: sa.morris8@gmail.com Paul Vixie Farsight Security Inc 177 Bovet Road, Suite 180 San Mateo, CA 94402 United States of America Email: paul@redbarn.org - Donald E. Eastlake 3rd - Huawei Technologies + Futurewei Technologies 155 Beaver Street Milford, MA 01753 United States of America Email: d3e3e3@gmail.com Olafur Gudmundsson CloudFlare San Francisco, CA 94107 United States of America