DNSSEC Longterm Key Rotation

Overview

BIND9/Design/DNSSEC describes very basic functionality where DNS zone is signed with provided signing keys. Those keys need to be generated and periodically rotated.

This document describes long-term solution for automatic key generation/rotation feature. See also DNSSEC Short-term Key Rotation.

Design

Black boxes in the diagram already exist, we need to write or modify blue boxes and interconnections.

• Run modified OpenDNSSEC Enforcer daemon or something else on a node as a key generator.
  • Use key rotation policy (aka KASP) stored in LDAP DB.
• New PKCS#11 module (provided by IPA) as the PKCS#11 provider with LDAP backend for key storage
  • (optionally) Private keys can be stored in IPA Vault instead of plain LDAP. This is implementation detail of PKCS#11 module and should not be visible to PKCS#11 users. However this could require special handling during upgrade.
• OpenDNSSEC and BIND will use keys directly over PKCS#11
• Metadata required by BIND and OpenDNSSEC (timestamps, key flags etc.) will be stored in LDAP DB
• Key rotation will be done in a distributed way: See Simo’s proposal for distributed key rotation
• LDAP schema should be forward-compatible so migration from DNSSEC Short-term Key Rotation to long-term solution will not require changes in LDAP schema and data migration.
  • LDAP schema for key metadata will be designed on page BIND9/Design/DNSSEC
  • LDAP schema for PKCS#11 will be designed separately in the scope of IPA PKCS#11 module
• Trust Anchors need to be updated on client side. See RFC 5011: Automated Updates of DNSSEC Trust Anchors: This mechanism solves public key rotation on client side for case with at least one non-compromised key. Case where all keys were compromised needs discussion.
  • Note that this mechanism is implemented in Unbound and BIND 9 (managed-keys option).

Feature Management

It is expected that FreeIPA team will deliver WebUI/CLI/API for key and policy management:

• Read RFC 6781 section 2 before you start thinking about user interface**. Any mistake in key management can prune whole DNS sub-tree so we need to be careful and show enough warning signs.
• Per-zone per-key user-initiated key rotation / revocation / deletion / generation (if DNSSEC is being enabled for particular zone).
• Ability to modify KASP.
• Automated notification that new KSK has to be uploaded to parent domain.
• BIG emergency button like throw away all existing keys and start from scratch. This will be required when keys were compromised or if something went wrong and admin is not able to debug it :-)

Implementation

Any additional requirements or changes discovered during the implementation phase.

Replication

No significant impact is expected. Key data will be replicated from among all nodes. Some replication conflicts could theoretically happen when keys are generated at multiple times at once.

Those conflicts should be solved with Simo’s algorithm for distributed key rotation.

Updates and Upgrades

Upgrade has to install and configure all new depedencies.

Initial state before upgrade

• N IPA replicas with DNSSEC Short-term Key Rotation
  • I.e. N instances of key distribution scripts from short-term solution
• 1 OpenDNSSEC service instance (key generator running on single IPA node)

Requirements

Now we want to upgrade a first IPA replica to this long-term solution. For simplicity, let’s add a requirement to upgrade the replica with OpenDNSSEC instance first. (We can generalize the procedure if this requirement is not acceptable.)

Upgrade procedure

• stop key distribution script
• stop OpenDNSSEC service
• configure PKCS#11 responder and providers in SSSD
• reconfigure BIND to use PKCS#11 instead of keys in files
  • LDAP schema for keys should be forward compatible so data conversion will not be needed. Only the interface for key manipulation will change.
• convert OpenDNSSEC version 1 database to OpenDNSSEC version 2 with LDAP backend We need to convert local SQLite database from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC.
• (optional step) To be done only if Vault will be used as key storage instead of plain LDAP: Convert private keys from LDAP to Vault.
  • See discussion on freeipa-devel. There are multiple variants how to do LDAP->Vault upgrade. All of them are internal implementation detail of PKCS#11 module and should not be visible to either BIND or OpenDNSSEC.

Dependencies

New depedencies:

• New PKCS#11 module
• Modified version of OpenDNSSEC Enforcer daemon: discussion on opendnssec-user list
• BIND 9 with functional PKCS#11 interface (it should be BIND 9.10)
• (optionally) IPA Vault

External Impact and Dependencies

• Cooperation with OpenDNSSEC developers is required.
  • May be that we can use something else if OpenDNSSEC is not willing to cooperate.
• SSSD team or somebody else has to write the PKCS#11 module.
• FreeIPA team has to provide user interface for key and policy management.
• BIND needs to be rebased to 9.10 otherwise we need to backport support for PKCS#11 from BIND 9.10 to BIND 9.9.

Backup and Restore

• Signing keys can be re-generated after restore. This will require cooperation with operator of parent DNS zone because hashes of new keys have to be uploaded to the parent zone. For security reasons, I still prefer not to backup DNS signing keys.
• KASP and other metadata in LDAP can be backed up along with other DNS data.

Test Plan

General idea: Muck with system clock on all nodes at once and check if:

• New keys are generated as necessary.
• Admin is notified if KSK keys are about to expire and hash of a new key has to be uploaded to parent domain.
• KASP is enforced properly after a change.

RFE Author

Petr Spacek <pspacek@…>