Internet Engineering Task Force (IETF) F. Ljunggren Request for Comments: 6841 Kirei AB Category: Informational AM. Eklund Lowinder ISSN: 2070-1721 .SE T. Okubo ICANN January 2013 A Framework for DNSSEC Policies and DNSSEC Practice Statements
AbstractThis document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6841.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6 3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 7 3.3. Relationship between DNSSEC Policy and Practice Statement . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 9 4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Publication and Repositories . . . . . . . . . . . . . . . 11 4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12 4.4. Facility, Management, and Operational Controls . . . . . . 13 4.5. Technical Security Controls . . . . . . . . . . . . . . . 17 4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 20 4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 22 4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 23 5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
RFC4033], [RFC4034], [RFC4035]) address these vulnerabilities by using public key cryptography to add data origin authentication, data integrity verification, and authenticated denial-of-existence capabilities to the DNS. In short, DNSSEC provides a way for software to verify the origin of DNS data and validate that it has not been modified in transit or by intermediaries. To provide a means for stakeholders to evaluate the strength and security of the DNSSEC chain of trust, an entity operating a DNSSEC- enabled zone may publish a DNSSEC Practice Statement (DPS), comprising statements describing critical security controls and procedures relevant for scrutinizing the trustworthiness of the system. The DPS may also identify any of the DNSSEC Policies (DPs) it supports, explaining how it meets their requirements. The DP and DPS are not primarily aimed at users who rely on signed responses from the DNS ("relying parties"); instead, their audience is other stakeholders of the DNS infrastructure, a group that may include bodies such as regulatory authorities. Even though this document is heavily inspired by the "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" [RFC3647], with large parts being drawn from that document, the properties and structure of the DNSSEC trust model are fundamentally different from those of the X.509 Public Key Infrastructure (PKI).
It does not, however, define a particular Policy or Practice Statement, nor does it seek to provide legal advice or recommendations as to the contents.
Compromise (key compromise): Key compromise is a situation where the private component of a signing key is lost, stolen, exposed, modified, or used in an unauthorized manner. More strictly, even a suspicion that one of these has occurred will be enough to be considered as key compromise. DNS: The Domain Name System (DNS) is a hierarchical global naming catalog for computers, services, or any resource connected to the Internet. DNS zone: A portion of the global Domain Name System (DNS) namespace for which administrative responsibility has been delegated. DNSSEC: DNS Security Extensions (DNSSEC) is a set of IETF specifications [RFC4033] [RFC4034] [RFC4035] that uses public key cryptography to add data origin authentication, data integrity verification, and authenticated denial of existence capabilities to DNS. DNSSEC Policy: A DNSSEC Policy (DP) sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone. DNSSEC Practice Statement: A DNSSEC Practice Statement (DPS) is a practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level. Key rollover: An operational process to change one of the DNSSEC keys used for signing a zone via distribution of public keys in a trusted manner. Multi-person control: A security concept to distribute the authority of an operation over multiple persons, to mitigate threats caused by a single authorized individual. For example, a key recovery function may require some number of authorized individuals (m) out of the (n) to whom a portion of the recovery key was distributed, to combine their key fragments, before key recovery can occur. PKI: Public Key Infrastructure (PKI) is a concept that makes use of asymmetric cryptography to provide a system with integrity, authentication, and confidentiality and to do it via distribution of public keys in a trusted manner.
Policy authority: The body responsible for setting and administering a DNSSEC Policy and for determining whether a DPS is suitable for that Policy. Relying party: An entity that relies on a signed response from the DNS. Repository: A location on the Internet to store DP, DPS, trust anchors, and other related information that should be kept public. Security posture: A security posture is an indicator of how secure an entity is and how secure the entity should be. It is the result of an adequate threat model and risk assessment. Separation of duties: A security concept that limits the influence of a single person by segregating roles and responsibilities. Signing key: Private component of an asymmetric key pair that is used for signing of resource records within the zone. Note that the other component, called public key, is used for signature validation. TLD: A Top-Level Domain (TLD) is one of the domains at the highest level below the root in the hierarchy of the DNS. Trust anchor: Public portion of a key pair that is the authoritative entity used to authenticate the first element in a chain of trust.
A DP also constitutes a basis for an audit, accreditation, or another assessment of an entity. Each entity can be assessed against one or more DPs that it claims to implement.
organizations or multiple zones. By contrast, a Practice Statement would usually apply only to a single zone operator or a single organization, since it describes the actual controls in place that meet the requirements of applicable Policy. For example, a TLD manager or regulatory authority may define requirements in a Policy for the operation of one or more zones. The Policy will be a broad statement of the general requirements for managing the zone. A zone operator may be required to write its own Practice Statement to support the Policy, explaining how it meets the requirements of the Policy. Alternatively, a zone operator that is also the manager of that zone, and not governed by any external Policy, may still choose to disclose operational practices by publishing a DPS. The zone operator might do so to provide transparency and to gain community trust in its operations. A Policy and a Practice Statement also differ in the level of detail each expresses: although there may be variations, a Practice Statement will provide a description of procedures and controls and so will usually be more detailed than a Policy, which provides general principles. The main differences between a Policy and Practice Statement can be summarized as follows: (a) Operation of a DNS zone with DNSSEC may be governed by a Policy that establishes requirements stating what the entity operating that zone must do. An entity can use a Practice Statement to disclose how it meets the requirements of a Policy or how it has implemented critical processes and controls, absent a controlling Policy. (b) A Policy may serve the purpose of establishing a common basis of trusted operation throughout a set of zones in the DNS hierarchy. By contrast, a Practice Statement is a statement of a single zone operator or organization. (c) A Practice Statement is generally more detailed than a Policy and specifies how the zone operator or organization implements critical processes and controls, and how the entity meets any requirements specified in the one or more Policies under which it operates DNSSEC.
Section 5 below. The topics are described in detail in Section 4. A Policy can be expressed as a single set of provisions. A Practice Statement can also be expressed as a single set of provisions with each component addressing the requirements of one or more Policies. Alternatively, it could be a set of provisions that do not reference any particular policy but instead describe a set of self-imposed controls to the stakeholders. For example, a Practice Statement could be expressed as a combination of the following: (a) a list of Policies supported by the DPS; (b) for each Policy in (a), a set of provisions that contains statements addressing the requirements by filling in details not stipulated in that policy or expressly left to the discretion of the implementer. Such statements serve to show how this particular Practice Statement implements the requirements of the particular Policy; or (c) a set of provisions that contains statements regarding the DNSSEC operations practices, independent of any Policy. The statements provided in (b) may augment or refine the stipulations of an applicable Policy, but generally they must not conflict with the stipulations. In certain cases, however, a Policy authority may permit exceptions because certain compensating controls of the entity disclosed in its Practice Statement allow it to provide a level of assurance equivalent to full compliance with the policy. The framework outlines the contents of a set of provisions, in terms of eight primary components, as follows: 1. Introduction 2. Publication and Repositories 3. Operational Requirements 4. Facility, Management, and Operational Controls 5. Technical Security Controls 6. Zone Signing
7. Compliance Audit 8. Legal Matters This framework can be used by Policy authorities to write DNSSEC Policies and by zone operators to write a DNSSEC Practice Statements. Having a set of documents with the same structure facilitates comparisons with the corresponding documents of other zones. Section 5 for the complete outline. Drafters of DPSs conforming to this framework are permitted to add additional levels of subcomponents below those described here to meet specific needs. All components listed in Section 5 should be present, but drafters may leave components empty, only stating "no stipulation", if so required.
o Off-site backup.
* Contractual requirements including indemnification for damages due to the actions of the contractor personnel; * Auditing and monitoring of contractor personnel; and * Other controls on contracting personnel. o Documentation to be supplied to personnel during initial training, retraining, or otherwise.
o Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.
1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the zone's signatures required to be generated using modules compliant with the US FIPS 140-2 [FIPS-140-2] standard? If so, what is the required FIPS 140-2 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/ output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests? 2. Is the private key under m of n multi-person control? If yes, provide m and n (two-person control is a special case of m of n, where m = 2 and n >= 2). 3. Is the private key escrowed? If so, who is the escrow agent, in what form is the key escrowed (e.g., plaintext, encrypted, split key), and what are the security controls on the escrow system? 4. Is the private key backed up? If so, who is the backup agent, in what form is the key backed up (e.g., plaintext, encrypted, split key), and what are the security controls on the backup system? 5. Is the private key archived? If so, who is the archival agent, in what form is the key archived (e.g. plaintext, encrypted, split key), and what are the security controls on the archival system? 6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (e.g., plaintext, encrypted, or split key)? 7. How is the private key stored in the module (e.g., plaintext, encrypted, or split key)? 8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?
9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration. 10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and zeroizing the key. 4.5.1 through 4.5.3 potentially need to be answered with respect to activation data rather than with respect to keys.
5. identification and authentication; 6. trusted path; and 7. security testing. This subcomponent may also address requirements for product assurance, product evaluation analysis, testing, profiling, product certification, and/or product accreditation.
and determine their own behavior. In addition, this section will be used to state the compliance to the cryptographic and operational requirements pertaining to zone signing, if any. RFC4034], NSEC3 [RFC5155], or any other mechanism defined in the future that is used to authenticate the denial of existence of resource records. This subcomponent describes what mechanisms are used, any parameters associated with that mechanism, and how these mechanisms and parameters may be changed.
Section 4 of this document is structured so that it provides guidance for each corresponding component and subcomponent of the outline. 1. INTRODUCTION 1.1. Overview 1.2. Document name and identification 1.3. Community and applicability 1.4. Specification administration 1.4.1. Specification administration organization 1.4.2. Contact information 1.4.3. Specification change procedures 2. PUBLICATION AND REPOSITORIES 2.1. Repositories 2.2. Publication of public keys 3. OPERATIONAL REQUIREMENTS 3.1. Meaning of domain names
3.2. Identification and authentication of child zone manager 3.3. Registration of delegation signer (DS) resource records 3.4. Method to prove possession of private key 3.5. Removal of DS resource records 3.5.1. Who can request removal 3.5.2. Procedure for removal request 3.5.3. Emergency removal request 4. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 4.1. Physical controls 4.1.1. Site location and construction 4.1.2. Physical access 4.1.3. Power and air conditioning 4.1.4. Water exposures 4.1.5. Fire prevention and protection 4.1.6. Media storage 4.1.7. Waste disposal 4.1.8. Off-site backup 4.2. Procedural controls 4.2.1. Trusted roles 4.2.2. Number of persons required per task 4.2.3. Identification and authentication for each role 4.2.4. Tasks requiring separation of duties 4.3. Personnel controls 4.3.1. Qualifications, experience, and clearance requirements 4.3.2. Background check procedures 4.3.3. Training requirements 4.3.4. Job rotation frequency and sequence 4.3.5. Sanctions for unauthorized actions 4.3.6. Contracting personnel requirements 4.3.7. Documentation supplied to personnel 4.4. Audit logging procedures 4.4.1. Types of events recorded 4.4.2. Frequency of processing log 4.4.3. Retention period for audit log information 4.4.4. Protection of audit log 4.4.5. Audit log backup procedures 4.4.6. Audit collection system 4.4.7. Vulnerability assessments 4.5. Compromise and disaster recovery 4.5.1. Incident and compromise handling procedures 4.5.2. Corrupted computing resources, software, and/or data 4.5.3. Entity private key compromise procedures 4.5.4. Business continuity and IT disaster recovery capabilities 4.6. Entity termination
5. TECHNICAL SECURITY CONTROLS 5.1. Key pair generation and installation 5.1.1. Key pair generation 5.1.2. Public key delivery 5.1.3. Public key parameters generation and quality checking 5.1.4. Key usage purposes 5.2. Private key protection and cryptographic module engineering controls 5.2.1. Cryptographic module standards and controls 5.2.2. Private key (m-of-n) multi-person control 5.2.3. Private key escrow 5.2.4. Private key backup 5.2.5. Private key storage on cryptographic module 5.2.6. Private key archival 5.2.7. Private key transfer into or from a cryptographic module 5.2.8. Method of activating private key 5.2.9. Method of deactivating private key 5.2.10. Method of destroying private key 5.3. Other aspects of key pair management 5.4. Activation data 5.4.1. Activation data generation and installation 5.4.2. Activation data protection 5.4.3. Other aspects of activation data 5.5. Computer security controls 5.6. Network security controls 5.7. Timestamping 5.8. Life cycle technical controls 6. ZONE SIGNING 6.1. Key lengths, key types, and algorithms 6.2. Authenticated denial of existence 6.3. Signature format 6.4. Key rollover 6.5. Signature lifetime and re-signing frequency 6.6. Verification of resource records 6.7. Resource records time-to-live 7. COMPLIANCE AUDIT 7.1. Frequency of entity compliance audit 7.2. Identity/qualifications of auditor 7.3. Auditor's relationship to audited party 7.4. Topics covered by audit 7.5. Actions taken as a result of deficiency 7.6. Communication of results 8. LEGAL MATTERS
RFC 3647 and its predecessor (RFC 2527), and the authors acknowledge the work in the development of these documents. In addition, the authors would like to acknowledge the contributions made by Richard Lamb, Jakob Schlyter, and Stephen Morris. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.