DNSKEYs und Key rollover - "best practices"
Da eine DNSSEC-signierte Zone auf gültige Schlüssel angewiesen ist, sind die so genannten "key rollovers", bei denen ein Zone-signing Key (ZSK) oder Key-signing key (KSK) durch einen neuen ersetzt wird, eine der heikelsten Punkte der Verwaltung DNSSEC-signierten Zonen/Domänen.
Diese Seite gibt praktische Tips ("best practices") wie diese key rollovers am besten vollzogen werden können.
Es gibt keinen absolut zwingenden Grund, key rollovers durchzuführen. Schlüssel könnten ohne "inactivate"-Datum generiert und dann "für immer" benutzt werden. Das sollte man aber nicht tun. Authentische Signaturen sind nur so lange authentisch, wie man darauf vertrauen kann, dass der zum Signieren benutzte private Schlüssel nicht geknackt oder kompromittiert wurde.
Das "kann" jeder Zeit passieren! Je länger die verwendeten Schlüssel sind, desto aufwändiger ist es, sie zu knacken. Je besser Sie Ihre privaten Schlüssel verwahren, des schwieriger ist es, sie zu kompromittieren.
Empfehlungen zur Schlüsselhandhabung
Es wird empfohlen, die privaten DNSKEYs an einem sicheren Ort zu verwahren. Am besten ist es, sie in einem Hardware Security Module (HSM) oder in einem Software HSM, das dies PKIX-konform in Software umsetzt, zu verwahren. Es sollte auch nur eine definierte Gruppe an Administratoren Zugriff auf die Schlüssel haben.
Zumindest sollten die Schlüssel nicht auf dem von aussen erreichbaren Nameserver liegen, sondern ein Signing-Proxy benutzt werden, der auch die Schlüssel verwaltet. Auch dann sollte der Key-signing key nur bei Bedarf hervor geholt werden, und ansonsten offline, z.B. auf einem USB-Stick, sicher verwahrt werden.
Schlüssellängen
Da ein rollover des Key-signing keys (KSK) eine "out-of-band"-Kommunikation mit dem Registrar erfordert, wird dieser im allgemeinen weniger oft gewechselt. Daher sollte er im allgemeinen dann auch höheren Sicherheitsanforderungen genügen, sprich länger als die Zone-signing keys sein.
Das NIST empfiehlt 1024 Bit für ZSKs und 2048 KSKs. Am LRZ verwenden wir sowohl für KSK, als auch ZSK 2048 Bit.
Key rollover Perioden
regelmäßige keyrollovers
Das NIST empfiehlt, ZSKs alle eine drei Monate zu "rollen" und KSKs alle sechs Monate. Da jeder Key rollover, insbesondere der des KSK mit Aufwand verbunden ist, und potentiell zu Problemen führen kann, dass eine Zone oder Domäne nicht erreichbar ist, sind so hohe Anforderungen nur für Domänen angebracht, die sich einem hohen Angriffspotential ausgesetzt sehen.
Am LRZ wird der ZSK ungefähr alle halbe Jahre gewechselt und der KSK alle zwei Jahre. Das ist aber kein zwingender Rhythmus.
Notfall-rollovers
Wichtiger, als sich an regelmäßige key rollovers zu halten, ist, dass die Netzwerkverantwortlichen, mit den key rollover Prozeduren so weit vertraut sind, dass im Notfall ein rollover reibunglos durchgeführt werden kann.
Da ein Schlüssel jederzeit kompromittiert werden kann, und dann die Signaturen in der Zone durch einen neuen ZSK oder KSK ersetzt werden müssen, muß ein rollover auch im Notfall reibunglos vollzogen werden können.
D.h. der Systemadminstrator sollte sich NICHT erst dann damit auseinandersetzen und einlesen müssen...
Das ist auch das überzeugendste Argument für regelmäßig rollovers. Wenn man mit der Prozedur vertraut ist, sie mehrmals - ohne Zeitdruck - durchgeführt hat, hat man die beste Übung für den Notfall!
Standby-Keys
Wenn man einen Schlüssel schon vorher auf Vorrat erzeugt und in der Zone veröffentlicht, aber noch nicht zum Signieren verwendet, hat man einen Standby-Key, auf den man schnell umschalten kann. Dabei ist man aber immer gezwungen, mindestens eine TTL der Client-Nameserver zu warten, in der noch die Einträge mit der Signatur des alten Schlüssels gecacht werden.
Rollover-Strategien
Es gibt verschiedene Strategien, um key rollovers durchzuführen. Entscheidend ist immer, dass sichergestellt werden muss, dass keine ungültigen Signaturen veröffentlicht werden..
Dabei muss auch immer die TTL ("time-to-live") der Schlüssel und Signaturen in den Caching-Resolvern in Betracht gezogen werden. Änderungen propagieren sich teilweise nur mit Stunden- oder Tagelangen Verzögerungen, und insbesondere Fehlkonfigurationen können damit nicht ad-hoc zurückgezogen werden!
Zwei Strategien haben sich im wesentlichen durchgesetzt, die auch von BIND transparent unterstützt werden:
"Pre-publish"-Methode und die "Double Signature"-Methode
Bei der "Double Signature"-Methode wird ein neuer Schlüssel gleich zum Signieren benutzt. Dabei werden die Resource Record Sets sowohl mit dem alten, als auch dem neuen DNSKEY signiert, d.h. jedes RRSet hat dann zwei RRSIGs. Damit verdoppelt man aufgrund der Länge der Signaturen die Größe der Zonen-Datei.
Wenn der neue Schlüssel auf die Client-Nameserver propagiert ist (mindestens eine TTL), muss nur noch mit dem neuen Schlüssel signiert werden, die RRSets haben nur noch einfache Signaturen und die Zonen-Datei ist wieder auf normale Größe geschrumpft. Der alte Schlüssel kann dann auch zurück gezogen werden.
Bei der "Pre-publish"-Methode wird ein neuer Schlüssel erzeugt, der vorerst nicht zum Signieren verwendet wird. Der Schlüssel wird aber schon vorab in der Zone veröffentlicht, und wird damit auf die anderen Client-Nameserver propagiert.
Erst dann, dabei muss auch wieder mindestens eine TTL der Nameserver abgelaufen sein, wird der neue Schlüssel zum Signieren verwendet. Der alte Schlüsssel wird nicht mehr zum Signieren verwendet, d.h. es treten keine doppelten Signaturen auf, die die Zonengröße anwachsen lassen würden. Der alte Schlüssel wird aber weiterhin veröffentlicht, da caching resolvers noch RRSets mit den alten Signaturen enthalten können.
Erst nach Ablaufen einer weiteren TTL, muss der alte DNSKEY nicht mehr veröffentlich werden, und die Zone enthält nun nurch noch den neuen DNSKEY und dessen RRSIG Signaturen.
Kombinierte Rollover-Strategie für ZSK und KSK
Aufgrund des Anwachsens der Zonendateigröße im Falle doppelter Signaturen, wird empfohlen, für den ZSK die "pre-publish"-Methode zu verwenden. Da der KSK nur für die DNSKEY Resource records zum Signieren verwendet wird, kann der KSK mit der "double signature"-Methode gerollt werden.
Da dann zeitweise zwei gültige KSK zum Signieren verwendet werden, müssen auch diese beiden in Parentzone veröffentlicht werden!
Zeitdaten der Schlüssel
DNSSEC-Schlüssel haben fünf wichtige Zeitdaten in Ihrer Meta-Information, die von BIND ausgelesen wird, um die Schlüssel entsprechend für das Signieren von Zonen zu verwenden. Das hat auch entsprechende Folgen für deren Bekanntheit in caching Resolvern:
| Datum | Parameter | Bedeutung | Zone | Resolver? |
|---|---|---|---|---|
| Creation | implizit | Zeitpunkt an dem die Schlüssel-Dateien erzeugt wurden | Nein | irrelevant |
| Publishing | -P | Datum, an dem der Schlüssel in der Zone veröffentlicht wird | Ja | bekannt |
| Activation | -A | BIND verwendet den Schlüssel ab diesem Zeitpunkt zum Signieren (evtl. parallel mit einem anderen gültigen Schlüssel) | wird zum Signieren verwendet | Signaturen werden geprüft |
| Inactivation | -I | BIND verwendet den Schlüssel von an nicht mehr zum Signieren | Ja | Signaturen noch vorhanden |
| Deletion | -D | Schlüssel wird aus der Zone gelöscht (d.h. entfernt), die Dateien .key und .private werden nicht gelöscht | Nein | irrelevant |
Schlüsselerzeugung
dnssec-keygen erzeugt Schlüssel per default ohne ein Inactivation oder Deletion Datum, d.h. die Schlüssel sind für alle Zeit gültig.
Mit dnssec-keygen würde man Schlüssel mit entsprechenden Daten erzeugen, um mit einmonatigen pre-publishing und post-publishing Zeiten, caching Resolvern genügend Zeit für die Updates ihrer Zonen zu geben. Es ist zu empfehlen, einen Vorrat an ZSK-Schlüsseln für einige Jahre zu haben und den letzten Schlüssel ohne ein Inactivation und Deletion Datum das kreieren. Das ist aber mühselig und fehleranfällig!
Wir empfehlen daher die Handhabung von Schlüssel nicht manuell durchzuführen, sondern den dnssec-keymgr zu verwenden. Siehe unser Wiki-Howto!
dnssec-keymgr
Der dnssec-keymgr, der mit BIND 9.11 eingeführt wurde, und auch wie hier im Wiki beschrieben für BIND 9.9 verwendet werden kann, erlaubt gemanagte Schlüsselverwaltung nach beiden Methoden.
Dazu muss man die entsprechenden Zeiten für "pre-publish" und "post-publish" gemäß der TTLs auf den Client-Nameservern setzen, um den ZSK mit der "pre-publish"-Methode gemanagt zu rollen.
Wegen der "out-of-band"-Kommunikation zur Veröffentlichung des Key-signing keys in der Parentzone, sollte der KSK aber nicht durch den dnssec-keymgr verwaltet werden. Dafür wird einfach kein rollover angegeben, dann wird ein KSK erzeugt, der nicht abläuft und bei Bedarf sollte der Netzwerkverantwortliche einen entsprechenden zweiten, gültigen per Hand KSK erzeugen.
Der dnssec-keymgr prüft die Gültigkeitszeiten der im key directory vorhandenen Schlüssel, und wird bei Vorhandensein eines zweiten gültigen und veröffentlichten KSK entsprechend Signaturen mit beiden KSK erzeugen.
RFCs
RFC6781 "DNSSEC Operational Practices, Version 2", gibt auch Richtlinien und Strategien zu key rollovers, und deren Relationen zum allgemeinen DNSSEC-Betrieb wird in RFC4641 "DNSSEC Operational Practices" dargelegt.