draft-ietf-dnsext-zone-status-03.txt   draft-ietf-dnsext-zone-status-04.txt 
DNSEXT WG Edward Lewis DNSEXT WG Edward Lewis
INTERNET DRAFT NAI Labs INTERNET DRAFT NAI Labs
Category:I-D September 19, 2000 Category:I-D January 3, 2001
DNS Security Extension Clarification on Zone Status DNS Security Extension Clarification on Zone Status
<draft-ietf-dnsext-zone-status-03.txt> <draft-ietf-dnsext-zone-status-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 31 skipping to change at line 31
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org. namedroppers@ops.ietf.org.
This draft expires on March, 19, 2001. This draft expires on July 3, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999, 2000). All rights reserved. Copyright (C) The Internet Society (1999-2001). All rights reserved.
Abstract Abstract
The definition of a secured zone is presented, clarifying and updating 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 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 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 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 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 (or not used). To further simplify the determination of a zone's
status, "experimentally secure" status is deprecated. status, "experimentally secure" status is deprecated.
skipping to change at line 57 skipping to change at line 57
1 Introduction 1 Introduction
Whether a DNS zone is "secured" or not is a question asked in at least Whether a DNS zone is "secured" or not is a question asked in at least
four contexts. A zone administrator asks the question when four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone. asks the question upon receipt of data belonging to the zone.
Expires March 19, 2001 [Page 1] Expires July 3, 2001 [Page 1]
1.1 When a Zone's Status is Important 1.1 When a Zone's Status is Important
A zone administrator needs to be able to determine what steps are 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 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 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 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 security. This document will define what makes a zone qualify as
secure. secure.
skipping to change at line 114 skipping to change at line 114
secured, along with its delegations. The dilemma here is that secured, along with its delegations. The dilemma here is that
subarea1 cannot get its zone keys properly signed as its parent zone, subarea1 cannot get its zone keys properly signed as its parent zone,
region1, is not secured. region1, is not secured.
The colloquial phrase describing the collection of contiguous secured The colloquial phrase describing the collection of contiguous secured
zones at or below subarea1.region1.test. is an "island of security." 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 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 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 key(s) for subarea1.region1.test., i.e., the root of the island of
Expires March 19, 2001 [Page 2] Expires July 3, 2001 [Page 2]
security. Other resolvers (not so configured) will recognize this security. Other resolvers (not so configured) will recognize this
island as unsecured. island as unsecured.
An island of security begins with one zone whose public key is An island of security begins with one zone whose public key is
pre-configured in resolvers. Within this island are subzones which pre-configured in resolvers. Within this island are subzones which
are also secured. The "bottom" of the island is defined by are also secured. The "bottom" of the island is defined by
delegations to unsecured zones. One island may also be on top of delegations to unsecured zones. One island may also be on top of
another - meaning that there is at least one unsecured zone between another - meaning that there is at least one unsecured zone between
the bottom of the upper island and the root of the lower secured the bottom of the upper island and the root of the lower secured
skipping to change at line 137 skipping to change at line 137
Although both subarea1.region1.test. and region2.test. have both been Although both subarea1.region1.test. and region2.test. have both been
properly brought to a secured state by the administering staff, only properly brought to a secured state by the administering staff, only
the latter of the two is actually "globally" secured - in the sense the latter of the two is actually "globally" secured - in the sense
that all DNSSEC resolvers can and will verify its data. The former, 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 subarea1, will be seen as secured by a subset of those resolvers, just
those appropriately configured. This document refers to such zones as those appropriately configured. This document refers to such zones as
being "locally" secured. being "locally" secured.
In RFC 2535, there is a provision for "certification authorities," In RFC 2535, there is a provision for "certification authorities,"
entities that will sign public keys for zones such as subarea1. There entities that will sign public keys for zones such as subarea1. There
is another draft, [SIGAUTH], that restricts this activity. Regardless is another draft, [RFC3008], that restricts this activity. Regardless
of the other draft, resolvers would still need proper configuration to of the other draft, resolvers would still need proper configuration to
be able to use the certification authority to verify the data for the be able to use the certification authority to verify the data for the
subarea1 island. subarea1 island.
1.2.1 Determing the closest security root 1.2.1 Determing the closest security root
Given a domain, in order to determine whether it is secure or not, the 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 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 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 most matching (in order from the root) right-most labels to the given
skipping to change at line 171 skipping to change at line 171
unsigned. However, if we descend from "testing..." and find keys unsigned. However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured. "domain...." then we can conclude that "sub..." is secured.
Note that this example assumes one-label deep zones, and assumes that Note that this example assumes one-label deep zones, and assumes that
we do not configure overlapping islands of security. To be clear, the we do not configure overlapping islands of security. To be clear, the
definition given should exclude "short.xy.test." from being a closest definition given should exclude "short.xy.test." from being a closest
security root for "short.xy." even though 2 labels match. security root for "short.xy." even though 2 labels match.
Overlapping islands of security introduce no conceptually interesting Overlapping islands of security introduce no conceptually interesting
Expires March 19, 2001 [Page 3] Expires July 3, 2001 [Page 3]
ideas and do not impact the protocol in anyway. However, protocol ideas and do not impact the protocol in anyway. However, protocol
implementers are advised to make sure their code is not thrown for a implementers are advised to make sure their code is not thrown for a
loop by overlaps. Overlaps are sure to be configuration problems as loop by overlaps. Overlaps are sure to be configuration problems as
islands of security grow to encompass larger regions of the name islands of security grow to encompass larger regions of the name
space. space.
1.3 Parent Statement of Child Security 1.3 Parent Statement of Child Security
In 1.1 of this document, there is the comment "the parent states that In 1.1 of this document, there is the comment "the parent states that
skipping to change at line 228 skipping to change at line 228
1.4 Impact on RFC 2535 1.4 Impact on RFC 2535
This document updates sections of RFC 2535. The definition of a 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 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 updated to eliminate the definition of experimental keys and
illustrate a way to still achieve the functionality they were designed 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 to provide. Section 3.1.3 is updated by the specifying the value of
the protocol octet in a zone key. the protocol octet in a zone key.
Expires March 19, 2001 [Page 4] Expires July 3, 2001 [Page 4]
1.5 "MUST" and other key words 1.5 "MUST" and other key words
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC 2119]. in this document are to be interpreted as described in [RFC 2119].
Currently, only "MUST" is used in this document. Currently, only "MUST" is used in this document.
2 Status of a Zone 2 Status of a Zone
In this section, rules governing a zone's DNSSEC status are presented. In this section, rules governing a zone's DNSSEC status are presented.
skipping to change at line 285 skipping to change at line 285
2.c Off-tree Validation - Any authorization model that permits domain 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 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. zone keys that will enable a resolver to trust the keys.
2.1 Globally Secured 2.1 Globally Secured
A globally secured zone, in a nutshell, is a zone that uses only A globally secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies mandatory to implement algorithms (RFC 2535, section 3.2) and relies
Expires March 19, 2001 [Page 5] Expires July 3, 2001 [Page 5]
on a key certification chain that parallels the delegation tree on a key certification chain that parallels the delegation tree
(on-tree validation). Globally secured zones are defined by the (on-tree validation). Globally secured zones are defined by the
following rules. following rules.
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least 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 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
the set. the set.
2.1.b. The zone's apex KEY RR set MUST be signed by a private key 2.1.b. The zone's apex KEY RR set MUST be signed by a private key
skipping to change at line 340 skipping to change at line 340
and/or the verification of the zone keys in use may rely on a and/or the verification of the zone keys in use may rely on a
verification chain that is not parallel to the delegation tree verification chain that is not parallel to the delegation tree
(off-tree validation). (off-tree validation).
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 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. 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 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. one of the following two subclauses MUST hold true.
Expires March 19, 2001 [Page 6] Expires July 3, 2001 [Page 6]
2.2.b.1 The private key's public companion MUST be pre-configured in 2.2.b.1 The private key's public companion MUST be pre-configured in
all the resolvers of interest. all the resolvers of interest.
2.2.b.2 The private key's public component MUST be a zone signing KEY 2.2.b.2 The private key's public component MUST be a zone signing KEY
RR (2.a) authorized to provide validation of the zone's apex KEY RR RR (2.a) authorized to provide validation of the zone's apex KEY RR
set, as recognized by resolvers of interest. set, as recognized by resolvers of interest.
The previous sentence is trying to convey the notion of using a The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain name trusted third party to provide validation of keys. If the domain name
skipping to change at line 397 skipping to change at line 397
3 Experimental Status 3 Experimental Status
The purpose of an experimentally secured zone is to facilitate the The purpose of an experimentally secured zone is to facilitate the
migration from an unsecured zone to a secured zone. This distinction migration from an unsecured zone to a secured zone. This distinction
is dropped. is dropped.
The objective of facilitating the migration can be achieved without a The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status. Experimentally special designation of an experimentally secure status. Experimentally
Expires March 19, 2001 [Page 7] Expires July 3, 2001 [Page 7]
secured is a special case of globally secured. A zone administrator secured is a special case of globally secured. A zone administrator
can achieve this by publishing a zone with signatures and configuring can achieve this by publishing a zone with signatures and configuring
a set of test resolvers with the corresponding public keys. Even if 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 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 signature, the resolvers will need some pre-configuration to know to
process the signatures. This allows a zone to be secured with in the 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 sphere of the experiment, yet still be registered as unsecured in the
general Internet. general Internet.
skipping to change at line 453 skipping to change at line 453
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997 Requirement Levels," RFC 2119, March 1997
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997. Updates in the Domain Name System," RFC 2136, April 1997.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999. 2535, March 1999.
Expires March 19, 2001 [Page 8] Expires July 3, 2001 [Page 8]
[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple [RFC3007] B. Wellington, "Simple Secure Domain Name System (DNS)
Secure Domain Name System (DNS) Dynamic Update," version 00, February Dynamic Update," November, 2000.
2000.
[SIGAUTH] B. Wellington, draft-ietf-dnsext-signing-auth-01.txt [RFC3008] B. Wellington, "Domain Name System Security (DNSSEC)
Signing Authority", November, 2000.
10 Author Information 10 Author Information
Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443 Edward Lewis
259 2352 <lewis@tislabs.com> NAI Labs
3060 Washington Road Glenwood
MD 21738
+1 443 259 2352
<lewis@tislabs.com>
11 Full Copyright Statement 11 Full Copyright Statement
Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of developing
skipping to change at line 493 skipping to change at line 497
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires March 19, 2001 [Page 9] Expires July 3, 2001 [Page 9]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/