[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 4986

                   dnsext-rollover-requirements        February 2006



   Network Working Group
   Internet Draft                                            S. Crocker
   Expires: August 2006                                  Shinkuro, Inc.
                                                               H. Eland
                                                        Afilias Limited
                                                               R. Mundy
                                                           SPARTA, Inc.
                                                          February 2006

           Requirements related to DNSSEC Trust Anchor Rollover
              draft-ietf-dnsext-rollover-requirements-00.txt


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.


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 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.
                     dnsext-rollover-requirements        February 2006







Table of Contents

   1. Terminology....................................................2
   2. Introduction...................................................2
   3. Background.....................................................3
   4. Definitions....................................................4
   5. Requirements...................................................6
      5.1 Scalability................................................6
      5.2 No Intellectual Property Encumbrance.......................6
      5.3 General Applicability......................................6
      5.4 Support Private Networks...................................6
      5.5 Support Reconnecting Systems...............................7
      5.6 Manual Operations Permitted................................7
      5.7 Planned and Unplanned Rollovers............................7
      5.8 Timeliness.................................................7
      5.9 High Availability..........................................7
      5.10 New RR Types..............................................7
   6. Security Considerations........................................7
   7. IANA Considerations............................................8
   8. References.....................................................8
      8.1 Normative References.......................................8
      8.2 Informative References.....................................8
   9. Acknowledgments................................................8
   10. Author's Addresses............................................8
   11. Intellectual Property Statement...............................9
   12. Disclaimer of Validity........................................9
   13. Copyright Statement...........................................9


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
   [RFC2119].

   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
                     dnsext-rollover-requirements        February 2006


   The Domain Name System Security Extensions (DNSSEC) as described in
   RFC4033, RFC4034 and RFC4035 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 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
                     dnsext-rollover-requirements        February 2006


   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 Rollover:
   The operator of a signed zone has issued new DNSKEY RR(s) and/or DS
   RR(s) as part of an exceptional event. Any security-aware resolver
   using those RR(s) as Trust Anchor(s) must quickly remove them from
   use by the resolver.

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.
                     dnsext-rollover-requirements        February 2006



Normal or Scheduled Trust Anchor Rollover:
   The operator of 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.
   Operators of security-aware resolvers using RR(s) from that zone as
   Trust Anchors need to acquire new and remove revoked Trust Anchors
   at roughly the same time as the signed zone issues or revokes RR(s).

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 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.
                     dnsext-rollover-requirements        February 2006



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

   The solution SHOULD not have any intellectual property encumbrance
   on either the technologies used by the solution nor implementations
   of the solution. The technology used by the solution SHOULD permit
   implementers to provide complete, running implementations that have
   Berkley open source type of licensing.


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.
                     dnsext-rollover-requirements        February 2006


5.5 Support Reconnecting Systems

   The solution MUST support rollover for security-aware resolvers that
   have been disconnected from the network for up to twelve months.


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.


5.9 High Availability

   Information about the issuer's view of that 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. [Editor's note: should 'reasonable
   length of time' be more specific? If so, what should it be?]


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.


6. Security Considerations
                     dnsext-rollover-requirements        February 2006


   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.


8. References

8.1 Normative References


   [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels,
             S Bradner, March 1997

   [RFC4033] DNS Security Introduction and Requirements, R. Arends,
             et.al., March 2005

   [RFC4034] Resource Records for the DNS Security Extensions, R.
             Arends, et.al., March 2005

   [RFC4035] Protocol Modifications for the DNS Security Extensions, R.
             Arends, et.al., March 2005


8.2 Informative References

   None at this point.


9. Acknowledgments

   None at this point.


10. Author's Addresses

   Steve Crocker
   1025 Vermont Ave
   Washington, DC 20005, USA
   Email: steve@shinkuro.com

   Howard Eland
   Afilias
   300 Welsh Road
                     dnsext-rollover-requirements        February 2006


   Building 3, Suite 105
   Horsham, PA 19044, USA
   Email: heland@afilias.info

   Russ Mundy
   7075 Samuel Morse Dr.
   Columbia, MD 21046, USA
   Email: mundy@sparta.com


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


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


13. Copyright Statement
                     dnsext-rollover-requirements        February 2006


   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.


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/