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.
Datatracker
Report a datatracker bug
draft-ietf-dnsext-rollover-requirements-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4986.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |