TSIG

Das TSIG Netzwerk - Protokoll ( t ransaction sig Art oder eine Transaktion Signatur) ist beschrieben in RFC  2845. Es wird in erster Linie durch das verwendete Domain - Name - System (DNS) , die eine Form von Authentifizierung für die dynamische Aktualisierung von Daten zu liefern. DNS - Datenbanken, obwohl es sein kann , Wird zwischen Servern für Abfragen verwendet. TSIG verwendet ein gemeinsames Geheimnis und eine Einweg- Hash- Funktion, um eine Form der Sicherheit durch Kryptografie bereitzustellen, um jedes Ende einer Verbindung als berechtigt zu identifizieren, eine DNS-Aktualisierungsanforderung zu stellen oder darauf zu antworten.

Obwohl DNS-Abfragen anonym sein können (außer DNSSEC ), müssen DNS-Updates authentifiziert werden, da sie die Namensstruktur des Netzwerks (Internet oder privates Netzwerk) ändern. Die Verwendung eines gemeinsamen Geheimnisses zwischen dem Client (Slave), der das Update durchführt, und dem DNS-Server, der es bereitstellt (Master), stellt die Authentifizierung des Clients sicher. Die Aktualisierungsanforderung kann jedoch über ein unsicheres Netzwerk (Internet) erfolgen. Eine Einweg-Hash-Funktion wird verwendet, um zu verhindern, dass Dritte den Schlüssel kennen, indem sie auf den Netzwerkverkehr warten und ihn dann verwenden, um ihre eigenen Änderungen am Client-DNS-Server vorzunehmen.

Die Verwendung eines Zeitelements ( Zeitstempels ) im Protokoll ermöglicht es, einen Wiederholungsangriff zu vermeiden. Daher erfordert die Verwendung von TSIG die Synchronisation der Server auf derselben Zeitquelle. Die Verwendung des NTP- Protokolls bietet beispielsweise diesen Dienst.

Implementierung

Ein DNS-Update ( RFC  2136) ist eine Reihe von Anweisungen für einen DNS-Server. Es enthält einen Header, den zu aktualisierenden Bereich, die Voraussetzungen, die erfüllt sein müssen, und die Datensätze (RR), die aktualisiert werden müssen. TSIG fügt einen letzten Datensatz hinzu, der das Zeitelement ( Zeitstempel ), einen Hash der Anforderung und den Namen des geheimen Schlüssels enthält, der zum Signieren der Anforderung verwendet wird. Der RFC  2535 schlägt einen Namen vor, dessen Format empfohlen wird.

Die Antwort nach einem erfolgreichen von TSIG signierten Update wird ebenfalls mit einem TSIG-Datensatz signiert. Fehler werden nicht signiert, um zu verhindern, dass ein Angreifer mithilfe von Aktualisierungsanforderungen, die speziell für diesen Zweck gestellt wurden, etwas über den Schlüssel erfährt.

Mit dem Programm nsupdate können Sie TSIG verwenden, um Aktualisierungen durchzuführen. Mit dem Dig- Programm können Sie TSIG verwenden, um authentifizierte Zonenanforderungen oder -übertragungen durchzuführen .

Der TSIG-Datensatz hat dasselbe Format wie die anderen Datensätze in einer Aktualisierungsanforderung. Die Bedeutung der Felder ist in RFC  1035 beschrieben.

TSIG-Datensatzfelder

Felder	Bytes	Beschreibung
NAME	max 256	Name des TSIG-Schlüssels, der zwischen Client und Server eindeutig sein muss
ART	2	TSIG (250)
KLASSE	2	JEDER (255)
TTL	4	0 (TSIG-Datensatz darf nicht gepuffert werden ( Cache ))
RDLENGTH	2	RDATA-Feldlänge
RDATA	Variable	Struktur bestehend aus dem Zeitelement ( Zeitstempel ), dem Algorithmus und dem Hash.

Alternativen zu TSIG

Obwohl TSIG weit verbreitet ist, wirft dieses Protokoll viele Probleme auf:

• Es erfordert die Bereitstellung eines gemeinsamen Geheimnisses für jeden Server, der Updates benötigt.
• Der HMAC-MD5-Hash ist nur 128 Bit,
• Es gibt keine Hierarchie von Berechtigungen: Jeder Client, der einen geheimen Schlüssel besitzt, kann jeden Datensatz in der Zone aktualisieren.

Somit haben sich verschiedene Alternativen oder Erweiterungen ergeben.

