Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ohta-simple-dns-02.txt < prev next >

Wrap

Text File | 1996-11-26 | 44KB | 1,062 lines

INTERNET DRAFT M. Ohta draft-ohta-simple-dns-02.txt Tokyo Institute of Technology November 1996 Simple Secure DNS 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract An extension to DNS is proposed to make answers from it authenticated. The extension is designed to be minimal, which will be useful as a framework to make applications provide required level of authentication and/or confidentiality. The changes to the existing architecture of DNS is also minimized. 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. M. Ohta Expires on May 27, 1995 [Page 1] INTERNET DRAFT Simple Secure DNS November 1996 To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. M. Ohta Expires on May 27, 1995 [Page 2] INTERNET DRAFT Simple Secure DNS November 1996 Though the secure DNS can be an authenticated source of information to establish secure communication between hosts, such as distribution of host's public keys, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which supports queries for the new RR types in this document with required additional section processing. For more protection against some denial service type attack, additional authentication mechanism may be supported for secure zone transfer. A security aware recursive resolver is a resolver which can perform authenticated retrieval of DNS data in secure zones. From several seed zones, DNS tree is recursively traversed with authentication to get the final authenticated answer. A security aware recursive resolver is configured with static information to confirm that data from name servers of some seed zones are actually secure. A security aware stub resolver is a resolver which can perform authenticated communication with a recursive resolver. A stub resolver may be configured with static information to authenticate communication between recursive resolvers. The recursive and stub resolvers may be colocated on the same host and communicate securely though some operating system mechanism, for example, UNIX domain sockets, or they may be located on different hosts. So, how the recursive and stub resolvers securely communicate is out of scope of this document. But, it is suggested that a security aware stub resolver communicate with a security aware recursive resolver colocated with name server through normal DNS query through secure IP [SECIP] protocol. In this case, secure IP can not use DNS to establish security relationship so that some static configuration is necessary. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Previous Version and to the Existing Mechanism A lot of simplification is performed to the previous version of the draft: "draft-ohta-simple-dns-00.txt. First, protocol in this document, now, introduces no important changes to the existing DNS architecture. That is: No new OPCODE, NCQUERY, is added. Some query types for authentication matches its own RR type and CNAME. The M. Ohta Expires on May 27, 1995 [Page 3] INTERNET DRAFT Simple Secure DNS November 1996 impossibility of the current DNS to have CNAME only zone is left untouched. SD (Security Desired) bit is not added. As the desire needs to be expressed only for the secure communication between recursive and stub resolvers, it's out of the scope of this document. If secure IP protocol is used for the communication the fact that the secure IP protocol is used itself shows that the security is desired. SA (Security Assured) bit is not added. Instead, if secure communication channel to stub resolvers is used, secure recursive resolver must assure RRs that the answer section contains authenticated data only. Meaning of MINTTL field of SOA RRs is untouched, though it is widely known that using it as negative caching period is inappropriate. Cases of domain names are not canonicalized. They are canonicalized only when digest value is computed. To NSIG RR, <signer> field is added. Optional resolver operation mode for cross authentication is added. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. Binary format of each RRs are arranged with the byte sex of bigendean in the same order as the textual format. When RR types are used as query type, RRD and NSIG query matches a CNAME record too. M. Ohta Expires on May 27, 1995 [Page 4] INTERNET DRAFT Simple Secure DNS November 1996 RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax (<class> and <ttl> are omitted throughout the document): <node> [RRD] <type> <ottl> <digest> where [RRD] is the RR name of RRD, <digest> is the digest of all the resource records of type <type> of node <node>. <ottl> is the original TTL value of the records. <type> is a 16 bit quantity, <ottl> is a 32 bit quantity, <digest> is of variable length. When computing <digest>, records are represented in binary form in DNS packet with the following canonicalization: No domain name compression is performed. Upper case letters in domain names are converted to the corresponding lower case letters. If there are multiple records of the same <type>, they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. For example, four strings "AB", "AC", "BA" and "ABC" are sorted as ["AB", "ABC", "AC", "BA"]. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased already, should be replaced with the <ottl> (original TTL) field of the RRD record. When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the <ottl> value in RRD data. A node, in general, has multiple [RRD] records for each RR type the node has. But, it is impossible and unnecessary to cover <type>s of RRD, NSIG and ZSIG with digest. Still, it is necessary to have RRD of such <type>s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the <digest> field of length zero. To compute <digest> of [RRD] RR type itself, the <digest> field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. M. Ohta Expires on May 27, 1995 [Page 5] INTERNET DRAFT Simple Secure DNS November 1996 NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: <domain> [NSIG] <signer> <timestamp> <expire> <signature> where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), <signer> is a domain name of a zone who signs [ZA] and <timestamp> is the time when the signature is computed. <expire> is the number of seconds the signature will be valid after <timestamp>. <timestamp> and <expire> are 32 bit quantities. <signature> is of variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. When computing <signature>; <timestamp>, <expire> and <digest> of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: M. Ohta Expires on May 27, 1995 [Page 6] INTERNET DRAFT Simple Secure DNS November 1996 <domain> [ZA] <valid from> <authenticator> where [ZA] is the RR name of ZA, <valid from> is the time from when the <authenticator> is used. <valid from> is 32 bit absolute time. <authenticator> is of variable length. The actual content of <authenticator> varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. <valid from> field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new <authenticator>. If multiple [ZA]s exist during the transition, <timestamp> field of NSIG is compared to the <valid from> fields in [ZA]s to select the RR actually used for the signature. Older RR should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. <node> [ZSIG] <signer> <[NSIG]> <timestamp> <expire> <signature> where [ZSIG] is the RR name of ZSIG data, <signer> is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the <signer>. <timestamp>, <expire> and <signature> are the same as that of [NSIG] except that the signature covers the sequence of <timestamp> <expire> <digest>, where <digest> is the <digest> field of [RRD] of [ZA] of a signed zone. In general, only a <signer> who is a parent or an ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable <signer>s according to their local security policy. If multiple ZSIG RRs of different [ZSIG] values exist, the most preferable one is chosen by the resolver's local security policy. For the root zone or M. Ohta Expires on May 27, 1995 [Page 7] INTERNET DRAFT Simple Secure DNS November 1996 locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". ZL will have the following syntax. <zone> [ZL] <nttl> <first> <last> <n> <domain name #1> ... <domain name #n> <timestamp> <expire> <signature> where [ZL] is the RR name of ZL data, <nttl> is the number of seconds appropriate for negative caching, <n> is the number of domains covered by the record. The record contains all the domain names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) <first> and before <last> sorted with dictionary order. Cases of characters in <first>, <last> <domain name #1>... must be canonicalized to lower cases. <first> and <last> is merely a separator and should not be interpreted that such a node exists unless explicitly listed as <domain name #1>. Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, comparison are by dictionary oder, that is, first bytes are compared first. For example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.". M. Ohta Expires on May 27, 1995 [Page 8] INTERNET DRAFT Simple Secure DNS November 1996 Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as <last>, it is considered to be ordered after all the other names in the domain. For example, <zone> [ZL] <nttl> <zone> <zone> 0 <timestamp> <expire> <signature> represents a zone consisting of only a single node. <nttl> and <n> are two byte integers. <first>, <last>, <domain name #1>, ..., <domain name #n> have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). <timestamp>, <expire> and <signature> are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of <timestamp> <expire> <nttl> <first> <last> <n> <domain name #1> ... <domain name #n> contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. Secure zone transfer, protected by zone's key, may be used to detect that the primary server compromised and continue operation with older but secure data. The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to M. Ohta Expires on May 27, 1995 [Page 9] INTERNET DRAFT Simple Secure DNS November 1996 provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the M. Ohta Expires on May 27, 1995 [Page 10] INTERNET DRAFT Simple Secure DNS November 1996 answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of RRD. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Go to step 6. 4. Start matching down in the cache. If QNAME is found in the cache, copy all the RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data at 3.b, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query. Store the results, including any intermediate CNAMEs, in the answer section of the response. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFR] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. The TCP transport of a secure zone transfer meessage has the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone message | |s | | |t | | |e +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the M. Ohta Expires on May 27, 1995 [Page 11] INTERNET DRAFT Simple Secure DNS November 1996 signature of the transferred zone. Unlike AXFER, [SXFR] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The configuration file also contains information of ZA RRs the SBELT servers serves. The match count will be -1 to indicate that M. Ohta Expires on May 27, 1995 [Page 12] INTERNET DRAFT Simple Secure DNS November 1996 no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. TTL for secure data should be shortened not to exceed its authenticated <expire> period. Data in the cache also contains a bit telling whether the resolver think the data is secure or not. In the CACHE, authenticated RR has precedence over unauthenticated RR. During authentication, data should be stored in the cache as unauthenticated. Later, if the data is proven to be secure, the bit is flagged. If the data is proven to be insecure, the data is flushed. 5.3 Resolver Algorithm Stub resolvers believes anything recursive resolvers returns through secure communication channel. For recursive resolvers, the four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries until one returns a response. 4. Analyze the response, either: a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA M. Ohta Expires on May 27, 1995 [Page 13] INTERNET DRAFT Simple Secure DNS November 1996 of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. if the answer is in the authoritative data of a secure zone of a name server co-located with the resolver, no further authentication is necessary. 2. To authenticate RRD of ZA, use ZSIG and authenticated ZA of <signer> zone. 3. To authenticate ZA, use RRD of ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate RRD, use NSIG and authenticated ZA. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. 7. if the response is a name error, that is, a node which matches query does not exist, confirm it by authenticating ZL data in the additional section of the response. For example, to authenticate that data matching "a.b.c.d." dose not exist in a zone "c.d.", it should be confirmed that nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d." does exist. Depending on the zone's structure (whether "b.c.d." exists or not), the same thing may be confirmed by the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and M. Ohta Expires on May 27, 1995 [Page 14] INTERNET DRAFT Simple Secure DNS November 1996 "*.c.d" do not exist. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type <type> ^ |digest | RR with RR type <type> M. Ohta Expires on May 27, 1995 [Page 15] INTERNET DRAFT Simple Secure DNS November 1996 other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5.4 Resolver Algorithm for Cross Authentication (Optional) Usually, recursive resolver traverses DNS tree in top down manner from the nearest ancestor (often, the root node) of the sought node down toward the leaf direction. The selection corresponds to the step 2. 2. Find the best server to ask. of the top level resolver algorithm in section 5.3. By introducing a new RR type: XSIG, it is possible to find the best server in a bottom up manner. XSIG has the following format: <zone> XSIG <signee> <[ZA]> <digest> where, <digest> is the variable length digest of <[ZA]> RR of <signee> zone. The value of XSIG is <to be assigned by IANA>. Usually, <signee> is an ancestor of <zone>. Then, if a resolver is configured with static authentication information of <zone>, the resolver can reliably know the [ZA] information of <signee> zone. If <signee> zone also has XSIG, authentication may be chained up to the root zone. During the up sequence of authentication, XSIG may, only once, traverse the DNS tree, after which only the down sequence through NSIG (as described in step 4.b in section 5.3) is allowed. The algorithm to find the best server with terminology of the section 5.2 is as follows: 1. Start from a zone served by SBELT name servers. 2. If the zone has XSIG record with <signee> of the ancestor of the SNAME, the search has finished. 3. If the zone has XSIG record with <signee> of the ancestor of the zone itself, up the zone hierarchy and recursively continue the search at step 2. 4. If none of the conditions are met, try the next zone in the M. Ohta Expires on May 27, 1995 [Page 16] INTERNET DRAFT Simple Secure DNS November 1996 SBELT. If no zones are remaining, the search has failed. The use of the cross authentication scheme introduce some vulnerability but removes some, discussion on which is quite complex. There are also complex performance trade-offs. For example, even if an ancestor zone of SNAME is found in cache, the above steps must always be performed to find the nearest ancestor of SNAME, which is necessary for the security property of the cross authentication scheme. So, in this document, it's use is completely optional. 6. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA <expire> period is reached. Thus, until a resolver securely knows that <expire> period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, <expire> period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of <expire>/20. When resolvers caching information, it should be confirmed that cached period is shorter than <ottl> and <expire>*19/20 fractions rounded down minus the expected maximum error of the resolvers' clocks. Due to clock skew, a resolver may receive a <timestamp> dated in the future. The data should be relied if the error is below <expire>/10 fractions rounded down plus the expected maximum error of the resolver's clocks. To have an Internet wide upper bound on the life time of stale data, <expire> longer than a week should be shortened to a week. 7. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the M. Ohta Expires on May 27, 1995 [Page 17] INTERNET DRAFT Simple Secure DNS November 1996 reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. additional information on the queried node. other additional information. 8. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X form a single set of specification. Even if two specifications share the same digesting or signature mechanism, they have different [RRD] or [NSIG] values. 9. References [RFC1034] [RFC1035] [SECIP] Security Considerations The entire document is devoted on a security issue to make answers from DNS authenticated over unreliable transport mechanisms. No confidentiality is considered. Author's Address Masataka Ohta Computer Center Tokyo Institute of Technology M. Ohta Expires on May 27, 1995 [Page 18] INTERNET DRAFT Simple Secure DNS November 1996 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on May 27, 1995 [Page 19]