idnits 2.17.1 draft-ietf-dnsext-rollover-requirements-02.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 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 21, 2006) is 6520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC3979' on line 268 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Expires: December 23, 2006 R. Mundy 5 SPARTA, Inc. 6 S. Crocker 7 Shinkuro Inc. 8 S. Krishnaswamy 9 SPARTA, Inc. 10 June 21, 2006 12 Requirements related to DNSSEC Trust Anchor Rollover 13 draft-ietf-dnsext-rollover-requirements-02 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 December 23, 2006. 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 Anchor(s) 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 Anchor(s) 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 is 129 normally the IP address for one or more recursive resolvers. The 130 starting points for recursive resolvers are normally IP addresses for 131 DNS root name servers. Similarly, security-aware resolvers must have 132 one or more starting points to use for building the authenticated 133 chain to validate a signed DNS response. Instead of IP addresses, 134 DNSSEC requires that each operator of a security-aware resolver trust 135 one or more DNSKEY RR or a DS RR hash of a DNSKEY RR as their 136 starting point. Each of these starting points is called a Trust 137 Anchor. 139 It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors 140 when they are created by the signed zone operation nor are they Trust 141 Anchors because the records are published in the signed zone. A 142 DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a 143 security-aware resolver determines that the public key or hash will 144 be used as a Trust Anchor. Thus the signed zone operation that 145 created and/or published a DNSKEY RR (or DS RR) will likely not know 146 if any of the DNSKEY RRs or DS RRs associated with their zone are 147 being used as Trust Anchors by security aware resolvers. The obvious 148 exceptions are the DNSKEY RRs for the root zone that will be used by 149 many security-aware resolvers. For various reasons, DNSKEY RRs or DS 150 RRs from zones other than root can be used by operators of security- 151 aware resolvers as Trust Anchors. It follows that responsibility 152 lies with the operator of the security-aware resolver to ensure that 153 the DNSKEY RRs and/or DS RRs they have chosen to use as Trust Anchors 154 are valid at the time they are used by the security-aware resolver as 155 the starting point for building the authentication chain to validate 156 a signed DNS response. 158 When operators of security-aware resolvers choose one or more Trust 159 Anchors, they must also determine the method(s) they will use to 160 ensure that they are using valid RR(s) and that they are able to 161 determine when RR(s) being used as Trust Anchors should be replaced 162 or removed. Early adopters of DNS signed zones have published 163 information about the processes and methods they will use when their 164 DNSKEY RRs and/or DS RR(s) change so that security-aware resolvers 165 can change their Trust Anchors at the appropriate time. This 166 approach will not scale and, therefore, drives the need for an 167 automated specification-based approach for rollover of Trust Anchors 168 for security-aware resolvers. 170 4. Definitions 172 This document uses the definitions contained in RFC-4033 section 2 173 plus the following additional definitions (Alphabetic by first word): 175 Emergency Trust Anchor Revocation: The operator of a signed zone 176 wishes to indicate that the current DNSKEY and/or DS RR(s) are no 177 longer valid as part of an exceptional event. 179 Emergency Trust Anchor Rollover: The operator of a signed zone has 180 issued new DNSKEY RR(s) and/or DS RR(s) as part of an exceptional 181 event. 183 Initial Trust Relationship: An operator of a security-aware resolver 184 must ensure that they initially obtain any Trust Anchors in a 185 trustworthy manner. For example, the correctness of the root zone 186 DNSKEY RR could be verified by comparing what the operator 187 believes to be the root Trust Anchor with several 'well known' 188 sources such as the IANA web site, the DNS published root zone and 189 the publication of the public key in well known hard-copy forms. 190 For other Trust Anchors, the operator must ensure the accuracy and 191 validity of the DNSKEY RR or DS RR before designating them Trust 192 Anchor(s). This might be accomplished through a combination of 193 technical, procedural and contract relationships or use other 194 existing trust relationships outside of the current DNS protocol. 196 Normal or Scheduled Trust Anchor Rollover: The operator of a DNSSEC 197 signed zone has issued new DNSKEY RR(s) and/or DS RR(s) as a part 198 of an operational routine and may revoke existing DNSKEY RR(s) 199 and/or DS RR(s) at some point in time. 201 Trust Anchor: (in addition to RFC-4033 definition) A DNSKEY RR or DS 202 RR hash of a DNSKEY RR is associated with precisely one point in 203 the DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY 204 may be associated with each DNS zone and MAY be held by any number 205 of security-aware resolvers. Security-aware resolvers MAY have 206 Trust Anchor(s) from multiple DNS zones. Those responsible for 207 operation of security-aware resolvers are responsible for 208 determining which RRs will be used for Trust Anchors by that 209 resolver. 211 Trust Anchor Distribution: The method or methods used to convey the 212 DNSKEY RR(s) or DS RR(s) between the signed zone operation and the 213 security-aware resolver operation. The method or methods MUST be 214 deemed sufficiently trustworthy by the operator of the security- 215 aware resolver to ensure source authenticity and integrity of the 216 new RR(s) to maintain the Initial Trust Relationship required to 217 designate those RR(s) as Trust Anchor(s). 219 Trust Anchor Maintenance: Any change in a validating security-aware 220 resolver to add a new Trust Anchor, delete an existing Trust 221 Anchor, or replace an existing Trust Anchor with another. This 222 change might be accomplished manually or in some automated manner. 223 Those responsible for operation of the security-aware resolver are 224 responsible for establishing policies and procedures to ensure 225 that a sufficient Initial Trust Relationship is in place before 226 adding Trust Anchor(s) for a particular DNS zone to their 227 security-aware resolver configuration. 229 Trust Anchor Revocation and Removal: The invalidation of a particular 230 Trust Anchor that results when the operator of the signed zone 231 revokes or removes a DNSKEY RR or DS RR that is being used as a 232 Trust Anchor by any security-aware resolver(s). It is possible 233 that an original issuer may invalidate more than one RR at one 234 point in time, therefore, it MUST be clear to both the issuer and 235 security-aware resolver operator the exact RR(s) that have been 236 revoked or removed so the proper Trust Anchor or Trust Anchors are 237 removed by the operators of the security-aware resolver. 239 Trust Anchor Rollover: The method or methods necessary for the secure 240 replacement of one or multiple Trust Anchor(s) held by security- 241 aware resolvers. Trust Anchor Rollover should be considered a 242 sub-set of Trust Anchor Maintenance. 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 but in most cases will be less than 20 and 263 never expected to be as high as one thousand. 265 5.2. No Intellectual Property Encumbrance 267 Because trust anchor rollover is considered "mandatory-to-implement", 268 section 8 of [RFC3979] requires that the technology solution chosen 269 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 perpetual right to use, without fee, in commerce or otherwise, where 274 "use" includes descriptions of algorithms, distribution and/or use of 275 hardware implementations, distribution and/or use of software systems 276 in source and/or binary form, in all DNS or DNSSEC applications 277 including registry, registrar, domain name service including 278 authority, recursion, caching, forwarding, stub resolver, or similar. 280 In summary, no implementor, distributor, or operator of the 281 technology chosen for trust anchor management shall be expected or 282 required to pay any fee to any IPR holder for the right to implement, 283 distribute, or operate a system which includes the chosen mandatory- 284 to-implement solution. 286 5.3. General Applicability 288 The solution MUST provide the capability to maintain Trust Anchors in 289 security-aware resolvers for any and all DNS zones. 291 5.4. Support Private Networks 293 The solution MUST support private networks with their own DNS 294 hierarchy. 296 5.5. Detection of Stale Trust Anchors 298 The Trust Anchor Rollover solution MUST allow a validating security- 299 aware resolver to be able to detect if the DNSKEY or DS RR(s) can no 300 longer be updated given the current set of actual trust-anchors so 301 that initial trust may be re-established 303 5.6. Manual Operations Permitted 305 The solution MUST NOT prohibit the use of manual rollover and 306 maintenance activities in operations that choose to use manual 307 methods. A security-aware resolver MAY choose to use manual or 308 automated rollover operations or both but MUST provide at least one 309 method for operators to maintain Trust Anchors. 311 5.7. Planned and Unplanned Rollovers 313 The solution MUST permit both planned (pre-scheduled) and unplanned 314 (non-scheduled) rollover of Trust Anchors. Support for providing an 315 Initial Trust Relationship is OPTIONAL. 317 5.8. Timeliness 319 Resource Records used as Trust Anchors SHOULD be able to be 320 distributed to security-aware resolvers in a timely manner. 322 Operators of security-aware resolvers need to acquire new and remove 323 revoked DNSKEY or DS RR(s) that are being used as Trust Anchors for a 324 zone such that no old RR is used as a Trust Anchor for long after the 325 zone issues new or revokes existing RR(s). 327 5.9. High Availability 329 Information about the issuer's view of the state of Resource Records 330 used as Trust Anchors SHOULD be available in a trustworthy manner at 331 all times to security-aware resolvers. Information about Resource 332 Records that an issuer has invalidated which are known to be used as 333 Trust Anchors should be available in a trustworthy manner for a 334 reasonable length of time. 336 5.10. New RR Types 338 If a Trust Anchor Rollover solution requires new RR types, this 339 should be considered in the evaluation of solutions. The Working 340 Group needs to determine whether requiring a new RR type for a 341 Rollover solution is a good thing or a bad thing or something else. 343 5.11. Support for Trust Anchor Maintenance Operations 345 The Trust Anchor Rollover solution MUST support operations that allow 346 a validating security-aware resolver to add a new Trust Anchor, 347 delete an existing Trust Anchor, or replace an existing Trust Anchor 348 with another. 350 5.12. Recovery From Compromise 352 The Trust Anchor Rollover solution MUST allow a security aware 353 resolver to be able to recover from the compromise of any of its 354 configured Trust Anchors for a zone so long as at least one other 355 key, which is known to have not been compromised, is configured as a 356 Trust Anchor for that same zone at that resolver. 358 5.13. Non-degrading Trust 360 The Trust Anchor Rollover solution MUST provide sufficient means to 361 ensure authenticity and integrity so that by the existing trust 362 relation does not degrade by performing the rollover. 364 6. Security Considerations 366 This document defines overall requirements for an automated 367 specification-based Trust Anchor Rollover solution for security-aware 368 resolvers but specifically does not define the security mechanisms 369 needed to meet these requirements. 371 7. IANA Considerations 373 This document has no actions for the IANA. 375 8. Acknowledgements 377 None at this point. 379 9. Normative References 381 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 382 Levels", RFC 2119, March 1997. 384 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 385 "DNS Security Introduction and Requirements", RFC 4033, 386 March 2005. 388 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 389 "Resource Records for the DNS Security Extensions", RFC 4034, 390 March 2005. 392 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 393 "Protocol Modifications for the DNS Security Extensions", 394 RFC 4035, March 2005. 396 Authors' Addresses 398 Howard Eland 399 Afilias Limited 400 300 Welsh Road 401 Building 3, Suite 105 402 Horsham, PA 19044 403 USA 405 Email: heland@afilias.info 407 Russ Mundy 408 SPARTA, Inc. 409 7075 Samuel Morse Dr. 410 Columbia, MD 21046 411 USA 413 Email: mundy@sparta.com 415 Steve Crocker 416 Shinkuro Inc. 417 1025 Vermont Ave 418 Washington, DC 20005 419 USA 421 Email: steve@shinkuro.com 423 Suresh Krishnaswamy 424 SPARTA, Inc. 425 7075 Samuel Morse Dr. 426 Columbia, MD 21046 427 USA 429 Email: suresh@sparta.com 431 Intellectual Property Statement 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at 453 ietf-ipr@ietf.org. 455 Disclaimer of Validity 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 460 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 461 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 462 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Copyright Statement 467 Copyright (C) The Internet Society (2006). This document is subject 468 to the rights, licenses and restrictions contained in BCP 78, and 469 except as set forth therein, the authors retain all their rights. 471 Acknowledgment 473 Funding for the RFC Editor function is currently provided by the 474 Internet Society.