• Der RFC  2137 gibt eine Aktualisierungsmethode unter Verwendung eines öffentlichen Schlüssels im DNS-Eintragsspezifischen "GIS" an. Ein Client mit dem entsprechenden privaten Schlüssel kann Aktualisierungsanforderungen signieren. Diese Methode ist mit der sicheren Anforderungsmethode von DNSSEC kompatibel. Diese Methode wird jedoch von RFC  3007 nicht mehr unterstützt.
• Der RFC  3645 schlägt eine Erweiterung von TSIG vor, um die Verwendung der geheimen Schlüsselaustauschmethode GSS zu ermöglichen, sodass die Schlüssel nicht mehr manuell auf allen TSIG-Clients bereitgestellt werden müssen. Die Methode zum Verteilen öffentlicher Schlüssel mit GSS in einem DNS-Ressourceneintrag (RR) ist in RFC  2930 angegeben. Eine modifizierte GSS-TSIG-Methode namens " Generic Security Service Algorithm für Shared Secret Exchanges " für die Transaktion geheimer Schlüssel ) basiert auf Windows Kerberos Der Server mit dem Namen " Secured Dynamic Update" wurde in Microsoft Windows Active Directory- Servern und -Clients implementiert . In Kombination mit einem DNS, das ohne umgekehrte Auflösung mithilfe der RFC  1918- Adressierung konfiguriert wurde , leiten DNS-Server, die dieses Authentifizierungssystem verwenden, eine große Anzahl von Abfragen an Root-DNS- Server um . Es gibt eine Anycast- Gruppe, die für die Verarbeitung dieses Datenverkehrs außerhalb der Root-DNS-Server verantwortlich ist.
• Die  TSFC-Basis RFC 2845 erlaubt nur eine einzige Hash-Funktion: HMAC-MD5 wird nicht mehr als sehr robust angesehen. Im Jahr 2006 wurden Vorschläge zur Genehmigung der Verwendung von SHA1 RFC  3174 als Ersatz für MD5 gemacht. Der von SHA1 generierte 160-Bit-Digest sollte robuster sein als der von MD5 generierte 128-Bit-Digest.
• Der RFC  2930 definiert TKEY als eine Liste von DNS-Einträgen, die zum automatischen Verteilen von Schlüsseln vom Server an die Clients verwendet werden.
• Der RFC  3645 definiert GSS-TSIG mithilfe von GSS-API und TKEY, um Schlüssel automatisch zu verteilen.
• Der DNSCurve- Vorschlag weist viele Ähnlichkeiten mit TSIG auf.

Siehe auch

• primäre DNS (RR) -Einträge .

Anmerkungen und Referenzen

1. (en) "  Secret Key Transaction Authentifizierung für DNS (TSIG)  ", Antrag auf Kommentare n o  2845,Mai 2000.
2. (in) "  Dynamische Updates im Domain Name System (DNS UPDATE)  " Antrag auf Kommentare n o  2136April 1997.
3. (in) "  Domain Name System Security Extensions  " Request for Comments n o  2535März 1999.
4. (in) "  Domain - Namen - UMSETZUNG UND DATEN  " Antrag auf Kommentare n o  1035,November 1987.
5. (in) "  Sichere Domain Name System Dynamic Update  " Request for Comments n o  2137April 1997.
6. (in) "  Sichere Domain Name System (DNS) Dynamic Update  " Request for Comments n o  3007,November 2000.
7. (en) "  Generic Security Service - Algorithmus für den Secret Key Transaction Authentifizierung für DNS (GSS-TSIG)  ", Antrag auf Kommentare n o  3645,Oktober 2003.
8. (en) "  Secret Key Establishment für DNS (TKEY RR)  ", Antrag auf Kommentare n o  2930,September 2000.
9. (in) "  Address Allocation für Private Internets  " Antrag auf Kommentare n o  1918Februar 1996.
10. (en) Broido, Nemeth, claffy. Spektroskopie des DNS-Update-Verkehrs , CAIDA, 2002
11. (en) [1]
12. (in) "  US Secure Hash Algorithm 1 (SHA1)  ," Antrag auf Kommentare n o  3174,September 2001.

Externe Links

• RFC 2136 Dynamische Updates im Domain Name System (DNS-Updates)
• RFC 2845- Authentifizierung für Transaktionen mit geheimen Schlüsseln für DNS (TSIG)
• RFC 2930 Secret Key Establishment für DNS (TKEY RR)
• Generischer RFC 3645- Sicherheitsdienstalgorithmus für die Authentifizierung geheimer Schlüsseltransaktionen für DNS (GSS-TSIG)
• RFC 3174 US Secure Hash-Algorithmus 1
• RFC 4635 HMAC SHA TSIG-Algorithmuskennungen