XN--P1AI (РФ) DNSSEC Policy and Practice Statement

Transcription

1 XN--P1AI (РФ) DNSSEC Policy and Practice Statement XN--P1AI (РФ) DNSSEC Policy and Practice Statement... 1 INTRODUCTION... 2 Overview... 2 Document name and identification... 2 Community and Applicability... 2 Registry... 2 Registrar... 3 Registrant... 3 Relying party... 3 Applicability... 3 Specification Administration... 3 Specification administration organization... 3 Contact Information... 3 Specification change procedures... 3 PUBLICATION AND REPOSITORIES... 3 Repositories... 3 Publication of key signing keys... 4 Access controls on repositories... 4 OPERATIONAL REQUIREMENTS... 4 Activation of DNSSEC for child zone... 4 Identification and authentication of child zone manager... 4 Registration of delegation signer (DS) resource records... 4 Method to prove possession of private key... 4 Removal of DS record... 4 FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS... 4 Physical Controls... 4 Site location and construction... 4 Physical access... 4 Power and air conditioning... 5 Water exposures... 5 Fire prevention and protection... 5 Media storage... 5 Waste disposal... 5 Off-site backup... 5 Procedural Controls... 5 Personnel Controls... 5 Qualifications, experience, and clearance requirements... 5 Training requirements... 5 Retraining frequency and requirements... 6 Documentation Supplied to Personnel... 6 Audit Logging Procedures... 6 Compromise and Disaster Recovery... 6 TECHNICAL SECURITY CONTROLS... 6 Key Pair Generation and Installation... 6 Key pair generation... 6 Public key delivery... 6 Public key parameters generation and quality checking... 6 Key usage purposes... 6 Private key protection and Cryptographic Module Engineering Controls... 7 Private key (m-of-n) multi-person control... 7

2 Private key backup... 7 Private key archival... 7 Private key transfer into or from a cryptographic Module... 7 Method of activating private key... 7 Method of deactivating private key... 7 Method of destroying private key... 7 Other Aspects of Key Pair Management... 7 Public key archival... 7 Key usage periods... 7 Activation data... 8 Activation data generation and installation... 8 Activation data protection... 8 Other aspects of activation data... 8 Computer Security Controls... 8 Network Security Controls... 8 Timestamping... 8 Life Cycle Technical Controls... 8 System development controls... 8 Security management controls... 8 Life cycle security controls... 8 ZONE SIGNING... 9 Key lengths and algorithms... 9 Authenticated denial of existence... 9 Signature format... 9 Zone signing key roll-over... 9 Key signing key roll-over... 9 Signature life-time and re-signing frequency... 9 Verification of zone signing key set... 9 Verification of resource records... 9 Resource records time-to-live... 9 COMPLIANCE AUDIT... 9 LEGAL MATTERS... 9 INTRODUCTION Overview The present document describes procedures and measures undertaken to implement DNSSEC in the XN P1AI (РФ) TLD. Document name and identification DNSSEC Policy and Practice Statement, or DPS. Community and Applicability Registry The TLD Registry Operator bears responsibility for the Internet s top-level domain. The Registry Operator has powers to design domain names registration rules in the TLD, including the DNSSEC policy implementation procedures, as well as to manage and operate the KSK keys.

3 The Registry Operator will outsource Full Registry Solution to an external subcontractor, namely, JSC Technical Center Internet (hereinafter referred to as Registry Service Provider). The Registry Service Provider s duties will encompass maintenance of the registry database and SRS. Registry Service Provider is responsible for validation and processing of DNSSEC data received from an accredited registrar, formation and signing of the TLD zone file, management and operation of the ZSK keys, and distribution of the signed zone across the appropriate DNS servers. Registrar A Registrar is the party responsible for administration and management of domain names on of behalf of the Registrant. Accredited registrars are responsible for checking the attribution of a KSK key to a domain name administrator. Registrant A Registrant is a physical or legal entity that controls a domain name. Guided by their needs, registrants of domain names in the TLD introduce necessary changes via accredited registrars. TLD Registry Operator is not responsible for the accuracy of registrant s domain zone signing, as well as for the actuality of public keys placed in the Registry system in the form of DS records. Relying party The relying party is the entity relying on DNSSEC such as validating resolvers and other applications. The relying party is responsible for configuring and updating the appropriate trust anchors. Applicability This DPS is applied to the XN P1AI (РФ) TLD zone. It describes procedures and measures undertaken to implement DNSSEC in the XN P1AI (РФ) TLD. Registrant Zones are subject to Registrant's policy and do not fall under the scope of the present document. Specification Administration This document will be periodically revised and updated, where necessary. Specification administration organization The Technical Center of Internet, JSC Contact Information Russia, Moscow, Zoologicheskaya str., 8 Specification change procedures Any change to this document needs to be signed off by a senior IT-security engineer. PUBLICATION AND REPOSITORIES Repositories The Registry Service Provider publishes DNSSEC-relevant information on the official website at The electronic version of this DPS at this specific address is the official version thereof.

4 Publication of key signing keys The Registry Service Provider composes a chain of trust of DNSSEC by publishing public KSKs in the form of DS record directly in the root zone. Access controls on repositories Information published at the specific website is available to general public and is protected from unauthorized additions, deletion or modification of thecontent on the website. It is highly recommended that you validate the SSL certificate of the Registry Service Provider website. OPERATIONAL REQUIREMENTS Activation of DNSSEC for child zone DNSSEC is activated by at least one DS record and the corresponding DNSKEY record for the child zone sent from the Registrar to the Registry Service Provider. The Registry Service Provider presumes that the DS record is correct by performing the following tests: digest algorithm checkup, digest checkup and key tag checkup. Once the checkups have been passed and the zone has been delegated, the DS record is published in the DNS, which established a chain of trust to the child zone. Identification and authentication of child zone manager It is the responsibility of the Registrar to securely identify and authenticate the Registrant through a suitable mechanism. Registration of delegation signer (DS) resource records The Registry Service Provider accepts DNSKEY records and corresponding DS records through the EPP interface from each Registrar. The DS and DNSKEY records must be valid and sent in the format indicated in RFC The TLD Registry Database supports placement of DS records generated in accordance with RFC 4034 and RFC Method to prove possession of private key The Registry Service Provider does not conduct any controls with the aim of validating the Registrant as the private key manager. The Registrar is responsible for conducting suitable controls. Removal of DS record A DS record is removed by sending a request from the Registrar to the Registry Service Provider through the EPP interface. The removal of all DS records will deactivate the DNSSEC mechanism for the Registrant s zone. Only the Registrant, or the party formally designated by the Registrant, has the authority to request removal of the DS records. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS Physical Controls Site location and construction The Registry Service Provider operates several sites in the Russia. These include secure cabinets in data centres, safe room in the Registry Service Provider office and a backup site. Physical access All of our facilities have restricted access, limited to authorized personnel.

5 Power and air conditioning All facilities have UPS capabilities and air conditioning. The external data centre sites have redundant systems in place in the event of a power failure. Water exposures The Registry Service Provider has taken reasonable precautions to minimize the impact of water exposure to the signer systems. Fire prevention and protection All of our facilities have fire detectors and gas extinguishers. Media storage Sensitive media are stored in a safe which is only accessible by authorized personnel. Waste disposal Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal. Off-site backup The Registry Service Provider performs routine backups of critical system data. Off-site backup media are stored in a physically secure manner at remote location. Procedural Controls To operate the private KSKs there have been established two staff roles, namely, Crypto Officer and Crypto Operator, each providing for at least two authorized individuals to act in this capacity. Each person has his/her own authentication token and a password to access it. Operating the private KSKs requires at least two Crypto Officer s and one Crypto Operator s authentication tokens. Under no circumstances may the staffer deployed to operate the private KSKs combine the roles of Crypto Officer and Crypto Operator. To operate the private ZSK there has been established a staff role, namely, the Domain Zone Administrator, which provides for at least two individuals with the respective authority. To control and manage ZSKs in a semi-automatic mode at least one authorized individual is required. Another role is the External Observer, which provides for at least two individuals with the respective authority. External Observer controls the exercise of operational procedures with regard to the private KSK. Personnel Controls Qualifications, experience, and clearance requirements The personnel for the aforementioned trusted staff roles are employees of the Registry Service Provider or any other officers specifically approved by the Registry Operator. They must have expertise in the DNSSEC technology application area. Training requirements New staff engaged in the exercise of the above roles must study the internal policy documentation describing the DNSSEC functioning. They should also participate in DNSSEC procedures as External Observers.

6 Retraining frequency and requirements The Registry Service Provider periodically examines the necessity of staff retraining. Retraining is provided as necessary. Documentation Supplied to Personnel The regular procedures documentation is available to all the personnel involved. Audit Logging Procedures Each fact of accessing the specially assigned area for operating the DNSSEC cryptographic information is recorded in the automated system. In those zones where automation is impossible, facts of access thereto are documented in special journals. Journals and saved logs in the automated access system are regularly reviewed and analyzed. The periodicity of evaluation is determined by the security audit procedure. While evaluating the journals in question, a strict division of roles between person (s) who conduct the evaluation and those whose actions are subject to monitoring is ensured. Compromise and Disaster Recovery Somewhere an event has resulted or may result in a security breach, an internal inquiry is conducted to detect causes behind the incident and to remedy them. If such an event compromises the DNSSEC cryptographic information, an emergency key rollover shall be launched, with the Crypto Operator initiating the emergency key rollover procedure. When an emergency roll-over is performed for a compromised key, the Registry Service Provider s will continue to operate this key for at least a minimum time to complete emergency roll-over. TECHNICAL SECURITY CONTROLS Key Pair Generation and Installation Key pair generation New KSKs are generated and stored on a specialized device, Hardware Secure Module (HSM), which has no connection to the network infrastructure. All cryptographic operations requiring private KSK are performed with this device or with an equivalent one, which is used as back-up one. For the sake of backup, the private KSK may leave the device only in the encrypted form. New ZSKs are generated and stored on a DNSSEC signer server, which is connected to the TLD Registry Database s internal network infrastructure. All cryptographic operations requiring the private ZSK are performed with this device or with an equivalent one, which is used as backup one. The private ZSK can leave this device only in an encrypted form for the sake of backup. Public key delivery Public KSK is distributed to relying parties by means of DNS protocol. Public key parameters generation and quality checking Key parameters and quality control are regulated by the Registry Service Provider. Key usage purposes The Registry Service Provider uses signing keys only for generating signatures for the TLD zone.

7 Private key protection and Cryptographic Module Engineering Controls Private key (m-of-n) multi-person control Operations involving private KSK are performed by Crypto Officers and Crypto Operator as described in Procedural Controls section. The Crypto Officer s authentification tokens contain parts of a password required for activation of the private keys storage media at HSM. To restore the password m-of-n parts are required. Private key backup Backups of private keys are performed. The keys leave the devices only in the encrypted form. The Private KSK is kept in the encrypted form in an off-site safe which can only be accessed by Crypto Operator and decrypted by Crypto Officers. Backup copy of the private ZSK is stored at the hot-standby DNSSEC signer server which is located a remote site and is included into each registry database backup Private key archival Private keys that are no longer used are kept only as backup copies. Private key transfer into or from a cryptographic Module Private keys can only be transferred from the DNSSEC signer systems in the encrypted form and restored onto the backup system by authorized personnel, as described in Procedural Controls section. Method of activating private key Private KSKs are activated by unlocking the HSM and decrypting the private KSK storage. The Crypto Operator provides the Crypto Officers with access to console of the HSM. The Crypto Officers use authentification tokens to decrypt private KSK storage media at HSM. Private ZSKs are activated by the DNSSEC management interface under the Domain Zone Administrator s control. Method of deactivating private key Once the private KSK has been used it is deactivated immediately. The Private ZSK is stored within the online part of the signing system. It is in active state as long as it is marked as Active. Zone administrator is able to change ZSK s status by means of the DNSSEC management interface. Method of destroying private key Private keys are not subject to destruction. They are removed from the systems in a manner, so that they could not be used again. Other Aspects of Key Pair Management Public key archival Public keys are archived and backed up as a part of a routine backup procedure. Key usage periods KSKs will be rolled over once in thirteen months and ZSKs will be rolled over once in three months. The Registry Operator may change these periods as necessary. Obsolete keys are not reused.

