diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3090.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3090.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3090.txt b/contrib/bind9/doc/rfc/rfc3090.txt deleted file mode 100644 index 08008f7..0000000 --- a/contrib/bind9/doc/rfc/rfc3090.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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] - |
