draft-ietf-dnsext-zone-status-03.txt

bind-3.2.

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 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' 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

Expires March 19, 2001                                      [Page  5]
Internet Draft                                     September 19, 2000

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).

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.



Expires March 19, 2001                                      [Page  6]
Internet Draft                                     September 19, 2000

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 component 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.

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

Expires March 19, 2001                                      [Page  7]
Internet Draft                                     September 19, 2000

secured is a special case of globally 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/ICANN Considerations

This document does not request any action from an assigned number
authority nor recommends any actions.

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] P. Mockapetris, "Domain Names - Concepts and Facilities,"
RFC 1034, November 1987.

[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, November 1987.

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997

[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997.

[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999.


Expires March 19, 2001                                      [Page  8]
Internet Draft                                     September 19, 2000

[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
Secure Domain Name System (DNS) Dynamic Update," version 00, February
2000.

[SIGAUTH] B. Wellington, draft-ietf-dnsext-signing-auth-01.txt

10 Author Information

Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
259 2352 <[e-mail]>

11 Full Copyright Statement

Copyright (C) The Internet Society (1999, 2000).  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."


















Expires March 19, 2001                                      [Page  9]