idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Ljunggren 3 Internet-Draft Kirei AB 4 Intended status: Informational AM. Eklund Lowinder 5 Expires: September 9, 2012 .SE 6 T. Okubo 7 ICANN 8 March 8, 2012 10 DNSSEC Policy & Practice Statement Framework 11 draft-ietf-dnsop-dnssec-dps-framework-07 13 Abstract 15 This document presents a framework to assist writers of DNSSEC Policy 16 and Practice Statements such as Domain Managers and Zone Operators on 17 both the top-level and secondary level, who is managing and operating 18 a DNS zone with Security Extensions (DNSSEC) implemented. 20 In particular, the framework provides a comprehensive list of topics 21 that should be considered for inclusion into a DNSSEC Policy 22 definition and Practice Statement. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 9, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 6 66 3.3. Relationship between DNSSEC Policy and Practice 67 Statement . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 8 69 4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10 70 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Publication and repositories . . . . . . . . . . . . . . . 11 72 4.3. Operational requirements . . . . . . . . . . . . . . . . . 12 73 4.4. Facility, management and operational controls . . . . . . 12 74 4.5. Technical security controls . . . . . . . . . . . . . . . 16 75 4.6. Zone signing . . . . . . . . . . . . . . . . . . . . . . . 21 76 4.7. Compliance audit . . . . . . . . . . . . . . . . . . . . . 22 77 4.8. Legal matters . . . . . . . . . . . . . . . . . . . . . . 23 78 5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23 79 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 80 7. Security considerations . . . . . . . . . . . . . . . . . . . 26 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 9.1. Normative references . . . . . . . . . . . . . . . . . . . 27 84 9.2. Informative references . . . . . . . . . . . . . . . . . . 27 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 87 1. Introduction 89 1.1. Background 91 The Domain Name System (DNS) was not originally designed with strong 92 security mechanisms to provide integrity and authenticity of its 93 data. Over the years, a number of vulnerabilities have been 94 discovered that threaten the reliability and trustworthiness of the 95 system. 97 The Domain Name System Security Extensions (DNSSEC, [RFC4033], 98 [RFC4034], [RFC4035]) address these vulnerabilities by using public 99 key cryptography to add data origin authentication, data integrity 100 verification, and authenticated denial of existence capabilities to 101 the DNS. In short, DNSSEC provides a way for software to verify the 102 origin of DNS data and validate that it has not been modified in 103 transit. 105 To provide a means for users of the DNS ("relying parties") to 106 evaluate the strength and security of the DNSSEC chain of trust, an 107 entity operating a DNSSEC enabled zone may choose to publish a DNSSEC 108 Practice Statement (DPS), comprising statements of critical security 109 controls and procedures relevant for scrutinizing the trustworthiness 110 of the system. The DPS may also identify any DNSSEC Policies it 111 supports, explaining how it meets their requirements. 113 Even though this document is heavily inspired by the Internet X.509 114 Public Key Infrastructure Certificate Policy and Certification 115 Practices Framework [RFC3647], with large parts being drawn from that 116 document, the properties and structure of the DNSSEC trust model is 117 fundamentally different from those of the X.509 PKI. 119 For example, in the DNSSEC trust model there is no central control of 120 assurance or trust levels. Each zone manager selects their own way 121 of managing keys and operations, there being no necessity to perform 122 any coordination of security practices between different zones. The 123 degree to which a relying party can trust the binding embodied in the 124 DNSSEC chain of trust is dependent on the weakest link of that chain. 125 This implies that the security of zones is generally more critical 126 higher up in the DNS hierarchy. 128 Consequently, a DPS is focused only on stating the security posture 129 of a particular zone, not the entire domain name system. Moreover, 130 the DNS is of an almost ubiquitous nature and completely open. There 131 are no agreements with the relying (third) parties, which are all 132 entities relying on signed responses from the DNS. 134 1.2. Purpose 136 The purpose of this document is twofold. Firstly, the document aims 137 to explain the concepts of a DNSSEC Policy (DP) and of a DNSSEC 138 Practice Statement (DPS), and to describe the relationship between 139 the two. Secondly, it aims to present a framework to encourage and 140 assist writers of Policies and Practice Statements in creating 141 consistent and comparable documents. In particular, the framework 142 identifies the elements that should be considered in formulating a DP 143 or a DPS. It does not, however, define a particular Policy or 144 Practice Statement, not does it seek to provide legal advice or 145 recommendations as to the contents. 147 1.3. Scope 149 The scope of this document is limited to discussion of the topics 150 that can be covered in a DP or a DPS, but does not go into the 151 specific details that could possibly be included in each one. In 152 particular, this document describes the types of information that 153 should be considered for inclusion in them. 155 The DNSSEC Policy and Practice Statement framework should be viewed 156 and used as a checklist of factors that should be taken in to 157 consideration prior to deploying DNSSEC, and as an outline to create 158 an operational practices disclosure document. As such, it focuses on 159 the topics affected by the introduction of DNSSEC into a zone. Other 160 aspects, such as the operations of name servers and registry systems 161 are considered out of scope. The framework is primarily aimed at TLD 162 managers and organizations providing registry services, but may be 163 used by high-value domain holders and so serve as a checklist for 164 DNSSEC readiness at a high level. 166 This document assumes that the reader is familiar with the general 167 concepts of DNS, DNSSEC and PKI. 169 2. Definitions 171 This document makes use of the following defined terms: 173 Audit logs - Control evidence information generated by DNS and 174 DNSSEC-related systems, the surrounding facility or other manually 175 generated, non-electronic documentation to prove the integrity of 176 processes. Audit logs will be examined by the internal and/or 177 external auditors. 179 Activation data - Data values, other than keys, required to operate 180 the cryptographic modules used to protect the keys from unauthorized 181 use. 183 Chain of Trust - A hierarchical structure of trust consisting of DNS 184 keys, signatures, and delegation signer records that, when validated 185 in a series, can provide proof of authenticity of the last element in 186 the chain, providing that the first element is trusted. Usually, the 187 first element is a trust anchor. 189 Compromise (Key Compromise) - Key Compromise is a situation where the 190 private component of a Signing Key is lost, stolen, exposed, modified 191 or used in an unauthorized manner. More strictly, even a suspicion 192 that one of these has occurred will be enough to be considered as key 193 compromise. 195 DNS - The Domain Name System (DNS) is a hierarchical global naming 196 catalog for computers, services, or any resource connected to the 197 Internet. 199 DNS Zone - A portion of the global Domain Name System (DNS) namespace 200 for which administrative responsibility has been delegated. 202 DNSSEC - DNS Security Extensions (DNSSEC) is a set of IETF 203 specifications that use public key cryptography to add data origin 204 authentication, data integrity verification, and authenticated denial 205 of existence capabilities to DNS. 207 DNSSEC Policy - A DNSSEC Policy (DP) sets forth the requirements and 208 standards to be implemented for a DNSSEC signed zone. 210 DNSSEC Practice Statement - A DNSSEC Practice Statement (DPS) is a 211 practices disclosure document that may support and be a supplemental 212 document to the DNSSEC Policy (if such exists), and states how the 213 management of a given zone implements procedures and controls at a 214 high level. 216 Key Roll-Over - An operational process to change one of the DNSSEC 217 keys used for signing a zone. 219 PKI - Public Key Infrastructure (PKI) is a concept by which use of 220 asymmetric cryptography may provide a system with integrity, 221 authentication, confidentiality, and non-repudiation. 223 Policy Authority - The body responsible for setting and administering 224 a DNSSEC Policy, and for determining whether a DPS is suitable for 225 that Policy. 227 Relying Party - An entity that relies on a signed response from the 228 DNS. 230 Repository - A location on the Internet to store DP, DPS, Trust 231 Anchors and other related information that should be kept public. 233 Security Posture - A Security Posture is an indicator of how secure 234 an entity is and how secure the entity should be. It is the result 235 of an adequate threat modelling and risk assessment. 237 Separation of Duties - A security concept that limits the influence 238 of a single person by segregating roles and responsibilities. 240 Signing Key - A key-pair used for signing and validation of resource 241 records within the zone. 243 TLD - A Top-Level Domain (TLD) is one of the domains at the highest 244 level in the hierarchy of the DNS. 246 Trust Anchor - Public portion of a Signing Key that is the 247 authoritative entity used to authenticate the first element in a 248 chain of trust. 250 3. Concepts 252 This section describes the concepts of a DNSSEC Policy and of a 253 DNSSEC Practices Statement. Other related concepts are described as 254 well. 256 3.1. DNSSEC Policy 258 The DNSSEC Policy (DP) sets forth requirements that are appropriate 259 for a determined level of assurance. For example, a DP may encompass 260 all topics of this framework, each with a certain set of security 261 requirements, possibly grouped according to impact. The progression 262 from medium to high levels would correspond to increasing security 263 requirements and corresponding increasing levels of assurance. 265 DPs also constitute a basis for an audit, accreditation, or another 266 assessment of an entity. Each entity can be assessed against one or 267 more DPs that it is recognized as implementing. 269 3.2. DNSSEC Practice Statement 271 Most DNSSEC participants will not have the need to create a thorough 272 and detailed statement of practices. For example, a registrant may 273 be the sole relying party of its own zone and would already be aware 274 of the nature and trustworthiness of its services. In other cases, a 275 zone manager may provide registration services with only a very low 276 level of assurances where the domain names being secured may pose 277 only marginal risks if compromised. Publishing a DPS is most 278 relevant for entities operating a zone that contains a significant 279 number of delegations to other entities. 281 A DNSSEC Practice Statement (DPS) should contain information that is 282 relevant to the stakeholders of the relevant zone(s). Since these 283 generally include the Internet community, it should not contain such 284 information that could be considered to be sensitive details of an 285 entity's operations. 287 A DNSSEC Practice Statement may identify a supported DP, which may 288 subsequently be used by a relying party to evaluate the 289 trustworthiness of any digital signatures verified using the public 290 key of that entity. 292 3.3. Relationship between DNSSEC Policy and Practice Statement 294 A DNSSEC Policy and a DNSSEC Practice Statement address the same set 295 of topics that are of interest to the stakeholders in terms of the 296 degree to which a DNSSEC digital signature may be trusted. The 297 primary difference is in the focus of their provisions. A Policy 298 sets forth the requirements and standards to be implemented for a 299 DNSSEC signed zone. A Practice Statement, by contrast, states how a 300 zone operator (and possibly other participants in the management of a 301 given zone) implements procedures and controls to meet the 302 requirements stated in the Policy. In other words, the Policy says 303 what needs to be done, the Practice Statement says what is being 304 done. 306 An additional difference between a Policy and a Practice Statement 307 relates the scope of coverage of the two kinds of documents. Since a 308 Policy is a statement of requirements, it is best used for 309 communicating minimum operating guidelines that must be met by 310 complying parties; as such it may also be used to facilitate 311 interoperation of a level of trust between zones. Thus, a Policy may 312 apply to multiple organizations or multiple zones. By contrast, a 313 Practice Statement would usually apply only to a single zone operator 314 or a single organization. 316 For example, a TLD Manager or regulatory authority may define 317 requirements in a Policy for the operation of one or more zones. The 318 Policy will be a broad statement of the general requirements for 319 managing the zone. A zone operator may be required to write its own 320 Practice Statement to support the Policy by explaining how it meets 321 the requirements of the Policy. Alternatively, a zone operator that 322 is also the manager of that zone and not governed by any external 323 Policy may still choose to disclose operational practices by 324 publishing a DPS for the purpose of providing transparency and to 325 gain community trust in the operations. 327 A Policy and a Practice Statement also differ in the level of detail 328 of their provisions: although there may be variations, a Practice 329 Statement will provide a description of procedures and controls and 330 so will usually be more detailed than a Policy, which provides 331 general principles. 333 The main differences between a Policy and Practice Statement can be 334 summarized as follows: 336 (a) Operation of a DNS zone with DNSSEC may be governed by a Policy 337 that establishes requirements stating what the entity operating 338 that zone must do. An entity can use a Practice Statement to 339 disclose how it meets the requirements of a Policy or how it has 340 implemented critical processes and controls. 342 (b) A Policy may facilitate interoperation of level of trust through 343 several parts or levels in the DNS hierarchy. By contrast, a 344 Practice Statement is a statement of a single zone operator or 345 organization. 347 (c) A Practice Statement is generally more detailed than a Policy 348 and specifies how the zone operator or organization implements 349 critical processes and controls, and how the entity meets any 350 requirements specified in the one or more Policies under which 351 it operates DNSSEC. 353 3.4. Set of Provisions 355 A set of provisions is a collection of Policy requirements or 356 Practice statements, which may employ the approach described in this 357 framework by covering the topics appearing in Section 5 below. The 358 topics are described in detail in section 4. 360 A Policy can be expressed as a single set of provisions. 362 A Practice Statement can also be expressed as a single set of 363 provisions with each component addressing the requirements of one or 364 more Policies. Alternatively, it could be a set of provisions that 365 do not reference any particular policy but instead describe a set of 366 self-imposed controls to the relying parties. For example, a 367 Practice Statement could be expressed as a combination of the 368 following: 370 (a) a list of Policies supported by the DPS; 372 (b) for each Policy in (a), a set of provisions that contains 373 statements addressing the requirements by filling in details not 374 stipulated in that policy or expressly left to the discretion of 375 the implementor. Such statements serve to show how this 376 particular Practice Statement implements the requirements of the 377 particular Policy; or 379 (c) a set of provisions that contains statements regarding the 380 DNSSEC operations practices, regardless of any Policy. 382 The statements provided in (b) may augment or refine the stipulations 383 of an applicable Policy, but generally must not conflict with them. 384 In certain cases however, a Policy Authority may permit exceptions 385 because certain compensating controls of the entity disclosed in its 386 Practices Statement allow it to provide a level of assurance 387 equivalent to full compliance with the policy. 389 The framework outlines the contents of a set of provisions, in terms 390 of eight primary components, as follows: 392 1. Introduction 394 2. Publication and Repositories 396 3. Operational Requirements 398 4. Facility, Management, and Operational Controls 400 5. Technical Security Controls 402 6. Zone Signing 404 7. Compliance Audit 406 8. Legal Matters 408 This framework can be used by Policy Authorities to write DNSSEC 409 Policies and by zone operators to write a DNSSEC Practice Statements. 410 Having a set of documents with the same structure facilitates 411 comparisons with the corresponding documents of other zones. 413 4. Contents of a Set of Provisions 415 This section describes the contents of a set of provisions. Refer to 416 Section 5 for the complete outline. 418 Drafters of DPSs conforming to this framework are permitted to add 419 additional levels of subcomponents below those described here to meet 420 specific needs. All components listed in Section 5 should be 421 present, but drafters may leave components without stipulation if so 422 required. 424 4.1. Introduction 426 This component identifies and introduces the set of provisions, and 427 indicates the types of entities and applications for which the 428 document (either Policy or Practice Statement) is targeted. 430 4.1.1. Overview 432 This subcomponent provides a general introduction to the document. 433 It can also be used to provide a description of entities to which the 434 Policy or Practice Statement applies. 436 4.1.2. Document name and identification 438 This subcomponent provides any applicable names or other identifiers 439 of the document. 441 4.1.3. Community and applicability 443 This subcomponent identifies the stakeholders along with their 444 expected roles and responsibilities. These include (but are not 445 limited to) an entity signing the zone, entities relying on the 446 signed zone, other entities that have operational dependency on the 447 signed zone, and an entity that entrusted the zone signing. 449 4.1.4. Specification administration 451 This subcomponent includes the name and contact details of the 452 organization that is responsible for managing the DP/DPS. 454 If a formal or informal Policy Authority is responsible for 455 determining whether a DPS is suitable for the Policy this 456 subcomponent may include the name and contact information of the 457 entity in charge of making such a determination. In this case, the 458 subcomponent also includes the procedures by which this determination 459 is made. 461 4.2. Publication and repositories 463 The component describes the requirements for an entity to publish 464 information regarding its practices, public keys, the current status 465 of such keys together with details relating to the repositories in 466 which the information is held. This may include the responsibilities 467 of publishing the DPS and of identifying documents that are not made 468 publicly available owing to their sensitive nature, e.g. security 469 controls, clearance procedures, or business information. 471 4.2.1. Repositories 473 This subcomponent describes the repository mechanisms used for making 474 information available to the stakeholders, and may include: 476 o The locations of the repositories and the means by which they may 477 be accessed; 479 o An identification of the entity or entities that operate 480 repositories, such as a zone operator or a TLD Manager; 482 o Access control on published information objects. 484 o Any notification services which may be subscribed to by the 485 stakeholders; 487 4.2.2. Publication of public keys 489 This subcomponent contains information relating to the publication of 490 public keys: 492 o Whether the public keys are included in a key hierarchy, published 493 as Trust Anchors or both; 495 o The data formats and methods available to validate the 496 authenticity of public keys; 498 o The frequency and timing of publishing new information 499 (principally as advance notice for stakeholders relying on the 500 public keys). 502 4.3. Operational requirements 504 This component describes the operational requirements when operating 505 a DNSSEC signed zone. 507 4.3.1. Meaning of domain names 509 This subcomponent describes the overall policy of child zone naming, 510 if any. 512 4.3.2. Identification and authentication of child zone manager 514 This subcomponent describes how the child zone manager has initially 515 been identified, and how any subsequent change request is 516 authenticated as originating from the manager or their authorized 517 representative. 519 4.3.3. Registration of delegation signer (DS) resource records 521 This subcomponent describes the process of establishing the chain-of- 522 trust to the child zone by incorporating delegation signer (DS) 523 record(s) into the zone. 525 4.3.4. Method to prove possession of private key 527 This subcomponent describes whether, and if so under what 528 circumstances, the child zone manager is required to provide proof of 529 the possession of the private component of any current or subsequent 530 child zone Signing Key corresponding to a DS record they wish to 531 incorporate into the parent zone. 533 4.3.5. Removal of DS resource records 535 This subcomponent will explain how, when, and under what 536 circumstances the DS records may be removed from the zone. 538 4.4. Facility, management and operational controls 540 This component describes non-technical security controls (i.e., 541 physical, procedural, and personnel) in use by the entity to securely 542 perform the DNSSEC related functions such as physical access, key 543 management, disaster recovery, auditing, and archiving. 545 These non-technical security controls are critical for trusting the 546 signatures since lack of security may compromise DNSSEC operations. 547 For example, it could result in the creation of signatures with 548 erroneous information or in the compromise of the Signing Key. 550 Within each subcomponent, separate consideration will usually need to 551 be given to each entity type. 553 4.4.1. Physical controls 555 In this subcomponent, the physical controls on the facility housing 556 the entity systems are described. Topics addressed may include: 558 o Site location and construction, such as requirements for multiple 559 tiers of physical barriers, construction requirements for high- 560 security areas. It may also describe the use of locked rooms, 561 cages, safes, and cabinets etc.; 563 o Physical access, i.e. mechanisms to control access from one area 564 of the facility to another or additional controls for reaching 565 into higher tiers, such as dual-access control and two-factor 566 authentication; 568 o Power and air conditioning; 570 o Water exposures; 572 o Fire prevention and protection; 574 o Media storage, e.g. requiring the storage of backup media in a 575 separate location that is physically secure and protected from 576 fire, smoke, particle, and water damage; 578 o Waste disposal; and 580 o Off-site backup. 582 4.4.2. Procedural controls 584 In this subcomponent, requirements for recognizing trusted roles are 585 described, together with a description of the responsibilities of 586 each role. Examples of trusted roles include system administrators, 587 security officers, and system auditors. 589 For each task identified, the number of individuals required to 590 perform the task (m of n rule, if applicable) should be stated for 591 each role. Identification and authentication requirements for each 592 role may also be defined. 594 This subcomponent also includes the separation of duties in terms of 595 the roles that cannot be performed by the same individuals. 597 4.4.3. Personnel controls 599 This subcomponent addresses the following: 601 o Qualifications, experience, and clearances that personnel must 602 have as a condition of filling trusted roles or other important 603 roles. Examples include credentials, job experiences, and 604 official government clearances; 606 o Background checks and clearance procedures that are required in 607 connection with the hiring of personnel filling trusted roles or 608 other important roles; such roles may require a check of their 609 criminal records, financial records, references, and any 610 additional clearances required for the position in question; 612 o Training requirements and training procedures for each role 613 following the hiring of personnel; 615 o Any retraining period and retraining procedures for each role 616 after completion of initial training; 618 o Frequency and sequence for job rotation among various roles; 620 o Sanctions against personnel for unauthorized actions, such as 621 unauthorized use of authority, or unauthorized use of the entity 622 systems; 624 o Controls on personnel that are contractors rather than employees 625 of the entity; examples include: 627 * Bonding requirements on contract personnel; 629 * Contractual requirements including indemnification for damages 630 due to the actions of the contractor personnel; 632 * Auditing and monitoring of contractor personnel; and 634 * Other controls on contracting personnel. 636 o Documentation to be supplied to personnel during initial training, 637 retraining, or otherwise. 639 4.4.4. Audit logging procedures 641 This subcomponent is used to describe event logging and audit 642 systems, implemented for the purpose of maintaining an audit trail 643 and provide evidence of process integrity. Elements include the 644 following: 646 o Types of events recorded, such as attempts to access the system, 647 and requests made to the system; 649 o Frequency with which audit logs are processed or archived, for 650 example, weekly, following an alarm or anomalous event, or 651 whenever the audit log size reaches a particular size; 653 o Period for which audit logs are kept; 655 o Protection of audit logs: 657 * Who can view audit logs, for example only the audit 658 administrator; 660 * Protection against modification of audit logs, for instance a 661 requirement that no one may modify or delete the audit records 662 or that only an audit administrator may delete an audit file as 663 part of audit file rotation; and 665 * Protection against deletion of audit logs. 667 o Audit log backup procedures; 669 o Whether the audit log collection function is internal or external 670 to the system; 672 o Whether the subject who caused an audit event to occur is notified 673 of the audit action; and 675 o Vulnerability assessments, for example, where audit data is run 676 through a tool that identifies potential attempts to breach the 677 security of the system. 679 4.4.5. Compromise and disaster recovery 681 This subcomponent describes requirements relating to notification and 682 recovery procedures in the event of compromise or disaster. Each of 683 the following may need to be addressed separately: 685 o Identification or listing of the applicable incident and 686 compromise reporting and handling procedures. 688 o The recovery procedures used if computing resources, software, 689 and/or data are corrupted or suspected to have been corrupted. 690 These procedures describe how, and under what circumstances 691 operations of the system are to be suspended, how and when normal 692 operations are resumed, how the stakeholders are to be informed 693 and how to assess the damage and carry out the root cause 694 analysis. 696 o The recovery procedures used if any keys are compromised. These 697 procedures describe how a secure environment is re-established, 698 how the keys are rolled over, how a new Trust Anchor is provided 699 to the community (if applicable), and how new zone information is 700 published. 702 o The entity's capabilities to ensure business continuity following 703 a natural or other disaster. Such capabilities may include the 704 availability of a disaster recovery site at which operations may 705 be recovered. They may also include procedures for securing its 706 facility during the period of time following a natural or other 707 disaster and before a secure environment is re-established, either 708 at the original site or at a disaster recovery site. For example, 709 procedures to protect against theft of sensitive materials from an 710 earthquake-damaged site. 712 4.4.6. Entity termination 714 This subcomponent describes requirements relating to procedures for 715 termination of a contract with an entity, termination notification 716 and transition of responsibilities to another entity. The purpose 717 may be to ensure that the transition process will be transparent to 718 the relying parties and will not affect the services. 720 4.5. Technical security controls 722 This component is used to define the security measures taken to 723 protect the cryptographic keys and activation data (e.g., PINs, 724 passwords, or manually-held key shares) relevant to the DNSSEC 725 operations. Secure key management is critical to ensure that all 726 secret and private keys and activation data are protected and used 727 only by authorized personnel. 729 Also described here are other technical security controls used to 730 perform the functions of key generation, authentication, 731 registration, auditing, and archiving. Technical controls include 732 life-cycle security controls, software development environment 733 security, and operational security controls. 735 If applicable, other technical security controls on repositories, 736 authoritative name servers, or other participants may also be 737 documented here. 739 4.5.1. Key pair generation and installation 741 Key pair generation and installation need to be considered, which may 742 involve answering the following questions: 744 1. Who generates the zone's public/private key pairs? How is the 745 key generation performed? Is the key generation performed by 746 hardware or software? 748 2. How is the private key installed in all parts of the key 749 management system? 751 3. How are the zone's public keys provided securely to the parent 752 zone and potential relying parties? 754 4. Who generates the public key parameters. Is the quality of the 755 parameters checked during key generation? 757 5. For what purposes may the keys be used, and/or for what purposes 758 should usage of the key be restricted? 760 4.5.2. Private key protection and cryptographic module engineering 761 controls 763 Requirements for private key protection and cryptographic modules 764 need to be considered for key generation and creation of signatures. 765 The following questions may need to be answered: 767 1. What standards, if any, are required for the cryptographic 768 module used to generate the keys? A cryptographic module can be 769 composed of hardware, software, firmware, or any combination of 770 them. For example, are the zone's signatures required to be 771 generated using modules compliant with the US FIPS 140-2 772 standard? If so, what is the required FIPS 140-2 level of the 773 module? Are there any other engineering or other controls 774 relating to a cryptographic module, such as the identification 775 of the cryptographic module boundary, input/output, roles and 776 services, finite state machine, physical security, software 777 security, operating system security, algorithm compliance, 778 electromagnetic compatibility, and self tests. 780 2. Is the private key under n out of m multi-person control? If 781 yes, provide n and m (two person control is a special case of n 782 out of m, where n = m = 2). 784 3. Is the private key escrowed? If so, who is the escrow agent, in 785 what form is the key escrowed (e.g. plaintext, encrypted, split 786 key), and what are the security controls on the escrow system? 788 4. Is the private key backed up? If so, who is the backup agent, 789 in what form is the key backed up (e.g. plaintext, encrypted, 790 split key), and what are the security controls on the backup 791 system? 793 5. Is the private key archived? If so, who is the archival agent, 794 in what form is the key archived (e.g. plaintext, encrypted, 795 split key), and what are the security controls on the archival 796 system? 798 6. Under what circumstances, if any, can a private key be 799 transferred into or from a cryptographic module? Who is 800 permitted to perform such a transfer operation? In what form is 801 the private key during the transfer (e.g., plaintext, encrypted, 802 or split key)? 804 7. How is the private key stored in the module (e.g., plaintext, 805 encrypted, or split key)? 807 8. Who can activate (use) the private key? What actions must be 808 performed to activate the private key (e.g., login, power on, 809 supply PIN, insert token/key, automatic, etc.)? Once the key is 810 activated, is the key active for an indefinite period, active 811 for one time, or active for a defined time period? 813 9. Who can deactivate the private key and how? Examples of methods 814 of deactivating private keys include logging out, turning the 815 power off, removing the token/key, automatic deactivation, and 816 time expiration. 818 10. Who can destroy the private key and how? Examples of methods of 819 destroying private keys include token surrender, token 820 destruction, and zeroizing the key. 822 4.5.3. Other aspects of key pair management 824 Other aspects of key management need to be considered for the zone 825 operator and other participants. For each of these types of 826 entities, the following questions may need to be answered: 828 1. What are the life-cycle states for the management of any Signing 829 Keys? 831 2. What is the operational period of these keys? What are the usage 832 periods or active lifetimes for the pairs? 834 4.5.4. Activation data 836 Activation data refers to data values other than whole private keys 837 that are required to operate private keys or cryptographic modules 838 containing private keys, such as a PIN, passphrase, or portions of a 839 private key used in a key-splitting scheme. Protection of activation 840 data prevents unauthorized use of the private key and potentially 841 needs to be considered for the zone operator and other participants. 842 Such a consideration may need to address the entire life-cycle of the 843 activation data from generation through archival and destruction. 844 For each of the entity types, all of the questions listed in 4.5.1 845 through 4.5.3 potentially need to be answered with respect to 846 activation data rather than with respect to keys. 848 4.5.5. Computer security controls 850 This subcomponent is used to describe computer security controls such 851 as: 853 1. use of the trusted computing base concept or equivalent; 854 2. discretionary access control, labels, mandatory access controls; 856 3. object re-use; 858 4. auditing; 860 5. identification and authentication; 862 6. trusted path; and 864 7. security testing. 866 Product assurance may also be addressed. 868 A computer security rating for computer systems may be specified. 869 The rating could be based, for example, on a protection profile (PP) 870 of the Common Criteria for Information Technology Security 871 Evaluation, ISO/IEC 15408:1999. 873 This subcomponent may also address requirements for product 874 assurance, product evaluation analysis, testing, profiling, product 875 certification, and/or product accreditation. 877 4.5.6. Network security controls 879 This subcomponent addresses network security related controls, 880 including firewalls, routers and remote access. 882 4.5.7. Timestamping 884 This subcomponent addresses requirements or practices relating to the 885 use of timestamps on various data. It may also discuss whether or 886 not the time-stamping application must use a trusted time source. 888 4.5.8. Life cycle technical controls 890 This subcomponent addresses system development controls and security 891 management controls. 893 System development controls include development environment security, 894 development personnel security, configuration management security 895 during product maintenance, software engineering practices, software 896 development methodology, modularity, layering, use of failsafe design 897 and implementation techniques (e.g. defensive programming) and 898 development facility security. 900 Security management controls include execution of tools and 901 procedures to ensure that the operational systems and networks adhere 902 to configured security. These tools and procedures include checking 903 the integrity of the security software, firmware, and hardware to 904 ensure their correct operation. 906 4.6. Zone signing 908 This component covers all aspects of zone signing, including the 909 cryptographic specification surrounding the Signing Keys, signing 910 scheme, and methodology for key roll-over and the actual zone 911 signing. Child zones and other relying parties may depend on the 912 information in this section to understand the expected data in the 913 signed zone and determine their own behaviour. In addition, this 914 section will be used to state the compliance to the cryptographic and 915 operational requirements pertaining to zone signing, if any. 917 4.6.1. Key lengths, key types and algorithms 919 This subcomponent describes the key generation algorithm, the key 920 types used for signing the key set and zone data, and the key length 921 used to create the keys. It should also cover how changes to these 922 key lengths, key types and algorithms may be performed. 924 4.6.2. Authenticated denial of existence 926 Authenticated denial of existence refers to the usage of NSEC 927 [RFC4034], NSEC3 [RFC5155] or any other mechanism defined in the 928 future that is used to authenticate the denial of existence of 929 resource records. This subcomponent describes what mechanisms are 930 used, any parameters associated with that mechanism, and how these 931 mechanisms and parameters may be changed. 933 4.6.3. Signature format 935 This subcomponent is used to describe the signing method and 936 algorithms used for the zone signing. 938 4.6.4. Key roll-over 940 This subcomponent explains the key roll-over scheme for each key 941 type. 943 4.6.5. Signature life-time and re-signing frequency 945 This subcomponent describes the life-cycle of the Resource Record 946 Signature (RRSIG) record. 948 4.6.6. Verification of resource records 950 This subsection addresses the controls around the verification of the 951 resource records in order to validate and authenticate the data to be 952 signed. This may include a separate key set verification process if 953 using a split key signing scheme. 955 4.6.7. Resource records time-to-live 957 This subcomponent specifies the resource records' time-to-live (TTL) 958 for all types relevant to DNSSEC, as well as any global parameters 959 that affects the caching mechanisms of the resolvers. 961 4.7. Compliance audit 963 To prove the compliance with a Policy or the statements in the 964 Practices Statement a compliance audit can be conducted. This 965 component describes how the audit is to be conducted at the zone 966 operator and possibly at other involved entities. 968 4.7.1. Frequency of entity compliance audit 970 This subcomponent describes the frequency of the compliance audit. 972 4.7.2. Identity/qualifications of auditor 974 This subcomponent addresses what qualifications are required of the 975 auditor. For instance it may that an auditor must belong to a 976 specific association or that they have certain certifications. 978 4.7.3. Auditor's relationship to audited party 980 This subcomponent is used to clarify the relationship between the 981 auditor and the entity being audited. This becomes important if 982 there are any requirements or guidelines for the selection of the 983 auditor. 985 4.7.4. Topics covered by audit 987 Topics covered by audit depends on the scope of the audit. Since the 988 DNSSEC Policy and Practices Statement is the document to be audited 989 against, it is ideal to set the scope of the audit to the scope of 990 the DP/DPS. However, the scope may be narrowed down or expanded as 991 needed; for example, if there are not enough resources to conduct a 992 full audit, or some portion is under development and not ready for 993 the audit. 995 4.7.5. Actions taken as a result of deficiency 997 This subcomponent specifies the action taken in order to correct any 998 discrepancy that has a security impact. This could be the 999 remediation process for the audit findings or any other action to 1000 correct any discrepancy with the DNSSEC Policy or Practices 1001 Statement. 1003 4.7.6. Communication of results 1005 This subcomponent specifies how the results of the audit are 1006 communicated to the stakeholders. 1008 4.8. Legal matters 1010 The introduction of DNSSEC into a zone may have legal implications. 1011 Consequently, it may be appropriate to declare the legal status of 1012 the binding embodied in the DNSSEC digital signatures and to clarify 1013 on any limitations of liability assumed by the Registry Manager. 1015 In most cases, the DPS is not a contract or part of a contract; 1016 instead, it is laid out so that its terms and conditions are applied 1017 to the parties by separate documents, such as registrar or registrant 1018 agreements. In other cases its contents may form part of a legal 1019 contract between parties (either directly or via other agreements). 1020 In this case legal expertise should be consulted when drawing up 1021 sections of the document that may have contractual implications. 1023 At a minimum, the legal matters section should indicate under what 1024 jurisdiction the registry is operated, and provide references to any 1025 associated agreements that are in force. It may also be appropriate 1026 to inform of any identified implications on the protection of 1027 personally identifiable private information. 1029 5. Outline of a Set of Provisions 1031 This section contains a recommended outline for a set of provisions, 1032 intended to serve as a checklist or a standard template for use by DP 1033 or DPS writers. Such a common outline will facilitate: 1035 (a) Comparison of a DPS with a DP to ensure that the DPS faithfully 1036 implements the policy. 1038 (b) Comparison of two DPSs. 1040 Section 4 of this document is structured so that it provides guidance 1041 for each corresponding component and sub-component of the outline. 1043 1. INTRODUCTION 1044 1.1. Overview 1045 1.2. Document name and identification 1046 1.3. Community and applicability 1047 1.4. Specification administration 1048 1.4.1. Specification administration organization 1049 1.4.2. Contact information 1050 1.4.3. Specification change procedures 1051 2. PUBLICATION AND REPOSITORIES 1052 2.1. Repositories 1053 2.2. Publication of public keys 1054 3. OPERATIONAL REQUIREMENTS 1055 3.1. Meaning of domain names 1056 3.2. Identification and authentication of child zone manager 1057 3.3. Registration of delegation signer (DS) resource records 1058 3.4. Method to prove possession of private key 1059 3.5. Removal of DS resource records 1060 3.5.1. Who can request removal 1061 3.5.2. Procedure for removal request 1062 3.5.3. Emergency removal request 1063 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1064 4.1. Physical controls 1065 4.1.1. Site location and construction 1066 4.1.2. Physical access 1067 4.1.3. Power and air conditioning 1068 4.1.4. Water exposures 1069 4.1.5. Fire prevention and protection 1070 4.1.6. Media storage 1071 4.1.7. Waste disposal 1072 4.1.8. Off-site backup 1073 4.2. Procedural controls 1074 4.2.1. Trusted roles 1075 4.2.2. Number of persons required per task 1076 4.2.3. Identification and authentication for each role 1077 4.2.4. Tasks requiring separation of duties 1078 4.3. Personnel controls 1079 4.3.1. Qualifications, experience, and clearance 1080 requirements 1081 4.3.2. Background check procedures 1082 4.3.3. Training requirements 1083 4.3.4. Job rotation frequency and sequence 1084 4.3.5. Sanctions for unauthorized actions 1085 4.3.6. Contracting personnel requirements 1086 4.3.7. Documentation supplied to personnel 1087 4.4. Audit logging procedures 1088 4.4.1. Types of events recorded 1089 4.4.2. Frequency of processing log 1090 4.4.3. Retention period for audit log information 1091 4.4.4. Protection of audit log 1092 4.4.5. Audit log backup procedures 1093 4.4.6. Audit collection system 1094 4.4.7. Vulnerability assessments 1095 4.5. Compromise and disaster recovery 1096 4.5.1. Incident and compromise handling procedures 1097 4.5.2. Corrupted computing resources, software, and/or 1098 data 1099 4.5.3. Entity private key compromise procedures 1100 4.5.4. Business continuity and IT disaster recovery 1101 capabilities 1102 4.6. Entity termination 1103 5. TECHNICAL SECURITY CONTROLS 1104 5.1. Key pair generation and installation 1105 5.1.1. Key pair generation 1106 5.1.2. Public key delivery 1107 5.1.3. Public key parameters generation and quality 1108 checking 1109 5.1.4. Key usage purposes 1110 5.2. Private key protection and cryptographic module 1111 engineering controls 1112 5.2.1. Cryptographic module standards and controls 1113 5.2.2. Private key (m-of-n) multi-person control 1114 5.2.3. Private key escrow 1115 5.2.4. Private key backup 1116 5.2.5. Private key storage on cryptographic module 1117 5.2.6. Private key archival 1118 5.2.7. Private key transfer into or from a cryptographic 1119 module 1120 5.2.8. Method of activating private key 1121 5.2.9. Method of deactivating private key 1122 5.2.10. Method of destroying private key 1123 5.3. Other aspects of key pair management 1124 5.4. Activation data 1125 5.4.1. Activation data generation and installation 1126 5.4.2. Activation data protection 1127 5.4.3. Other aspects of activation data 1128 5.5. Computer security controls 1129 5.6. Network security controls 1130 5.7. Timestamping 1131 5.8. Life cycle technical controls 1132 6. ZONE SIGNING 1133 6.1. Key lengths, key types and algorithms 1134 6.2. Authenticated denial of existence 1135 6.3. Signature format 1136 6.4. Key roll-over 1137 6.5. Signature life-time and re-signing frequency 1138 6.6. Verification of resource records 1139 6.7. Resource records time-to-live 1140 7. COMPLIANCE AUDIT 1141 7.1. Frequency of entity compliance audit 1142 7.2. Identity/qualifications of auditor 1143 7.3. Auditor's relationship to audited party 1144 7.4. Topics covered by audit 1145 7.5. Actions taken as a result of deficiency 1146 7.6. Communication of results 1147 8. LEGAL MATTERS 1149 6. IANA considerations 1151 No action required. 1153 7. Security considerations 1155 The sensitivity of the information protected by DNSSEC on all levels 1156 in the DNS tree will vary significantly. In addition, there are no 1157 restrictions as to what types of information that can be protected 1158 using DNSSEC. Entities must evaluate their own environment and the 1159 chain of trust originating from their Trust Anchor, the associated 1160 threats and vulnerabilities, to determine the level of risk they are 1161 willing to accept. 1163 8. Acknowledgements 1165 The authors gratefully acknowledge, in no particular order, the 1166 contributions of the following persons: 1168 Richard Lamb 1170 Jakob Schlyter 1172 Stephen Morris 1174 9. References 1175 9.1. Normative references 1177 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1178 Rose, "DNS Security Introduction and Requirements", 1179 RFC 4033, March 2005. 1181 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1182 Rose, "Resource Records for the DNS Security Extensions", 1183 RFC 4034, March 2005. 1185 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1186 Rose, "Protocol Modifications for the DNS Security 1187 Extensions", RFC 4035, March 2005. 1189 9.2. Informative references 1191 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1192 Wu, "Internet X.509 Public Key Infrastructure Certificate 1193 Policy and Certification Practices Framework", RFC 3647, 1194 November 2003. 1196 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1197 Security (DNSSEC) Hashed Authenticated Denial of 1198 Existence", RFC 5155, March 2008. 1200 Authors' Addresses 1202 Fredrik Ljunggren 1203 Kirei AB 1204 P.O. Box 53204 1205 Goteborg SE-400 16 1206 Sweden 1208 Email: fredrik@kirei.se 1210 Anne-Marie Eklund Lowinder 1211 .SE (The Internet Infrastructure Foundation) 1212 P.O. Box 7399 1213 Stockholm SE-103 91 1214 Sweden 1216 Email: amel@iis.se 1217 Tomofumi Okubo 1218 Internet Corporation For Assigned Names and Numbers 1219 4676 Admiralty Way, Suite 330 1220 Marina del Ray, CA 90292 1221 USA 1223 Email: tomofumi.okubo@icann.org