TSIG

Le protocole de réseau TSIG (transaction signature ou signature de transaction) est décrit dans la RFC 2845[1]. Il est principalement utilisé par le système des noms de domaine (DNS) pour fournir une forme d'authentification pour les mises à jour dynamiques des bases de données DNS, bien qu'il puisse être utilisé entre serveurs pour les requêtes. TSIG utilise un secret partagé et une fonction de hachage unidirectionnelle pour apporter une forme de sécurité par la cryptographie pour identifier chaque extrémité d'une connexion comme ayant droit d'effectuer ou de répondre à une demande de mise à jour DNS.

Bien que les requêtes DNS puissent être anonymes (hormis DNSSEC), les mises à jour DNS doivent être authentifiées car elles modifient la structure de nommage du réseau (Internet ou réseau privé). L'utilisation d'un secret partagé entre le client (esclave) qui effectue la mise à jour et le serveur DNS qui la lui fournit (maître) assure l'authentification du client. Cependant, la demande de mise à jour peut être effectuée au travers d'un réseau non sûr (Internet). Une fonction de hachage unidirectionnelle est utilisée pour empêcher un tiers de prendre connaissance de la clé en écoutant le trafic sur le réseau puis de l'utiliser pour faire ses propres modifications sur le serveur DNS client.

L'utilisation d'un élément horaire (timestamp) dans le protocole permet d'éviter une attaque par rejeu. Ainsi, l'utilisation de TSIG nécessite une synchronisation des serveurs sur une même source horaire. L'utilisation du protocole NTP par exemple, offre ce service.

Implémentation

Une mise à jour DNS (RFC 2136[2]) est un ensemble d'instructions destinées à un serveur DNS. Elle contient un en-tête, la zone à mettre à jour, les prérequis qui doivent être satisfaits et les enregistrements (RR) qui doivent être mis à jour. TSIG ajoute un dernier enregistrement qui comprend l'élément horaire (timestamp), un hash de la requête et le nom de la clé secrète utilisée pour signer la requête. La RFC 2535[3] propose un format de nom qu'il est recommandé d'utiliser.

La réponse après une mise à jour signée TSIG réussie sera également signée d'un enregistrement TSIG. Les échecs ne sont pas signés pour éviter qu'un attaquant puisse apprendre quoi que ce soit de la clé en utilisant des requêtes de mise à jour fabriquées spécialement dans ce but.

Le programme nsupdate permet d'utiliser TSIG pour effectuer des mises à jour. Le programme dig permet d'utiliser TSIG pour effectuer des requêtes ou des transferts de zone authentifiées.

L'enregistrement TSIG est dans le même format que les autres enregistrements d'une requête de mise à jour. La signification des champs est décrite dans le RFC 1035[4].

**champs de l'enregistrement TSIG**
Champs	Bytes	Description
NAME	max 256	Nom de la clé TSIG qui doit être unique entre le client et le serveur
TYPE	2	TSIG (250)
CLASS	2	ANY (255)
TTL	4	0 (l'enregistrement TSIG ne doit pas être stocké en mémoire tampon (cache))
RDLENGTH	2	Longueur du champ RDATA
RDATA	variable	Structure comprenant l'élément horaire (timestamp), l'algorithme et le hash.

Alternatives à TSIG

Bien que TSIG soit largement employé, ce protocole pose de nombreux problèmes:

il nécessite de déployer un secret partagé pour chaque serveur ayant besoin de mises à jour,
le condensat HMAC-MD5 n'est que de 128 bits,
il n'a pas de hiérarchie des autorités : chaque client en possession d'une clé secrète peut mettre à jour n'importe quel enregistrement de la zone.

Ainsi, divers alternatives ou extensions ont vu le jour.

La RFC 2137[5] spécifie une méthode de mise à jour utilisant une clé publique dans l'enregistrement DNS spécifique "SIG". Un client détenant la clé privée correspondante peut signer les requêtes de mises à jour. Cette méthode est compatible avec la méthode des requêtes sécurisées de DNSSEC. Cependant, cette méthode est dépréciée par la RFC 3007[6].
La RFC 3645[7] propose une extension au TSIG pour permettre l'utilisation de la méthode d'échange de clés secrètes GSS, éliminant la nécessité de déployer manuellement les clés sur l'ensemble des clients TSIG. La méthode de distribution de clés publiques avec GSS dans un enregistrement ressource DNS (RR) est spécifiée dans la RFC 2930[8]. Une méthode GSS-TSIG modifiée appelée "Algorithme du service de sécurité générique pour les échanges de secrets partagés" (Generic Security Service Algorithm for Secret Key Transaction) est basée sur le serveur Kerberos de Windows appelée "mise à jour dynamique sécurisée" (Secured Dynamic Update) a été implémentée dans les serveurs et clients Microsoft Windows Active Directory. Utilisé en combinaison avec un DNS configuré sans résolution inverse utilisant l'adressage de la RFC 1918[9], les serveurs DNS utilisant ce système d'authentification redirigent un volume important de requêtes vers les serveurs DNS racine[10]. Il existe un groupe anycast chargé de traiter ce trafic en dehors des serveurs DNS racine[11].
La RFC 2845[1], base du TSIG, n'autorise qu'une fonction de hachage unique : HMAC-MD5 qui n'est plus considérée très robuste. En 2006, des propositions émergent pour autoriser l'utilisation du SHA1 RFC 3174[12] en remplacement du MD5. Le condensat de 160 bits généré par SHA1 devrait être plus robuste que celui de 128 bits généré par le MD5.
La RFC 2930[8] définit TKEY, une liste d'enregistrements DNS utilisés pour distribuer automatiquement des clés depuis le serveur vers les clients.
La RFC 3645[7] qui définit GSS-TSIG utilisant GSS-API et TKEY pour distribuer des clés automatiquement.
La proposition DNSCurve a de nombreuses similitudes avec TSIG.

Voir aussi

principaux enregistrements DNS (RR).

Notes et références

(en) « Secret Key Transaction Authentication for DNS (TSIG) », Request for comments n^o 2845, mai 2000.
(en) « Dynamic Updates in the Domain Name System (DNS UPDATE) », Request for comments n^o 2136, avril 1997.
(en) « Domain Name System Security Extensions », Request for comments n^o 2535, mars 1999.
(en) « DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION », Request for comments n^o 1035, novembre 1987.
(en) « Secure Domain Name System Dynamic Update », Request for comments n^o 2137, avril 1997.
(en) « Secure Domain Name System (DNS) Dynamic Update », Request for comments n^o 3007, novembre 2000.
(en) « Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) », Request for comments n^o 3645, octobre 2003.
(en) « Secret Key Establishment for DNS (TKEY RR) », Request for comments n^o 2930, septembre 2000.
(en) « Address Allocation for Private Internets », Request for comments n^o 1918, février 1996.
(en) Broido, Nemeth, claffy. Spectroscopy of DNS Update Traffic , CAIDA, 2002
(en)
(en) « US Secure Hash Algorithm 1 (SHA1) », Request for comments n^o 3174, septembre 2001.

Liens externes

RFC 2136 Dynamic Updates in the Domain Name System (mises à jour DNS)
RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
RFC 2930 Secret Key Establishment for DNS (TKEY RR)
RFC 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
RFC 3174 US Secure Hash Algorithm 1
RFC 4635 HMAC SHA TSIG Algorithm Identifiers

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.