doc: Add RFC documents

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]
+