Internet-Draft B. Wellington, O. Gudmundsson DNSSEC Working Group TISLabs <draft-ietf-dnssec-secfail-00.txt> August 1998 Intermediate Security Failures in DNSSEC <draft-ietf-dnssec-secfail-00.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document identifies the situations where a signature verification fails in a recursive security aware DNS server, and how DNS servers should handle these cases, and the errors that should be reported to DNS resolvers. This document proposes a new error to be returned by DNSSEC capable servers. A DNSSEC server acting as a recursive server MUST validate the signatures on RRsets in a response it passes on; this draft addresses the case when the data it receives fails signature Wellington, Gudmundsson Expires February 1999 [Page 1]
Internet-Draft dnssec-secfail-00.txt August 1998 verification. The end resolver must be notified of this occurence in such a way that it will not confuse it with another error. 1. Description A DNS [RFC1034, RFC1035] transaction is defined by a query/response pair. The resolver (client) sends a query to a name server. The name server will respond if it contains the necessary information, or forward the request to an authoritative server. The response consists of the answer to the query, as well as authority records showing that the response came from a valid source, and additional records. DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol. Each RRset (set of DNS records with the same name/class/type) is digitally signed, and the signature is verified by any server or resolver who receives it. The receiver must therefore have a valid key for verifying that data, as specified by a name/footprint pair. A key's validity is determined by recursively verifying that it was signed by a valid key; this recursion ends when a trusted key is reached. Trusted keys must be obtained out of band, for example through manual configuration. Consider a recursive name server (R) that forwards a query to another server (S). R receives an response from S, and attempts to verify the included RRsets using a key that it trusts. Note that this key may either be implicitly trusted or authenticated. The signature verification fails for one or more RRsets in the answer or authority section. The name server must communicate this error in its response. To do this, a new return code (RCODE) will be used, denoted SECFAIL (value TBD). When a resolver receives a DNS response with an RCODE of SECFAIL, that one of the following is true: 1) server S has sent invalid data to server R. 2) the data has been corrupted (possibly maliciously) between R and S. 3) server R has preconfigured S's key incorrectly. 4) There is more than one KEY with the same footprint and algorithm for that name, and server R contains one different from the one used by S to sign the data. This should not happen. None of the current RCODE values sufficiently describe the case where the data exists, but cannot be successfully retrieved and/or transmitted. It is the responsibility of both R and the resolver to attempt to identify the source of the problem. Wellington, Gudmundsson Expires February 1999 [Page 2]
Internet-Draft dnssec-secfail-00.txt August 1998 2. Proposal When the recursive name server (R) fails to verify a signed RRset in the answer or authority section of a response that it receives, it sets the RCODE of the response to SECFAIL before forwarding the response to the entity that originated the query. There are several possible modifications that could be made to the data by R: 1) all records could be passed unchanged 2) all records could be dropped 3) only the records that failed verification could be dropped 4) the SIGs of all records that failed verification could be dropped A solution to this problem has not yet been decided. If R receives a response with SECFAIL set, it does no processing on the response, simply forwarding it if necessary. An intelligent resolver MAY use additional queries to determine which of the RRsets was invalid. The ERR record [ERR] or EDNS [EDNS] could also be used to provide a more fine-grained description of the error. When R fails to verify an RRset, it can determine whether or not the key used has successfully verified other data (a flag or timestamp could be stored along with the key). If it has, then the key has not been misconfigured, and the error is due to data corruption (possibly malicious) or a data error on the authoritative server (S). R cannot further quantify the problem. If the key has never successfully verified data, then the problem may be a misconfigured key, or it could be due to malicious corruption or a very unreliable network. In any case, this should be logged, and the maintainer of R should determine (out of band) whether the preconfigured key is erroneous. R MAY elect to retry the query; this would succeed if the error was due to transient network problems or a partial attack. Unless a retransmission yields success, R should always send a response with SECFAIL set. 3. Limitations If the path between a resolver and an authoritative server is several hops, there is no way to determine at which recursive server the SECFAIL error occurred. The data will be passed through successive servers unchanged. There is no way to distinguish a server continuously reporting invalid data from an active attack. For instance, if a server has an preconfigured key that is invalid, all queries using that key will fail. An attack could easily simulate this behavior. There is no way to split SECFAIL into more specific errors, since the Wellington, Gudmundsson Expires February 1999 [Page 3]
Internet-Draft dnssec-secfail-00.txt August 1998 cause of the error cannot always be determined. 4. Security Considerations Unless transaction signatures of some form are used [RFC2065, TSIG], the RCODE field of a DNS response is not protected, so the SECFAIL RCODE could be added or stripped by an attacker. 5. References [EDNS] P. Vixie, "Extensions to DNS (EDNS)", Internet Draft <draft-ietf-dnsind-edns-02.txt>, March 1998 [ERR] R. Watson, O. Gudmundsson, "Error Record (ERR) for DNS" Internet Draft <draft-ietf-dnsind-dns- error-00.txt>, March 1998 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1034, ISI, November 1987. [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [SECEXT2] D. Eastlake, "Domain Name System Security Exten sions", Internet Draft <draft-ietf-dnssec- secext2-05.txt>, April 1998. [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)" Inter net Draft <draft-ietf-dnsind-tsig-05.txt>, June 1998. Wellington, Gudmundsson Expires February 1999 [Page 4]
Internet-Draft dnssec-secfail-00.txt August 1998 6. Author address Brian Wellington, Olafur Gudmundsson TIS Labs at Network Associates 3060 Washington Road Glenwood, MD 21738 +1 301 854 6889 bwelling@tis.com, ogud@tis.com Wellington, Gudmundsson Expires February 1999 [Page 5]
