Introduction

Overview

The purpose of this document is to enable stakeholders to determine the level of trust they wish to grant to the RIPE NCC DNSSEC management. It details the procedures and policies employed by the RIPE NCC in operating those zones for which it offers DNSSEC service.

This document conforms to the IETF Internet draft for a DNSSEC Practice Statement, or DPS (see: draft-ietf-dnsop-dnssec-dps-framework-01).

Document name and identification

DNSSEC Policy and Practice Statement or short DPS.

Community and Applicability

The zones maintained by the RIPE NCC follow a thin registry model. In this model, there is no intermediary between the owner of a zone (Registrant) and the operator of the parent zone (Registry).

Registry

All zones covered by this document have the RIPE NCC as a single registry. It is the responsibility of the registry to sign those zones and make their public keys available to the general public. The registry also enables its registrants to submit the public keys of their child zones in the form of Delegation Signer (DS) Resource Records. These are then included in the parent zone.

Registrant

It is the responsibility of the registrant to ensure the proper signing of their child zones. The registrant is also responsible for keeping the public key material at the registry updated according to their needs.

Relying Party

Public key material published by the registry as a trust anchor can be used by anybody interested in using the zones as secure entry points for DNSSEC. The relying party needs to ensure that it is using the trust anchors according to the current Acceptable Use Policy (AUP) which is included at the top of each trust anchor file.

Specification Administration

This DPS will be periodically reviewed and updated, as appropriate.

Specification administration organisation

RIPE Network Coordination Centre (RIPE NCC)

Contact Information

Attn.: DNS Services
Stationsplein 11
1012 AB Amsterdam
The Netherlands

Email: [email protected]

Specification Change Procedures

Any change to this document needs to be signed off by the manager of DNS services, a Senior Manager and the Information Security Officer of the RIPE NCC.

Publication and Repositories

Repositories

Information on the DNSSEC keys used to sign the zones for which the RIPE NCC systems are authoritative is provided via a TLS secured website.

Publication of Key Signing Keys (KSK)

The RIPE NCC will publish its Key Signing Keys in two formats.

Trust Anchor Format

This format can be directly included into a BIND resolver as a trust-anchor. It is equal to the specification of the DNSKEY resource record except for the TTL and class parameters, which are intentionally left out.

Delegation Signer (DS) Format

In this format, the public key is presented in a hash representation according to the DS Resource Record specification. There is no TTL or class parameter provided in this format.

Access Controls on Repositories

All keys are available with PGP signatures generated with the current RIPE NCC key. It is highly recommended that you validate both the SSL certificate of the website and the PGP signature of trust-anchor files.

Operational Requirements

Registration, Modification and Removal of Delegation Signer (DS) Resource Records

A child zone can create a chain of trust by updating its domain object in the RIPE Database and providing DS records provided in the ds-rdata field. Similarly, during roll-over events, a child zone's DS records can be changed by updating its domain object in the RIPE Database. If a child zone becomes unsigned, its DS record may be removed from its domain object in the RIPE Database. The process is detailed in the Procedure for Requesting DNSSEC Delegations

Method to Prove Possession of Private Key

During our pre-delegation checks, we will ensure that the DS records provided are available as DNSKEY records at the apex of the child zone. We will also check if these DNSKEYs are signed and verified against at least one of the supplied DS records.

Facility, Management and Operational Controls

Physical Controls

Site location and construction

RIPE NCC operates multiple sites in the Netherlands. These include server-rooms in the RIPE NCC offices, cabinets in data centres, and a backup site outside of Amsterdam.

Physical access

All of our facilities have restricted access, limited to authorised personnel.

Power and Air Conditioning

All facilities have Uninterruptible Power Supply (UPS) capabilities and air conditioning. The external data centre sites have redundant systems in place in the event of a power failure (the RIPE NCC offices do not have this redundancy).

Water Exposure

To avoid the risk of water exposure, all of our facilities are on elevated floors two to five metres above ground level. Additionally, we have a back-up site outside of Amsterdam at around 30 metres above sea level.

Fire Prevention and Protection

All facilities have fire detectors and gas extinguishers.

Media Storage

Sensitive media is stored in a safe which is only accessible by RIPE NCC Senior Management and specifically designated personal.

Waste Disposal

Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information is rendered unreadable before disposal.

Off-site Back-up

Signer backups are stored on our storage systems spread across all of our data centers.

Procedural Controls

Trusted Roles

There are at least two DNSSEC Operator teams. Each team is composed of two persons designated by Senior Management of the RIPE NCC. Each team member holds a part of a password, which when combined grants that team access to the signer systems.

Tasks Requiring Separation of Duties

Any task performed on the signer systems requires a complete team, as described in Trusted Roles, to be present.

Personnel Controls

Qualifications, Experience and Clearance Requirements

Engineers taking part in the Trusted Roles have to have been working for the company for no less than one year and must have the qualifications necessary for the DNS engineer job role.

Training Requirements

