[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-ljunggren-dps-framework) 00
01 02 03 04 05 06 07 08 09 10 11 RFC 6841
Network Working Group F. Ljunggren
Internet-Draft Kirei AB
Intended status: Informational A-M. Eklund-Lowinder
Expires: February 1, 2011 .SE
T. Okubo
ICANN
July 31, 2010
DNSSEC Policy & Practice Statement Framework
draft-ietf-dnsop-dnssec-dps-framework-02
Abstract
This document presents a framework to assist writers of DNSSEC Policy
and Practice Statements such as Domain Managers and Zone Operators on
both the top-level and secondary level, who is managing and operating
a DNS zone with Security Extensions (DNSSEC) 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 1, 2011.
Copyright Notice
Copyright (c) 2010 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
Ljunggren, et al. Expires February 1, 2011 [Page 1]
Internet-Draft DPS framework July 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. DPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Relationship between DNSSEC Policy and Practice
Statement . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Set of provisions . . . . . . . . . . . . . . . . . . . . 9
4. Contents of a set of provisions . . . . . . . . . . . . . . . 10
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Document Name and Identification . . . . . . . . . . . 11
4.1.3. Community and Applicability . . . . . . . . . . . . . 11
4.1.4. Specification Administration . . . . . . . . . . . . . 11
4.2. Publication and Repositories . . . . . . . . . . . . . . . 11
4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
4.3.1. Meaning of domain names . . . . . . . . . . . . . . . 12
4.3.2. Activation of DNSSEC for child zone . . . . . . . . . 12
4.3.3. Identification and authentication of child zone
manager . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.4. Registration of delegation signer (DS) resource
records . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.5. Method to prove possession of private key . . . . . . 12
4.3.6. Removal of DS resource records . . . . . . . . . . . . 12
4.4. Facility, Management and Operational Controls . . . . . . 13
4.4.1. Physical Controls . . . . . . . . . . . . . . . . . . 13
4.4.2. Procedural Controls . . . . . . . . . . . . . . . . . 13
4.4.3. Personnel Controls . . . . . . . . . . . . . . . . . . 14
4.4.4. Audit Logging Procedures . . . . . . . . . . . . . . . 14
4.4.5. Compromise and Disaster Recovery . . . . . . . . . . . 15
4.4.6. Entity termination . . . . . . . . . . . . . . . . . . 16
4.5. Technical Security Controls . . . . . . . . . . . . . . . 16
4.5.1. Key Pair Generation and Installation . . . . . . . . . 16
4.5.2. Private key protection and Cryptographic Module
Engineering Controls . . . . . . . . . . . . . . . . . 17
Ljunggren, et al. Expires February 1, 2011 [Page 2]
Internet-Draft DPS framework July 2010
4.5.3. Other Aspects of Key Pair Management . . . . . . . . . 18
4.5.4. Activation data . . . . . . . . . . . . . . . . . . . 18
4.5.5. Computer Security Controls . . . . . . . . . . . . . . 18
4.5.6. Network Security Controls . . . . . . . . . . . . . . 19
4.5.7. Timestamping . . . . . . . . . . . . . . . . . . . . . 19
4.5.8. Life Cycle Technical Controls . . . . . . . . . . . . 19
4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.1. Key lengths and algorithms . . . . . . . . . . . . . . 20
4.6.2. Authenticated denial of existence . . . . . . . . . . 20
4.6.3. Signature format . . . . . . . . . . . . . . . . . . . 20
4.6.4. Zone signing key roll-over . . . . . . . . . . . . . . 20
4.6.5. Key signing key roll-over . . . . . . . . . . . . . . 20
4.6.6. Signature life-time and re-signing frequency . . . . . 20
4.6.7. Verification of zone signing key set . . . . . . . . . 20
4.6.8. Verification of resource records . . . . . . . . . . . 20
4.6.9. Resource records time-to-live . . . . . . . . . . . . 21
4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 21
4.7.1. Frequency of entity compliance audit . . . . . . . . . 21
4.7.2. Identity/qualifications of auditor . . . . . . . . . . 21
4.7.3. Auditor's relationship to audited party . . . . . . . 21
4.7.4. Topics covered by audit . . . . . . . . . . . . . . . 21
4.7.5. Actions taken as a result of deficiency . . . . . . . 21
4.7.6. Communication of results . . . . . . . . . . . . . . . 22
4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 22
4.8.1. Fees . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8.2. Financial responsibility . . . . . . . . . . . . . . . 22
4.8.3. Confidentiality of business information . . . . . . . 22
4.8.4. Privacy of personal information . . . . . . . . . . . 23
4.8.5. Limitations of liability . . . . . . . . . . . . . . . 23
4.8.6. Term and termination . . . . . . . . . . . . . . . . . 23
5. Outline of a set of provisions . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Ljunggren, et al. Expires February 1, 2011 [Page 3]
Internet-Draft DPS framework July 2010
1. Introduction
1.1. Background
The DNS was not originally designed with strong security mechanisms
to provide integrity and authenticity of DNS data. Over the years, a
number of vulnerabilities have been discovered that threaten the
reliability and trustworthiness of the system.
The Domain Name System Security Extensions (DNSSEC, [RFC4033]) is a
set of IETF specifications which addresses these vulnerabilities by
adding data origin authentication, data integrity verification and
authenticated denial of existence capabilities to the Domain Name
System, using public key cryptography. In short, DNSSEC provides a
way for software to validate that Domain Name System (DNS) data has
not been modified during transit.
To provide means for the relying parties to evaluate the strength and
security of the DNSSEC chain of trust, an entity operating a DNSSEC
enabled zone may choose to publish a DNSSEC Practice Statement (DPS),
comprising statements of critical security controls and procedures
relevant for scrutinizing the trustworthiness of the system. The DPS
may also identify one or more DNSSEC Policies which are supported,
explaining how it meets the requirements of each Policy.
Even though this document is heavily inspired by the Internet X.509
Public Key Infrastructure Certificate Policy and Certification
Practices Framework [RFC3647], and large parts drawn from that
document, the properties and structure of the DNSSEC PKI is
fundamentally different from the X.509 PKI.
In the DNSSEC PKI there is no central control of assurance or trust
levels. Each zone manager may select their own way of managing keys
and operations, and there is no necessity to perform any coordination
of security practices between different zones in the DNS. The degree
to which a relying party can trust the binding embodied in the DNSSEC
chain of trust is dependent on the weakest link of that chain. This
implies that the security of zones is generally more critical higher
up in the DNS hierarchy.
Another significant difference is that the DPS is focused only on
stating the security posture of a zone, rather than for all
participants in the domain name system. The DNS is of a almost
ubiquitous nature, and there exists no agreements with the relying
(third) parties, which is all entities relying on signed responses
from the DNS.
Ljunggren, et al. Expires February 1, 2011 [Page 4]
Internet-Draft DPS framework July 2010
1.2. Purpose
The purpose of this document is twofold. Firstly, the document aims
to explain the concept of a DPS and describe the relationship between
a DNSSEC Policy (DP) and a DNSSEC Practice Statement (DPS). Second,
this document aims to present a framework to encourage and assist
writers of Policies and Practice Statements in creating heterogenous
and comparable documents. In particular, the framework identifies
the elements that should be considered in formulating a DP/DPS. The
purpose is not to define a particular Policy or Practice Statement,
per se. Moreover, this document does not aim to provide legal advice
or recommendations as to particular requirements or practices that
should be contained within a DP/DPS.
1.3. Scope
The scope of this document is limited to discussion of the topics
that can be covered in a DP/DPS and does not go into the specific
details that could possibly be included in each one. In particular,
this document describes the types of information that should be
considered for inclusion in a DP/DPS.
The DNSSEC Policy and Practice Statement framework should be viewed
and used as a checklist of factors that should be taken in to
consideration prior to deploying DNSSEC, and an outline to create a
operational practices disclosure document. It is primarily aimed at
TLD managers and organizations providing registry services, but may
be used by high-value domain holders and serve as a check sheet for
DNSSEC readiness at a high level.
This document assumes that the reader is familiar with the general
concepts of DNS, DNSSEC and PKI.
2. Definitions
This document makes use of the following defined terms:
Chain of Trust - Chain of Trust is a hierarchical structure of trust
that consists the Key Signing Keys, Zone Signing Keys and the
Delegation Signer Records.
DNS - The Domain Name System (DNS) is a hierarchical global naming
catalog for computers, services, or any resource connected to the
Internet. It associates various information with domain names
assigned to each of the participants.
DNS Zone - A portion of the global Domain Name System (DNS) namespace
Ljunggren, et al. Expires February 1, 2011 [Page 5]
Internet-Draft DPS framework July 2010
for which administrative responsibility has been delegated.
DNSSEC Policy - A DNSSEC Policy sets forth the requirements and
standards to be implemented for a DNSSEC signed zone. A Practice
Statement may support a Policy by explaining how it meets the
requirements of the Policy.
DNSSEC Practices Statement - A DNSSEC Practices Statement is a
practices disclosure document which may be a supplemental document to
the DNSSEC Policy (if such exists) and states how the management of a
given zone implements procedures and controls at a high level.
Relying Party - All entities that relies on the signed response from
the DNS.
Security Posture - A Security Posture is a barometer that indicates
how secure the entity is and how secure the entity should be which is
a result of an adequate threat modelling, vulnerability assessment
and risk assessment.
Trust Anchor - Public portion of the Key Signing Key which is the
authoritative entity used to cryptographically validate the chain of
trust to the signed resource record.
Key Roll Over - A operational process of DNSSEC to change either the
Key Signing Key or the Zone Signing Key.
Repository - Repository is a location on the internet to store DP,
DPS, Trust Anchors and other related information that should be kept
public.
Compromise (Key Compromise) - Key Compromise is a situation where the
private component of the Key Signing Key or Zone Signing Key are
lost, stolen or exposed, modified or under unauthorized usage. More
strictly, even a suspicion will be enough to be considered as key
compromise.
Public Key Infrastructure - A concept that uses asymmetric
cryptography, which may provide integrity, authentication,
confidentiality and non-repudiation to a system.
Activation data - Data values, other than keys, that are required to
operate the cryptographic modules which are usually used to protect
the keys from unauthorized use.
Separation of Duties - A security concept that limits the influence
of a single person by segregating the roles and responsibilities.
Ljunggren, et al. Expires February 1, 2011 [Page 6]
Internet-Draft DPS framework July 2010
Audit logs - Control evidence information generated by the DNS and
DNSSEC related systems, the surrounding facility or other manually
processed, non-electronic documentation to prove the integrity of
processes. Audit logs will be examined by the internal and/or
external auditors.
Policy Management Authority - A group formed by stake-holders from
each group within the organization operating DNSSEC. The group is
responsible for approving changes to the DPS. In addition, any other
matters that could possibly affect the DNSSEC operations are to be
discussed in this group.
3. Concepts
This section describes the concept of a DNSSEC Policy and of a DNSSEC
Practices Statement. Other related concepts are described as well.
3.1. DPS
Most DNSSEC participants may not have the need to create a thorough
and detailed statement of practices. For example, the registrant may
itself be the sole relying party of its own zone and would already be
aware of the nature and trustworthiness of its services. In other
cases, a zone manager may provide registration services providing
only a very low level of assurances where the domain names being
secured may pose only marginal risks if compromised. Publishing a
DPS is most relevant for entities operating a zone which contains a
significant number of delegations to other entities.
A DPS should contain information which is relevant to the
stakeholders of the relevant zone(s). Since these generally include
the Internet community, it should not contain such information which
could be considered to be sensitive details of an entity's
operations.
3.2. DP
The DP sets forth requirements that are appropriate for a determined
level of assurance. For example, a DP may encompass all topics of
this framework, each with a certain set of security requirements and
possibly grouped them into categories, such as medium impact and high
impact. The progression from medium to high levels would correspond
to increasing security requirements and corresponding increasing
levels of assurance.
A DPS may identify a supported DP, which may subsequently be used by
a relying party to evaluate the trustworthiness of any digital
Ljunggren, et al. Expires February 1, 2011 [Page 7]
Internet-Draft DPS framework July 2010
signatures verified using the public key of that entity.
DPs also constitute a basis for an audit, accreditation, or another
assessment of an entity. Each entity can be assessed against one or
more DPs that it is recognized as implementing.
3.3. Relationship between DNSSEC Policy and Practice Statement
A DNSSEC Policy and a DNSSEC Practice Statement address the same set
of topics that are of interest to the stakeholders in terms of the
degree to which a DNSSEC digital signature may be trusted. Their
primary difference is in the focus of their provisions. A Policy
sets forth the requirements and standards to be implemented for a
DNSSEC signed zone. In other words, the purpose of the Policy is to
establish what entities must do. A Practice Statement, by contrast,
states how a zone operator and possibly other participants in the
management of a given zone implements procedures and controls to meet
the requirements stated in the Policy. In other words, the purpose
of the Practice Statement is to disclose how the participants perform
their functions and implement controls.
An additional difference between a Policy and a Practice Statement
relates the scope of coverage of the two kinds of documents. Since a
Policy is a statement of requirements, it best used for communicating
minimum operating guidelines that must be met by complying parties,
but may as such also be used to facilitate interoperation of level of
trust between zones. Thus, a Policy may apply to multiple
organizations or multiple zones. By contrast, a Practice Statement
would usually apply only to a single zone operator or a single
organization.
For example, a TLD Manager or regulatory authority may define
requirements in a Policy for operations 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 by explaining how it meets the requirements of
the Policy. Or, a zone operator which 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, for the purpose
of providing transparency and gain community trust in the operations.
An additional difference between a Policy and a Practice Statement
concerns the level of detail of the provisions in each. Although the
level of detail may vary, a Practice Statement will generally be more
detailed than a Policy. A Practice Statement provides a detailed
description of procedures and controls in place to meet the Policy
Ljunggren, et al. Expires February 1, 2011 [Page 8]
Internet-Draft DPS framework July 2010
requirements, while a Policy is more general.
The main differences between a Policy and Practice Statement can
therefore be summarized as follows:
(a) Operation of a DNS zone with DNSSEC may be governed by a Policy,
to establish requirements that state 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.
(b) A Policy may facilitate interoperation of level of trust through
several parts or levels 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.
3.4. Set of provisions
A set of provisions is a collection of Policy requirements or
Practice statements, which may employ the approach described in this
framework by covering the topics appearing in Section 5 below. They
are also described in detail in Section 4 below.
A Policy can be expressed as a single set of provisions.
A Practice Statement can be expressed as a single set of provisions
with each component addressing the requirements of one or more
Policies, or, alternatively, as not referencing any particular policy
but used solely as to disclose any self-imposed provisions to the
relying parties. 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 responding to that Policy by filling in details not
stipulated in that policy or expressly left to the discretion of
the implementor; such statements serve to state how this
particular Practice Statement implements the requirements of the
particular Policy; or
(c) a set of provisions that contains statements regarding the
practices of the DNSSEC operations, regardless of any Policy.
The statements provided in (b) may augment or refine the stipulations
of an applicable Policy, but generally must not conflict with any of
Ljunggren, et al. Expires February 1, 2011 [Page 9]
Internet-Draft DPS framework July 2010
the stipulations of such Policy. In certain cases, however, a Policy
Authority may permit exceptions to the requirements in a Policy,
because certain compensating controls of the entity are disclosed in
its Practices Statement, that allow the entity to provide assurances
that are equivalent to the assurances provided by entities that are
in full compliance with the Policy.
This 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
Policy authorities can use this framework of eight primary components
to write a DNSSEC Policy. Moreover, a zone operator can use this
same framework to write a DNSSEC Practice Statement.
Therefore, an entity can establish a set of basic documents with the
same structure and ordering of topics, thereby facilitating
comparisons and mappings among these documents and among the
corresponding documents of other zones.
Drafters of DPSs in conformance with this framework are permitted to
add additional levels of subcomponents below the subcomponents
described in Section 4 for the purpose of meeting the needs of the
drafter's particular requirements.
4. Contents of a set of provisions
4.1. Introduction
This component identifies and introduces the set of provisions, and
indicates the types of entities and applications for which the
document (either the Policy or the Practice Statement being written)
is targeted.
4.1.1. Overview
This subcomponent provides a general introduction to the document
being written. This subcomponent can also be used to provide a
synopsis of the participants to which the Policy or Practice
Ljunggren, et al. Expires February 1, 2011 [Page 10]
Internet-Draft DPS framework July 2010
Statement applies.
4.1.2. Document Name and Identification
This subcomponent provides any applicable names or other identifiers
of the document.
4.1.3. Community and Applicability
This subcomponent addresses the stakeholders in DNSSEC along with the
expected roles and responsibilities. This includes but are not
limited to an entity signing the zone, an entity that relies on the
signed zone, other entities that have operational dependency on the
signed zone and an entity that entrusted the zone signing.
4.1.4. Specification Administration
This subcomponent includes the name and mailing address of the
organization that is responsible for drafting, registering,
maintaining, and updating of the DP/DPS. It also includes the name,
electronic mail address and telephone number of a contact person. As
an alternative to naming an actual person, the document may name a
title or role, an e-mail alias, and other generalized contact
information. In some cases, the organization may state that its
contact person, alone or in combination with others, is available to
answer questions about the document.
Moreover, when a formal or informal Policy Authority is responsible
for determining whether a zone operator should be allowed to operate
a Zone, it may wish to approve the DPS of the zone operator as being
suitable for the Policy. If so, this subcomponent can include the
name or title, electronic mail address (or alias), telephone number
and other generalized information of the entity in charge of making
such a determination. Finally, in this case, this subcomponent also
includes the procedures by which this determination is made.
4.2. Publication and Repositories
This component contains any applicable provisions regarding:
o An identification of the entity or entities that operate
repositories within the community, such as a zone operator or a
TLD Manager;
o The responsibility of an entity to publish information regarding
its practices, public keys, and the current status of such keys,
which may include the responsibilities of making the DPS publicly
available using various mechanisms and of identifying components,
subcomponents, and elements of such documents that exist but are
Ljunggren, et al. Expires February 1, 2011 [Page 11]
Internet-Draft DPS framework July 2010
not made publicly available, for instance, security controls,
clearance procedures, or business information due to their
sensitivity;
o When information must be published and the frequency of
publication; and
o Access control on published information objects.
4.3. Operational Requirements
This component describes the operational requirements when operating
a DNSSEC signed zone.
4.3.1. Meaning of domain names
This section describes the overall policy of child zone naming, if
any.
4.3.2. Activation of DNSSEC for child zone
This section describes the process of establishing the chain-of-trust
to the child zone by incorporating DS record(s) into the zone.
4.3.3. Identification and authentication of child zone manager
This section describes how the child zone manager has initially been
identified, and how any subsequent change request is authenticated as
to originate from the manager or its authorized representative.
4.3.4. Registration of delegation signer (DS) resource records
This section describes how the delegation signer resource records are
incorporated into the parent zone.
4.3.5. Method to prove possession of private key
This section describes how, if, or under which circumstances the
child zone manager is required to provide proof of the possession of
the private component of any current or subsequent child zone Key
Signing Key.
4.3.6. Removal of DS resource records
This section will explain how, when and under which circumstances the
DS record may be removed from the zone.
Ljunggren, et al. Expires February 1, 2011 [Page 12]
Internet-Draft DPS framework July 2010
4.4. Facility, Management and Operational Controls
This component describes non-technical security controls (that is,
physical, procedural, and personnel controls) in use by the entity to
securely perform the DNSSEC related functions such as physical
access, key management, disaster recovery, auditing and archiving.
These non-technical security controls are critical for trusting the
signatures since lack of security may compromise DNSSEC operations
resulting for example, in the creation of signatures with erroneous
information or compromising the Key Signing Key and/or Zone Signing
Key.
Within each subcomponent, separate consideration will, in general,
need to be given to each entity type.
4.4.1. Physical Controls
In this subcomponent, the physical controls on the facility housing
the entity systems are described. Topics addressed may include:
o Site location and construction, such as the construction
requirements for high-security areas and the use of locked rooms,
cages, safes, and cabinets;
o Physical access, i.e., mechanisms to control access from one area
of the facility to another or access into high-security zones,
such as locating DNSSEC operations in a secure computer room
monitored by guards, cameras or security alarms and requiring
movement from zone to zone to be accomplished using tokens and/or
PINs;
o Power and air conditioning;
o Water exposures;
o Fire prevention and protection;
o Media storage, for example, requiring the storage of backup media
in a separate location that is physically secure and protected
from fire, smoke, particle and water damage;
o Waste disposal; and
o Off-site backup.
4.4.2. Procedural Controls
In this subcomponent, requirements for recognizing trusted roles are
described, together with the responsibilities for each role.
Examples of trusted roles include system administrators, security
officers, and system auditors.
For each task identified, the number of individuals required to
Ljunggren, et al. Expires February 1, 2011 [Page 13]
Internet-Draft DPS framework July 2010
perform the task (n of m rule, if applicable) should be stated for
each role. Identification and authentication requirements for each
role may also be defined.
This component also includes the separation of duties in terms of the
roles that cannot be performed by the same individuals.
4.4.3. Personnel Controls
This subcomponent addresses the following:
o Qualifications, experience, and clearances that personnel must
have as a condition of filling trusted roles or other important
roles. Examples include credentials, job experiences, and
official government clearances that candidates for these positions
must have before being hired;
o Background checks and clearance procedures that are required in
connection with the hiring of personnel filling trusted roles or
perhaps other important roles; such roles may require a check of
their criminal records, financial records, references, and
additional clearances that a participant undertakes after a
decision has been made to hire a particular person;
o Training requirements and training procedures for each role
following the hiring of personnel;
o Any retraining period and retraining procedures for each role
after completion of initial training;
o Frequency and sequence for job rotation among various roles;
o Sanctions against personnel for unauthorized actions, unauthorized
use of authority, and unauthorized use of the entity systems;
o Controls on personnel that are independent contractors rather than
employees of the entity; examples include:
* Bonding requirements on contract personnel;
* 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.
4.4.4. Audit Logging Procedures
This subcomponent is used to describe event logging and audit
systems, implemented for the purpose of maintaining an audit trail
and provide evidence of processes' integrity. Elements include the
following:
Ljunggren, et al. Expires February 1, 2011 [Page 14]
Internet-Draft DPS framework July 2010
o Types of events recorded, such as attempts to access the system,
and requests made to the system;
o Frequency with which audit logs are processed or archived, for
example, weekly, following an alarm or anomalous event, or when
ever the audit log is n% full;
o Period for which audit logs are kept;
o Protection of audit logs:
* Who can view audit logs, for example only the audit
administrator;
* Protection against modification of audit logs, for instance a
requirement that no one may modify or delete the audit records
or that only an audit administrator may delete an audit file as
part of rotating the audit file; and
* Protection against deletion of audit logs.
o Audit log back up procedures;
o Whether the audit log accumulation function is internal or
external to the system;
o Whether the subject who caused an audit event to occur is notified
of the audit action; and
o Vulnerability assessments, for example, where audit data is run
through a tool that identifies potential attempts to breach the
security of the system.
4.4.5. Compromise and Disaster Recovery
This subcomponent describes requirements relating to notification and
recovery procedures in the event of compromise or disaster. Each of
the following may need to be addressed separately:
o Identification or listing of the applicable incident and
compromise reporting and handling procedures.
o The recovery procedures used if computing resources, software,
and/or data are corrupted or suspected to be corrupted. These
procedures describe how a secure environment is re-established,
whether the Key Signing Key or Zone Signing key requires a roll
over, how to assess the damage and carry out the root cause
analysis.
o The recovery procedures used if the Key Signing Key or Zone
Signing Key is compromised. These procedures describe how a
secure environment is re-established, how the keys are rolled
over, how a new Trust Anchor is provided to the users (if
applicable) and how new zone is published.
o The entity's capabilities to ensure business continuity following
a natural or other disaster. Such capabilities may include the
availability of a disaster recovery site at which operations may
Ljunggren, et al. Expires February 1, 2011 [Page 15]
Internet-Draft DPS framework July 2010
be recovered. They may also include procedures for securing its
facility during the period of time following a natural or other
disaster and before a secure environment is re-established, either
at the original site or at a disaster recovery site. For example,
procedures to protect against theft of sensitive materials from an
earthquake-damaged site.
4.4.6. Entity termination
This subcomponent describes requirements relating to procedures for
entity termination, termination notification and transition of
responsibilities of a zone operator or other entity, where the
purpose may be to ensure that the transition process will be
transparent to the relying parties and will not affect the services.
4.5. Technical Security Controls
This component is used to define the security measures taken to
protect the cryptographic keys and activation data (e.g., PINs,
passwords, or manually-held key shares) relevant to the DNSSEC
operations. Secure key management is critical to ensure that all
secret and private keys and activation data are protected and used
only by authorized personnel.
This component also describes other technical security controls used
to securely perform the functions of key generation, authentication,
registration, auditing, and archiving. Technical controls include
life-cycle security controls (including software development
environment security) and operational security controls.
This component can also be used to define other technical security
controls on repositories, authoritative name servers or other
participants where applicable.
4.5.1. Key Pair Generation and Installation
Key pair generation and installation need to be considered, whereas
the following questions potentially need to be answered:
1. Who generates the zone's public, private key pairs? Furthermore,
how is the key generation performed? Is the key generation
performed by hardware or software?
2. How is the private key installed in all parts of the key
management system?
Ljunggren, et al. Expires February 1, 2011 [Page 16]
Internet-Draft DPS framework July 2010
3. How is the zones's public keys provided securely to parent zone
and potential relying parties?
4. Who generates the public key parameters, and is the quality of
the parameters checked during key generation?
5. For what purposes may the keys be used, or for what purposes
should usage of the key be restricted?
4.5.2. Private key protection and Cryptographic Module Engineering
Controls
Requirements for private key protection and cryptographic modules
need to be considered for key generation and creation of signatures.
The following questions potentially need to be answered:
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 zones signatures required to be
generated using modules compliant with the US FIPS 140-2? 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 n out of m multi-person control? If
yes, provide n and m (two person control is a special case of n
out of m, where n = m = 2)?
3. Is the private key escrowed? If so, who is the escrow agent,
what form is the key escrowed in (examples include 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,
what form is the key backed up in (examples include 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,
what form is the key archived in (examples include 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 (i.e., plaintext, encrypted,
or split key)?
Ljunggren, et al. Expires February 1, 2011 [Page 17]
Internet-Draft DPS framework July 2010
7. How is the private key stored in the module (i.e., 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.3. Other Aspects of Key Pair Management
Other aspects of key management need to be considered for the zone
operator and other participants. For each of these types of
entities, the following questions potentially need to be answered:
1. Is the public key archived? If so, who is the archival agent and
what are the security controls on the archival system?
2. What is the operational period of the keys. What are the usage
periods, or active lifetimes for the pairs?
4.5.4. Activation data
Activation data refers to data values other than whole private keys
that are required to operate private keys or cryptographic modules
containing private keys, such as a PIN, passphrase, or portions of a
private key used in a key-splitting scheme. Protection of activation
data prevents unauthorized use of the private key, and potentially
needs to be considered for the zone operator and other participants.
Such consideration potentially needs to address the entire life-cycle
of the activation data from generation through archival and
destruction. For each of the entity types, all of the questions
listed in 4.5.1 through 4.5.3 potentially need to be answered with
respect to activation data rather than with respect to keys.
4.5.5. Computer Security Controls
This subcomponent is used to describe computer security controls such
as: use of the trusted computing base concept or equivalent,
discretionary access control, labels, mandatory access controls,
object re-use, audit, identification and authentication, trusted
Ljunggren, et al. Expires February 1, 2011 [Page 18]
Internet-Draft DPS framework July 2010
path, and security testing. Product assurance may also be addressed.
A computer security rating for computer systems may be specified.
The rating could be based, for example, on a protection profile (PP)
of the Common Criteria for Information Technology Security
Evaluation, ISO/IEC 15408:1999. This subcomponent may also address
requirements for product evaluation analysis, testing, profiling,
product certification, and/or product accreditation related activity
undertaken.
4.5.6. Network Security Controls
This subcomponent addresses network security related controls,
including firewalls, routers and remote access.
4.5.7. Timestamping
This subcomponent addresses requirements or practices relating to the
use of timestamps on various data. It may also discuss whether or
not the time-stamping application must use a trusted time source.
4.5.8. Life Cycle Technical Controls
This subcomponent addresses system development controls and security
management controls.
System development controls include development environment security,
development personnel security, configuration management security
during product maintenance, software engineering practices, software
development methodology, modularity, layering, use of failsafe design
and implementation techniques (e.g., defensive programming) and
development facility security.
Security management controls include execution of tools and
procedures to ensure that the operational systems and networks adhere
to configured security. These tools and procedures include checking
the integrity of the security software, firmware, and hardware to
ensure their correct operation.
4.6. Zone Signing
This component covers all aspects of zone signing, including the
cryptographic specification surrounding the Key Signing Key and Zone
Signing Key, signing scheme and methodology for key roll-over and the
actual zone signing. Child zones and other relying parties may
depend on the information in this section to understand the expected
data in the signed zone and determine their own behavior. In
addition, this section will be used to state the compliance to the
Ljunggren, et al. Expires February 1, 2011 [Page 19]
Internet-Draft DPS framework July 2010
cryptographic and operational requirements pertaining to zone signing
if applicable.
4.6.1. Key lengths and algorithms
This subcomponent describes the key generation algorithm and the key
length used to create the Key Signing Key and the Zone Signing Key.
4.6.2. Authenticated denial of existence
Authenticated denial of existence refers to the usage of NSEC (RFC
4034 [RFC4034]), NSEC3 (RFC 5155 [RFC5155]) or any other record
defined in the future that is used to authenticate the denial of
existence of the resource record.
4.6.3. Signature format
This subcomponent is used to describe the signing method and
algorithms used for the zone signing.
4.6.4. Zone signing key roll-over
This subcomponent explains the Zone signing key roll-over scheme.
4.6.5. Key signing key roll-over
This subcomponent addresses the Key signing key roll-over scheme.
4.6.6. Signature life-time and re-signing frequency
This subcomponent identifies the life-cycle of the Resource Record
Signature (RRSIG) record.
4.6.7. Verification of zone signing key set
This subsection addresses the controls around the keyset signing
process performed by the Key Signing Key. The procedures surrounding
KSK management may be different from those of the ZSK, hence it may
be necessary to authenticate the data signed by the KSK.
4.6.8. Verification of resource records
This subsection addresses the controls around the verification of the
resource records in order to validate and authenticate the data to be
signed.
Ljunggren, et al. Expires February 1, 2011 [Page 20]
Internet-Draft DPS framework July 2010
4.6.9. Resource records time-to-live
This subcomponent specifies the time-to-live (TTL) for each DNSSEC
related resource record such as DNSKEY, NSEC/NSEC3, DS and RRSIG.
4.7. Compliance Audit
The ideal and the only way to prove the compliance with a Policy or
the statements in the Practices Statement is to conduct an audit.
This component describes the outline of how the audit is conducted at
the zone operator and possibly at other involved entities.
4.7.1. Frequency of entity compliance audit
This subcomponent describes the frequency of the compliance audit.
4.7.2. Identity/qualifications of auditor
This subcomponent addresses what is the qualifications for the
auditor. For instance it may be an auditor from a specific
association or an auditor that has a certain certifications.
4.7.3. Auditor's relationship to audited party
This subcomponent is used to clarify the relationship between the
auditor and the entity being audited. This becomes important if
there is any requirements or guidelines for selection of the auditor.
4.7.4. Topics covered by audit
Topics covered by audit refers to the scope of the audit. Since the
DNSSEC Policy and Practices Statement is the document to be audited
against, it is ideal to set the scope to the scope of the DP/DPS.
However, the scope may be narrowed down or expanded as needed for
example in case there is not enough resources to conduct a full
audit, or some portion is under development and not ready for the
audit.
4.7.5. Actions taken as a result of deficiency
This subcomponent specifies the action taken in order to correct any
discrepancy. This could be the remediation process for the audit
findings or any other action to correct any descrepancy with the
DNSSEC Policy or Practices Statement.
Ljunggren, et al. Expires February 1, 2011 [Page 21]
Internet-Draft DPS framework July 2010
4.7.6. Communication of results
This subcomponent specifies how the results of the audit are
communicated to the stakeholders.
4.8. Legal Matters
This component covers legal matters. Sections 8.1 and 8.2 of the
framework discuss the business issues of fees to be charged for
various services and the financial responsibility of participants to
maintain resources for ongoing operations. The remaining sections
are generally concerned with legal topics.
With respect to many of the legal subcomponents within this
component, a DPS drafter may choose to include in the document terms
and conditions that apply directly to registrants or relying parties.
For instance, a Registry Manager may set forth limitations of
liability that apply to registrants and relying parties. The
inclusion of terms and conditions is likely to be appropriate only
where the DPS is itself a contract or part of a contract.
In most cases, however, the DPS is not a contract or part of a
contract; instead, it is laid out so that its terms and conditions
are applied to the parties by separate documents, which may include
associated agreements, such as registrar or registrant agreements.
In that event, a drafter may write a Policy so as to require that
certain legal terms and conditions appear (or not appear) in such
associated agreements.
4.8.1. Fees
This subcomponent contains any applicable provisions regarding fees
charged for DNSSEC or services related to DNSSEC.
4.8.2. Financial responsibility
This subcomponent contains requirements or disclosures relating to
the resources available to the zone operator, and to remain solvent
if they are liable to pay a judgment or settlement in connection with
a claim arising out of such operations.
4.8.3. Confidentiality of business information
This subcomponent contains provisions relating to the treatment of
confidential business information. Specifically, this subcomponent
addresses:
Ljunggren, et al. Expires February 1, 2011 [Page 22]
Internet-Draft DPS framework July 2010
o The scope of what is considered confidential information;
o The types of information that are considered to be outside the
scope of confidential information; and
o The responsibilities of participants that receive confidential
information to secure it from compromise, and refrain from using
it or disclosing it to third parties.
4.8.4. Privacy of personal information
This subcomponent relates to the protection that participants,
particularly a Registry Operator, may be required to afford to
personally identifiable private information of registrants and other
participants. Specifically, this subcomponent addresses the
following, to the extent pertinent under applicable law:
o The designation and disclosure of the applicable privacy plan that
applies to a participant's activities, if required by applicable
law or policy;
o Information that is or is not considered private;
o Any responsibility of participants that receive private
information to secure it, and refrain from using it and from
disclosing it to third parties;
o Any requirements as to notices to, or consent from individuals
regarding use or disclosure of private information; and
o Any circumstances under which a participant is entitled or
required to disclose private information pursuant to judicial,
administrative process in a private or governmental proceeding, or
in any legal proceeding.
4.8.5. Limitations of liability
This subcomponent can include limitations of liability in a DPS or
limitations that appear or must appear in an agreement associated
with the DPS, such as a registrar or registrant agreement.
4.8.6. Term and termination
This subcomponent can include the time period in which a DPS remains
in force and the circumstances under which the document, portions of
the document, or its applicability to a particular participant can be
terminated. In addition or alternatively, the DP may include
requirements that certain term and termination clauses appear in
agreements, such as registrar or registrant agreements. In
particular, such terms can include:
Ljunggren, et al. Expires February 1, 2011 [Page 23]
Internet-Draft DPS framework July 2010
o The term of a document or agreement, that is, when the document
becomes effective and when it expires if it is not terminated
earlier.
o Termination provisions stating circumstances under which the
document, certain portions of it, or its application to a
particular participant ceases to remain in effect.
o Any consequences of termination of the document. For example,
certain provisions of an agreement may survive its termination and
remain in force. Examples include acknowledgements of
intellectual property rights and confidentiality provisions.
Also, termination may trigger a responsibility of parties to
return confidential information to the party that disclosed it.
5. Outline of a set of provisions
1. INTRODUCTION
1.1. Overview
1.2. Document name and identification
1.3. Community and Applicability
1.3.1. Registry
1.3.2. Registrar
1.3.3. Registrant
1.3.4. Relying Party
1.3.5 Auditor
1.3.4. 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 key signing keys
2.3. Access controls on repositories
3. OPERATIONAL REQUIREMENTS
3.1. Meaning of domain names
3.2. Activation of DNSSEC for child zone
3.3. Identification and authentication of child zone manager
3.4. Registration of delegation signer (DS) resource records
3.5. Method to prove possession of private key
3.6. Removal of DS record
3.6.1. Who can request removal
3.6.2. Procedure for removal request
3.6.3. Emergency removal request
4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS
4.1. Physical Controls
Ljunggren, et al. Expires February 1, 2011 [Page 24]
Internet-Draft DPS framework July 2010
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. Retraining frequency and requirements
4.3.5. Job rotation frequency and sequence
4.3.6. Sanctions for unauthorized actions
4.3.7. Contracting personnel requirements
4.3.8. 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. Notification to event-causing subject
4.4.8. 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
Ljunggren, et al. Expires February 1, 2011 [Page 25]
Internet-Draft DPS framework July 2010
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.3.1. Public key archival
5.3.2. Key usage periods
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
5.8.1. System development controls
5.8.2. Security management controls
5.8.3. Life cycle security controls
6. ZONE SIGNING
6.1. Key lengths and algorithms
6.2. Authenticated denial of existence
6.3. Signature format
6.4. Zone signing key roll-over
6.5. Key signing key roll-over
6.6. Signature life-time and re-signing frequency
6.7. Verification of zone signing key set
6.8. Verification of resource records
6.9. 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
8.1. Fees
8.2. Financial responsibility
8.3. Confidentiality of business information
8.3.1. Scope of confidential information
Ljunggren, et al. Expires February 1, 2011 [Page 26]
Internet-Draft DPS framework July 2010
8.3.2. Information not within the scope of confidential
information
8.3.3. Responsibility to protect confidential information
8.4. Privacy of personal information
8.4.1. Information treated as private
8.4.2. Information not deemed private
8.4.3. Responsibility to protect private information
8.4.4. Disclosure Pursuant to Judicial or Administrative
Process
8.5. Limitations of liability
8.6. Term and termination
8.6.1. Term
8.6.2. Termination
8.6.3. Dispute resolution provisions
8.6.4. Governing law
6. Security Considerations
The sensitivity of the information protected by DNSSEC on all levels
in the DNS tree will vary significantly. There are also not any
restrictions of what kinds of information that can be protected using
DNSSEC. Entities must evaluate their own environment and the chain
of trust originating from their Trust Anchor, the associated threats
and vulnerabilities, to determine the level of risk they are willing
to accept.
7. Acknowledgements
The authors gratefully acknowledges, in no particular order, the
contributions of the following persons:
Richard Lamb
Jakob Schlyter
8. References
8.1. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Ljunggren, et al. Expires February 1, 2011 [Page 27]
Internet-Draft DPS framework July 2010
8.2. Informative References
[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.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
Authors' Addresses
Fredrik Ljunggren
Kirei AB
P.O. Box 53204
Goteborg SE-400 16
Sweden
Email: fredrik@kirei.se
Anne-Marie Eklund-Lowinder
.SE (The Internet Infrastructure Foundation)
P.O. Box 7399
Stockholm SE-103 91
Sweden
Email: amel@iis.se
Tomofumi Okubo
Internet Corporation For Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Ray, CA 90292
USA
Email: tomofumi.okubo@icann.org
Ljunggren, et al. Expires February 1, 2011 [Page 28]
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/