diff options
Diffstat (limited to 'doc/rfc/rfc3090.txt')
| -rw-r--r-- | doc/rfc/rfc3090.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt new file mode 100644 index 0000000..08008f7 --- /dev/null +++ b/doc/rfc/rfc3090.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group E. Lewis +Request for Comments: 3090 NAI Labs +Category: Standards Track March 2001 + + + DNS Security Extension Clarification on Zone Status + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The definition of a secured zone is presented, clarifying and + updating sections of RFC 2535. RFC 2535 defines a zone to be secured + based on a per algorithm basis, e.g., a zone can be secured with RSA + keys, and not secured with DSA keys. This document changes this to + define a zone to be secured or not secured regardless of the key + algorithm used (or not used). To further simplify the determination + of a zone's status, "experimentally secure" status is deprecated. + +1 Introduction + + Whether a DNS zone is "secured" or not is a question asked in at + least four contexts. A zone administrator asks the question when + configuring a zone to use DNSSEC. A dynamic update server asks the + question when an update request arrives, which may require DNSSEC + processing. A delegating zone asks the question of a child zone when + the parent enters data indicating the status the child. A resolver + asks the question upon receipt of data belonging to the zone. + +1.1 When a Zone's Status is Important + + A zone administrator needs to be able to determine what steps are + needed to make the zone as secure as it can be. Realizing that due + to the distributed nature of DNS and its administration, any single + zone is at the mercy of other zones when it comes to the appearance + of security. This document will define what makes a zone qualify as + secure. + + + + +Lewis Standards Track [Page 1] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + A name server performing dynamic updates needs to know whether a zone + being updated is to have signatures added to the updated data, NXT + records applied, and other required processing. In this case, it is + conceivable that the name server is configured with the knowledge, + but being able to determine the status of a zone by examining the + data is a desirable alternative to configuration parameters. + + A delegating zone is required to indicate whether a child zone is + secured. The reason for this requirement lies in the way in which a + resolver makes its own determination about a zone (next paragraph). + To shorten a long story, a parent needs to know whether a child + should be considered secured. This is a two part question. Under + what circumstances does a parent consider a child zone to be secure, + and how does a parent know if the child conforms? + + A resolver needs to know if a zone is secured when the resolver is + processing data from the zone. Ultimately, a resolver needs to know + whether or not to expect a usable signature covering the data. How + this determination is done is out of the scope of this document, + except that, in some cases, the resolver will need to contact the + parent of the zone to see if the parent states that the child is + secured. + +1.2 Islands of Security + + The goal of DNSSEC is to have each zone secured, from the root zone + and the top-level domains down the hierarchy to the leaf zones. + Transitioning from an unsecured DNS, as we have now, to a fully + secured - or "as much as will be secured" - tree will take some time. + During this time, DNSSEC will be applied in various locations in the + tree, not necessarily "top down." + + For example, at a particular instant, the root zone and the "test." + TLD might be secured, but region1.test. might not be. (For + reference, let's assume that region2.test. is secured.) However, + subarea1.region1.test. may have gone through the process of becoming + secured, along with its delegations. The dilemma here is that + subarea1 cannot get its zone keys properly signed as its parent zone, + region1, is not secured. + + The colloquial phrase describing the collection of contiguous secured + zones at or below subarea1.region1.test. is an "island of security." + The only way in which a DNSSEC resolver will come to trust any data + from this island is if the resolver is pre-configured with the zone + key(s) for subarea1.region1.test., i.e., the root of the island of + security. Other resolvers (not so configured) will recognize this + island as unsecured. + + + + +Lewis Standards Track [Page 2] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + An island of security begins with one zone whose public key is pre- + configured in resolvers. Within this island are subzones which are + also secured. The "bottom" of the island is defined by delegations + to unsecured zones. One island may also be on top of another - + meaning that there is at least one unsecured zone between the bottom + of the upper island and the root of the lower secured island. + + Although both subarea1.region1.test. and region2.test. have both been + properly brought to a secured state by the administering staff, only + the latter of the two is actually "globally" secured - in the sense + that all DNSSEC resolvers can and will verify its data. The former, + subarea1, will be seen as secured by a subset of those resolvers, + just those appropriately configured. This document refers to such + zones as being "locally" secured. + + In RFC 2535, there is a provision for "certification authorities," + entities that will sign public keys for zones such as subarea1. + There is another document, [RFC3008], that restricts this activity. + Regardless of the other document, resolvers would still need proper + configuration to be able to use the certification authority to verify + the data for the subarea1 island. + +1.2.1 Determining the closest security root + + Given a domain, in order to determine whether it is secure or not, + the first step is to determine the closest security root. The + closest security root is the top of an island of security whose name + has the most matching (in order from the root) right-most labels to + the given domain. + + For example, given a name "sub.domain.testing.signed.exp.test.", and + given the secure roots "exp.test.", "testing.signed.exp.test." and + "not-the-same.xy.", the middle one is the closest. The first secure + root shares 2 labels, the middle 4, and the last 0. + + The reason why the closest is desired is to eliminate false senses of + insecurity because of a NULL key. Continuing with the example, the + reason both "testing..." and "exp.test." are listed as secure root is + presumably because "signed.exp.test." is unsecured (has a NULL key). + If we started to descend from "exp.test." to our given domain + (sub...), we would encounter a NULL key and conclude that sub... was + unsigned. However, if we descend from "testing..." and find keys + "domain...." then we can conclude that "sub..." is secured. + + Note that this example assumes one-label deep zones, and assumes that + we do not configure overlapping islands of security. To be clear, + the definition given should exclude "short.xy.test." from being a + closest security root for "short.xy." even though 2 labels match. + + + +Lewis Standards Track [Page 3] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + Overlapping islands of security introduce no conceptually interesting + ideas and do not impact the protocol in anyway. However, protocol + implementers are advised to make sure their code is not thrown for a + loop by overlaps. Overlaps are sure to be configuration problems as + islands of security grow to encompass larger regions of the name + space. + +1.3 Parent Statement of Child Security + + In 1.1 of this document, there is the comment "the parent states that + the child is secured." This has caused quite a bit of confusion. + + The need to have the parent "state" the status of a child is derived + from the following observation. If you are looking to see if an + answer is secured, that it comes from an "island of security" and is + properly signed, you must begin at the (appropriate) root of the + island of security. + + To find the answer you are inspecting, you may have to descend + through zones within the island of security. Beginning with the + trusted root of the island, you descend into the next zone down. As + you trust the upper zone, you need to get data from it about the next + zone down, otherwise there is a vulnerable point in which a zone can + be hijacked. When or if you reach a point of traversing from a + secured zone to an unsecured zone, you have left the island of + security and should conclude that the answer is unsecured. + + However, in RFC 2535, section 2.3.4, these words seem to conflict + with the need to have the parent "state" something about a child: + + There MUST be a zone KEY RR, signed by its superzone, for every + subzone if the superzone is secure. This will normally appear in + the subzone and may also be included in the superzone. But, in + the case of an unsecured subzone which can not or will not be + modified to add any security RRs, a KEY declaring the subzone to + be unsecured MUST appear with the superzone signature in the + superzone, if the superzone is secure. + + The confusion here is that in RFC 2535, a secured parent states that + a child is secured by SAYING NOTHING ("may also be" as opposed to + "MUST also be"). This is counter intuitive, the fact that an absence + of data means something is "secured." This notion, while acceptable + in a theoretic setting has met with some discomfort in an operation + setting. However, the use of "silence" to state something does + indeed work in this case, so there hasn't been sufficient need + demonstrated to change the definition. + + + + + +Lewis Standards Track [Page 4] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +1.4 Impact on RFC 2535 + + This document updates sections of RFC 2535. The definition of a + secured zone is an update to section 3.4 of the RFC. Section 3.4 is + updated to eliminate the definition of experimental keys and + illustrate a way to still achieve the functionality they were + designed to provide. Section 3.1.3 is updated by the specifying the + value of the protocol octet in a zone key. + +1.5 "MUST" and other key words + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in [RFC 2119]. + Currently, only "MUST" is used in this document. + +2 Status of a Zone + + In this section, rules governing a zone's DNSSEC status are + presented. There are three levels of security defined: global, + local, and unsecured. A zone is globally secure when it complies + with the strictest set of DNSSEC processing rules. A zone is locally + secured when it is configured in such a way that only resolvers that + are appropriately configured see the zone as secured. All other + zones are unsecured. + + Note: there currently is no document completely defining DNSSEC + verification rules. For the purposes of this document, the strictest + rules are assumed to state that the verification chain of zone keys + parallels the delegation tree up to the root zone. (See 2.b below.) + This is not intended to disallow alternate verification paths, just + to establish a baseline definition. + + To avoid repetition in the rules below, the following terms are + defined. + + 2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01 + for name type (indicating a zone key) and either value 00 or value 01 + for key type (indicating a key permitted to authenticate data). (See + RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value + of DNSSEC (3) or ALL (255). + + The definition updates RFC 2535's definition of a zone key. The + requirement that the protocol field be either DNSSEC or ALL is a new + requirement (a change to section 3.1.3.) + + 2.b On-tree Validation - The authorization model in which only the + parent zone is recognized to supply a DNSSEC-meaningful signature + that is used by a resolver to build a chain of trust from the child's + + + +Lewis Standards Track [Page 5] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + + keys to a recognized root of security. The term "on-tree" refers to + following the DNS domain hierarchy (upwards) to reach a trusted key, + presumably the root key if no other key is available. The term + "validation" refers to the digital signature by the parent to prove + the integrity, authentication and authorization of the child's key to + sign the child's zone data. + + 2.c Off-tree Validation - Any authorization model that permits domain + names other than the parent's to provide a signature over a child's + zone keys that will enable a resolver to trust the keys. + +2.1 Globally Secured + + A globally secured zone, in a nutshell, is a zone that uses only + mandatory to implement algorithms (RFC 2535, section 3.2) and relies + on a key certification chain that parallels the delegation tree (on- + tree validation). Globally secured zones are defined by the + following rules. + + 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at + least one zone signing KEY RR (2.a) of a mandatory to implement + algorithm in the set. + + 2.1.b. The zone's apex KEY RR set MUST be signed by a private key + belonging to the parent zone. The private key's public companion + MUST be a zone signing KEY RR (2.a) of a mandatory to implement + algorithm and owned by the parent's apex. + + If a zone cannot get a conforming signature from the parent zone, the + child zone cannot be considered globally secured. The only exception + to this is the root zone, for which there is no parent zone. + + 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies + RFC 2535, section 2.3.2.) Note: there is some operational discomfort + with the current NXT record. This requirement is open to + modification when two things happen. First, an alternate mechanism + to the NXT is defined and second, a means by which a zone can + indicate that it is using an alternate method. + + 2.1.d. Each RR set that qualifies for zone membership MUST be signed + by a key that is in the apex's KEY RR set and is a zone signing KEY + RR (2.a) of a mandatory to implement algorithm. (Updates 2535, + section 2.3.1.) + + Mentioned earlier, the root zone is a special case. The root zone + will be considered to be globally secured provided that if conforms + to the rules for locally secured, with the exception that rule 2.1.a. + be also met (mandatory to implement requirement). + + + +Lewis Standards Track [Page 6] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +2.2 Locally Secured + + The term "locally" stems from the likely hood that the only resolvers + to be configured for a particular zone will be resolvers "local" to + an organization. + + A locally secured zone is a zone that complies with rules like those + for a globally secured zone with the following exceptions. The + signing keys may be of an algorithm that is not mandatory to + implement and/or the verification of the zone keys in use may rely on + a verification chain that is not parallel to the delegation tree + (off-tree validation). + + 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at + least one zone signing KEY RR (2.a) in the set. + + 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and + one of the following two subclauses MUST hold true. + + 2.2.b.1 The private key's public companion MUST be pre-configured in + all the resolvers of interest. + + 2.2.b.2 The private key's public companion MUST be a zone signing KEY + RR (2.a) authorized to provide validation of the zone's apex KEY RR + set, as recognized by resolvers of interest. + + The previous sentence is trying to convey the notion of using a + trusted third party to provide validation of keys. If the domain + name owning the validating key is not the parent zone, the domain + name must represent someone the resolver trusts to provide + validation. + + 2.2.c. NXT records MUST be deployed throughout the zone. Note: see + the discussion following 2.1.c. + + 2.2.d. Each RR set that qualifies for zone membership MUST be signed + by a key that is in the apex's KEY RR set and is a zone signing KEY + RR (2.a). (Updates 2535, section 2.3.1.) + +2.3 Unsecured + + All other zones qualify as unsecured. This includes zones that are + designed to be experimentally secure, as defined in a later section + on that topic. + + + + + + + +Lewis Standards Track [Page 7] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +2.4 Wrap up + + The designation of globally secured, locally secured, and unsecured + are merely labels to apply to zones, based on their contents. + Resolvers, when determining whether a signature is expected or not, + will only see a zone as secured or unsecured. + + Resolvers that follow the most restrictive DNSSEC verification rules + will only see globally secured zones as secured, and all others as + unsecured, including zones which are locally secured. Resolvers that + are not as restrictive, such as those that implement algorithms in + addition to the mandatory to implement algorithms, will see some + locally secured zones as secured. + + The intent of the labels "global" and "local" is to identify the + specific attributes of a zone. The words are chosen to assist in the + writing of a document recommending the actions a zone administrator + take in making use of the DNS security extensions. The words are + explicitly not intended to convey a state of compliance with DNS + security standards. + +3 Experimental Status + + The purpose of an experimentally secured zone is to facilitate the + migration from an unsecured zone to a secured zone. This distinction + is dropped. + + The objective of facilitating the migration can be achieved without a + special designation of an experimentally secure status. + Experimentally secured is a special case of locally secured. A zone + administrator can achieve this by publishing a zone with signatures + and configuring a set of test resolvers with the corresponding public + keys. Even if the public key is published in a KEY RR, as long as + there is no parent signature, the resolvers will need some pre- + configuration to know to process the signatures. This allows a zone + to be secured with in the sphere of the experiment, yet still be + registered as unsecured in the general Internet. + +4 IANA Considerations + + This document does not request any action from an assigned number + authority nor recommends any actions. + + + + + + + + + +Lewis Standards Track [Page 8] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +5 Security Considerations + + Without a means to enforce compliance with specified protocols or + recommended actions, declaring a DNS zone to be "completely" secured + is impossible. Even if, assuming an omnipotent view of DNS, one can + declare a zone to be properly configured for security, and all of the + zones up to the root too, a misbehaving resolver could be duped into + believing bad data. If a zone and resolver comply, a non-compliant + or subverted parent could interrupt operations. The best that can be + hoped for is that all parties are prepared to be judged secure and + that security incidents can be traced to the cause in short order. + +6 Acknowledgements + + The need to refine the definition of a secured zone has become + apparent through the efforts of the participants at two DNSSEC + workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA- + funded research network), and other workshops. Further discussions + leading to the document include Olafur Gudmundsson, Russ Mundy, + Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and + others have contributed significant input via the namedroppers + mailing list. + +7 References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System", RFC 2136, + April 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + + + + +Lewis Standards Track [Page 9] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +10 Author's Address + + Edward Lewis + NAI Labs + 3060 Washington Road Glenwood + MD 21738 + + Phone: +1 443 259 2352 + EMail: lewis@tislabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lewis Standards Track [Page 10] + +RFC 3090 DNS Security Extension on Zone Status March 2001 + + +11 Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Lewis Standards Track [Page 11] + |