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