rfc3090.txt

RFC 的详细文档！

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