idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-10.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 (September 29, 2012) is 4219 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: April 2, 2013 .SE 6 T. Okubo 7 ICANN 8 September 29, 2012 10 A Framework for DNSSEC Policies and DNSSEC Practice Statements 11 draft-ietf-dnsop-dnssec-dps-framework-10 13 Abstract 15 This document presents a framework to assist writers of DNSSEC 16 Policies and DNSSEC Practice Statements, such as Domain Managers and 17 Zone Operators on both the top-level and secondary level, who are 18 managing and operating a DNS zone with Security Extensions (DNSSEC) 19 implemented. 21 In particular, the framework provides a comprehensive list of topics 22 that should be considered for inclusion into a DNSSEC Policy 23 definition and Practice Statement. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 2, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 6 67 3.3. Relationship between DNSSEC Policy and Practice 68 Statement . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 8 70 4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10 71 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2. Publication and repositories . . . . . . . . . . . . . . . 11 73 4.3. Operational requirements . . . . . . . . . . . . . . . . . 12 74 4.4. Facility, management and operational controls . . . . . . 12 75 4.5. Technical security controls . . . . . . . . . . . . . . . 17 76 4.6. Zone signing . . . . . . . . . . . . . . . . . . . . . . . 21 77 4.7. Compliance audit . . . . . . . . . . . . . . . . . . . . . 22 78 4.8. Legal matters . . . . . . . . . . . . . . . . . . . . . . 23 79 5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23 80 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 81 7. Security considerations . . . . . . . . . . . . . . . . . . . 26 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 9.1. Normative references . . . . . . . . . . . . . . . . . . . 27 85 9.2. Informative references . . . . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 1.1. Background 92 The Domain Name System (DNS) was not originally designed with strong 93 security mechanisms to provide integrity and authenticity of its 94 data. Over the years, a number of vulnerabilities have been 95 discovered that threaten the reliability and trustworthiness of the 96 system. 98 The Domain Name System Security Extensions (DNSSEC, [RFC4033], 99 [RFC4034], [RFC4035]) address these vulnerabilities by using public 100 key cryptography to add data origin authentication, data integrity 101 verification, and authenticated denial of existence capabilities to 102 the DNS. In short, DNSSEC provides a way for software to verify the 103 origin of DNS data and validate that it has not been modified in 104 transit or by intermediaries. 106 To provide a means for users who rely on signed responses from the 107 DNS ("relying parties") to evaluate the strength and security of the 108 DNSSEC chain of trust, an entity operating a DNSSEC enabled zone may 109 choose to publish a DNSSEC Practice Statement (DPS), comprising 110 statements describing critical security controls and procedures 111 relevant for scrutinizing the trustworthiness of the system. The DPS 112 may also identify any DNSSEC Policies it supports, explaining how it 113 meets their requirements. 115 Even though this document is heavily inspired by the Internet X.509 116 Public Key Infrastructure Certificate Policy and Certification 117 Practices Framework [RFC3647], with large parts being drawn from that 118 document, the properties and structure of the DNSSEC trust model are 119 fundamentally different from those of the X.509 PKI. 121 1.2. Purpose 123 The purpose of this document is twofold. Firstly, the document 124 explains the concepts of a DNSSEC Policy (DP) and of a DNSSEC 125 Practice Statement (DPS), and to describe the relationship between 126 the two. Secondly, it presents a framework to encourage and assist 127 writers of Policies and Practice Statements in creating consistent 128 and comparable documents. In particular, the framework identifies 129 the elements that should be considered in formulating a DP or a DPS. 130 It does not, however, define a particular Policy or Practice 131 Statement, nor does it seek to provide legal advice or 132 recommendations as to the contents. 134 1.3. Scope 136 The scope of this document is limited to discussion of the topics 137 that can be covered in a DP or a DPS, but does not go into the 138 specific details that could possibly be included in each one. In 139 particular, this document describes the types of information that 140 should be considered for inclusion in them. 142 The DNSSEC Policy and Practice Statement framework should be viewed 143 and used as a checklist of factors that ought be taken in to 144 consideration prior to deploying DNSSEC, and as an outline to create 145 an operational practices disclosure document. As such, it focuses on 146 the topics affected by the introduction of DNSSEC into a zone. Other 147 aspects, such as the operations of name servers and registry systems, 148 are considered out of scope. The framework is primarily aimed at TLD 149 managers and organizations providing registry services, but may be 150 used by high-value domain holders and so serve as a checklist for 151 DNSSEC readiness at a high level. 153 This document assumes that the reader is familiar with the general 154 concepts of DNS, DNSSEC and PKI. 156 2. Definitions 158 This document makes use of the following defined terms: 160 Audit logs - Control evidence information to prove the integrity of 161 processes. This may be generated by DNS and DNSSEC-related systems, 162 supplied by the surrounding facility, or obtained from manually 163 generated, non-electronic documentation. Audit logs will be examined 164 by the internal and/or external auditors. 166 Activation data - Data values, other than keys, required to operate 167 the cryptographic modules used to protect the keys from unauthorized 168 use. 170 Chain of Trust - A hierarchical structure of trust consisting of DNS 171 keys, signatures, and delegation signer records that, when validated 172 in a series, can provide proof of authenticity of the last element in 173 the chain, providing that the first element is trusted. Usually, the 174 first element is a trust anchor. 176 Compromise (Key Compromise) - Key Compromise is a situation where the 177 private component of a Signing Key is lost, stolen, exposed, modified 178 or used in an unauthorized manner. More strictly, even a suspicion 179 that one of these has occurred will be enough to be considered as key 180 compromise. 182 DNS - The Domain Name System (DNS) is a hierarchical global naming 183 catalog for computers, services, or any resource connected to the 184 Internet. 186 DNS Zone - A portion of the global Domain Name System (DNS) namespace 187 for which administrative responsibility has been delegated. 189 DNSSEC - DNS Security Extensions (DNSSEC) is a set of IETF 190 specifications [RFC4033], [RFC4034], [RFC4035] that use public key 191 cryptography to add data origin authentication, data integrity 192 verification, and authenticated denial of existence capabilities to 193 DNS. 195 DNSSEC Policy - A DNSSEC Policy (DP) sets forth the security 196 requirements and standards to be implemented for a DNSSEC signed 197 zone. 199 DNSSEC Practice Statement - A DNSSEC Practice Statement (DPS) is a 200 practices disclosure document that may support and be a supplemental 201 document to the DNSSEC Policy (if such exists), and states how the 202 management of a given zone implements procedures and controls at a 203 high level. 205 Key rollover - An operational process to change one of the DNSSEC 206 keys used for signing a zone via distribution of public keys in a 207 trusted manner. 209 Multi-person control - A security concept to distribute the authority 210 of an operation over multiple persons, to mitigate threats caused by 211 a single authorized individual. For example, a key recovery function 212 may require some number of authorized individuals (m) out of the (n) 213 to whom a portion of the recovery key was distributed, to combine 214 their key fragments, before key recovery can occur. 216 PKI - Public Key Infrastructure (PKI) is a concept that makes use of 217 asymmetric cryptography to provide a system with integrity, 218 authentication, confidentiality and via distribution of public keys 219 in a trusted manner. 221 Policy Authority - The body responsible for setting and administering 222 a DNSSEC Policy, and for determining whether a DPS is suitable for 223 that Policy. 225 Relying Party - An entity that relies on a signed response from the 226 DNS. 228 Repository - A location on the Internet to store DP, DPS, Trust 229 Anchors and other related information that should be kept public. 231 Security Posture - A Security Posture is an indicator of how secure 232 an entity is and how secure the entity should be. It is the result 233 of an adequate threat model and risk assessment. 235 Separation of Duties - A security concept that limits the influence 236 of a single person by segregating roles and responsibilities. 238 Signing Key - Private component of an asymmetric key-pair that is 239 used for signing of resource records within the zone. Note that the 240 other component, called public key, is used for signature validation. 242 TLD - A Top-Level Domain (TLD) is one of the domains at the highest 243 level below the root in the hierarchy of the DNS. 245 Trust Anchor - Public portion of a key-pair that is the authoritative 246 entity used to authenticate the first element in a chain of trust. 248 3. Concepts 250 This section describes the concepts of a DNSSEC Policy and of a 251 DNSSEC Practices Statement. Other related concepts are described as 252 well. 254 3.1. DNSSEC Policy 256 A DNSSEC Policy (DP) sets forth requirements that are appropriate for 257 a specified level of assurance. For example, a DP may encompass all 258 topics of this framework, each with a certain set of security 259 requirements, possibly grouped according to impact. The progression 260 from medium to high levels of assurance would correspond to 261 increasing security requirements and corresponding increasing levels 262 of assurance. 264 A DP also constitues a basis for an audit, accreditation, or another 265 assessment of an entity. Each entity can be assessed against one or 266 more DPs that it claims to implement. 268 3.2. DNSSEC Practice Statement 270 Most zone managers using DNSSEC will not have the need to create a 271 thorough and detailed statement of practices. For example, a 272 registrant may be the sole relying party of its own zone and would 273 already be aware of the nature and trustworthiness of its services. 274 In other cases, a zone manager may provide registration services with 275 only a very low level of assurances where the domain names being 276 secured may pose only marginal risks if compromised. Publishing a 277 DPS is most relevant for entities operating a zone that contains a 278 significant number of delegations to other entities. 280 A DNSSEC Practice Statement (DPS) should contain information that is 281 relevant to the stakeholders of the relevant zone(s). Since these 282 generally include the Internet community, it should not contain such 283 information that could be considered to be sensitive details of an 284 entity's operations. 286 A DNSSEC Practice Statement may identify a supported DP, which may 287 subsequently be used by a relying party to evaluate the 288 trustworthiness of any digital signatures verified using the public 289 key of that entity. 291 3.3. Relationship between DNSSEC Policy and Practice Statement 293 A DNSSEC Policy and a DNSSEC Practice Statement address the same set 294 of topics that are of interest to the stakeholders in terms of the 295 degree to which a DNSSEC digital signature may be trusted. The 296 primary difference is in the focus of their provisions. A Policy 297 sets forth the requirements and standards to be implemented for a 298 DNSSEC signed zone, and may be used to communicate requirements that 299 must be met by complying parties; as such it may also be used to 300 determine or establish equivalency between policies associated with 301 different zones. A Practice Statement, by contrast, describes how a 302 zone operator (and possibly other participants in the management of a 303 given zone) implements procedures and controls to meet the 304 requirements of applicable Policies. In other words, the Policy says 305 what needs to be done, the Practice Statement says what is being 306 done. 308 An additional difference between a Policy and a Practice Statement 309 relates to the scope of coverage of the two kinds of documents, in 310 terms of its applicability. A Policy may apply to multiple 311 organizations or multiple zones. By contrast, a Practice Statement 312 would usually apply only to a single zone operator or a single 313 organization, since it describes the actual controls in place that 314 meet the requirements of applicable Policy. 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, explaining how it meets the 321 requirements of the Policy. Alternatively, a zone operator that is 322 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. The zone operator might do so to provide 325 transparency and to gain community trust in its operations. 327 A Policy and a Practice Statement also differ in the level of detail 328 each expresses: 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, absent a 341 controlling Policy 343 (b) A Policy may serve the purpose of establishing a common basis of 344 trusted operation throughout a set of zones in the DNS 345 hierarchy. By contrast, a Practice Statement is a statement of 346 a single zone operator or organization. 348 (c) A Practice Statement is generally more detailed than a Policy 349 and specifies how the zone operator or organization implements 350 critical processes and controls, and how the entity meets any 351 requirements specified in the one or more Policies under which 352 it operates DNSSEC. 354 3.4. Set of Provisions 356 A set of provisions is a collection of Policy requirements or 357 Practice statements, which may employ the approach described in this 358 framework by covering the topics appearing in Section 5 below. The 359 topics are described in detail in section 4. 361 A Policy can be expressed as a single set of provisions. 363 A Practice Statement can also be expressed as a single set of 364 provisions with each component addressing the requirements of one or 365 more Policies. Alternatively, it could be a set of provisions that 366 do not reference any particular policy but instead describe a set of 367 self-imposed controls to the relying parties. For example, a 368 Practice Statement could be expressed as a combination of the 369 following: 371 (a) a list of Policies supported by the DPS; 373 (b) for each Policy in (a), a set of provisions that contains 374 statements addressing the requirements by filling in details not 375 stipulated in that policy or expressly left to the discretion of 376 the implementer. Such statements serve to show how this 377 particular Practice Statement implements the requirements of the 378 particular Policy; or 380 (c) a set of provisions that contains statements regarding the 381 DNSSEC operations practices, independent of any Policy. 383 The statements provided in (b) may augment or refine the stipulations 384 of an applicable Policy, but generally they must not conflict with 385 the stipulations. In certain cases however, a Policy Authority may 386 permit exceptions because certain compensating controls of the entity 387 disclosed in its Practices Statement allow it to provide a level of 388 assurance equivalent to full compliance with the policy. 390 The framework outlines the contents of a set of provisions, in terms 391 of eight primary components, as follows: 393 1. Introduction 395 2. Publication and Repositories 397 3. Operational Requirements 399 4. Facility, Management, and Operational Controls 401 5. Technical Security Controls 403 6. Zone Signing 405 7. Compliance Audit 407 8. Legal Matters 409 This framework can be used by Policy Authorities to write DNSSEC 410 Policies and by zone operators to write a DNSSEC Practice Statements. 411 Having a set of documents with the same structure facilitates 412 comparisons with the corresponding documents of other zones. 414 4. Contents of a Set of Provisions 416 This section describes the contents of a set of provisions. Refer to 417 Section 5 for the complete outline. 419 Drafters of DPSs conforming to this framework are permitted to add 420 additional levels of subcomponents below those described here to meet 421 specific needs. All components listed in Section 5 should be 422 present, but drafters may leave components empty, only stating "no 423 stipulation", if so required. 425 4.1. Introduction 427 This component identifies and introduces the set of provisions, and 428 indicates the types of entities and applications for which the 429 document (either Policy or Practice Statement) is targeted. 431 4.1.1. Overview 433 This subcomponent provides a general introduction to the document. 434 It can also be used to provide a description of entities to which the 435 Policy or Practice Statement applies. 437 4.1.2. Document name and identification 439 This subcomponent provides any applicable names or other identifiers 440 of the document. 442 4.1.3. Community and applicability 444 This subcomponent identifies the stakeholders along with their 445 expected roles and responsibilities. These include (but are not 446 limited to) an entity signing the zone, entities relying on the 447 signed zone, other entities that have operational dependency on the 448 signed zone, and an entity that entrusted the zone signing. 450 4.1.4. Specification administration 452 This subcomponent contains the contact details of the organization 453 responsible for managing the DP/DPS, as well as the specification 454 change procedures. These procedures may include the description of 455 the notification mechanisms used to provide advance notice of 456 amendments which are deemed to materially affect the assurance 457 provided by the entity, and how/when such amendments will be 458 communicated to the stakeholders. 460 If a Policy Authority is responsible for determining whether a DPS is 461 suitable for the Policy, this subcomponent may include the name and 462 contact information of the entity in charge of making such a 463 determination. In this case, the subcomponent also includes the 464 procedures by which this determination is made. 466 4.2. Publication and repositories 468 The component describes the requirements for an entity to publish 469 information regarding its practices, public keys, the current status 470 of such keys together with details relating to the repositories in 471 which the information is held. This may include the responsibilities 472 of publishing the DPS and of identifying documents that are not made 473 publicly available owing to their sensitive nature, e.g. security 474 controls, clearance procedures, or business information. 476 4.2.1. Repositories 478 This subcomponent describes the repository mechanisms used for making 479 information available to the stakeholders, and may include: 481 o The locations of the repositories and the means by which they may 482 be accessed; 484 o An identification of the entity or entities that operate 485 repositories, such as a zone operator or a TLD Manager; 487 o Access control on published information objects. 489 o Any notification services which may be subscribed to by the 490 stakeholders; 492 4.2.2. Publication of public keys 494 This subcomponent contains information relating to the publication of 495 public keys: 497 o Whether the public keys are included in a key hierarchy, published 498 as Trust Anchors or both; 500 o The data formats and methods available to validate the 501 authenticity of public keys; 503 o The frequency and timing of publishing new information 504 (principally as advance notice for stakeholders relying on the 505 public keys). 507 4.3. Operational requirements 509 This component describes the operational requirements when operating 510 a DNSSEC signed zone. 512 4.3.1. Meaning of domain names 514 This subcomponent describes the overall policy of child zone naming, 515 if any. 517 4.3.2. Identification and authentication of child zone manager 519 This subcomponent describes how the child zone manager has initially 520 been identified, and how any subsequent change request is 521 authenticated as originating from the manager or their authorized 522 representative. 524 4.3.3. Registration of delegation signer (DS) resource records 526 This subcomponent describes the process of establishing the chain-of- 527 trust to the child zone by incorporating delegation signer (DS) 528 record(s) into the zone. 530 4.3.4. Method to prove possession of private key 532 This subcomponent describes whether, and if so under what 533 circumstances, the child zone manager is required to provide proof of 534 the possession of the private component of any current or subsequent 535 child zone Signing Key corresponding to a DS record they wish to 536 incorporate into the parent zone. 538 4.3.5. Removal of DS resource records 540 This subcomponent will explain how, when, and under what 541 circumstances the DS records may be removed from the zone. 543 4.4. Facility, management and operational controls 545 This component describes non-technical security controls (i.e., 546 physical, procedural, and personnel) in use by the entity to securely 547 perform the DNSSEC related functions. Such controls include physical 548 access, key management, disaster recovery, auditing, and archiving. 550 These non-technical security controls are critical for trusting the 551 DNSSEC signatures, since lack of security may compromise DNSSEC 552 operations. For example, it could result in the creation of 553 signatures with erroneous information or in the compromise of the 554 Signing Key. 556 Within each subcomponent, separate consideration will usually need to 557 be given to each entity type. 559 4.4.1. Physical controls 561 In this subcomponent, the physical controls on the facility housing 562 the entity systems are described. Topics addressed may include: 564 o Site location and construction, such as requirements for multiple 565 tiers of physical barriers, construction requirements for high- 566 security areas etc. It may also describe the use of locked rooms, 567 cages, safes, and cabinets etc.; 569 o Physical access, i.e. mechanisms to control access from one area 570 of the facility to another or additional controls for reaching 571 into higher tiers, such as dual-access control and two-factor 572 authentication; 574 o Power and air conditioning; 576 o Water exposures; 578 o Fire prevention and protection; 580 o Media storage, e.g. requiring the storage of backup media in a 581 separate location that is physically secure and protected from 582 fire, smoke, particle, and water damage; 584 o Waste disposal; and 586 o Off-site backup. 588 4.4.2. Procedural controls 590 In this subcomponent, requirements for recognizing trusted roles are 591 described, together with a description of the responsibilities of 592 each role. Examples of trusted roles include system administrators, 593 security officers, crypto officers and system auditors. 595 For each task identified, the number of individuals required to 596 perform the task (m of n rule, if applicable) should be stated for 597 each role. Identification and authentication requirements for each 598 role may also be defined. 600 This subcomponent also includes the separation of duties in terms of 601 the roles that cannot be performed by the same individuals. 603 4.4.3. Personnel controls 605 This subcomponent addresses the following: 607 o Qualifications, experience, and clearances that personnel must 608 have as a condition of filling trusted roles or other important 609 roles. Examples include credentials, job experiences, and 610 official government clearances; 612 o Background checks and clearance procedures that are required in 613 connection with the hiring of personnel filling trusted roles or 614 other important roles. Such roles may require a check of their 615 criminal records, financial records, references, and any 616 additional clearances required for the position in question; 618 o Training requirements and training procedures for each role 619 following the hiring of personnel; 621 o Any retraining period and retraining procedures for each role 622 after completion of initial training; 624 o Frequency and sequence for job rotation among various roles; 626 o Sanctions against personnel for unauthorized actions, such as 627 unauthorized use of authority, or unauthorized use of the entity 628 systems; 630 o Controls on personnel that are contractors rather than employees 631 of the entity; examples include: 633 * Bonding requirements on contract personnel; 635 * Contractual requirements including indemnification for damages 636 due to the actions of the contractor personnel; 638 * Auditing and monitoring of contractor personnel; and 640 * Other controls on contracting personnel. 642 o Documentation to be supplied to personnel during initial training, 643 retraining, or otherwise. 645 4.4.4. Audit logging procedures 647 This subcomponent is used to describe event logging and audit 648 systems, implemented for the purpose of maintaining an audit trail 649 and to provide evidence of process integrity. Elements include the 650 following: 652 o Types of events recorded, such as records of key roll over and 653 other key management operations, the personnel assigned to various 654 roles, attempts to access the system and requests made to the 655 system; 657 o Frequency with which audit logs are processed or archived, for 658 example, weekly, following an alarm or anomalous event, or 659 whenever the audit log size reaches a particular size; 661 o Period for which audit logs are kept; 663 o Protection of audit logs: 665 * Who can view audit logs, for example only the audit 666 administrator; 668 * Protection against modification of audit logs, for instance a 669 requirement that no one may modify or delete the audit records 670 or that only an audit administrator may delete an audit file as 671 part of audit file rotation; and 673 * Protection against deletion of audit logs. 675 o Audit log backup procedures; 677 o Whether the audit log collection function is internal or external 678 to the system; 680 o Whether the subject who caused an audit event to occur is notified 681 of the audit action; and 683 o Vulnerability assessments, for example, where audit data is run 684 through a tool that identifies potential attempts to breach the 685 security of the system. 687 4.4.5. Compromise and disaster recovery 689 This subcomponent describes requirements relating to notification and 690 recovery procedures in the event of compromise or disaster. Each of 691 the following may need to be addressed separately: 693 o Identification or listing of the applicable incident and 694 compromise reporting and handling procedures, which may include 695 the investigation of measures to prevent the event from 696 reoccurring. 698 o The recovery procedures used if computing resources, software, 699 and/or data are corrupted or suspected to have been corrupted. 700 These procedures describe how, and under what circumstances 701 operations of the system are to be suspended, how and when normal 702 operations are resumed, how the stakeholders are to be informed 703 and how to assess the damage and carry out the root cause 704 analysis. 706 o The recovery procedures used if any keys are compromised. These 707 procedures describe how a secure environment is re-established, 708 how the keys are rolled over, how a new Trust Anchor is provided 709 to the community (if applicable), and how new zone information is 710 published. 712 o The entity's capabilities to ensure business continuity following 713 a natural or other disaster. Such capabilities may include the 714 availability of a disaster recovery site at which operations may 715 be recovered. They may also include procedures for securing its 716 facility during the period of time following a natural or other 717 disaster and before a secure environment is re-established, either 718 at the original site or at a disaster recovery site. For example, 719 procedures to protect against theft of sensitive materials from an 720 earthquake-damaged site. 722 4.4.6. Entity termination 724 This subcomponent describes requirements relating to procedures for 725 termination of a contract with an entity, termination notification 726 and transition of responsibilities to another entity. The purpose 727 may be to ensure that the transition process will be transparent to 728 the relying parties and will not affect the services. 730 4.5. Technical security controls 732 This component is used to define the security measures taken to 733 protect the cryptographic keys and activation data (e.g., PINs, 734 passwords, or manually-held key shares) relevant to DNSSEC 735 operations. Secure key management is critical to ensure that all 736 secret and private keys and activation data are protected and used 737 only by authorized personnel. 739 Also described here are other technical security controls used to 740 perform the functions of key generation, authentication, 741 registration, auditing, and archiving. Technical controls include 742 life-cycle security controls, software development environment 743 security, and operational security controls. 745 If applicable, other technical security controls on repositories, 746 authoritative name servers, or other participants may also be 747 documented here. 749 4.5.1. Key pair generation and installation 751 Key pair generation and installation need to be considered, which may 752 involve answering the following questions: 754 1. Who generates the zone's public/private key pairs? How is the 755 key generation performed? Is the key generation performed by 756 hardware or software? 758 2. How is the private key installed in all parts of the key 759 management system? 761 3. How are the zone's public keys provided securely to the parent 762 zone and potential relying parties? 764 4. Who generates the public key parameters. Is the quality of the 765 parameters checked during key generation? 767 5. For what purposes may the keys be used, and/or for what purposes 768 should usage of the key be restricted? 770 4.5.2. Private key protection and cryptographic module engineering 771 controls 773 Requirements for private key protection and cryptographic modules 774 need to be considered for key generation and creation of signatures. 775 The following questions may need to be answered: 777 1. What standards, if any, are required for the cryptographic 778 module used to generate the keys? A cryptographic module can be 779 composed of hardware, software, firmware, or any combination of 780 them. For example, are the zone's signatures required to be 781 generated using modules compliant with the US FIPS 140-2 782 standard? If so, what is the required FIPS 140-2 level of the 783 module? Are there any other engineering or other controls 784 relating to a cryptographic module, such as the identification 785 of the cryptographic module boundary, input/output, roles and 786 services, finite state machine, physical security, software 787 security, operating system security, algorithm compliance, 788 electromagnetic compatibility, and self tests. 790 2. Is the private key under m of n multi-person control? If yes, 791 provide m and n (two person control is a special case of m of n, 792 where m = 2 and n >= 2). 794 3. Is the private key escrowed? If so, who is the escrow agent, in 795 what form is the key escrowed (e.g. plaintext, encrypted, split 796 key), and what are the security controls on the escrow system? 798 4. Is the private key backed up? If so, who is the backup agent, 799 in what form is the key backed up (e.g. plaintext, encrypted, 800 split key), and what are the security controls on the backup 801 system? 803 5. Is the private key archived? If so, who is the archival agent, 804 in what form is the key archived (e.g. plaintext, encrypted, 805 split key), and what are the security controls on the archival 806 system? 808 6. Under what circumstances, if any, can a private key be 809 transferred into or from a cryptographic module? Who is 810 permitted to perform such a transfer operation? In what form is 811 the private key during the transfer (e.g., plaintext, encrypted, 812 or split key)? 814 7. How is the private key stored in the module (e.g., plaintext, 815 encrypted, or split key)? 817 8. Who can activate (use) the private key? What actions must be 818 performed to activate the private key (e.g., login, power on, 819 supply PIN, insert token/key, automatic, etc.)? Once the key is 820 activated, is the key active for an indefinite period, active 821 for one time, or active for a defined time period? 823 9. Who can deactivate the private key and how? Examples of methods 824 of deactivating private keys include logging out, turning the 825 power off, removing the token/key, automatic deactivation, and 826 time expiration. 828 10. Who can destroy the private key and how? Examples of methods of 829 destroying private keys include token surrender, token 830 destruction, and zeroizing the key. 832 4.5.3. Other aspects of key pair management 834 Other aspects of key management need to be considered for the zone 835 operator and other participants. For each of these types of 836 entities, the following questions may need to be answered: 838 1. What are the life-cycle states for the management of any Signing 839 Keys? 841 2. What is the operational period of these keys? What are the usage 842 periods or active lifetimes for the pairs? 844 4.5.4. Activation data 846 Activation data refers to data values other than whole private keys 847 that are required to operate private keys or cryptographic modules 848 containing private keys, such as a PIN, passphrase, or portions of a 849 private key used in a key-splitting scheme. Protection of activation 850 data prevents unauthorized use of the private key and potentially 851 needs to be considered for the zone operator and other participants. 852 Such a consideration may need to address the entire life-cycle of the 853 activation data from generation through archival and destruction. 854 For each of the entity types, all of the questions listed in 4.5.1 855 through 4.5.3 potentially need to be answered with respect to 856 activation data rather than with respect to keys. 858 4.5.5. Computer security controls 860 This subcomponent is used to describe computer security controls such 861 as: 863 1. use of the trusted computing base concept or equivalent; 864 2. discretionary access control, labels, mandatory access controls; 866 3. object re-use; 868 4. auditing; 870 5. identification and authentication; 872 6. trusted path; and 874 7. security testing. 876 This subcomponent may also address requirements for product 877 assurance, product evaluation analysis, testing, profiling, product 878 certification, and/or product accreditation. 880 4.5.6. Network security controls 882 This subcomponent addresses network security related controls, 883 including firewalls, routers and remote access. 885 4.5.7. Timestamping 887 This subcomponent addresses requirements or practices relating to the 888 use of timestamps on various data. It may also discuss whether or 889 not the time-stamping application must use a trusted time source. 891 4.5.8. Life cycle technical controls 893 This subcomponent addresses system development controls and security 894 management controls. 896 System development controls include development environment security, 897 development personnel security, configuration management security 898 during product maintenance, software engineering practices, software 899 development methodology, modularity, layering, use of failsafe design 900 and implementation techniques (e.g. defensive programming) and 901 development facility security. 903 Security management controls include execution of tools and 904 procedures to ensure that the operational systems and networks adhere 905 to configured security. These tools and procedures include checking 906 the integrity of the security software, firmware, and hardware to 907 ensure their correct operation. 909 4.6. Zone signing 911 This component covers all aspects of zone signing, including the 912 cryptographic specification surrounding the Signing Keys, signing 913 scheme, and methodology for key rollover and the actual zone signing. 914 Child zones and other relying parties may depend on the information 915 in this section to understand the expected data in the signed zone 916 and determine their own behavior. In addition, this section will be 917 used to state the compliance to the cryptographic and operational 918 requirements pertaining to zone signing, if any. 920 4.6.1. Key lengths, key types and algorithms 922 This subcomponent describes the key generation algorithm, the key 923 types used for signing the key set and zone data, and key lengths 924 used to create the keys. It should also cover how changes to these 925 key lengths, key types and algorithms may be performed. 927 4.6.2. Authenticated denial of existence 929 Authenticated denial of existence refers to the usage of NSEC 930 [RFC4034], NSEC3 [RFC5155] or any other mechanism defined in the 931 future that is used to authenticate the denial of existence of 932 resource records. This subcomponent describes what mechanisms are 933 used, any parameters associated with that mechanism, and how these 934 mechanisms and parameters may be changed. 936 4.6.3. Signature format 938 This subcomponent is used to describe the signing method and 939 algorithms used for the zone signing. 941 4.6.4. Key rollover 943 This subcomponent explains the key rollover scheme for each key type. 945 4.6.5. Signature life-time and re-signing frequency 947 This subcomponent describes the life-cycle of the Resource Record 948 Signature (RRSIG) record. 950 4.6.6. Verification of resource records 952 This subsection addresses the controls around the verification of the 953 resource records in order to validate and authenticate the data to be 954 signed. This may include a separate key set verification process if 955 using a split key signing scheme. 957 4.6.7. Resource records time-to-live 959 This subcomponent specifies the resource records' time-to-live (TTL) 960 for all types relevant to DNSSEC, as well as any global parameters 961 that affect the caching mechanisms of the resolvers. 963 4.7. Compliance audit 965 To prove the compliance with a Policy or the statements in the 966 Practices Statement, a compliance audit can be conducted. This 967 component describes how the audit is to be conducted at the zone 968 operator and, possibly, at other involved entities. 970 4.7.1. Frequency of entity compliance audit 972 This subcomponent describes the frequency of the compliance audit. 974 4.7.2. Identity/qualifications of auditor 976 This subcomponent addresses what qualifications are required of the 977 auditor. For instance it may that an auditor must belong to a 978 specific association or that they have certain certifications. 980 4.7.3. Auditor's relationship to audited party 982 This subcomponent is used to clarify the relationship between the 983 auditor and the entity being audited. This becomes important if 984 there are any requirements or guidelines for the selection of the 985 auditor. 987 4.7.4. Topics covered by audit 989 Topics covered by audit depends on the scope of the audit. Since the 990 DNSSEC Policy and Practices Statement is the document to be audited 991 against, it is ideal to set the scope of the audit to the scope of 992 the DP/DPS. However, the scope may be narrowed down or expanded as 993 needed; for example, if there are not enough resources to conduct a 994 full audit, or some portion is under development and not ready for 995 the audit. 997 4.7.5. Actions taken as a result of deficiency 999 This subcomponent specifies the action taken in order to correct any 1000 discrepancy that has a security impact. This could be the 1001 remediation process for the audit findings or any other action to 1002 correct any discrepancy with the DNSSEC Policy or Practices 1003 Statement. 1005 4.7.6. Communication of results 1007 This subcomponent specifies how the results of the audit are 1008 communicated to the stakeholders. 1010 4.8. Legal matters 1012 The introduction of DNSSEC into a zone may have legal implications. 1013 Consequently, it may be appropriate to declare the legal status of 1014 the binding embodied in the DNSSEC digital signatures and to clarify 1015 on any limitations of liability asserted by the Registry Manager. 1017 In most cases, the DPS is not a contract or part of a contract; 1018 instead, it is laid out so that its terms and conditions are applied 1019 to the parties by separate documents, such as registrar or registrant 1020 agreements. In other cases, its contents may form part of a legal 1021 contract between parties (either directly or via other agreements). 1022 In this case, legal expertise should be consulted when drawing up 1023 sections of the document that may have contractual implications. 1025 At a minimum, the legal matters section should indicate under what 1026 jurisdiction the registry is operated, and provide references to any 1027 associated agreements that are in force. It may also be appropriate 1028 to inform of any identified implications on the protection of 1029 personally identifiable private information. 1031 5. Outline of a Set of Provisions 1033 This section contains a recommended outline for a set of provisions, 1034 intended to serve as a checklist or a standard template for use by DP 1035 or DPS writers. Such a common outline will facilitate: 1037 (a) Comparison of a DPS with a DP to ensure that the DPS faithfully 1038 implements the policy. 1040 (b) Comparison of two DPSs. 1042 Section 4 of this document is structured so that it provides guidance 1043 for each corresponding component and sub-component of the outline. 1045 1. INTRODUCTION 1046 1.1. Overview 1047 1.2. Document name and identification 1048 1.3. Community and applicability 1049 1.4. Specification administration 1050 1.4.1. Specification administration organization 1051 1.4.2. Contact information 1052 1.4.3. Specification change procedures 1053 2. PUBLICATION AND REPOSITORIES 1054 2.1. Repositories 1055 2.2. Publication of public keys 1056 3. OPERATIONAL REQUIREMENTS 1057 3.1. Meaning of domain names 1058 3.2. Identification and authentication of child zone manager 1059 3.3. Registration of delegation signer (DS) resource records 1060 3.4. Method to prove possession of private key 1061 3.5. Removal of DS resource records 1062 3.5.1. Who can request removal 1063 3.5.2. Procedure for removal request 1064 3.5.3. Emergency removal request 1065 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1066 4.1. Physical controls 1067 4.1.1. Site location and construction 1068 4.1.2. Physical access 1069 4.1.3. Power and air conditioning 1070 4.1.4. Water exposures 1071 4.1.5. Fire prevention and protection 1072 4.1.6. Media storage 1073 4.1.7. Waste disposal 1074 4.1.8. Off-site backup 1075 4.2. Procedural controls 1076 4.2.1. Trusted roles 1077 4.2.2. Number of persons required per task 1078 4.2.3. Identification and authentication for each role 1079 4.2.4. Tasks requiring separation of duties 1080 4.3. Personnel controls 1081 4.3.1. Qualifications, experience, and clearance 1082 requirements 1083 4.3.2. Background check procedures 1084 4.3.3. Training requirements 1085 4.3.4. Job rotation frequency and sequence 1086 4.3.5. Sanctions for unauthorized actions 1087 4.3.6. Contracting personnel requirements 1088 4.3.7. Documentation supplied to personnel 1089 4.4. Audit logging procedures 1090 4.4.1. Types of events recorded 1091 4.4.2. Frequency of processing log 1092 4.4.3. Retention period for audit log information 1093 4.4.4. Protection of audit log 1094 4.4.5. Audit log backup procedures 1095 4.4.6. Audit collection system 1096 4.4.7. Vulnerability assessments 1097 4.5. Compromise and disaster recovery 1098 4.5.1. Incident and compromise handling procedures 1099 4.5.2. Corrupted computing resources, software, and/or 1100 data 1101 4.5.3. Entity private key compromise procedures 1102 4.5.4. Business continuity and IT disaster recovery 1103 capabilities 1104 4.6. Entity termination 1105 5. TECHNICAL SECURITY CONTROLS 1106 5.1. Key pair generation and installation 1107 5.1.1. Key pair generation 1108 5.1.2. Public key delivery 1109 5.1.3. Public key parameters generation and quality 1110 checking 1111 5.1.4. Key usage purposes 1112 5.2. Private key protection and cryptographic module 1113 engineering controls 1114 5.2.1. Cryptographic module standards and controls 1115 5.2.2. Private key (m-of-n) multi-person control 1116 5.2.3. Private key escrow 1117 5.2.4. Private key backup 1118 5.2.5. Private key storage on cryptographic module 1119 5.2.6. Private key archival 1120 5.2.7. Private key transfer into or from a cryptographic 1121 module 1122 5.2.8. Method of activating private key 1123 5.2.9. Method of deactivating private key 1124 5.2.10. Method of destroying private key 1125 5.3. Other aspects of key pair management 1126 5.4. Activation data 1127 5.4.1. Activation data generation and installation 1128 5.4.2. Activation data protection 1129 5.4.3. Other aspects of activation data 1130 5.5. Computer security controls 1131 5.6. Network security controls 1132 5.7. Timestamping 1133 5.8. Life cycle technical controls 1134 6. ZONE SIGNING 1135 6.1. Key lengths, key types and algorithms 1136 6.2. Authenticated denial of existence 1137 6.3. Signature format 1138 6.4. Key rollover 1139 6.5. Signature life-time and re-signing frequency 1140 6.6. Verification of resource records 1141 6.7. Resource records time-to-live 1142 7. COMPLIANCE AUDIT 1143 7.1. Frequency of entity compliance audit 1144 7.2. Identity/qualifications of auditor 1145 7.3. Auditor's relationship to audited party 1146 7.4. Topics covered by audit 1147 7.5. Actions taken as a result of deficiency 1148 7.6. Communication of results 1149 8. LEGAL MATTERS 1151 6. IANA considerations 1153 No action required. 1155 7. Security considerations 1157 The sensitivity of the information protected by DNSSEC at different 1158 tiers in the DNS tree varies significantly. In addition, there are 1159 no restrictions as to what types of information (i.e., DNS records) 1160 that can be protected using DNSSEC. Each relying party must evaluate 1161 its own environment and the chain of trust originating from a Trust 1162 Anchor, the associated threats and vulnerabilities, to determine the 1163 level of risk it is willing to accept when relying on DNSSEC- 1164 protected objects. 1166 Secondly, there is no way of determining under what policy (if any) 1167 DNS data has been signed. Interested parties must stay informed 1168 using the methods which should be described in section 1.4.3 1169 (Specification change procedures) of the DPS. 1171 If there are changes made to the policy which materially affect the 1172 security posture of the zone, as well as communicating the change 1173 through the methods previously mentioned, it may be appropriate to 1174 signal these changes by rolling the key(s). In this case, the actual 1175 time at which the new policy takes effect is indicated by the 1176 presence of signatures created by the new key. 1178 8. Acknowledgements 1180 This document is inspired by RFC 3647 and its predecessor (RFC 2527), 1181 and the authors acknowledge the work in the development of these 1182 documents. 1184 In addition, the authors would like to acknowledge the contributions 1185 made by Richard Lamb, Jakob Schlyter and Stephen Morris. 1187 9. References 1188 9.1. Normative references 1190 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1191 Rose, "DNS Security Introduction and Requirements", 1192 RFC 4033, March 2005. 1194 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1195 Rose, "Resource Records for the DNS Security Extensions", 1196 RFC 4034, March 2005. 1198 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1199 Rose, "Protocol Modifications for the DNS Security 1200 Extensions", RFC 4035, March 2005. 1202 9.2. Informative references 1204 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1205 Wu, "Internet X.509 Public Key Infrastructure Certificate 1206 Policy and Certification Practices Framework", RFC 3647, 1207 November 2003. 1209 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1210 Security (DNSSEC) Hashed Authenticated Denial of 1211 Existence", RFC 5155, March 2008. 1213 Authors' Addresses 1215 Fredrik Ljunggren 1216 Kirei AB 1217 P.O. Box 53204 1218 Goteborg SE-400 16 1219 Sweden 1221 Email: fredrik@kirei.se 1223 Anne-Marie Eklund Lowinder 1224 .SE (The Internet Infrastructure Foundation) 1225 P.O. Box 7399 1226 Stockholm SE-103 91 1227 Sweden 1229 Email: amel@iis.se 1230 Tomofumi Okubo 1231 Internet Corporation For Assigned Names and Numbers 1232 4676 Admiralty Way, Suite 330 1233 Marina del Ray, CA 90292 1234 USA 1236 Email: tomofumi.okubo@icann.org