5. Authenticating DNS Responses (Authentification des réponses DNS)
Pour utiliser les RR DNSSEC pour l'authentification, un résolveur sensible à la sécurité nécessite une connaissance configurée d'au moins un RR DNSKEY ou DS authentifié. Le processus d'obtention et d'authentification de cette ancre de confiance initiale est réalisé via un mécanisme externe. Par exemple, un résolveur pourrait utiliser un échange authentifié hors ligne pour obtenir le RR DNSKEY d'une zone ou pour obtenir un RR DS qui identifie et authentifie le RR DNSKEY d'une zone. Le reste de cette section suppose que le résolveur a d'une manière ou d'une autre obtenu un ensemble initial d'ancres de confiance.
Un RR DNSKEY initial peut être utilisé pour authentifier le RRset DNSKEY de l'apex d'une zone. Pour authentifier un RRset DNSKEY d'apex en utilisant une clé initiale, le résolveur doit (MUST) :
- vérifier que le RR DNSKEY initial apparaît dans le RRset DNSKEY d'apex, et que le RR DNSKEY a le Flag Zone Key (bit 7 RDATA DNSKEY) défini ; et
- vérifier qu'il existe un RR RRSIG qui couvre le RRset DNSKEY d'apex, et que la combinaison du RR RRSIG et du RR DNSKEY initial authentifie le RRset DNSKEY. Le processus d'utilisation d'un RR RRSIG pour authentifier un RRset est décrit dans la Section 5.3.
Une fois que le résolveur a authentifié le RRset DNSKEY d'apex en utilisant un RR DNSKEY initial, les délégations de cette zone peuvent être authentifiées en utilisant des RR DS. Cela permet à un résolveur de partir d'une clé initiale et d'utiliser des RRsets DS pour procéder récursivement dans l'arbre DNS, obtenant d'autres RRsets DNSKEY d'apex. Si le résolveur était configuré avec un RR DNSKEY racine, et si chaque délégation avait un RR DS qui lui est associé, alors le résolveur pourrait obtenir et valider n'importe quel RRset DNSKEY d'apex. Le processus d'utilisation des RR DS pour authentifier les références est décrit dans la Section 5.2.
La Section 5.3 montre comment le résolveur peut utiliser les RR DNSKEY dans le RRset DNSKEY d'apex et les RR RRSIG de la zone pour authentifier tous les autres RRsets dans la zone une fois que le résolveur a authentifié le RRset DNSKEY d'apex d'une zone. La Section 5.4 montre comment le résolveur peut utiliser les RRsets NSEC authentifiés de la zone pour prouver qu'un RRset n'est pas présent dans la zone.
Lorsqu'un résolveur indique son support pour DNSSEC (en définissant le bit DO), un serveur de noms sensible à la sécurité devrait tenter de fournir les RRsets DNSKEY, RRSIG, NSEC et DS nécessaires dans une réponse (voir Section 3). Cependant, un résolveur sensible à la sécurité peut toujours recevoir une réponse qui manque des RR DNSSEC appropriés, que ce soit en raison de problèmes de configuration tels qu'un serveur de noms récursif en amont non sensible à la sécurité qui interfère accidentellement avec les RR DNSSEC ou en raison d'une attaque délibérée dans laquelle un adversaire forge une réponse, supprime les RR DNSSEC d'une réponse, ou modifie une requête de sorte que les RR DNSSEC semblent ne pas être demandés. L'absence de données DNSSEC dans une réponse ne doit pas (MUST NOT) en elle-même être prise comme une indication qu'aucune information d'authentification n'existe.
Un résolveur devrait (SHOULD) s'attendre à des informations d'authentification provenant de zones signées. Un résolveur devrait (SHOULD) croire qu'une zone est signée si le résolveur a été configuré avec des informations de clé publique pour la zone, ou si le parent de la zone est signé et que la délégation du parent contient un RRset DS.
5.1. Special Considerations for Islands of Security (Considérations spéciales pour les îlots de sécurité)
Les îlots de sécurité (voir [RFC4033]) sont des zones signées pour lesquelles il n'est pas possible de construire une chaîne d'authentification vers la zone depuis son parent. Valider les signatures au sein d'un îlot de sécurité nécessite que le validateur ait d'autres moyens d'obtenir une clé de zone authentifiée initiale pour l'îlot. Si un validateur ne peut pas obtenir une telle clé, il devrait (SHOULD) passer à un fonctionnement comme si les zones dans l'îlot de sécurité étaient non signées.
Tous les processus normaux de validation des réponses s'appliquent aux îlots de sécurité. La seule différence entre la validation normale et la validation au sein d'un îlot de sécurité réside dans la manière dont le validateur obtient une ancre de confiance pour la chaîne d'authentification.
5.2. Authenticating Referrals (Authentification des références)
Une fois que le RRset DNSKEY d'apex pour une zone parente signée a été authentifié, les RRsets DS peuvent être utilisés pour authentifier la délégation vers une zone enfant signée. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY d'apex de la zone enfant et contient un condensé cryptographique du RR DNSKEY de la zone enfant. L'utilisation d'un algorithme de condensé cryptographique fort garantit qu'il est informatiquement infaisable pour un adversaire de générer un RR DNSKEY qui correspond au condensé. Ainsi, l'authentification du condensé permet à un résolveur d'authentifier le RR DNSKEY correspondant. Le résolveur peut ensuite utiliser ce RR DNSKEY enfant pour authentifier l'ensemble du RRset DNSKEY d'apex enfant.
Étant donné un RR DS pour une délégation, le RRset DNSKEY d'apex de la zone enfant peut être authentifié si tous les éléments suivants sont vrais :
- Le RR DS a été authentifié en utilisant un RR DNSKEY dans le RRset DNSKEY d'apex du parent (voir Section 5.3).
- L'Algorithm et le Key Tag dans le RR DS correspondent au champ Algorithm et au key tag d'un RR DNSKEY dans le RRset DNSKEY d'apex de la zone enfant, et, lorsque le nom de propriétaire et le RDATA du RR DNSKEY sont hachés en utilisant l'algorithme de condensé spécifié dans le champ Digest Type du RR DS, la valeur de condensé résultante correspond au champ Digest du RR DS.
- Le RR DNSKEY correspondant dans la zone enfant a le bit Zone Flag défini, la clé privée correspondante a signé le RRset DNSKEY d'apex de la zone enfant, et le RR RRSIG résultant authentifie le RRset DNSKEY d'apex de la zone enfant.
Si la référence de la zone parente ne contenait pas de RRset DS, la réponse aurait dû inclure un RRset NSEC signé prouvant qu'aucun RRset DS n'existe pour le nom délégué (voir Section 3.1.4). Un résolveur sensible à la sécurité doit (MUST) interroger les serveurs de noms de la zone parente pour le RRset DS si la référence n'inclut ni un RRset DS ni un RRset NSEC prouvant que le RRset DS n'existe pas (voir Section 4).
Si le validateur authentifie un RRset NSEC qui prouve qu'aucun RRset DS n'est présent pour cette zone, alors il n'y a pas de chemin d'authentification menant du parent à l'enfant. Si le résolveur a un RR DNSKEY ou DS initial qui appartient à la zone enfant ou à toute délégation en dessous de la zone enfant, ce RR DNSKEY ou DS initial peut (MAY) être utilisé pour rétablir un chemin d'authentification. Si aucun tel RR DNSKEY ou DS initial n'existe, le validateur ne peut pas authentifier les RRsets dans ou en dessous de la zone enfant.
Si le validateur ne supporte aucun des algorithmes listés dans un RRset DS authentifié, alors le résolveur n'a pas de chemin d'authentification supporté menant du parent à l'enfant. Le résolveur devrait traiter ce cas comme il traiterait le cas d'un RRset NSEC authentifié prouvant qu'aucun RRset DS n'existe, comme décrit ci-dessus.
Notez que, pour une délégation signée, il y a deux RR NSEC associés au nom délégué. Un RR NSEC réside dans la zone parente et peut être utilisé pour prouver si un RRset DS existe pour le nom délégué. Le deuxième RR NSEC réside dans la zone enfant et identifie quels RRsets sont présents à l'apex de la zone enfant. Le RR NSEC parent et le RR NSEC enfant peuvent toujours être distingués car le bit SOA sera défini dans le RR NSEC enfant et clair dans le RR NSEC parent. Un résolveur sensible à la sécurité doit (MUST) utiliser le RR NSEC parent lorsqu'il tente de prouver qu'un RRset DS n'existe pas.
Si le résolveur ne supporte aucun des algorithmes listés dans un RRset DS authentifié, alors le résolveur ne pourra pas vérifier le chemin d'authentification vers la zone enfant. Dans ce cas, le résolveur devrait (SHOULD) traiter la zone enfant comme si elle était non signée.
5.3. Authenticating an RRset with an RRSIG RR (Authentification d'un RRset avec un RR RRSIG)
Un validateur peut utiliser un RR RRSIG et son RR DNSKEY correspondant pour tenter d'authentifier des RRsets. Le validateur vérifie d'abord le RR RRSIG pour vérifier qu'il couvre le RRset, a un intervalle de temps valide et identifie un RR DNSKEY valide. Le validateur construit ensuite la forme canonique des données signées en ajoutant le RDATA RRSIG (à l'exclusion du champ Signature) avec la forme canonique du RRset couvert. Enfin, le validateur utilise la clé publique et la signature pour authentifier les données signées. Les Sections 5.3.1, 5.3.2 et 5.3.3 décrivent chaque étape en détail.
5.3.1. Checking the RRSIG RR Validity (Vérification de la validité du RR RRSIG)
Un résolveur sensible à la sécurité peut utiliser un RR RRSIG pour authentifier un RRset si toutes les conditions suivantes sont remplies :
- Le RR RRSIG et le RRset doivent (MUST) avoir le même nom de propriétaire et la même classe.
- Le champ Signer's Name du RR RRSIG doit (MUST) être le nom de la zone qui contient le RRset.
- Le champ Type Covered du RR RRSIG doit (MUST) être égal au type du RRset.
- Le nombre de labels dans le nom de propriétaire du RRset doit (MUST) être supérieur ou égal à la valeur du champ Labels du RR RRSIG.
- La notion actuelle du temps du validateur doit (MUST) être inférieure ou égale au temps listé dans le champ Expiration du RR RRSIG.
- La notion actuelle du temps du validateur doit (MUST) être supérieure ou égale au temps listé dans le champ Inception du RR RRSIG.
- Les champs Signer's Name, Algorithm et Key Tag du RR RRSIG doivent (MUST) correspondre au nom de propriétaire, à l'algorithme et au key tag d'un RR DNSKEY dans le RRset DNSKEY d'apex de la zone.
- Le RR DNSKEY correspondant doit (MUST) être présent dans le RRset DNSKEY d'apex de la zone, et doit (MUST) avoir le bit Zone Flag (bit 7 du Flag RDATA DNSKEY) défini.
Il est possible que plus d'un RR DNSKEY corresponde aux conditions ci-dessus. Dans ce cas, le validateur ne peut pas prédéterminer quel RR DNSKEY utiliser pour authentifier la signature, et il doit (MUST) essayer chaque RR DNSKEY correspondant jusqu'à ce que la signature soit validée ou que le validateur ait épuisé les clés publiques correspondantes à essayer.
Notez que ce processus d'authentification n'a de sens que si le validateur authentifie le RR DNSKEY avant de l'utiliser pour valider les signatures. Le RR DNSKEY correspondant est considéré comme authentique si :
- le RRset DNSKEY d'apex contenant le RR DNSKEY est considéré comme authentique ; ou
- le RRset couvert par le RR RRSIG est le RRset DNSKEY d'apex lui-même, et le RR DNSKEY correspond soit à un RR DS authentifié de la zone parente, soit à une ancre de confiance.
5.3.2. Reconstructing the Signed Data (Reconstruction des données signées)
Une fois que le RR RRSIG a satisfait les exigences de validité décrites dans la Section 5.3.1, le validateur doit reconstruire les données signées originales. Les données signées originales incluent le RDATA RRSIG (à l'exclusion du champ Signature) et la forme canonique du RRset. Outre le fait d'être ordonné, la forme canonique du RRset peut également différer du RRset reçu en raison de la compression de nom DNS, de TTLs décrémentés ou d'expansion wildcard. Le validateur devrait utiliser ce qui suit pour reconstruire les données signées originales :
signed_data = RRSIG_RDATA | RR(1) | RR(2)... où
"|" désigne la concaténation
RRSIG_RDATA est le format wire des champs RDATA RRSIG
avec le champ Signature exclu et le Signer's Name
en forme canonique.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
name est calculé selon la fonction ci-dessous
class est la classe du RRset
type est le type du RRset et tous les RR dans la classe
OrigTTL est la valeur du champ Original TTL RRSIG
Tous les noms dans le champ RDATA sont en forme canonique
L'ensemble de tous les RR(i) est trié en ordre canonique.
Pour calculer le nom :
soit rrsig_labels = la valeur du champ Labels RRSIG
soit fqdn = nom de domaine complet du RRset en
forme canonique
soit fqdn_labels = nombre de labels du fqdn ci-dessus.
si rrsig_labels = fqdn_labels,
name = fqdn
si rrsig_labels < fqdn_labels,
name = "*." | les labels rrsig_label les plus à droite du
fqdn
si rrsig_labels > fqdn_labels
le RR RRSIG n'a pas passé les vérifications de validation
nécessaires et ne doit pas (MUST NOT) être utilisé pour authentifier ce
RRset.
Les formes canoniques pour les noms et RRsets sont définies dans [RFC4034].
Les RRsets NSEC à une frontière de délégation nécessitent un traitement spécial. Il y a deux RRsets NSEC distincts associés à un nom délégué signé. Un RRset NSEC réside dans la zone parente et spécifie quels RRsets sont présents dans la zone parente. Le deuxième RRset NSEC réside dans la zone enfant et identifie quels RRsets sont présents à l'apex de la zone enfant. Le RRset NSEC parent et le RRset NSEC enfant peuvent toujours être distingués car seul un RR NSEC enfant indiquera qu'un RRset SOA existe au nom. Lors de la reconstruction du RRset NSEC original pour la délégation de la zone parente, les RR NSEC ne doivent pas (MUST NOT) être combinés avec les RR NSEC de la zone enfant. Lors de la reconstruction du RRset NSEC original pour l'apex de la zone enfant, les RR NSEC ne doivent pas (MUST NOT) être combinés avec les RR NSEC de la zone parente.
Notez que chacun des deux RRsets NSEC à un point de délégation a un RR RRSIG correspondant avec un nom de propriétaire correspondant au nom délégué, et chacun de ces RR RRSIG est une donnée autoritaire associée à la même zone qui contient le RRset NSEC correspondant. Si nécessaire, un résolveur peut distinguer ces RR RRSIG en vérifiant le champ Signer's Name.
5.3.3. Checking the Signature (Vérification de la signature)
Une fois que le résolveur a validé le RR RRSIG comme décrit dans la Section 5.3.1 et reconstruit les données signées originales comme décrit dans la Section 5.3.2, le validateur peut tenter d'utiliser la signature cryptographique pour authentifier les données signées, et donc (enfin !) authentifier le RRset.
Le champ Algorithm dans le RR RRSIG identifie l'algorithme cryptographique utilisé pour générer la signature. La signature elle-même est contenue dans le champ Signature du RDATA RRSIG, et la clé publique utilisée pour vérifier la signature est contenue dans le champ Public Key du ou des RR DNSKEY correspondants (trouvés dans la Section 5.3.1). [RFC4034] fournit une liste des types d'algorithmes et fournit des pointeurs vers les documents qui définissent l'utilisation de chaque algorithme.
5.4. Authenticated Denial of Existence (Déni d'existence authentifié)
Un résolveur peut utiliser des RR NSEC authentifiés pour prouver qu'un RRset n'est pas présent dans une zone signée. Les serveurs de noms sensibles à la sécurité devraient automatiquement inclure tous les RR NSEC nécessaires pour les zones signées dans leurs réponses aux résolveurs sensibles à la sécurité.
Le déni d'existence est déterminé par les règles suivantes :
-
Si le nom de RR demandé correspond au nom de propriétaire d'un RR NSEC authentifié, alors le champ type bit map du RR NSEC liste tous les types de RR présents à ce nom de propriétaire, et un résolveur peut prouver que le type de RR demandé n'existe pas en vérifiant le type de RR dans le bit map. Si le nombre de labels dans le nom de propriétaire d'un RR NSEC authentifié est égal au champ Labels du RR RRSIG couvrant, alors l'existence du RR NSEC prouve que l'expansion wildcard n'aurait pas pu être utilisée pour correspondre à la demande.
-
Si le nom de RR demandé apparaîtrait après le nom de propriétaire d'un RR NSEC authentifié et avant le nom listé dans le champ Next Domain Name de ce RR NSEC selon l'ordre canonique des noms DNS défini dans [RFC4034], alors aucun RRset avec le nom demandé n'existe dans la zone. Cependant, il est possible qu'un wildcard puisse être utilisé pour correspondre au nom de propriétaire et au type de RR demandés, donc prouver que le RRset demandé n'existe pas nécessite également de prouver qu'aucun RRset wildcard possible n'existe qui aurait pu être utilisé pour générer une réponse positive.
De plus, les résolveurs sensibles à la sécurité doivent (MUST) authentifier les RRsets NSEC qui composent la preuve de non-existence comme décrit dans la Section 5.3.
Pour prouver la non-existence d'un RRset, le résolveur doit être capable de vérifier à la fois que le RRset interrogé n'existe pas et qu'aucun RRset wildcard pertinent n'existe. Prouver cela peut nécessiter plus d'un RRset NSEC de la zone. Si l'ensemble complet des RRsets NSEC nécessaires n'est pas présent dans une réponse (peut-être en raison d'une troncation de message), alors un résolveur sensible à la sécurité doit (MUST) renvoyer la requête afin de tenter d'obtenir la collection complète de RR NSEC nécessaires pour vérifier la non-existence du RRset demandé. Comme pour toutes les opérations DNS, cependant, le résolveur doit (MUST) limiter le travail qu'il effectue pour répondre à une requête particulière.
Puisqu'un RR NSEC validé prouve l'existence à la fois de lui-même et de son RR RRSIG correspondant, un validateur doit (MUST) ignorer les paramètres des bits NSEC et RRSIG dans un RR NSEC.
5.5. Resolver Behavior When Signatures Do Not Validate (Comportement du résolveur lorsque les signatures ne se valident pas)
Si pour une raison quelconque aucun des RRSIG ne peut être validé, la réponse devrait (SHOULD) être considérée comme BAD. Si la validation était effectuée pour servir une requête récursive, le serveur de noms doit (MUST) retourner RCODE 2 au client d'origine. Cependant, il doit (MUST) retourner la réponse complète si et seulement si la requête d'origine avait le bit CD défini. Voir également la Section 4.7 sur la mise en cache des réponses qui ne se valident pas.
5.6. Authentication Example (Exemple d'authentification)
L'Annexe C montre un exemple du processus d'authentification.