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

Versions: 00 01 02 03 04 RFC 4986

Network Working Group                                           H. Eland
Internet-Draft                                           Afilias Limited
Intended status: Informational                                  R. Mundy
Expires: March 5, 2007                                      SPARTA, Inc.
                                                              S. Crocker
                                                           Shinkuro Inc.
                                                         S. Krishnaswamy
                                                            SPARTA, Inc.
                                                               Sept 2006


          Requirements related to DNSSEC Trust Anchor Rollover
               draft-ietf-dnsext-rollover-requirements-03

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 March 5, 2007.

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 March 5, 2007                 [Page 1]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 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 . . . . . . . . . . .  7
     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  . . . . . . . . . . . . .  8
     5.8.  Timeliness . . . . . . . . . . . . . . . . . . . . . . . .  8
     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
     5.13. Non-degrading Trust  . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

















Eland, et al.             Expires March 5, 2007                 [Page 2]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 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 RFC-2119 words in the requirements is intended to
   unambiguously describe a requirement.  If a tradeoff is to be made
   between conflicting requirements when choosing a solution the
   requirement with MUST language will have higher preference than
   requirements with SHOULD, MAY, or RECOMMEND language.  It is
   understood that a tradeoff may need to be made between requirements
   that both contain RFC2119 language.


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



Eland, et al.             Expires March 5, 2007                 [Page 3]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006


   normally the IP address for one or more recursive name servers.  The
   starting points for recursive name servers 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
   Trust 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) may 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):





Eland, et al.             Expires March 5, 2007                 [Page 4]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006



   Trust Anchor:  From RFC-4033, "A configured DNSKEY RR or DS RR hash
      of a DNSKEY RR.  A validating security-aware resolver uses this
      public key or hash as a starting point for building the
      authentication chain to a signed DNS response."  Additionally, 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.

   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.

   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.







Eland, et al.             Expires March 5, 2007                 [Page 5]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006



   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 a zone administrator may invalidate more than one RR
      at one point in time, therefore, it MUST be clear to both the zone
      administrator 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.

   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.

   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.

   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.


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



Eland, et al.             Expires March 5, 2007                 [Page 6]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006


   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 not be known to be encumbered or must be available under
   royalty-free terms.

   For this purpose, "royalty-free" is defined as follows: world wide,
   irrevocable, perpetual right to use, without fee, in commerce or
   otherwise, where "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.

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) can no
   longer be updated given the current set of actual trust-anchors, so
   that initial trust may be re-established.

5.6.  Manual Operations Permitted

   The operator of a security-aware resolver may choose manual or
   automated rollover, but the rollover protocol must allow the



Eland, et al.             Expires March 5, 2007                 [Page 7]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006


   implementation to support both automated and manual rollover.
   Implementation of the rollover protocol is likely to be mandatory,
   but that's out of scope for this requirements document.

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.

   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 zone administrator'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 a zone administrator 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 or protocol
   modifications, this should be considered in the evaluation of
   solutions.  The Working Group needs to determine whether such changes
   are 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



Eland, et al.             Expires March 5, 2007                 [Page 8]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006


   key, which is known to have not been compromised, is configured as a
   Trust Anchor for that same zone at that resolver.

5.13.  Non-degrading Trust

   The Trust Anchor Rollover solution MUST provide sufficient means to
   ensure authenticity and integrity so that by the existing trust
   relation does not degrade by performing the rollover.


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.


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 March 5, 2007                 [Page 9]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 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 March 5, 2007                [Page 10]

Internet-Draft  DNSSEC Trust Anchor Rollover Requirements      Sept 2006


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

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Eland, et al.             Expires March 5, 2007                [Page 11]


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