Zusammenfassung

  • RFC 2845 nahm den MAC der auslösenden Anfrage in den MAC einer signierten DNS-Antwort auf.
  • Bei einem DNS/TCP-Austausch mit mehreren Nachrichten umfasste ein laufender MAC den vorherigen MAC und die nachfolgenden Nachrichten in ihrer Reihenfolge. TSIG stand in der ersten und letzten Nachricht sowie mindestens alle hundert Nachrichten an einem Prüfpunkt.
  • RFC 8945 verlangte später TSIG in jeder gesendeten Antwortnachricht, ließ Prüfern aber eine begrenzte Kompatibilitätstoleranz. Keine der beiden Regeln macht Transaktionsauthentifizierung zu Vertraulichkeit, Datenwahrheit oder lokaler Autorisierung.

Eine Antwort war kein losgelöstes Paket

DNS-Nachrichtenkennungen und Antwortcodes beschrieben einen Austausch, authentifizierten aber weder den Kommunikationspartner noch schützten sie die Transaktion vor Veränderungen. RFC 2845 ergänzte im Mai 2000 TSIG: einen Metadatensatz in der DNS-Nachricht, der mit einem gemeinsamen Geheimnis geprüft wurde. Der Geltungsbereich war bewusst auf zwei Partner beschränkt. Beide mussten denselben Schlüssel eingerichtet haben; dessen Verteilung lag außerhalb der Spezifikation.

Die zentrale Designentscheidung steckte in den Eingabedaten des MAC. Zuerst authentifizierte der Client seine Anfrage. Für eine signierte Antwort bezog der Server den Anfrage-MAC, die Antwort und die TSIG-Variablen der Antwort in die Berechnung ein. Der Prüfer betrachtete die Antwort dadurch nicht als neues Objekt ohne Vorgeschichte: Die kryptografische Prüfung reichte bis zur Anfrage zurück. Signierte Zeit und zulässige Abweichung waren ebenfalls abgedeckt, sodass ein Vermittler die Zeitfelder nicht ändern und den MAC gültig lassen konnte.

Diese Bindung machte eine Aussage über abgedeckte Bytes und eine Schlüsselbeziehung. Weil beide Partner das Geheimnis teilten, zeigte eine erfolgreiche Prüfung, dass die Nachricht zum konfigurierten Schlüssel passte; sie identifizierte nicht die Person oder den Prozess, der den Schlüssel hielt. TSIG verschlüsselte DNS nicht und entschied nicht, ob ein Server ein Update zulassen sollte. RFC 2136 definierte DNS UPDATE; die lokale Richtlinie musste weiterhin festlegen, ob der authentifizierte Partner die Zone ändern durfte.

Ein Transfer wurde zu einem Nachrichtenprotokoll

Schwieriger war eine Antwort aus mehreren Nachrichten, etwa bei einem Zonentransfer über TCP. Würde man jedes Paket isoliert prüfen, ginge die geordnete Beziehung zwischen den Nachrichten verloren. RFC 2845 verlangte TSIG für die erste und die letzte Nachricht sowie mindestens alle hundert Nachrichten einen signierten Prüfpunkt. Dazwischen floss jede DNS-Nachricht der Reihe nach in die nächste MAC-Berechnung ein – zusammen mit dem vorherigen MAC und den maßgeblichen Zeitfeldern.

Geprüft wurde damit die Kontinuität eines begrenzten Abschnitts des Streams, nicht jede Zwischennachricht mit einer unabhängigen Signatur. Bei einem Fehler musste laut RFC die TCP-Verbindung geschlossen und der Transfer als unterbrochen behandelt werden; ein genaues Wiederholungsverfahren schrieb sie nicht vor. Ein gültiger Prüfpunkt belegt einen Teil des empfangenen Nachrichtenverlaufs, nicht was der Server später dauerhaft übernahm oder ein sekundärer Server anschließend auslieferte.

Die Regel änderte sich, die Grenze blieb

RFC 4635 ergänzte HMAC-SHA-Algorithmuskennungen über das ursprüngliche HMAC-MD5-Design hinaus. 2020 ersetzte RFC 8945 RFC 2845 und RFC 4635 als Internet Standard STD 93. Die Senderregel wurde strenger: Ein konformer Sender signiert jede Antwortnachricht. Die Kompatibilitätsregel für Prüfer ist eine andere: Sie müssen bis zu 99 unsignierte Zwischennachrichten akzeptieren und zugleich Signaturen in der ersten und letzten Nachricht verlangen. Diese Toleranz erlaubt es einem modernen Sender nicht, Signaturen wegzulassen.

RFC 8945 benennt auch die Beweisgrenze: TSIG authentifiziert die Übertragung zwischen zwei Partnern mit gemeinsamem Geheimnis, nicht Herkunft oder Richtigkeit der Quelldaten. Das ist etwas anderes als DNSSEC, das Daten mit einem anderen Vertrauensmodell authentifiziert. TKEY kann in manchen Umgebungen Schlüssel etablieren, doch die Schlüsselverteilung ist keine Funktion von TSIG. Die Standards beschreiben einen begrenzten Mechanismus, kein universelles Vertrauenssiegel.

Quellen: RFC 1035; RFC 2104; RFC 2845; RFC 8945; RFC 4635; RFC 2136; RFC 2930.