8 Activation data Activation data generation and installation Activation data is a set of passwords for authentification tokens used to activate KSK by Crypto Operators and Crypto Officers (PIN-codes). Activation data protection Crypto Operators and Crypto Officers protect activation data in a sufficiently secure manner. Other aspects of activation data As a part of the emergency operation pattern, the Crypto Officers and the Crypto Operators may hold a copy of the password in individual sealed boxes in a secure location at Registry Service Provider s site. Computer Security Controls All critical components of the Registry Service Provider s systems are placed in secure facilities. Access to the systems is granted to authorized personnel responsible for a certain staff role. All cases of access to critical components are logged. Network Security Controls Systems holding the online part of DNSSEC signing infrastructure are connected to the internal network infrastructure which is logically separated from the Registry Service Provider s production infrastructure. The only communications channel to those systems is through the Registry Service Provider s firewall, which is limited to minimal capabilities necessary to operate the systems. The system holding private KSK has no network connection. Transfer of a Key Signing Request (KSR) to an offline signer system is performed manually using removable media. Timestamping The online DNSSEC signer systems securely synchronize their system clocks with a trusted time source inside our network. For the offline part of DNSSEC signing infrastructure time will be set manually before each KSK-related procedure. Life Cycle Technical Controls System development controls Applications that are developed by the Registry Service Provider can be traced to version control repositories. A third-party s components used on the Registry Service Provider s DNSSEC signer systems are tested and verified for compatibility with the Registry Service Provider s applications in lab environment before being deployed to production systems. Security management controls The Registry Service Provider conducts regular security audits of the systems. Life cycle security controls The signer systems are designed to require minimum maintenance. Updates critical to the security and operations of the signers system will be applied after testing and approval in lab environment.

9 ZONE SIGNING Key lengths and algorithms The algorithm and the key length for signing key that are considered secure by the Registry Service Provider for the usage period are adopted. Current algorithm for both KSK and ZSK is RSA-SHA256 with a key length of 2048 bits used for KSK and 1024bits for ZSK. Authenticated denial of existence For authentication of denial of existence the NSEC3 OPT-OUT mechanism is used [RFC 5155]. Signature format Signatures are generated using RSA with the SHA256 hash [RFC 5702]. Zone signing key roll-over Pre-publication scheme will be applied for ZSK [RFC 4641]. Key signing key roll-over Double-signature scheme will be applied for KSK [RFC 4641]. Signature life-time and re-signing frequency DNSKEY RR set signature life-time is 20 days. Other RR sets signatures life-time is 45 days. The re-signing frequency rate is once in every two hours. Signatures life-time and re-signing frequency can be changed by the Registry Service Provider as necessary. Verification of zone signing key set KSR, which consists of public ZSKs and KSKs, is signed by the Registry Service Provider PGP key. The offline signer system will automatically validate this signature with pre-imported PGP key before accepting the KSR for signing. Verification of resource records The Registry Service Provider verifies that all the resource records are conformant with the protocol standards. Resource records time-to-live TTL of DNSKEY, DS and their corresponding RRSIG is set to (4 days). TTL of NSEC3 and the corresponding RRSIG is set to 3600 (1 hour), which is the same as negative cache value for the zone. Those TTLs can be changed by the Registry Service Provider as necessary. COMPLIANCE AUDIT A regular audit takes place. It is regulated by the internal security audit policy. The audit reports are provided to the Registry Service Provider. Operational improvements are applied as necessary. LEGAL MATTERS The Registry Service Provider has no legal responsibilities for the matters described in this DPS. When operating TLD DNSSEC Service, the Registry Service Provider follows the law of Russian Federation and the rules defined by the Registry Operator.