idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-11.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 (November 05, 2012) is 4187 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: May 9, 2013 .SE 6 T. Okubo 7 ICANN 8 November 05, 2012 10 A Framework for DNSSEC Policies and DNSSEC Practice Statements 11 draft-ietf-dnsop-dnssec-dps-framework-11 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 May 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 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 stakeholders to evaluate the strength and 107 security of the DNSSEC chain of trust, an entity operating a DNSSEC 108 enabled zone may publish a DNSSEC Practice Statement (DPS), 109 comprising statements describing critical security controls and 110 procedures relevant for scrutinizing the trustworthiness of the 111 system. The DPS may also identify any DNSSEC Policies (DP) it 112 supports, explaining how it meets their requirements. 114 The DP and DPS are not primarily aimed at users who rely on signed 115 responses from the DNS ("relying parties"); instead, their audience 116 is other stakeholders of the DNS infrastructure, a group that may 117 include bodies such as regulatory authorities. 119 Even though this document is heavily inspired by the Internet X.509 120 Public Key Infrastructure Certificate Policy and Certification 121 Practices Framework [RFC3647], with large parts being drawn from that 122 document, the properties and structure of the DNSSEC trust model are 123 fundamentally different from those of the X.509 PKI. 125 1.2. Purpose 127 The purpose of this document is twofold. Firstly, the document 128 explains the concepts of a DNSSEC Policy (DP) and of a DNSSEC 129 Practice Statement (DPS), and to describe the relationship between 130 the two. Secondly, it presents a framework to encourage and assist 131 writers of Policies and Practice Statements in creating consistent 132 and comparable documents. In particular, the framework identifies 133 the elements that should be considered in formulating a DP or a DPS. 134 It does not, however, define a particular Policy or Practice 135 Statement, nor does it seek to provide legal advice or 136 recommendations as to the contents. 138 1.3. Scope 140 The scope of this document is limited to discussion of the topics 141 that can be covered in a DP or a DPS, but does not go into the 142 specific details that could possibly be included in each one. In 143 particular, this document describes the types of information that 144 should be considered for inclusion in them. 146 The DNSSEC Policy and Practice Statement framework should be viewed 147 and used as a checklist of factors that ought be taken in to 148 consideration prior to deploying DNSSEC, and as an outline to create 149 an operational practices disclosure document. As such, it focuses on 150 the topics affected by the introduction of DNSSEC into a zone. Other 151 aspects, such as the operations of name servers and registry systems, 152 are considered out of scope. The framework is primarily aimed at TLD 153 managers and organizations providing registry services, but may be 154 used by high-value domain holders and so serve as a checklist for 155 DNSSEC readiness at a high level. 157 This document assumes that the reader is familiar with the general 158 concepts of DNS, DNSSEC and PKI. 160 2. Definitions 162 This document makes use of the following defined terms: 164 Audit logs - Control evidence information to prove the integrity of 165 processes. This may be generated by DNS and DNSSEC-related systems, 166 supplied by the surrounding facility, or obtained from manually 167 generated, non-electronic documentation. Audit logs will be examined 168 by the internal and/or external auditors. 170 Activation data - Data values, other than keys, required to operate 171 the cryptographic modules used to protect the keys from unauthorized 172 use. 174 Chain of Trust - A hierarchical structure of trust consisting of DNS 175 keys, signatures, and delegation signer records that, when validated 176 in a series, can provide proof of authenticity of the last element in 177 the chain, providing that the first element is trusted. Usually, the 178 first element is a trust anchor. 180 Compromise (Key Compromise) - Key Compromise is a situation where the 181 private component of a Signing Key is lost, stolen, exposed, modified 182 or used in an unauthorized manner. More strictly, even a suspicion 183 that one of these has occurred will be enough to be considered as key 184 compromise. 186 DNS - The Domain Name System (DNS) is a hierarchical global naming 187 catalog for computers, services, or any resource connected to the 188 Internet. 190 DNS Zone - A portion of the global Domain Name System (DNS) namespace 191 for which administrative responsibility has been delegated. 193 DNSSEC - DNS Security Extensions (DNSSEC) is a set of IETF 194 specifications [RFC4033], [RFC4034], [RFC4035] that use public key 195 cryptography to add data origin authentication, data integrity 196 verification, and authenticated denial of existence capabilities to 197 DNS. 199 DNSSEC Policy - A DNSSEC Policy (DP) sets forth the security 200 requirements and standards to be implemented for a DNSSEC signed 201 zone. 203 DNSSEC Practice Statement - A DNSSEC Practice Statement (DPS) is a 204 practices disclosure document that may support and be a supplemental 205 document to the DNSSEC Policy (if such exists), and states how the 206 management of a given zone implements procedures and controls at a 207 high level. 209 Key rollover - An operational process to change one of the DNSSEC 210 keys used for signing a zone via distribution of public keys in a 211 trusted manner. 213 Multi-person control - A security concept to distribute the authority 214 of an operation over multiple persons, to mitigate threats caused by 215 a single authorized individual. For example, a key recovery function 216 may require some number of authorized individuals (m) out of the (n) 217 to whom a portion of the recovery key was distributed, to combine 218 their key fragments, before key recovery can occur. 220 PKI - Public Key Infrastructure (PKI) is a concept that makes use of 221 asymmetric cryptography to provide a system with integrity, 222 authentication, confidentiality and via distribution of public keys 223 in a trusted manner. 225 Policy Authority - The body responsible for setting and administering 226 a DNSSEC Policy, and for determining whether a DPS is suitable for 227 that Policy. 229 Relying Party - An entity that relies on a signed response from the 230 DNS. 232 Repository - A location on the Internet to store DP, DPS, Trust 233 Anchors and other related information that should be kept public. 235 Security Posture - A Security Posture is an indicator of how secure 236 an entity is and how secure the entity should be. It is the result 237 of an adequate threat model and risk assessment. 239 Separation of Duties - A security concept that limits the influence 240 of a single person by segregating roles and responsibilities. 242 Signing Key - Private component of an asymmetric key-pair that is 243 used for signing of resource records within the zone. Note that the 244 other component, called public key, is used for signature validation. 246 TLD - A Top-Level Domain (TLD) is one of the domains at the highest 247 level below the root in the hierarchy of the DNS. 249 Trust Anchor - Public portion of a key-pair that is the authoritative 250 entity used to authenticate the first element in a chain of trust. 252 3. Concepts 254 This section describes the concepts of a DNSSEC Policy and of a 255 DNSSEC Practices Statement. Other related concepts are described as 256 well. 258 3.1. DNSSEC Policy 260 A DNSSEC Policy (DP) sets forth requirements that are appropriate for 261 a specified level of assurance. For example, a DP may encompass all 262 topics of this framework, each with a certain set of security 263 requirements, possibly grouped according to impact. The progression 264 from medium to high levels of assurance would correspond to 265 increasing security requirements and corresponding increasing levels 266 of assurance. 268 A DP also constitues a basis for an audit, accreditation, or another 269 assessment of an entity. Each entity can be assessed against one or 270 more DPs that it claims to implement. 272 3.2. DNSSEC Practice Statement 274 Most zone managers using DNSSEC will not have the need to create a 275 thorough and detailed statement of practices. For example, a 276 registrant may be the sole relying party of its own zone and would 277 already be aware of the nature and trustworthiness of its services. 278 In other cases, a zone manager may provide registration services with 279 only a very low level of assurances where the domain names being 280 secured may pose only marginal risks if compromised. Publishing a 281 DPS is most relevant for entities operating a zone that contains a 282 significant number of delegations to other entities. 284 A DNSSEC Practice Statement (DPS) should contain information that is 285 relevant to the stakeholders of the relevant zone(s). Since these 286 generally include the Internet community, it should not contain such 287 information that could be considered to be sensitive details of an 288 entity's operations. 290 A DNSSEC Practice Statement may identify a supported DP, which may 291 subsequently be used by a relying party to evaluate the 292 trustworthiness of any digital signatures verified using the public 293 key of that entity. 295 3.3. Relationship between DNSSEC Policy and Practice Statement 297 A DNSSEC Policy and a DNSSEC Practice Statement address the same set 298 of topics of interest to the stakeholders in terms of the level of 299 confidence ascribed to the security posture of a zone. The primary 300 difference is in the focus of their provisions. A Policy sets forth 301 the requirements and standards to be implemented for a DNSSEC signed 302 zone, and may be used to communicate requirements that must be met by 303 complying parties; as such it may also be used to determine or 304 establish equivalency between policies associated with different 305 zones. A Practice Statement, by contrast, describes how a zone 306 operator (and possibly other participants in the management of a 307 given zone) implements procedures and controls to meet the 308 requirements of applicable Policies. In other words, the Policy says 309 what needs to be done, the Practice Statement says what is being 310 done. 312 An additional difference between a Policy and a Practice Statement 313 relates to the scope of coverage of the two kinds of documents, in 314 terms of its applicability. A Policy may apply to multiple 315 organizations or multiple zones. By contrast, a Practice Statement 316 would usually apply only to a single zone operator or a single 317 organization, since it describes the actual controls in place that 318 meet the requirements of applicable Policy. 320 For example, a TLD Manager or regulatory authority may define 321 requirements in a Policy for the operation of one or more zones. The 322 Policy will be a broad statement of the general requirements for 323 managing the zone. A zone operator may be required to write its own 324 Practice Statement to support the Policy, explaining how it meets the 325 requirements of the Policy. Alternatively, a zone operator that is 326 also the manager of that zone, and not governed by any external 327 Policy may still choose to disclose operational practices by 328 publishing a DPS. The zone operator might do so to provide 329 transparency and to gain community trust in its operations. 331 A Policy and a Practice Statement also differ in the level of detail 332 each expresses: although there may be variations, a Practice 333 Statement will provide a description of procedures and controls and 334 so will usually be more detailed than a Policy, which provides 335 general principles. 337 The main differences between a Policy and Practice Statement can be 338 summarized as follows: 340 (a) Operation of a DNS zone with DNSSEC may be governed by a Policy 341 that establishes requirements stating what the entity operating 342 that zone must do. An entity can use a Practice Statement to 343 disclose how it meets the requirements of a Policy or how it has 344 implemented critical processes and controls, absent a 345 controlling Policy 347 (b) A Policy may serve the purpose of establishing a common basis of 348 trusted operation throughout a set of zones in the DNS 349 hierarchy. By contrast, a Practice Statement is a statement of 350 a single zone operator or organization. 352 (c) A Practice Statement is generally more detailed than a Policy 353 and specifies how the zone operator or organization implements 354 critical processes and controls, and how the entity meets any 355 requirements specified in the one or more Policies under which 356 it operates DNSSEC. 358 3.4. Set of Provisions 360 A set of provisions is a collection of Policy requirements or 361 Practice statements, which may employ the approach described in this 362 framework by covering the topics appearing in Section 5 below. The 363 topics are described in detail in section 4. 365 A Policy can be expressed as a single set of provisions. 367 A Practice Statement can also be expressed as a single set of 368 provisions with each component addressing the requirements of one or 369 more Policies. Alternatively, it could be a set of provisions that 370 do not reference any particular policy but instead describe a set of 371 self-imposed controls to the stakeholders. For example, a Practice 372 Statement could be expressed as a combination of the following: 374 (a) a list of Policies supported by the DPS; 376 (b) for each Policy in (a), a set of provisions that contains 377 statements addressing the requirements by filling in details not 378 stipulated in that policy or expressly left to the discretion of 379 the implementer. Such statements serve to show how this 380 particular Practice Statement implements the requirements of the 381 particular Policy; or 383 (c) a set of provisions that contains statements regarding the 384 DNSSEC operations practices, independent of any Policy. 386 The statements provided in (b) may augment or refine the stipulations 387 of an applicable Policy, but generally they must not conflict with 388 the stipulations. In certain cases however, a Policy Authority may 389 permit exceptions because certain compensating controls of the entity 390 disclosed in its Practices Statement allow it to provide a level of 391 assurance equivalent to full compliance with the policy. 393 The framework outlines the contents of a set of provisions, in terms 394 of eight primary components, as follows: 396 1. Introduction 398 2. Publication and Repositories 400 3. Operational Requirements 402 4. Facility, Management, and Operational Controls 404 5. Technical Security Controls 406 6. Zone Signing 408 7. Compliance Audit 410 8. Legal Matters 412 This framework can be used by Policy Authorities to write DNSSEC 413 Policies and by zone operators to write a DNSSEC Practice Statements. 414 Having a set of documents with the same structure facilitates 415 comparisons with the corresponding documents of other zones. 417 4. Contents of a Set of Provisions 419 This section describes the contents of a set of provisions. Refer to 420 Section 5 for the complete outline. 422 Drafters of DPSs conforming to this framework are permitted to add 423 additional levels of subcomponents below those described here to meet 424 specific needs. All components listed in Section 5 should be 425 present, but drafters may leave components empty, only stating "no 426 stipulation", if so required. 428 4.1. Introduction 430 This component identifies and introduces the set of provisions, and 431 indicates the types of entities and applications for which the 432 document (either Policy or Practice Statement) is targeted. 434 4.1.1. Overview 436 This subcomponent provides a general introduction to the document. 437 It can also be used to provide a description of entities to which the 438 Policy or Practice Statement applies. 440 4.1.2. Document name and identification 442 This subcomponent provides any applicable names or other identifiers 443 of the document. 445 4.1.3. Community and applicability 447 This subcomponent identifies the stakeholders along with their 448 expected roles and responsibilities. These include (but are not 449 limited to) an entity signing the zone, entities relying on the 450 signed zone, other entities that have operational dependency on the 451 signed zone, and an entity that entrusted the zone signing. 453 4.1.4. Specification administration 455 This subcomponent contains the contact details of the organization 456 responsible for managing the DP/DPS, as well as the specification 457 change procedures. These procedures may include the description of 458 the notification mechanisms used to provide advance notice of 459 amendments which are deemed to materially affect the assurance 460 provided by the entity, and how/when such amendments will be 461 communicated to the stakeholders. 463 If a Policy Authority is responsible for determining whether a DPS is 464 suitable for the Policy, this subcomponent may include the name and 465 contact information of the entity in charge of making such a 466 determination. In this case, the subcomponent also includes the 467 procedures by which this determination is made. 469 4.2. Publication and repositories 471 The component describes the requirements for an entity to publish 472 information regarding its practices, public keys, the current status 473 of such keys together with details relating to the repositories in 474 which the information is held. This may include the responsibilities 475 of publishing the DPS and of identifying documents that are not made 476 publicly available owing to their sensitive nature, e.g. security 477 controls, clearance procedures, or business information. 479 4.2.1. Repositories 481 This subcomponent describes the repository mechanisms used for making 482 information available to the stakeholders, and may include: 484 o The locations of the repositories and the means by which they may 485 be accessed; 487 o An identification of the entity or entities that operate 488 repositories, such as a zone operator or a TLD Manager; 490 o Access control on published information objects. 492 o Any notification services which may be subscribed to by the 493 stakeholders; 495 4.2.2. Publication of public keys 497 This subcomponent contains information relating to the publication of 498 public keys: 500 o Whether the public keys are included in a key hierarchy, published 501 as Trust Anchors or both; 503 o The data formats and methods available to validate the 504 authenticity of public keys; 506 o The frequency and timing of publishing new information 507 (principally as advance notice for stakeholders relying on the 508 public keys). 510 4.3. Operational requirements 512 This component describes the operational requirements when operating 513 a DNSSEC signed zone. 515 4.3.1. Meaning of domain names 517 This subcomponent describes the overall policy of child zone naming, 518 if any. 520 4.3.2. Identification and authentication of child zone manager 522 This subcomponent describes how the child zone manager has initially 523 been identified, and how any subsequent change request is 524 authenticated as originating from the manager or their authorized 525 representative. 527 4.3.3. Registration of delegation signer (DS) resource records 529 This subcomponent describes the process of establishing the chain-of- 530 trust to the child zone by incorporating delegation signer (DS) 531 record(s) into the zone. 533 4.3.4. Method to prove possession of private key 535 This subcomponent describes whether, and if so under what 536 circumstances, the child zone manager is required to provide proof of 537 the possession of the private component of any current or subsequent 538 child zone Signing Key corresponding to a DS record they wish to 539 incorporate into the parent zone. 541 4.3.5. Removal of DS resource records 543 This subcomponent will explain how, when, and under what 544 circumstances the DS records may be removed from the zone. 546 4.4. Facility, management and operational controls 548 This component describes non-technical security controls (i.e., 549 physical, procedural, and personnel) in use by the entity to securely 550 perform the DNSSEC related functions. Such controls include physical 551 access, key management, disaster recovery, auditing, and archiving. 553 These non-technical security controls are critical for trusting the 554 DNSSEC signatures, since lack of security may compromise DNSSEC 555 operations. For example, it could result in the creation of 556 signatures with erroneous information or in the compromise of the 557 Signing Key. 559 Within each subcomponent, separate consideration will usually need to 560 be given to each entity type. 562 4.4.1. Physical controls 564 In this subcomponent, the physical controls on the facility housing 565 the entity systems are described. Topics addressed may include: 567 o Site location and construction, such as requirements for multiple 568 tiers of physical barriers, construction requirements for high- 569 security areas etc. It may also describe the use of locked rooms, 570 cages, safes, and cabinets etc.; 572 o Physical access, i.e. mechanisms to control access from one area 573 of the facility to another or additional controls for reaching 574 into higher tiers, such as dual-access control and two-factor 575 authentication; 577 o Power and air conditioning; 579 o Water exposures; 581 o Fire prevention and protection; 583 o Media storage, e.g. requiring the storage of backup media in a 584 separate location that is physically secure and protected from 585 fire, smoke, particle, and water damage; 587 o Waste disposal; and 589 o Off-site backup. 591 4.4.2. Procedural controls 593 In this subcomponent, requirements for recognizing trusted roles are 594 described, together with a description of the responsibilities of 595 each role. Examples of trusted roles include system administrators, 596 security officers, crypto officers and system auditors. 598 For each task identified, the number of individuals required to 599 perform the task (m of n rule, if applicable) should be stated for 600 each role. Identification and authentication requirements for each 601 role may also be defined. 603 This subcomponent also includes the separation of duties in terms of 604 the roles that cannot be performed by the same individuals. 606 4.4.3. Personnel controls 608 This subcomponent addresses the following: 610 o Qualifications, experience, and clearances that personnel must 611 have as a condition of filling trusted roles or other important 612 roles. Examples include credentials, job experiences, and 613 official government clearances; 615 o Background checks and clearance procedures that are required in 616 connection with the hiring of personnel filling trusted roles or 617 other important roles. Such roles may require a check of their 618 criminal records, financial records, references, and any 619 additional clearances required for the position in question; 621 o Training requirements and training procedures for each role 622 following the hiring of personnel; 624 o Any retraining period and retraining procedures for each role 625 after completion of initial training; 627 o Frequency and sequence for job rotation among various roles; 629 o Sanctions against personnel for unauthorized actions, such as 630 unauthorized use of authority, or unauthorized use of the entity 631 systems; 633 o Controls on personnel that are contractors rather than employees 634 of the entity; examples include: 636 * Bonding requirements on contract personnel; 638 * Contractual requirements including indemnification for damages 639 due to the actions of the contractor personnel; 641 * Auditing and monitoring of contractor personnel; and 643 * Other controls on contracting personnel. 645 o Documentation to be supplied to personnel during initial training, 646 retraining, or otherwise. 648 4.4.4. Audit logging procedures 650 This subcomponent is used to describe event logging and audit 651 systems, implemented for the purpose of maintaining an audit trail 652 and to provide evidence of process integrity. Elements include the 653 following: 655 o Types of events recorded, such as records of key roll over and 656 other key management operations, the personnel assigned to various 657 roles, attempts to access the system and requests made to the 658 system; 660 o Frequency with which audit logs are processed or archived, for 661 example, weekly, following an alarm or anomalous event, or 662 whenever the audit log size reaches a particular size; 664 o Period for which audit logs are kept; 666 o Protection of audit logs: 668 * Who can view audit logs, for example only the audit 669 administrator; 671 * Protection against modification of audit logs, for instance a 672 requirement that no one may modify or delete the audit records 673 or that only an audit administrator may delete an audit file as 674 part of audit file rotation; and 676 * Protection against deletion of audit logs. 678 o Audit log backup procedures; 680 o Whether the audit log collection function is internal or external 681 to the system; 683 o Whether the subject who caused an audit event to occur is notified 684 of the audit action; and 686 o Vulnerability assessments, for example, where audit data is run 687 through a tool that identifies potential attempts to breach the 688 security of the system. 690 4.4.5. Compromise and disaster recovery 692 This subcomponent describes requirements relating to notification and 693 recovery procedures in the event of compromise or disaster. Each of 694 the following may need to be addressed separately: 696 o Identification or listing of the applicable incident and 697 compromise reporting and handling procedures, which may include 698 the investigation of measures to prevent the event from 699 reoccurring. 701 o The recovery procedures used if computing resources, software, 702 and/or data are corrupted or suspected to have been corrupted. 703 These procedures describe how, and under what circumstances 704 operations of the system are to be suspended, how and when normal 705 operations are resumed, how the stakeholders are to be informed 706 and how to assess the damage and carry out the root cause 707 analysis. 709 o The recovery procedures used if any keys are compromised. These 710 procedures describe how a secure environment is re-established, 711 how the keys are rolled over, how a new Trust Anchor is provided 712 to the community (if applicable), and how new zone information is 713 published. 715 o The entity's capabilities to ensure business continuity following 716 a natural or other disaster. Such capabilities may include the 717 availability of a disaster recovery site at which operations may 718 be recovered. They may also include procedures for securing its 719 facility during the period of time following a natural or other 720 disaster and before a secure environment is re-established, either 721 at the original site or at a disaster recovery site. For example, 722 procedures to protect against theft of sensitive materials from an 723 earthquake-damaged site. 725 4.4.6. Entity termination 727 This subcomponent describes requirements relating to procedures for 728 termination of a contract with an entity, termination notification 729 and transition of responsibilities to another entity. The purpose 730 may be to ensure that the transition process will be transparent to 731 the stakeholders, and will not affect the services. 733 4.5. Technical security controls 735 This component is used to define the security measures taken to 736 protect the cryptographic keys and activation data (e.g., PINs, 737 passwords, or manually-held key shares) relevant to DNSSEC 738 operations. Secure key management is critical to ensure that all 739 secret and private keys and activation data are protected and used 740 only by authorized personnel. 742 Also described here are other technical security controls used to 743 perform the functions of key generation, authentication, 744 registration, auditing, and archiving. Technical controls include 745 life-cycle security controls, software development environment 746 security, and operational security controls. 748 If applicable, other technical security controls on repositories, 749 authoritative name servers, or other participants may also be 750 documented here. 752 4.5.1. Key pair generation and installation 754 Key pair generation and installation need to be considered, which may 755 involve answering the following questions: 757 1. Who generates the zone's public/private key pairs? How is the 758 key generation performed? Is the key generation performed by 759 hardware or software? 761 2. How is the private key installed in all parts of the key 762 management system? 764 3. How are the zone's public keys provided securely to the parent 765 zone and potential relying parties? 767 4. Who generates the public key parameters. Is the quality of the 768 parameters checked during key generation? 770 5. For what purposes may the keys be used, and/or for what purposes 771 should usage of the key be restricted? 773 4.5.2. Private key protection and cryptographic module engineering 774 controls 776 Requirements for private key protection and cryptographic modules 777 need to be considered for key generation and creation of signatures. 778 The following questions may need to be answered: 780 1. What standards, if any, are required for the cryptographic 781 module used to generate the keys? A cryptographic module can be 782 composed of hardware, software, firmware, or any combination of 783 them. For example, are the zone's signatures required to be 784 generated using modules compliant with the US FIPS 140-2 785 standard? If so, what is the required FIPS 140-2 level of the 786 module? Are there any other engineering or other controls 787 relating to a cryptographic module, such as the identification 788 of the cryptographic module boundary, input/output, roles and 789 services, finite state machine, physical security, software 790 security, operating system security, algorithm compliance, 791 electromagnetic compatibility, and self tests. 793 2. Is the private key under m of n multi-person control? If yes, 794 provide m and n (two person control is a special case of m of n, 795 where m = 2 and n >= 2). 797 3. Is the private key escrowed? If so, who is the escrow agent, in 798 what form is the key escrowed (e.g. plaintext, encrypted, split 799 key), and what are the security controls on the escrow system? 801 4. Is the private key backed up? If so, who is the backup agent, 802 in what form is the key backed up (e.g. plaintext, encrypted, 803 split key), and what are the security controls on the backup 804 system? 806 5. Is the private key archived? If so, who is the archival agent, 807 in what form is the key archived (e.g. plaintext, encrypted, 808 split key), and what are the security controls on the archival 809 system? 811 6. Under what circumstances, if any, can a private key be 812 transferred into or from a cryptographic module? Who is 813 permitted to perform such a transfer operation? In what form is 814 the private key during the transfer (e.g., plaintext, encrypted, 815 or split key)? 817 7. How is the private key stored in the module (e.g., plaintext, 818 encrypted, or split key)? 820 8. Who can activate (use) the private key? What actions must be 821 performed to activate the private key (e.g., login, power on, 822 supply PIN, insert token/key, automatic, etc.)? Once the key is 823 activated, is the key active for an indefinite period, active 824 for one time, or active for a defined time period? 826 9. Who can deactivate the private key and how? Examples of methods 827 of deactivating private keys include logging out, turning the 828 power off, removing the token/key, automatic deactivation, and 829 time expiration. 831 10. Who can destroy the private key and how? Examples of methods of 832 destroying private keys include token surrender, token 833 destruction, and zeroizing the key. 835 4.5.3. Other aspects of key pair management 837 Other aspects of key management need to be considered for the zone 838 operator and other participants. For each of these types of 839 entities, the following questions may need to be answered: 841 1. What are the life-cycle states for the management of any Signing 842 Keys? 844 2. What is the operational period of these keys? What are the usage 845 periods or active lifetimes for the pairs? 847 4.5.4. Activation data 849 Activation data refers to data values other than whole private keys 850 that are required to operate private keys or cryptographic modules 851 containing private keys, such as a PIN, passphrase, or portions of a 852 private key used in a key-splitting scheme. Protection of activation 853 data prevents unauthorized use of the private key and potentially 854 needs to be considered for the zone operator and other participants. 855 Such a consideration may need to address the entire life-cycle of the 856 activation data from generation through archival and destruction. 857 For each of the entity types, all of the questions listed in 4.5.1 858 through 4.5.3 potentially need to be answered with respect to 859 activation data rather than with respect to keys. 861 4.5.5. Computer security controls 863 This subcomponent is used to describe computer security controls such 864 as: 866 1. use of the trusted computing base concept or equivalent; 867 2. discretionary access control, labels, mandatory access controls; 869 3. object re-use; 871 4. auditing; 873 5. identification and authentication; 875 6. trusted path; and 877 7. security testing. 879 This subcomponent may also address requirements for product 880 assurance, product evaluation analysis, testing, profiling, product 881 certification, and/or product accreditation. 883 4.5.6. Network security controls 885 This subcomponent addresses network security related controls, 886 including firewalls, routers and remote access. 888 4.5.7. Timestamping 890 This subcomponent addresses requirements or practices relating to the 891 use of timestamps on various data. It may also discuss whether or 892 not the time-stamping application must use a trusted time source. 894 4.5.8. Life cycle technical controls 896 This subcomponent addresses system development controls and security 897 management controls. 899 System development controls include development environment security, 900 development personnel security, configuration management security 901 during product maintenance, software engineering practices, software 902 development methodology, modularity, layering, use of failsafe design 903 and implementation techniques (e.g. defensive programming) and 904 development facility security. 906 Security management controls include execution of tools and 907 procedures to ensure that the operational systems and networks adhere 908 to configured security. These tools and procedures include checking 909 the integrity of the security software, firmware, and hardware to 910 ensure their correct operation. 912 4.6. Zone signing 914 This component covers all aspects of zone signing, including the 915 cryptographic specification surrounding the Signing Keys, signing 916 scheme, and methodology for key rollover and the actual zone signing. 917 Child zones and other relying parties may depend on the information 918 in this section to understand the expected data in the signed zone 919 and determine their own behavior. In addition, this section will be 920 used to state the compliance to the cryptographic and operational 921 requirements pertaining to zone signing, if any. 923 4.6.1. Key lengths, key types and algorithms 925 This subcomponent describes the key generation algorithm, the key 926 types used for signing the key set and zone data, and key lengths 927 used to create the keys. It should also cover how changes to these 928 key lengths, key types and algorithms may be performed. 930 4.6.2. Authenticated denial of existence 932 Authenticated denial of existence refers to the usage of NSEC 933 [RFC4034], NSEC3 [RFC5155] or any other mechanism defined in the 934 future that is used to authenticate the denial of existence of 935 resource records. This subcomponent describes what mechanisms are 936 used, any parameters associated with that mechanism, and how these 937 mechanisms and parameters may be changed. 939 4.6.3. Signature format 941 This subcomponent is used to describe the signing method and 942 algorithms used for the zone signing. 944 4.6.4. Key rollover 946 This subcomponent explains the key rollover scheme for each key type. 948 4.6.5. Signature life-time and re-signing frequency 950 This subcomponent describes the life-cycle of the Resource Record 951 Signature (RRSIG) record. 953 4.6.6. Verification of resource records 955 This subsection addresses the controls around the verification of the 956 resource records in order to validate and authenticate the data to be 957 signed. This may include a separate key set verification process if 958 using a split key signing scheme. 960 4.6.7. Resource records time-to-live 962 This subcomponent specifies the resource records' time-to-live (TTL) 963 for all types relevant to DNSSEC, as well as any global parameters 964 that affect the caching mechanisms of the resolvers. 966 4.7. Compliance audit 968 To prove the compliance with a Policy or the statements in the 969 Practices Statement, a compliance audit can be conducted. This 970 component describes how the audit is to be conducted at the zone 971 operator and, possibly, at other involved entities. 973 4.7.1. Frequency of entity compliance audit 975 This subcomponent describes the frequency of the compliance audit. 977 4.7.2. Identity/qualifications of auditor 979 This subcomponent addresses what qualifications are required of the 980 auditor. For instance it may that an auditor must belong to a 981 specific association or that they have certain certifications. 983 4.7.3. Auditor's relationship to audited party 985 This subcomponent is used to clarify the relationship between the 986 auditor and the entity being audited. This becomes important if 987 there are any requirements or guidelines for the selection of the 988 auditor. 990 4.7.4. Topics covered by audit 992 Topics covered by audit depends on the scope of the audit. Since the 993 DNSSEC Policy and Practices Statement is the document to be audited 994 against, it is ideal to set the scope of the audit to the scope of 995 the DP/DPS. However, the scope may be narrowed down or expanded as 996 needed; for example, if there are not enough resources to conduct a 997 full audit, or some portion is under development and not ready for 998 the audit. 1000 4.7.5. Actions taken as a result of deficiency 1002 This subcomponent specifies the action taken in order to correct any 1003 discrepancy that has a security impact. This could be the 1004 remediation process for the audit findings or any other action to 1005 correct any discrepancy with the DNSSEC Policy or Practices 1006 Statement. 1008 4.7.6. Communication of results 1010 This subcomponent specifies how the results of the audit are 1011 communicated to the stakeholders. 1013 4.8. Legal matters 1015 The introduction of DNSSEC into a zone may have legal implications. 1016 Consequently, it may be appropriate to declare the legal status of 1017 the binding embodied in the DNSSEC digital signatures and to clarify 1018 on any limitations of liability asserted by the Registry Manager. 1020 In most cases, the DPS is not a contract or part of a contract; 1021 instead, it is laid out so that its terms and conditions are applied 1022 to the parties by separate documents, such as registrar or registrant 1023 agreements. In other cases, its contents may form part of a legal 1024 contract between parties (either directly or via other agreements). 1025 In this case, legal expertise should be consulted when drawing up 1026 sections of the document that may have contractual implications. 1028 At a minimum, the legal matters section should indicate under what 1029 jurisdiction the registry is operated, and provide references to any 1030 associated agreements that are in force. It may also be appropriate 1031 to inform of any identified implications on the protection of 1032 personally identifiable private information. 1034 5. Outline of a Set of Provisions 1036 This section contains a recommended outline for a set of provisions, 1037 intended to serve as a checklist or a standard template for use by DP 1038 or DPS writers. Such a common outline will facilitate: 1040 (a) Comparison of a DPS with a DP to ensure that the DPS faithfully 1041 implements the policy. 1043 (b) Comparison of two DPSs. 1045 Section 4 of this document is structured so that it provides guidance 1046 for each corresponding component and sub-component of the outline. 1048 1. INTRODUCTION 1049 1.1. Overview 1050 1.2. Document name and identification 1051 1.3. Community and applicability 1052 1.4. Specification administration 1053 1.4.1. Specification administration organization 1054 1.4.2. Contact information 1055 1.4.3. Specification change procedures 1056 2. PUBLICATION AND REPOSITORIES 1057 2.1. Repositories 1058 2.2. Publication of public keys 1059 3. OPERATIONAL REQUIREMENTS 1060 3.1. Meaning of domain names 1061 3.2. Identification and authentication of child zone manager 1062 3.3. Registration of delegation signer (DS) resource records 1063 3.4. Method to prove possession of private key 1064 3.5. Removal of DS resource records 1065 3.5.1. Who can request removal 1066 3.5.2. Procedure for removal request 1067 3.5.3. Emergency removal request 1068 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1069 4.1. Physical controls 1070 4.1.1. Site location and construction 1071 4.1.2. Physical access 1072 4.1.3. Power and air conditioning 1073 4.1.4. Water exposures 1074 4.1.5. Fire prevention and protection 1075 4.1.6. Media storage 1076 4.1.7. Waste disposal 1077 4.1.8. Off-site backup 1078 4.2. Procedural controls 1079 4.2.1. Trusted roles 1080 4.2.2. Number of persons required per task 1081 4.2.3. Identification and authentication for each role 1082 4.2.4. Tasks requiring separation of duties 1083 4.3. Personnel controls 1084 4.3.1. Qualifications, experience, and clearance 1085 requirements 1086 4.3.2. Background check procedures 1087 4.3.3. Training requirements 1088 4.3.4. Job rotation frequency and sequence 1089 4.3.5. Sanctions for unauthorized actions 1090 4.3.6. Contracting personnel requirements 1091 4.3.7. Documentation supplied to personnel 1092 4.4. Audit logging procedures 1093 4.4.1. Types of events recorded 1094 4.4.2. Frequency of processing log 1095 4.4.3. Retention period for audit log information 1096 4.4.4. Protection of audit log 1097 4.4.5. Audit log backup procedures 1098 4.4.6. Audit collection system 1099 4.4.7. Vulnerability assessments 1100 4.5. Compromise and disaster recovery 1101 4.5.1. Incident and compromise handling procedures 1102 4.5.2. Corrupted computing resources, software, and/or 1103 data 1104 4.5.3. Entity private key compromise procedures 1105 4.5.4. Business continuity and IT disaster recovery 1106 capabilities 1107 4.6. Entity termination 1108 5. TECHNICAL SECURITY CONTROLS 1109 5.1. Key pair generation and installation 1110 5.1.1. Key pair generation 1111 5.1.2. Public key delivery 1112 5.1.3. Public key parameters generation and quality 1113 checking 1114 5.1.4. Key usage purposes 1115 5.2. Private key protection and cryptographic module 1116 engineering controls 1117 5.2.1. Cryptographic module standards and controls 1118 5.2.2. Private key (m-of-n) multi-person control 1119 5.2.3. Private key escrow 1120 5.2.4. Private key backup 1121 5.2.5. Private key storage on cryptographic module 1122 5.2.6. Private key archival 1123 5.2.7. Private key transfer into or from a cryptographic 1124 module 1125 5.2.8. Method of activating private key 1126 5.2.9. Method of deactivating private key 1127 5.2.10. Method of destroying private key 1128 5.3. Other aspects of key pair management 1129 5.4. Activation data 1130 5.4.1. Activation data generation and installation 1131 5.4.2. Activation data protection 1132 5.4.3. Other aspects of activation data 1133 5.5. Computer security controls 1134 5.6. Network security controls 1135 5.7. Timestamping 1136 5.8. Life cycle technical controls 1137 6. ZONE SIGNING 1138 6.1. Key lengths, key types and algorithms 1139 6.2. Authenticated denial of existence 1140 6.3. Signature format 1141 6.4. Key rollover 1142 6.5. Signature life-time and re-signing frequency 1143 6.6. Verification of resource records 1144 6.7. Resource records time-to-live 1145 7. COMPLIANCE AUDIT 1146 7.1. Frequency of entity compliance audit 1147 7.2. Identity/qualifications of auditor 1148 7.3. Auditor's relationship to audited party 1149 7.4. Topics covered by audit 1150 7.5. Actions taken as a result of deficiency 1151 7.6. Communication of results 1152 8. LEGAL MATTERS 1154 6. IANA considerations 1156 No action required. 1158 7. Security considerations 1160 The sensitivity of the information protected by DNSSEC at different 1161 tiers in the DNS tree varies significantly. In addition, there are 1162 no restrictions as to what types of information (i.e., DNS records) 1163 that can be protected using DNSSEC. Each relying party must evaluate 1164 its own environment and the chain of trust originating from a Trust 1165 Anchor, the associated threats and vulnerabilities, to determine the 1166 level of risk it is willing to accept when relying on DNSSEC- 1167 protected objects. 1169 8. Acknowledgements 1171 This document is inspired by RFC 3647 and its predecessor (RFC 2527), 1172 and the authors acknowledge the work in the development of these 1173 documents. 1175 In addition, the authors would like to acknowledge the contributions 1176 made by Richard Lamb, Jakob Schlyter and Stephen Morris. 1178 9. References 1180 9.1. Normative references 1182 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1183 Rose, "DNS Security Introduction and Requirements", 1184 RFC 4033, March 2005. 1186 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1187 Rose, "Resource Records for the DNS Security Extensions", 1188 RFC 4034, March 2005. 1190 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1191 Rose, "Protocol Modifications for the DNS Security 1192 Extensions", RFC 4035, March 2005. 1194 9.2. Informative references 1196 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1197 Wu, "Internet X.509 Public Key Infrastructure Certificate 1198 Policy and Certification Practices Framework", RFC 3647, 1199 November 2003. 1201 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1202 Security (DNSSEC) Hashed Authenticated Denial of 1203 Existence", RFC 5155, March 2008. 1205 Authors' Addresses 1207 Fredrik Ljunggren 1208 Kirei AB 1209 P.O. Box 53204 1210 Goteborg SE-400 16 1211 Sweden 1213 Email: fredrik@kirei.se 1215 Anne-Marie Eklund Lowinder 1216 .SE (The Internet Infrastructure Foundation) 1217 P.O. Box 7399 1218 Stockholm SE-103 91 1219 Sweden 1221 Email: amel@iis.se 1223 Tomofumi Okubo 1224 Internet Corporation For Assigned Names and Numbers 1225 4676 Admiralty Way, Suite 330 1226 Marina del Ray, CA 90292 1227 USA 1229 Email: tomofumi.okubo@icann.org