Généralisation du DS

Description: Théorie

La généralisation du DS a été imaginée pour pouvoir établir une chaine de confiance DNSSEC vers un domaine dont un ou plusieurs parents ne sont pas sécurisés. Une exemple:

'gds.' est securisé
'unsec.gds.' n'est pas securisé
'sec.unsec.gds.' est sécurisé

Avec la définition actuelle du champs DS, les seules méthodes permettant de construire une chaine de confiance vers 'sec.unsec.gds.' sont:

La zone 'unsec.gds.' devient sécurisée(on créé des clés, on signe la zone et on génére un DS dans 'gds.') et on stocke y un DS pour 'sec.unsec.gds.'.
Tous les clients qui veulent valider des requêtes dans le domaine 'sec.unsec.gds.' positionnent une des clés de ce domaine comme clés de confiance(trusted key).

La généralisation du DS permets de stocker un DS pour 'sec.unsec.gds.' dans la zone gds.. Conceptuellement on a relaché la contrainte qui impose qu'un DS ne puisse être présent que si le domaine est délégué. Cette assouplissement permets de "sauter" des zones non-sécurisés de manière sécurisée.

Générer un DS généralisé: pratique

Nous allons dérouler un exemple de génération de DS généralisé à partir des trois domaines exemples dont voici des extraits des fichiers de zone:

db.sec.unsecure.gds.

sec.unsecure.gds. SOA  ....
sec.unsecure.gds. NS   ....
     
$INCLUDE "Ksec.unsec.gds.+....
$INCLUDE "Ksec.unsec.gds.+....
$INCLUDE "Ksec.unsec.gds.+....

db.unsecure.gds.

unsecure.gds. SOA  ....
unsecure.gds. NS   ....
     
sec.unsecure.gds. IN NS ....
sec.unsecure.gds. IN NS ...

db.gds.

gds. SOA  ....
     NS   ....

unsecure.gds. IN NS ....
              IN NS ...

$INCLUDE "Kgds.+....
$INCLUDE "Kgds.+....
$INCLUDE "Kgds.+....

Dans un process normal on signerait le fichier de zone 'db.gds.' de la zone 'gds.', avec les clés qui sont incluses en fin de fichier.
En signant la zone 'sec.unsecure.gds.', dnssec-sigzone devrait avoir généré le fichier 'dsset-sec.unsecure.gds.'. Pour créé un DS généralisé pour 'sec.unsecure.gds.' dans la zone 'gds.', il suffit de rajouter $INCLUDE "dsset-sec.unsecure.gds." à la fin du fichier 'db.gds.'. En signant 'db.gds.' avec le dnssec-sigzone patché (celui qui est dans la version patché de BIND), on obtient un fichier 'db.gds.signed' qui contient des DS signés(avec aussi les NSEC)pour 'sec.unsecure.gds.'.

Si cette zone est gérée par un BIND patché on obtient le comportement attendu: la requête "sec.unsecure.gds. DS ?" reverra bien un DS signé qui permettra d'établir une chaine de confiance de 'gds.' vers 'sec.unsecure.gds.'.

Limitations

Ce patch a été écrit avec la contrainte de ne pas être trop intrusif au niveau de BIND, en conséquence il y a des limitations pour impléménter correctement le concept de DS généralisé. La seule limitation connue à l'heure actuelle est que dés qu'un enregistrement de DS généralisé existe dans une zone, ce même serveur ne doit pas servir une des sous-zones ou un des zones intermédiaires de ce domaine.

Dans notre exemple, le même serveur BIND ne peux pas gérer correctement en même temps gds. et unsecure.gds. ou sec.unsecure.gds.

Si le serveur gère gds. et unsecure.gds., on obtient une réponse de type SOA quand on demande un DS pour sec.unsecure.gds.(c'est la réponse de la zone unsecure.gds.)
Si le serveur est configuré pour gérer gds. et sec.unsecure.gds., on obtient un NSEC quand on demande un DS pour sec.unsecure.gds.(c'est la réponse de la zone sec.unsecure.gds.)

Cette limitation semble assez lourde à lever à l'heure actuelle. Ce patch est plus un "proof-of-concept" qu'une chose à faire tourner en environnement de production. Il faut néanmoins garder à l'esprit cette limitation.

Téléchargements

Disponible au téléchargement:

ftp://ftp.irisa.fr/local/idsa/code/patch-bind/gds/ : le patch de BIND qui change son comportement vis-à-vis des DS. Ce patch contient aussi une version modifié de dnssec-signzone qui permet de générer les DS généralisés de manière correcte.