Should a new team be formed, this team will have to observe at least one regular key roll-over with an existing team.

Job Rotation Frequency and Sequence

No single team can perform regular key roll-overs more than twice in a row.

Contracting Personnel Requirements

No person outside of the specified Trusted Roles can get access to the signer systems. If necessary, a team can perform certain tasks with the guidance of an external contractor. At no time is the contractor allowed to be the person performing the tasks on the system.

Documentation Supplied to Personnel

The regular procedures for backup and restore are available to all personnel involved. If major alterations to those procedures are made, the engineers of those teams will be informed accordingly.

Audit Logging Procedures

Types of Events Recorded

Physical access to the facilities used for our signing systems is logged automatically on enter and exit. The main operation site requires personnel to be specifically granted permission to enter the suite in which the equipment is located and they will have to sign-in using a valid identification (passport, drivers licence, etc.).

Log messages from the signer systems will be sent securely to a logging system and recorded for audit purposes.

Protection of Audit Log

Audit logs of our main operation site are kept by an external data center operator. These logs are not available to any of our employees and cannot be modified at the request of any of our employees. Access to the audit logs of our own facilities is only available to the operations department.

Compromise and Disaster Recovery

Any relevant events relating to the secure operation of our systems will be announced to the RIPE DNS Working Group and RIPE ENUM Working Group mailing lists, as well as other fora appropriate at the time.

Incident and Compromise Handling Procedures

If an event leads to, or could lead to, a detected security compromise, we will perform an investigation to determine the nature of the incident. If we suspect the incident has compromised the private component of an active key, an emergency key roll-over procedure will be performed.

Entity Private Key Compromise Procedures

Upon the suspected or known compromise of a key, we will assess the situation, develop an action plan and implement the action plan with approval from the Information Security Officer and Senior Management.

When we perform an emergency roll-over for a compromised KSK, we will continue to operate this key for at least the minimum time specified to retrieve our public key trust anchors in the AUP.

Technical Security Controls

Key Pair Generation and Installation

Key Pair Generation

Both KSK and Zone Signing Key (ZSK) are generated on the signer systems using a Trusted Platform Module (TPM) chip.

Public Key Delivery

The public key is retrieved from the signer system via secure copy (SCP) and then published as detailed in the section Publication and Repositories.

Key Usage Purposes

A key must only be used for one zone and cannot be reused.

Private Key Protection and Cryptographic Module Engineering Controls

Cryptographic Module Standards and Controls

Systems used for signing the zones are FIPS 140-2 Level 2-certified.

Private Key (m-of-n) Multi-person Control

No access to unencrypted keys is available in the entire system. Access to the signer system is specified in the Trusted Roles section.

Private Key Backup

The signer system pushes a back-up onto our storage system every time an operation changes the system status. This back-up is encrypted using the on-board TPM chip. Access to the back-up archives is limited to persons designated by Senior Management.

Private Key Archival

Private keys can be restored from the back-ups specified above. Private keys are not archived on the signer system once they have been revoked.

Private Key Transfer Into or From a Cryptographic Module

Private keys can only be transferred off the system in encrypted form and restored onto the back-up system by the teams described in the Trusted Roles section.

Other Aspects of Key Pair Management

Public Key Archival

We are only publishing the public keys currently relevant to the operation of our zones. No archive of public keys past their revocation is available.

Key Usage Periods

KSKs will be rolled over annually and ZSKs will be rolled over once a month.

Computer Security Controls

RIPE NCC ensures that the systems maintaining key software and data files are Trustworthy Systems secure from unauthorized access. In addition, RIPE NCC limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers.

Network Security Controls

Systems holding the signing infrastructure are inside a dedicated VLAN inside our network infrastructure. The only communications channel to those systems is through our firewall, which is limited to the minimal capabilities necessary for the operation of the system.

Timestamping

The signer systems securely sychronise their system clocks with a trusted time source inside our network.

Life Cycle Technical Controls

System Development Controls

We are using a third-party solution on our signer systems. We test new releases of this software in a lab environment provided by our supplier. Once these tests are concluded successfully, we do a staged roll-out of the new release onto our inactive signer system first, and then onto our active signer system.

Zone Signing

Key Lengths and Algorithms

Key Signing Key

We use a key length of 2048 bits with RSA as the generation algorithm.

Zone Signing Key

We use a key length of 1024 bits with RSA as the generation algorithm.

Authenticated Denial of Existence

Authenticated denial of existence will be provided through the use of NSEC records as specified in RFC 4034.

Signature Format

Our signatures are created with the SHA1 hash using RSA.

Zone Signing Key Roll-over

We will roll the ZSK with a pre-publishing scheme as described in RFC 4641, section 4.2.1.1.

Key Signing Key Roll-over

We will roll the KSK with a double-signing scheme as described in RFC 4641, section 4.2.1.2.

Signature Life-time and Re-signing Frequency

We re-sign our zones daily with a signature lifetime of 30 days.

Resource Records Time-to-live