idnits 2.17.1 draft-ietf-dnsext-rollover-requirements-00.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 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. ** 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- 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 (February 2006) is 6645 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) == Unused Reference: 'RFC4033' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 342, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 dnsext-rollover-requirements February 2006 3 Network Working Group 4 Internet Draft S. Crocker 5 Expires: August 2006 Shinkuro, Inc. 6 H. Eland 7 Afilias Limited 8 R. Mundy 9 SPARTA, Inc. 10 February 2006 12 Requirements related to DNSSEC Trust Anchor Rollover 13 draft-ietf-dnsext-rollover-requirements-00.txt 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 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference 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 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Every DNS security-aware resolver must have at least one Trust 40 Anchor to use as the basis for validating responses from DNS signed 41 zones. For various reasons, most DNS security-aware resolvers are 42 expected to have several Trust Anchors. For some operations, manual 43 monitoring and updating of Trust Anchors may be feasible but many 44 operations will require automated methods for updating Trust Anchors 45 in their security-aware resolvers. This document identifies the 46 requirements that must be met by an automated DNS Trust Anchor 47 rollover solution for security-aware DNS resolvers. 49 Table of Contents 51 1. Terminology....................................................2 52 2. Introduction...................................................2 53 3. Background.....................................................3 54 4. Definitions....................................................4 55 5. Requirements...................................................6 56 5.1 Scalability................................................6 57 5.2 No Intellectual Property Encumbrance.......................6 58 5.3 General Applicability......................................6 59 5.4 Support Private Networks...................................6 60 5.5 Support Reconnecting Systems...............................7 61 5.6 Manual Operations Permitted................................7 62 5.7 Planned and Unplanned Rollovers............................7 63 5.8 Timeliness.................................................7 64 5.9 High Availability..........................................7 65 5.10 New RR Types..............................................7 66 6. Security Considerations........................................7 67 7. IANA Considerations............................................8 68 8. References.....................................................8 69 8.1 Normative References.......................................8 70 8.2 Informative References.....................................8 71 9. Acknowledgments................................................8 72 10. Author's Addresses............................................8 73 11. Intellectual Property Statement...............................9 74 12. Disclaimer of Validity........................................9 75 13. Copyright Statement...........................................9 77 1. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 81 this document are to be interpreted as described in RFC-2119 82 [RFC2119]. 84 The use of the RFC-2119 words in this version of document is 85 preliminary in nature and feedback is requested as to the correct 86 word to use for each of the requirements. 88 2. Introduction 89 The Domain Name System Security Extensions (DNSSEC) as described in 90 RFC4033, RFC4034 and RFC4035 defines new records and protocol 91 modifications to DNS that permit security-aware resolvers to 92 validate DNS Resource Records (RRs)from one or more Trust Anchor(s) 93 held by security-aware resolvers. 95 Security-aware resolvers will have to initially obtain their Trust 96 Anchors in a trustworthy manner to ensure the Trust Anchors are 97 correct and valid. There are a number of ways that this initial step 98 can be accomplished however details of this step are beyond the 99 scope of this document. Once an operator has obtained Trust Anchors, 100 initially entering the Trust Anchor(s) into their security-aware 101 resolvers will in many instances be a manual operation. 103 For some operational environments, manual management of Trust 104 Anchors might be a viable approach. However, many operational 105 environments will require a more automated specification-based 106 method for up-dating and managing Trust Anchors. Several mechanisms 107 for automated specification-based approaches have been proposed to 108 the DNS Extensions (dnsext) Working Group but each seems to be 109 solving a somewhat different group of requirements. As a result, the 110 Working Group determined that a requirements document needed to be 111 developed so that each of the proposed mechanisms can be measured 112 against a consistent set of requirements. This document provides 113 these Trust Anchor Rollover requirements. 115 3. Background 117 DNS resolvers need to have one or more starting points to use in 118 obtaining DNS answers. The starting points for stub resolvers is 119 normally the IP address for one or more recursive resolvers. The 120 starting points for recursive resolvers are normally IP addresses 121 for DNS root name servers. Similarly, security-aware resolvers must 122 have one or more starting points to use for building the 123 authenticated chain to validate a signed DNS response. Instead of IP 124 addresses, DNSSEC requires that each operator of a security-aware 125 resolver trust one or more DNSKEY RR or a DS RR hash of a DNSKEY RR 126 as their starting point. Each of these starting points is called a 127 Trusted Anchor. 129 It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors 130 when they are created by the signed zone operation nor are they 131 Trust Anchors because the records are published in the signed zone. 132 A DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a 133 security-aware resolver determines that the public key or hash will 134 be used as a Trust Anchor. Thus the signed zone operation that 135 created and/or published a DNSKEY RR (or DS RR) will likely not know 136 if any of the DNSKEY RRs or DS RRs associated with their zone are 137 being used as Trust Anchors by security aware resolvers. The obvious 138 exceptions are the DNSKEY RRs for the root zone that will be used by 139 many security-aware resolvers. For various reasons, DNSKEY RRs or DS 140 RRs from zones other than root can be used by operators of security- 141 aware resolvers as Trust Anchors. It follows that responsibility 142 lies with the operator of the security-aware resolver to ensure that 143 the DNSKEY RRs and/or DS RRs they have chosen to use as Trust 144 Anchors are valid at the time they are used by the security-aware 145 resolver as the starting point for building the authentication chain 146 to validate a signed DNS response. 148 When operators of security-aware resolvers choose one or more Trust 149 Anchors, they must also determine the method(s) they will use to 150 ensure that they are using valid RR(s) and that they are able to 151 determine when RR(s) being used as Trust Anchors should be replaced 152 or removed. Early adopters of DNS signed zones have published 153 information about the processes and methods they will use when their 154 DNSKEY RRs and/or DS RR(s) change so that security-aware resolvers 155 can change their Trust Anchors at the appropriate time. This 156 approach will not scale and, therefore, drives the need for an 157 automated specification-based approach for rollover of Trust Anchors 158 for security-aware resolvers. 160 4. Definitions 162 This document uses the definitions contained in RFC-4033 section 2 163 plus the following additional definitions (Alphabetic by first 164 word): 166 Emergency Trust Anchor Rollover: 167 The operator of a signed zone has issued new DNSKEY RR(s) and/or DS 168 RR(s) as part of an exceptional event. Any security-aware resolver 169 using those RR(s) as Trust Anchor(s) must quickly remove them from 170 use by the resolver. 172 Initial Trust Relationship: 173 An operator of a security-aware resolver must ensure that they 174 initially obtain any Trust Anchors in a trustworthy manner. For 175 example, the correctness of the root zone DNSKEY RR could be 176 verified by comparing what the operator believes to be the root 177 Trust Anchor with several 'well known' sources such as the IANA web 178 site, the DNS published root zone and the publication of the public 179 key in well known hard-copy forms. For other Trust Anchors, the 180 operator must ensure the accuracy and validity of the DNSKEY RR or 181 DS RR before designating them Trust Anchor(s). This might be 182 accomplished through a combination of technical, procedural and 183 contract relationships or use other existing trust relationships 184 outside of the current DNS protocol. 186 Normal or Scheduled Trust Anchor Rollover: 187 The operator of DNSSEC signed zone has issued new DNSKEY RR(s) 188 and/or DS RR(s) as a part of an operational routine and may revoke 189 existing DNSKEY RR(s) and/or DS RR(s) at some point in time. 190 Operators of security-aware resolvers using RR(s) from that zone as 191 Trust Anchors need to acquire new and remove revoked Trust Anchors 192 at roughly the same time as the signed zone issues or revokes RR(s). 194 Trust Anchor: 195 (in addition to RFC-4033 definition) A DNSKEY RR or DS RR hash of a 196 DNSKEY RR is associated with precisely one point in the DNS 197 hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY may be 198 associated with each DNS zone and MAY be held by any number of 199 security-aware resolvers. Security-aware resolvers MAY have Trust 200 Anchor(s) from multiple DNS zones. Those responsible for operation 201 of security-aware resolvers are responsible for determining which 202 RRs will be used for Trust Anchors by that resolver. 204 Trust Anchor Distribution: 205 The method or methods used to convey the DNSKEY RR(s) or DS RR(s) 206 between the signed zone operation and the security-aware resolver 207 operation. The method or methods MUST be deemed sufficiently 208 trustworthy by the operator of the security-aware resolver to ensure 209 source authenticity and integrity of the new RR(s) to maintain the 210 Initial Trust Relationship required to designate those RR(s) as 211 Trust Anchor(s). 213 Trust Anchor Maintenance: 214 Any change in a validating security-aware resolver to add a new 215 Trust Anchor, delete an existing Trust Anchor, or replace an 216 existing Trust Anchor with another. This change might be 217 accomplished manually or in some automated manner. Those responsible 218 for operation of the security-aware resolver are responsible for 219 establishing policies and procedures to ensure that a sufficient 220 Initial Trust Relationship is in place before adding Trust Anchor(s) 221 for a particular DNS zone to their security-aware resolver 222 configuration. 224 Trust Anchor Revocation and Removal: 225 The invalidation of a particular Trust Anchor that results when the 226 operator of the signed zone revokes or removes a DNSKEY RR or DS RR 227 that is being used as a Trust Anchor by any security-aware 228 resolver(s). It is possible that an original issuer may invalidate 229 more than one RR at one point in time, therefore, it MUST be clear 230 to both the issuer and security-aware resolver operator the exact 231 RR(s) that have been revoked or removed so the proper Trust Anchor 232 or Trust Anchors are removed by the operators of the security-aware 233 resolver. 235 Trust Anchor Rollover: 236 The method or methods necessary for the secure replacement of one or 237 multiple Trust Anchor(s) held by security-aware resolvers. Trust 238 Anchor Rollover should be considered a sub-set of Trust Anchor 239 Maintenance. 241 5. Requirements 243 Following are the requirements for DNSSEC automated specification- 244 based Trust Anchor Rollover: 246 5.1 Scalability 248 The automated Trust Anchor Rollover solution MUST be capable of 249 scaling to Internet-wide useage. The probable largest number of 250 instances of security-aware resolvers needing to rollover a Trust 251 Anchor will be for the root zone. This number could be extremely 252 large (possibly many millions) if a number of applications have 253 embedded security-aware resolvers. The number of Trust Anchors that 254 might be configured into any one validating security-aware resolver 255 is not known with certainty at this time but in most cases will be 256 less than 20 and never expected to be as high as one thousand. 258 5.2 No Intellectual Property Encumbrance 260 The solution SHOULD not have any intellectual property encumbrance 261 on either the technologies used by the solution nor implementations 262 of the solution. The technology used by the solution SHOULD permit 263 implementers to provide complete, running implementations that have 264 Berkley open source type of licensing. 266 5.3 General Applicability 268 The solution MUST provide the capability to maintain Trust Anchors 269 in security-aware resolvers for any and all DNS zones. The same 270 solution SHALL be able to be used to maintain Trust Anchors for the 271 root zone and other zones. 273 5.4 Support Private Networks 275 The solution MUST support private networks with their own DNS 276 hierarchy. 278 5.5 Support Reconnecting Systems 280 The solution MUST support rollover for security-aware resolvers that 281 have been disconnected from the network for up to twelve months. 283 5.6 Manual Operations Permitted 285 The solution MUST NOT prohibit the use of manual rollover and 286 maintenance activities in operations that choose to use manual 287 methods. A security-aware resolver MAY choose to use manual or 288 automated rollover operations or both but MUST provide at least one 289 method for operators to maintain Trust Anchors. 291 5.7 Planned and Unplanned Rollovers 293 The solution MUST permit both planned (pre-scheduled) and unplanned 294 (non-scheduled) rollover of Trust Anchors. Support for providing an 295 Initial Trust Relationship is OPTIONAL. 297 5.8 Timeliness 299 Resource Records used as Trust Anchors SHOULD be able to be 300 distributed to security-aware resolvers in a timely manner. 302 5.9 High Availability 304 Information about the issuer's view of that state of Resource 305 Records used as Trust Anchors SHOULD be available in a trustworthy 306 manner at all times to security-aware resolvers. Information about 307 Resource Records that an issuer has invalidated which are known to 308 be used as Trust Anchors should be available in a trustworthy manner 309 for a reasonable length of time. [Editor's note: should 'reasonable 310 length of time' be more specific? If so, what should it be?] 312 5.10 New RR Types 314 If a Trust Anchor Rollover solution requires new RR types, this 315 should be considered in the evaluation of solutions. The Working 316 Group needs to determine whether requiring a new RR type for a 317 Rollover solution is a good thing or a bad thing or something else. 319 6. Security Considerations 320 This document defines overall requirements for an automated 321 specification-based Trust Anchor Rollover solution for security- 322 aware resolvers but specifically does not define the security 323 mechanisms needed to meet these requirements. 325 7. IANA Considerations 327 This document has no actions for the IANA. 329 8. References 331 8.1 Normative References 333 [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels, 334 S Bradner, March 1997 336 [RFC4033] DNS Security Introduction and Requirements, R. Arends, 337 et.al., March 2005 339 [RFC4034] Resource Records for the DNS Security Extensions, R. 340 Arends, et.al., March 2005 342 [RFC4035] Protocol Modifications for the DNS Security Extensions, R. 343 Arends, et.al., March 2005 345 8.2 Informative References 347 None at this point. 349 9. Acknowledgments 351 None at this point. 353 10. Author's Addresses 355 Steve Crocker 356 1025 Vermont Ave 357 Washington, DC 20005, USA 358 Email: steve@shinkuro.com 360 Howard Eland 361 Afilias 362 300 Welsh Road 363 Building 3, Suite 105 364 Horsham, PA 19044, USA 365 Email: heland@afilias.info 367 Russ Mundy 368 7075 Samuel Morse Dr. 369 Columbia, MD 21046, USA 370 Email: mundy@sparta.com 372 11. Intellectual Property Statement 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed 376 to pertain to the implementation or use of the technology described 377 in this document or the extent to which any license under such 378 rights might or might not be available; nor does it represent that 379 it has made any independent effort to identify any such rights. 380 Information on the procedures with respect to rights in RFC 381 documents can be found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use 386 of such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository 388 at http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at ietf- 394 ipr@ietf.org. 396 12. Disclaimer of Validity 398 This document and the information contained herein are provided on 399 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 400 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 401 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 402 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 13. Copyright Statement 407 Copyright (C) The Internet Society (2006). This document is subject 408 to the rights, licenses and restrictions contained in BCP 78, and 409 except as set forth therein, the authors retain all their rights. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.