620 lines
24 KiB
Plaintext
620 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|