--- /dev/null
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+
+
git.samba.org / tridge / bind9.git / blobdiff