idnits 2.17.1 draft-ietf-dnsext-rollover-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2006) is 6358 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3979 (ref. '5') (Obsoleted by RFC 8179) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Eland 3 Internet-Draft Afilias Limited 4 Intended status: Informational R. Mundy 5 Expires: May 31, 2007 SPARTA, Inc. 6 S. Crocker 7 Shinkuro Inc. 8 S. Krishnaswamy 9 SPARTA, Inc. 10 November 27, 2006 12 Requirements related to DNSSEC Trust Anchor Rollover 13 draft-ietf-dnsext-rollover-requirements-04 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 31, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Every DNS security-aware resolver must have at least one Trust Anchor 47 to use as the basis for validating responses from DNS signed zones. 48 For various reasons, most DNS security-aware resolvers are expected 49 to have several Trust Anchors. For some operations, manual 50 monitoring and updating of Trust Anchors may be feasible but many 51 operations will require automated methods for updating Trust Anchors 52 in their security-aware resolvers. This document identifies the 53 requirements that must be met by an automated DNS Trust Anchor 54 rollover solution for security-aware DNS resolvers. 56 Table of Contents 58 1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2 No Intellectual Property Encumbrance . . . . . . . . . . . 7 65 5.3 General Applicability . . . . . . . . . . . . . . . . . . . 7 66 5.4 Support Private Networks . . . . . . . . . . . . . . . . . 7 67 5.5 Detection of Stale Trust Anchors . . . . . . . . . . . . . 7 68 5.6 Manual Operations Permitted . . . . . . . . . . . . . . . . 7 69 5.7 Planned and Unplanned Rollovers . . . . . . . . . . . . . . 8 70 5.8 Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.9 High Availability . . . . . . . . . . . . . . . . . . . . . 8 72 5.10 New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.11 Support for Trust Anchor Maintenance Operations . . . . . . 8 74 5.12 Recovery From Compromise . . . . . . . . . . . . . . . . . 8 75 5.13 Non-degrading Trust . . . . . . . . . . . . . . . . . . . . 9 76 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 77 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 78 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 81 Intellectual Property and Copyright Statements . . . . . . . . . . 11 83 1 Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [1]. 89 The use of RFC-2119 words in the requirements is intended to 90 unambiguously describe a requirement. If a tradeoff is to be made 91 between conflicting requirements when choosing a solution the 92 requirement with MUST language will have higher preference than 93 requirements with SHOULD, MAY, or RECOMMEND language. It is 94 understood that a tradeoff may need to be made between requirements 95 that both contain RFC2119 language. 97 2 Introduction 99 The Domain Name System Security Extensions (DNSSEC) as described in 100 [2] [3] and [4] defines new records and protocol modifications to DNS 101 that permit security-aware resolvers to validate DNS Resource Records 102 (RRs) from one or more Trust Anchors held by security-aware 103 resolvers. 105 Security-aware resolvers will have to initially obtain their Trust 106 Anchors in a trustworthy manner to ensure the Trust Anchors are 107 correct and valid. There are a number of ways that this initial step 108 can be accomplished however details of this step are beyond the scope 109 of this document. Once an operator has obtained Trust Anchors, 110 initially entering the Trust Anchors into their security-aware 111 resolvers will in many instances be a manual operation. 113 For some operational environments, manual management of Trust Anchors 114 might be a viable approach. However, many operational environments 115 will require a more automated specification-based method for up- 116 dating and managing Trust Anchors. Several mechanisms for automated 117 specification-based approaches have been proposed to the DNS 118 Extensions (dnsext) Working Group but each seems to be solving a 119 somewhat different group of requirements. As a result, the Working 120 Group determined that a requirements document needed to be developed 121 so that each of the proposed mechanisms can be measured against a 122 consistent set of requirements. This document provides these Trust 123 Anchor Rollover requirements. 125 3 Background 127 DNS resolvers need to have one or more starting points to use in 128 obtaining DNS answers. The starting points for stub resolvers are 129 normally the IP addresses for one or more recursive name servers. 130 The starting points for recursive name servers are normally IP 131 addresses for DNS root name servers. Similarly, security-aware 132 resolvers must have one or more starting points to use for building 133 the authenticated chain to validate a signed DNS response. Instead 134 of IP addresses, DNSSEC requires that each resolver trust one or more 135 DNSKEY RR or DS RR as their starting point. Each of these starting 136 points is called a Trust Anchor. 138 It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors 139 when they are created by the signed zone operation nor are they Trust 140 Anchors because the records are published in the signed zone. A 141 DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a 142 security-aware resolver determines that the public key or hash will 143 be used as a Trust Anchor. Thus the signed zone operator that 144 created and/or published these RRs may not know if any of the DNSKEY 145 RRs or DS RRs associated with their zone are being used as Trust 146 Anchors by security aware resolvers. The obvious exceptions are the 147 DNSKEY RR(s) for the root zone that will be used by many security- 148 aware resolvers. For various reasons, DNSKEY RRs or DS RRs from 149 zones other than root can be used by operators of security-aware 150 resolvers as Trust Anchors. It follows that responsibility lies with 151 the operator of the security-aware resolver to ensure that the DNSKEY 152 and/or DS RRs they have chosen to use as Trust Anchors are valid at 153 the time they are used by the security-aware resolver as the starting 154 point for building the authentication chain to validate a signed DNS 155 response. 157 When operators of security-aware resolvers choose one or more Trust 158 Anchors, they must also determine the method(s) they will use to 159 ensure that they are using valid RRs and that they are able to 160 determine when RRs being used as Trust Anchors should be replaced or 161 removed. Early adopters of DNS signed zones have published 162 information about the processes and methods they will use when their 163 DNSKEY and/or DS RRs change so that operators of security-aware 164 resolvers can change the Trust Anchors at the appropriate time. This 165 approach will not scale and, therefore, drives the need for an 166 automated specification-based approach for rollover of Trust Anchors 167 for security-aware resolvers. 169 4 Definitions 171 This document uses the definitions contained in RFC-4033 section 2 172 plus the following additional definitions: 174 Trust Anchor: From RFC-4033, "A configured DNSKEY RR or DS RR hash 175 of a DNSKEY RR. A validating security-aware resolver uses this 176 public key or hash as a starting point for building the 177 authentication chain to a signed DNS response." Additionally, a 178 DNSKEY RR or DS RR is associated with precisely one point in the 179 DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY may 180 be associated with each DNS zone and MAY be held by any number of 181 security-aware resolvers. Security-aware resolvers MAY have Trust 182 Anchors from multiple DNS zones. Those responsible for operation 183 of security-aware resolvers are responsible for determining which 184 RRs will be used for Trust Anchors by that resolver. 186 Initial Trust Relationship: An operator of a security-aware resolver 187 must ensure that they initially obtain any Trust Anchors in a 188 trustworthy manner. For example, the correctness of the root zone 189 DNSKEY RR(s) could be verified by comparing what the operator 190 believes to be the root Trust Anchor(s) with several 'well known' 191 sources such as the IANA web site, the DNS published root zone and 192 the publication of the public key in well known hard-copy forms. 193 For other Trust Anchors, the operator must ensure the accuracy and 194 validity of the DNSKEY and/or DS RRs before designating them Trust 195 Anchors. This might be accomplished through a combination of 196 technical, procedural and contract relationships or use other 197 existing trust relationships outside of the current DNS protocol. 199 Trust Anchor Distribution: The method or methods used to convey the 200 DNSKEY and/or DS RR(s) between the signed zone operation and the 201 security-aware resolver operation. The method or methods MUST be 202 deemed sufficiently trustworthy by the operator of the security- 203 aware resolver to ensure source authenticity and integrity of the 204 new RRs to maintain the Initial Trust Relationship required to 205 designate those RRs as Trust Anchors. 207 Trust Anchor Maintenance: Any change in a validating security-aware 208 resolver to add a new Trust Anchor, delete an existing Trust 209 Anchor, or replace an existing Trust Anchor with another. This 210 change might be accomplished manually or in some automated manner. 211 Those responsible for operation of the security-aware resolver are 212 responsible for establishing policies and procedures to ensure 213 that a sufficient Initial Trust Relationship is in place before 214 adding Trust Anchors for a particular DNS zone to their security- 215 aware resolver configuration. 217 Trust Anchor Revocation and Removal: The invalidation of a 218 particular Trust Anchor that results when the operator of the 219 signed zone revokes or removes a DNSKEY RR or DS RR that is being 220 used as a Trust Anchor by any security-aware resolver. It is 221 possible that a zone administrator may invalidate more than one RR 222 at one point in time, therefore, it MUST be clear to both the zone 223 administrator and security-aware resolver the exact RR(s) that 224 have been revoked or removed so the proper Trust Anchor or Trust 225 Anchors are removed. 227 Trust Anchor Rollover: The method or methods necessary for the 228 secure replacement of one or multiple Trust Anchors held by 229 security-aware resolvers. Trust Anchor Rollover should be 230 considered a sub-set of Trust Anchor Maintenance. 232 Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a 233 DNSSEC signed zone has issued new DNSKEY and/or DS RR(s) as a part 234 of an operational routine. 236 Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a 237 signed zone has issued new DNSKEY and/or DS RR(s) as part of an 238 exceptional event. 240 Emergency Trust Anchor Revocation: The operator of a signed zone 241 wishes to indicate that the current DNSKEY and/or DS RR(s) are no 242 longer valid as part of an exceptional event. 244 5 Requirements 246 Following are the requirements for DNSSEC automated specification- 247 based Trust Anchor Rollover: 249 5.1 Scalability 251 The automated Trust Anchor Rollover solution MUST be capable of 252 scaling to Internet-wide useage. The probable largest number of 253 instances of security-aware resolvers needing to rollover a Trust 254 Anchor will be for the root zone. This number could be extremely 255 large (possibly many millions) if a number of applications have 256 embedded security-aware resolvers. 258 The automated Trust Anchor Rollover solution MUST be able to support 259 Trust Anchors for multiple zones and multiple Trust Anchors for each 260 DNS zone. The number of Trust Anchors that might be configured into 261 any one validating security-aware resolver is not known with 262 certainty at this time; in most cases it will be less than 20 but it 263 may even be as high as one thousand. 265 5.2 No Intellectual Property Encumbrance 267 Because trust anchor rollover is likely to be "mandatory-to- 268 implement", section 8 of [5] requires that the technology solution 269 chosen must not be known to be encumbered or must be available under 270 royalty-free terms. 272 For this purpose, "royalty-free" is defined as follows: world wide, 273 irrevocable, perpetual right to use, without fee, in commerce or 274 otherwise, where "use" includes descriptions of algorithms, 275 distribution and/or use of hardware implementations, distribution 276 and/or use of software systems in source and/or binary form, in all 277 DNS or DNSSEC applications including registry, registrar, domain name 278 service including authority, recursion, caching, forwarding, stub 279 resolver, or similar. 281 In summary, no implementor, distributor, or operator of the 282 technology chosen for trust anchor management shall be expected or 283 required to pay any fee to any IPR holder for the right to implement, 284 distribute, or operate a system which includes the chosen mandatory- 285 to-implement solution. 287 5.3 General Applicability 289 The solution MUST provide the capability to maintain Trust Anchors in 290 security-aware resolvers for any and all DNS zones. 292 5.4 Support Private Networks 294 The solution MUST support private networks with their own DNS 295 hierarchy. 297 5.5 Detection of Stale Trust Anchors 299 The Trust Anchor Rollover solution MUST allow a validating security- 300 aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can 301 no longer be updated given the current set of actual trust-anchors. 302 In these cases, the resolver should inform the operator of the need 303 to reestablish initial trust. 305 5.6 Manual Operations Permitted 307 The operator of a security-aware resolver may choose manual or 308 automated rollover, but the rollover protocol must allow the 309 implementation to support both automated and manual rollover. 310 Implementation of the rollover protocol is likely to be mandatory, 311 but that's out of scope for this requirements document. 313 5.7 Planned and Unplanned Rollovers 315 The solution MUST permit both planned (pre-scheduled) and unplanned 316 (non-scheduled) rollover of Trust Anchors. Support for providing an 317 Initial Trust Relationship is OPTIONAL. 319 5.8 Timeliness 321 Resource Records used as Trust Anchors SHOULD be able to be 322 distributed to security-aware resolvers in a timely manner. 324 Security-aware resolvers need to acquire new and remove revoked 325 DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone 326 such that no old RR is used as a Trust Anchor for long after the zone 327 issues new or revokes existing RRs. 329 5.9 High Availability 331 Information about the zone administrator's view of the state of 332 Resource Records used as Trust Anchors SHOULD be available in a 333 trustworthy manner at all times to security-aware resolvers. 334 Information about Resource Records that a zone administrator has 335 invalidated which are known to be used as Trust Anchors should be 336 available in a trustworthy manner for a reasonable length of time. 338 5.10 New RR Types 340 If a Trust Anchor Rollover solution requires new RR types or protocol 341 modifications, this should be considered in the evaluation of 342 solutions. The Working Group needs to determine whether such changes 343 are a good thing or a bad thing or something else. 345 5.11 Support for Trust Anchor Maintenance Operations 347 The Trust Anchor Rollover solution MUST support operations that allow 348 a validating security-aware resolver to add a new Trust Anchor, 349 delete an existing Trust Anchor, or replace an existing Trust Anchor 350 with another. 352 5.12 Recovery From Compromise 354 The Trust Anchor Rollover solution MUST allow a security aware 355 resolver to be able to recover from the compromise of any of its 356 configured Trust Anchors for a zone so long as at least one other 357 key, which is known to have not been compromised, is configured as a 358 Trust Anchor for that same zone at that resolver. 360 5.13 Non-degrading Trust 362 The Trust Anchor Rollover solution MUST provide sufficient means to 363 ensure authenticity and integrity so that the existing trust relation 364 does not degrade by performing the rollover. 366 6 Security Considerations 368 This document defines overall requirements for an automated 369 specification-based Trust Anchor Rollover solution for security-aware 370 resolvers but specifically does not define the security mechanisms 371 needed to meet these requirements. 373 7 IANA Considerations 375 This document has no actions for the IANA. 377 8 Acknowledgements 379 This document reflects the majority opinion of the DNSEXT Working 380 Group members on the topic of requirements related to DNSSEC trust 381 anchor rollover. The contributions made by various members of the 382 working group to improve the readability and style of this document 383 are graciously acknowledged. 385 9. Normative References 387 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 388 Levels", RFC 2119, March 1997. 390 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 391 "DNS Security Introduction and Requirements", RFC 4033, 392 March 2005. 394 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 395 "Resource Records for the DNS Security Extensions", RFC 4034, 396 March 2005. 398 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 399 "Protocol Modifications for the DNS Security Extensions", 400 RFC 4035, March 2005. 402 [5] Bradner, S., "Intellectual Property Rights in IETF Technology", 403 RFC 3979, March 2005. 405 Authors' Addresses 407 Howard Eland 408 Afilias Limited 409 300 Welsh Road 410 Building 3, Suite 105 411 Horsham, PA 19044 412 USA 414 Email: heland@afilias.info 416 Russ Mundy 417 SPARTA, Inc. 418 7075 Samuel Morse Dr. 419 Columbia, MD 21046 420 USA 422 Email: mundy@sparta.com 424 Steve Crocker 425 Shinkuro Inc. 426 1025 Vermont Ave 427 Washington, DC 20005 428 USA 430 Email: steve@shinkuro.com 432 Suresh Krishnaswamy 433 SPARTA, Inc. 434 7075 Samuel Morse Dr. 435 Columbia, MD 21046 436 USA 438 Email: suresh@sparta.com 440 Full Copyright Statement 442 Copyright (C) The Internet Society (2006). 444 This document is subject to the rights, licenses and restrictions 445 contained in BCP 78, and except as set forth therein, the authors 446 retain all their rights. 448 This document and the information contained herein are provided on an 449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 451 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 452 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 453 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Intellectual Property 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Acknowledgment 482 Funding for the RFC Editor function is provided by the IETF 483 Administrative Support Activity (IASA).