Network Working Group H. Eland
Internet-Draft Afilias Limited
Expires: November 7, 2006 R. Mundy
SPARTA, Inc.
S. Crocker
Shinkuro Inc.
S. Krishnaswamy
SPARTA, Inc.
May 6, 2006
Requirements related to DNSSEC Trust Anchor Rollover
draft-ietf-dnsext-rollover-requirements-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Every DNS security-aware resolver must have at least one Trust Anchor
to use as the basis for validating responses from DNS signed zones.
For various reasons, most DNS security-aware resolvers are expected
Eland, et al. Expires November 7, 2006 [Page 1]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
to have several Trust Anchors. For some operations, manual
monitoring and updating of Trust Anchors may be feasible but many
operations will require automated methods for updating Trust Anchors
in their security-aware resolvers. This document identifies the
requirements that must be met by an automated DNS Trust Anchor
rollover solution for security-aware DNS resolvers.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. No Intellectual Property Encumbrance . . . . . . . . . . . 6
5.3. General Applicability . . . . . . . . . . . . . . . . . . 7
5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7
5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
5.6. Manual Operations Permitted . . . . . . . . . . . . . . . 7
5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . 7
5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 7
5.9. High Availability . . . . . . . . . . . . . . . . . . . . 8
5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
5.11. Support for Trust Anchor Maintenance Operations . . . . . 8
5.12. Recovery From Compromise . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Eland, et al. Expires November 7, 2006 [Page 2]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
The use of the RFC-2119 words in this version of document is
preliminary in nature and feedback is requested as to the correct
word to use for each of the requirements.
2. Introduction
The Domain Name System Security Extensions (DNSSEC) as described in
[2] [3] and [4] defines new records and protocol modifications to DNS
that permit security-aware resolvers to validate DNS Resource Records
(RRs) from one or more Trust Anchor(s) held by security-aware
resolvers.
Security-aware resolvers will have to initially obtain their Trust
Anchors in a trustworthy manner to ensure the Trust Anchors are
correct and valid. There are a number of ways that this initial step
can be accomplished however details of this step are beyond the scope
of this document. Once an operator has obtained Trust Anchors,
initially entering the Trust Anchor(s) into their security-aware
resolvers will in many instances be a manual operation.
For some operational environments, manual management of Trust Anchors
might be a viable approach. However, many operational environments
will require a more automated specification-based method for up-
dating and managing Trust Anchors. Several mechanisms for automated
specification-based approaches have been proposed to the DNS
Extensions (dnsext) Working Group but each seems to be solving a
somewhat different group of requirements. As a result, the Working
Group determined that a requirements document needed to be developed
so that each of the proposed mechanisms can be measured against a
consistent set of requirements. This document provides these Trust
Anchor Rollover requirements.
3. Background
DNS resolvers need to have one or more starting points to use in
obtaining DNS answers. The starting points for stub resolvers is
normally the IP address for one or more recursive resolvers. The
starting points for recursive resolvers are normally IP addresses for
DNS root name servers. Similarly, security-aware resolvers must have
one or more starting points to use for building the authenticated
Eland, et al. Expires November 7, 2006 [Page 3]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
chain to validate a signed DNS response. Instead of IP addresses,
DNSSEC requires that each operator of a security-aware resolver trust
one or more DNSKEY RR or a DS RR hash of a DNSKEY RR as their
starting point. Each of these starting points is called a Trusted
Anchor.
It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors
when they are created by the signed zone operation nor are they Trust
Anchors because the records are published in the signed zone. A
DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a
security-aware resolver determines that the public key or hash will
be used as a Trust Anchor. Thus the signed zone operation that
created and/or published a DNSKEY RR (or DS RR) will likely not know
if any of the DNSKEY RRs or DS RRs associated with their zone are
being used as Trust Anchors by security aware resolvers. The obvious
exceptions are the DNSKEY RRs for the root zone that will be used by
many security-aware resolvers. For various reasons, DNSKEY RRs or DS
RRs from zones other than root can be used by operators of security-
aware resolvers as Trust Anchors. It follows that responsibility
lies with the operator of the security-aware resolver to ensure that
the DNSKEY RRs and/or DS RRs they have chosen to use as Trust Anchors
are valid at the time they are used by the security-aware resolver as
the starting point for building the authentication chain to validate
a signed DNS response.
When operators of security-aware resolvers choose one or more Trust
Anchors, they must also determine the method(s) they will use to
ensure that they are using valid RR(s) and that they are able to
determine when RR(s) being used as Trust Anchors should be replaced
or removed. Early adopters of DNS signed zones have published
information about the processes and methods they will use when their
DNSKEY RRs and/or DS RR(s) change so that security-aware resolvers
can change their Trust Anchors at the appropriate time. This
approach will not scale and, therefore, drives the need for an
automated specification-based approach for rollover of Trust Anchors
for security-aware resolvers.
4. Definitions
This document uses the definitions contained in RFC-4033 section 2
plus the following additional definitions (Alphabetic by first word):
Emergency Trust Anchor Revocation: The operator of a signed zone
wishes to indicate that the current DNSKEY and/or DS RR(s) are no
longer valid as part of an exceptional event.
Eland, et al. Expires November 7, 2006 [Page 4]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
Emergency Trust Anchor Rollover: The operator of a signed zone has
issued new DNSKEY RR(s) and/or DS RR(s) as part of an exceptional
event.
Initial Trust Relationship: An operator of a security-aware resolver
must ensure that they initially obtain any Trust Anchors in a
trustworthy manner. For example, the correctness of the root zone
DNSKEY RR could be verified by comparing what the operator
believes to be the root Trust Anchor with several 'well known'
sources such as the IANA web site, the DNS published root zone and
the publication of the public key in well known hard-copy forms.
For other Trust Anchors, the operator must ensure the accuracy and
validity of the DNSKEY RR or DS RR before designating them Trust
Anchor(s). This might be accomplished through a combination of
technical, procedural and contract relationships or use other
existing trust relationships outside of the current DNS protocol.
Normal or Scheduled Trust Anchor Rollover: The operator of a DNSSEC
signed zone has issued new DNSKEY RR(s) and/or DS RR(s) as a part
of an operational routine and may revoke existing DNSKEY RR(s)
and/or DS RR(s) at some point in time.
Trust Anchor: (in addition to RFC-4033 definition) A DNSKEY RR or DS
RR hash of a DNSKEY RR is associated with precisely one point in
the DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY
may be associated with each DNS zone and MAY be held by any number
of security-aware resolvers. Security-aware resolvers MAY have
Trust Anchor(s) from multiple DNS zones. Those responsible for
operation of security-aware resolvers are responsible for
determining which RRs will be used for Trust Anchors by that
resolver.
Trust Anchor Distribution: The method or methods used to convey the
DNSKEY RR(s) or DS RR(s) between the signed zone operation and the
security-aware resolver operation. The method or methods MUST be
deemed sufficiently trustworthy by the operator of the security-
aware resolver to ensure source authenticity and integrity of the
new RR(s) to maintain the Initial Trust Relationship required to
designate those RR(s) as Trust Anchor(s).
Trust Anchor Maintenance: Any change in a validating security-aware
resolver to add a new Trust Anchor, delete an existing Trust
Anchor, or replace an existing Trust Anchor with another. This
change might be accomplished manually or in some automated manner.
Those responsible for operation of the security-aware resolver are
responsible for establishing policies and procedures to ensure
that a sufficient Initial Trust Relationship is in place before
Eland, et al. Expires November 7, 2006 [Page 5]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
adding Trust Anchor(s) for a particular DNS zone to their
security-aware resolver configuration.
Trust Anchor Revocation and Removal: The invalidation of a particular
Trust Anchor that results when the operator of the signed zone
revokes or removes a DNSKEY RR or DS RR that is being used as a
Trust Anchor by any security-aware resolver(s). It is possible
that an original issuer may invalidate more than one RR at one
point in time, therefore, it MUST be clear to both the issuer and
security-aware resolver operator the exact RR(s) that have been
revoked or removed so the proper Trust Anchor or Trust Anchors are
removed by the operators of the security-aware resolver.
Trust Anchor Rollover: The method or methods necessary for the secure
replacement of one or multiple Trust Anchor(s) held by security-
aware resolvers. Trust Anchor Rollover should be considered a
sub-set of Trust Anchor Maintenance.
5. Requirements
Following are the requirements for DNSSEC automated specification-
based Trust Anchor Rollover:
5.1. Scalability
The automated Trust Anchor Rollover solution MUST be capable of
scaling to Internet-wide useage. The probable largest number of
instances of security-aware resolvers needing to rollover a Trust
Anchor will be for the root zone. This number could be extremely
large (possibly many millions) if a number of applications have
embedded security-aware resolvers.
The automated Trust Anchor Rollover solution MUST be able to support
Trust Anchors for multiple zones and multiple Trust Anchors for each
DNS zone. The number of Trust Anchors that might be configured into
any one validating security-aware resolver is not known with
certainty at this time but in most cases will be less than 20 and
never expected to be as high as one thousand.
5.2. No Intellectual Property Encumbrance
Because trust anchor rollover is considered "mandatory-to-implement",
section 8 of [RFC3979] requires that the technology solution chosen
must be unencumbered or must be available under royalty-free terms.
For this purpose, "royalty-free" is defined as follows: world wide,
perpetual right to use, without fee, in commerce or otherwise, where
Eland, et al. Expires November 7, 2006 [Page 6]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
"use" includes descriptions of algorithms, distribution and/or use of
hardware implementations, distribution and/or use of software systems
in source and/or binary form, in all DNS or DNSSEC applications
including registry, registrar, domain name service including
authority, recursion, caching, forwarding, stub resolver, or similar.
In summary, no implementor, distributor, or operator of the
technology chosen for trust anchor management shall be expected or
required to pay any fee to any IPR holder for the right to implement,
distribute, or operate a system which includes the chosen mandatory-
to-implement solution.
5.3. General Applicability
The solution MUST provide the capability to maintain Trust Anchors in
security-aware resolvers for any and all DNS zones. The same
solution SHALL be able to be used to maintain Trust Anchors for the
root zone and other zones.
5.4. Support Private Networks
The solution MUST support private networks with their own DNS
hierarchy.
5.5. Detection of Stale Trust Anchors
The Trust Anchor Rollover solution MUST allow a validating security-
aware resolver to be able to detect if the DNSKEY or DS RR(s) being
used as its Trust Anchors are no longer valid.
5.6. Manual Operations Permitted
The solution MUST NOT prohibit the use of manual rollover and
maintenance activities in operations that choose to use manual
methods. A security-aware resolver MAY choose to use manual or
automated rollover operations or both but MUST provide at least one
method for operators to maintain Trust Anchors.
5.7. Planned and Unplanned Rollovers
The solution MUST permit both planned (pre-scheduled) and unplanned
(non-scheduled) rollover of Trust Anchors. Support for providing an
Initial Trust Relationship is OPTIONAL.
5.8. Timeliness
Resource Records used as Trust Anchors SHOULD be able to be
distributed to security-aware resolvers in a timely manner.
Eland, et al. Expires November 7, 2006 [Page 7]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
Operators of security-aware resolvers need to acquire new and remove
revoked DNSKEY or DS RR(s) that are being used as Trust Anchors for a
zone such that no old RR is used as a Trust Anchor for long after the
zone issues new or revokes existing RR(s).
5.9. High Availability
Information about the issuer's view of the state of Resource Records
used as Trust Anchors SHOULD be available in a trustworthy manner at
all times to security-aware resolvers. Information about Resource
Records that an issuer has invalidated which are known to be used as
Trust Anchors should be available in a trustworthy manner for a
reasonable length of time.
5.10. New RR Types
If a Trust Anchor Rollover solution requires new RR types, this
should be considered in the evaluation of solutions. The Working
Group needs to determine whether requiring a new RR type for a
Rollover solution is a good thing or a bad thing or something else.
5.11. Support for Trust Anchor Maintenance Operations
The Trust Anchor Rollover solution MUST support operations that allow
a validating security-aware resolver to add a new Trust Anchor,
delete an existing Trust Anchor, or replace an existing Trust Anchor
with another.
5.12. Recovery From Compromise
The Trust Anchor Rollover solution MUST allow a security aware
resolver to be able to recover from the compromise of any of its
configured Trust Anchors for a zone so long as at least one other
key, which is known to have not been compromised, is configured as a
Trust Anchor for that same zone at that resolver.
6. Security Considerations
This document defines overall requirements for an automated
specification-based Trust Anchor Rollover solution for security-aware
resolvers but specifically does not define the security mechanisms
needed to meet these requirements.
7. IANA Considerations
This document has no actions for the IANA.
Eland, et al. Expires November 7, 2006 [Page 8]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
8. Acknowledgements
None at this point.
9. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
Eland, et al. Expires November 7, 2006 [Page 9]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
Authors' Addresses
Howard Eland
Afilias Limited
300 Welsh Road
Building 3, Suite 105
Horsham, PA 19044
USA
Email: heland@afilias.info
Russ Mundy
SPARTA, Inc.
7075 Samuel Morse Dr.
Columbia, MD 21046
USA
Email: mundy@sparta.com
Steve Crocker
Shinkuro Inc.
1025 Vermont Ave
Washington, DC 20005
USA
Email: steve@shinkuro.com
Suresh Krishnaswamy
SPARTA, Inc.
7075 Samuel Morse Dr.
Columbia, MD 21046
USA
Email: suresh@sparta.com
Eland, et al. Expires November 7, 2006 [Page 10]
Internet-Draft DNSSEC Trust Anchor Rollover Requirements May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eland, et al. Expires November 7, 2006 [Page 11]
