From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4986.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc4986.txt (limited to 'doc/rfc/rfc4986.txt') diff --git a/doc/rfc/rfc4986.txt b/doc/rfc/rfc4986.txt new file mode 100644 index 0000000..a710b48 --- /dev/null +++ b/doc/rfc/rfc4986.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group H. Eland +Request for Comments: 4986 Afilias Limited +Category: Informational R. Mundy + SPARTA, Inc. + S. Crocker + Shinkuro Inc. + S. Krishnaswamy + SPARTA, Inc. + August 2007 + + + Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +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. + + + + + + + + + + + + + + + + + + + + + +Eland, et al. Informational [Page 1] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.2. No Known 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eland, et al. Informational [Page 2] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +1. Introduction + + The Domain Name System Security Extensions (DNSSEC), as described in + [2], [3], and [4], define new records and protocol modifications to + DNS that permit security-aware resolvers to validate DNS Resource + Records (RRs) from one or more Trust Anchors held by such 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 Anchors 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 + updating and managing Trust Anchors. This document provides a list + of requirements that can be used to measure the effectiveness of any + proposed automated Trust Anchor rollover mechanism in a consistent + manner. + +2. 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 RECOMMENDED language. It is + understood that a tradeoff may need to be made between requirements + that both contain RFC 2119 language. + +3. Background + + DNS resolvers need to have one or more starting points to use in + obtaining DNS answers. The starting points for stub resolvers are + normally the IP addresses 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 resolver trust one or more + + + +Eland, et al. Informational [Page 3] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + + DNSKEY RRs or DS RRs 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 operator 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 operator that + created and/or published these RRs 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, which will be used as Trust Anchors 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 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 RRs and that they are able to + determine when RRs 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 and/or DS RRs change so that operators of security-aware + resolvers can manually change the Trust Anchors at the appropriate + time. This manual 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: + + 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 is associated with precisely one point in the + DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY be + associated with each DNS zone and MAY be held by any number of + security-aware resolvers. Security-aware resolvers MAY have Trust + Anchors from multiple DNS zones. Those responsible for the + + + +Eland, et al. Informational [Page 4] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + + operation of security-aware resolvers are responsible for + determining the set of RRs that will be used as Trust Anchors by + that resolver. + + Initial Trust Relationship: Operators of security-aware resolvers + must ensure that they initially obtain any Trust Anchors in a + trustworthy manner. For example, the correctness of the Root Zone + DNSKEY RR(s) could be verified by comparing what the operator + believes to be the Root Trust Anchor(s) 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 and/or DS RRs before designating them Trust + Anchors. This might be accomplished through a combination of + technical, procedural, and contractual relationships, or use other + existing trust relationships outside the current DNS protocol. + + Trust Anchor Distribution: The method or methods used to convey the + DNSKEY and/or DS RR(s) between the signed zone operator and the + security-aware resolver operator. 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 RRs to maintain the Initial Trust Relationship required to + designate those RRs as Trust Anchors. + + 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 the 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 Anchors 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. 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 the security-aware resolver the exact RR(s) that + have been revoked or removed so the proper Trust Anchor or Trust + Anchors are removed. + + + + + + + +Eland, et al. Informational [Page 5] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + + Trust Anchor Rollover: The method or methods necessary for the + secure replacement of one or multiple Trust Anchors held by + security-aware resolvers. Trust Anchor Rollover should be + considered a subset of Trust Anchor Maintenance. + + Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a + DNSSEC signed zone has issued a new DNSKEY and/or DS RR(s) as a + part of an operational routine. + + Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a + signed zone has issued a new DNSKEY 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 usage. The probable largest number of + instances of security-aware resolvers needing to rollover a Trust + Anchor will be those that use the public key(s) for the Root Zone as + Trust Anchor(s). This number could be extremely large 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; in most cases it will be less than 20 but it + may even be as high as one thousand. + +5.2. No Known Intellectual Property Encumbrance + + Because trust anchor rollover is likely to be "mandatory-to- + implement", section 8 of [5] requires that the technical 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: worldwide, + irrevocable, perpetual right to use, without fee, in commerce or + otherwise, where "use" includes descriptions of algorithms, + + + +Eland, et al. Informational [Page 6] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + + 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 and/or DS RR(s) can + no longer be updated given the current set of actual trust-anchors. + In these cases, the resolver should inform the operator of the need + to reestablish initial trust. + +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 + implementation to support both automated and manual Trust Anchor + Maintenance operations. 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. + + + + + + + +Eland, et al. Informational [Page 7] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +5.8. Timeliness + + Resource Records used as Trust Anchors SHOULD be able to be + distributed to security-aware resolvers in a timely manner. + + Security-aware resolvers need to acquire new and remove revoked + DNSKEY and/or DS RRs 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 RRs. + +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 and that 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 + 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 the existing trust relation + does not degrade by performing the rollover. + + + + + +Eland, et al. Informational [Page 8] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +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. Acknowledgements + + This document reflects the majority opinion of the DNSEXT Working + Group members on the topic of requirements related to DNSSEC trust + anchor rollover. The contributions made by various members of the + working group to improve the readability and style of this document + are graciously acknowledged. + +8. 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. + + [5] Bradner, S., "Intellectual Property Rights in IETF Technology", + RFC 3979, March 2005. + + + + + + + + + + + + + + + + + +Eland, et al. Informational [Page 9] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +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. + 7110 Samuel Morse Dr. + Columbia, MD 21046 + USA + + EMail: mundy@sparta.com + + + Steve Crocker + Shinkuro Inc. + 1025 Vermont Ave, Suite 820 + Washington, DC 20005 + USA + + EMail: steve@shinkuro.com + + + Suresh Krishnaswamy + SPARTA, Inc. + 7110 Samuel Morse Dr. + Columbia, MD 21046 + USA + + EMail: suresh@sparta.com + + + + + + + + + + + + + + +Eland, et al. Informational [Page 10] + +RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + + + + + + + + + + + + +Eland, et al. Informational [Page 11] + -- cgit v1.2.3