5. Authenticating DNS Responses (Autenticazione delle risposte DNS)
Per utilizzare i RR DNSSEC per l'autenticazione, un resolver consapevole della sicurezza richiede la conoscenza configurata di almeno un RR DNSKEY o DS autenticato. Il processo per ottenere e autenticare questa ancora di fiducia iniziale viene raggiunto tramite un meccanismo esterno. Ad esempio, un resolver potrebbe utilizzare uno scambio autenticato offline per ottenere il RR DNSKEY di una zona o per ottenere un RR DS che identifica e autentica il RR DNSKEY di una zona. Il resto di questa sezione presuppone che il resolver abbia in qualche modo ottenuto un insieme iniziale di ancore di fiducia.
Un RR DNSKEY iniziale può essere utilizzato per autenticare il RRset DNSKEY dell'apex di una zona. Per autenticare un RRset DNSKEY dell'apex utilizzando una chiave iniziale, il resolver deve (MUST):
- verificare che il RR DNSKEY iniziale appaia nel RRset DNSKEY dell'apex e che il RR DNSKEY abbia il Flag Zone Key (bit 7 RDATA DNSKEY) impostato; e
- verificare che esista un RR RRSIG che copre il RRset DNSKEY dell'apex e che la combinazione del RR RRSIG e del RR DNSKEY iniziale autentichi il RRset DNSKEY. Il processo per utilizzare un RR RRSIG per autenticare un RRset è descritto nella Sezione 5.3.
Una volta che il resolver ha autenticato il RRset DNSKEY dell'apex utilizzando un RR DNSKEY iniziale, le delegazioni da quella zona possono essere autenticate utilizzando i RR DS. Ciò consente a un resolver di partire da una chiave iniziale e utilizzare i RRset DS per procedere ricorsivamente lungo l'albero DNS, ottenendo altri RRset DNSKEY dell'apex. Se il resolver fosse configurato con un RR DNSKEY root e se ogni delegazione avesse un RR DS ad essa associato, il resolver potrebbe ottenere e validare qualsiasi RRset DNSKEY dell'apex. Il processo di utilizzo dei RR DS per autenticare i riferimenti è descritto nella Sezione 5.2.
La Sezione 5.3 mostra come il resolver può utilizzare i RR DNSKEY nel RRset DNSKEY dell'apex e i RR RRSIG dalla zona per autenticare tutti gli altri RRset nella zona una volta che il resolver ha autenticato il RRset DNSKEY dell'apex di una zona. La Sezione 5.4 mostra come il resolver può utilizzare i RRset NSEC autenticati dalla zona per provare che un RRset non è presente nella zona.
Quando un resolver indica il supporto per DNSSEC (impostando il bit DO), un server dei nomi consapevole della sicurezza dovrebbe tentare di fornire i RRset DNSKEY, RRSIG, NSEC e DS necessari in una risposta (vedere Sezione 3). Tuttavia, un resolver consapevole della sicurezza può ancora ricevere una risposta che manca dei RR DNSSEC appropriati, sia a causa di problemi di configurazione come un server dei nomi ricorsivo a monte non consapevole della sicurezza che interferisce accidentalmente con i RR DNSSEC, sia a causa di un attacco deliberato in cui un avversario falsifica una risposta, rimuove i RR DNSSEC da una risposta o modifica una query in modo che i RR DNSSEC sembrino non essere richiesti. L'assenza di dati DNSSEC in una risposta non deve (MUST NOT) essere considerata di per sé un'indicazione che non esistono informazioni di autenticazione.
Un resolver dovrebbe (SHOULD) aspettarsi informazioni di autenticazione da zone firmate. Un resolver dovrebbe (SHOULD) credere che una zona sia firmata se il resolver è stato configurato con informazioni sulla chiave pubblica per la zona, o se il genitore della zona è firmato e la delegazione dal genitore contiene un RRset DS.
5.1. Special Considerations for Islands of Security (Considerazioni speciali per le isole di sicurezza)
Le isole di sicurezza (vedere [RFC4033]) sono zone firmate per le quali non è possibile costruire una catena di autenticazione alla zona dal suo genitore. La validazione delle firme all'interno di un'isola di sicurezza richiede che il validatore abbia altri mezzi per ottenere una chiave di zona autenticata iniziale per l'isola. Se un validatore non può ottenere una tale chiave, dovrebbe (SHOULD) passare a operare come se le zone nell'isola di sicurezza fossero non firmate.
Tutti i processi normali per la validazione delle risposte si applicano alle isole di sicurezza. L'unica differenza tra la validazione normale e la validazione all'interno di un'isola di sicurezza è nel modo in cui il validatore ottiene un'ancora di fiducia per la catena di autenticazione.
5.2. Authenticating Referrals (Autenticazione dei riferimenti)
Una volta che il RRset DNSKEY dell'apex per una zona padre firmata è stato autenticato, i RRset DS possono essere utilizzati per autenticare la delegazione a una zona figlia firmata. Un RR DS identifica un RR DNSKEY nel RRset DNSKEY dell'apex della zona figlia e contiene un digest crittografico del RR DNSKEY della zona figlia. L'uso di un algoritmo di digest crittografico forte garantisce che sia computazionalmente impraticabile per un avversario generare un RR DNSKEY che corrisponda al digest. Quindi, l'autenticazione del digest consente a un resolver di autenticare il RR DNSKEY corrispondente. Il resolver può quindi utilizzare questo RR DNSKEY figlio per autenticare l'intero RRset DNSKEY dell'apex figlio.
Dato un RR DS per una delegazione, il RRset DNSKEY dell'apex della zona figlia può essere autenticato se tutti i seguenti elementi sono veri:
- Il RR DS è stato autenticato utilizzando un RR DNSKEY nel RRset DNSKEY dell'apex del genitore (vedere Sezione 5.3).
- L'Algorithm e il Key Tag nel RR DS corrispondono al campo Algorithm e al key tag di un RR DNSKEY nel RRset DNSKEY dell'apex della zona figlia, e, quando il nome del proprietario e i RDATA del RR DNSKEY vengono sottoposti a hash utilizzando l'algoritmo di digest specificato nel campo Digest Type del RR DS, il valore di digest risultante corrisponde al campo Digest del RR DS.
- Il RR DNSKEY corrispondente nella zona figlia ha il bit Zone Flag impostato, la chiave privata corrispondente ha firmato il RRset DNSKEY dell'apex della zona figlia, e il RR RRSIG risultante autentica il RRset DNSKEY dell'apex della zona figlia.
Se il riferimento dalla zona padre non conteneva un RRset DS, la risposta avrebbe dovuto includere un RRset NSEC firmato che dimostra che non esiste alcun RRset DS per il nome delegato (vedere Sezione 3.1.4). Un resolver consapevole della sicurezza deve (MUST) interrogare i server dei nomi per la zona padre per il RRset DS se il riferimento non include né un RRset DS né un RRset NSEC che dimostra che il RRset DS non esiste (vedere Sezione 4).
Se il validatore autentica un RRset NSEC che dimostra che non è presente alcun RRset DS per questa zona, allora non esiste un percorso di autenticazione che porta dal genitore al figlio. Se il resolver ha un RR DNSKEY o DS iniziale che appartiene alla zona figlia o a qualsiasi delegazione sotto la zona figlia, questo RR DNSKEY o DS iniziale può (MAY) essere utilizzato per ristabilire un percorso di autenticazione. Se non esiste tale RR DNSKEY o DS iniziale, il validatore non può autenticare gli RRset nella o sotto la zona figlia.
Se il validatore non supporta alcuno degli algoritmi elencati in un RRset DS autenticato, allora il resolver non ha un percorso di autenticazione supportato che porta dal genitore al figlio. Il resolver dovrebbe trattare questo caso come tratterebbe il caso di un RRset NSEC autenticato che dimostra che non esiste alcun RRset DS, come descritto sopra.
Si noti che, per una delegazione firmata, ci sono due RR NSEC associati al nome delegato. Un RR NSEC risiede nella zona padre e può essere utilizzato per provare se esiste un RRset DS per il nome delegato. Il secondo RR NSEC risiede nella zona figlia e identifica quali RRset sono presenti all'apex della zona figlia. Il RR NSEC padre e il RR NSEC figlio possono sempre essere distinti perché il bit SOA sarà impostato nel RR NSEC figlio e cancellato nel RR NSEC padre. Un resolver consapevole della sicurezza deve (MUST) utilizzare il RR NSEC padre quando tenta di provare che un RRset DS non esiste.
Se il resolver non supporta alcuno degli algoritmi elencati in un RRset DS autenticato, allora il resolver non sarà in grado di verificare il percorso di autenticazione alla zona figlia. In questo caso, il resolver dovrebbe (SHOULD) trattare la zona figlia come se fosse non firmata.
5.3. Authenticating an RRset with an RRSIG RR (Autenticazione di un RRset con un RR RRSIG)
Un validatore può utilizzare un RR RRSIG e il suo RR DNSKEY corrispondente per tentare di autenticare gli RRset. Il validatore controlla prima il RR RRSIG per verificare che copra l'RRset, abbia un intervallo di tempo valido e identifichi un RR DNSKEY valido. Il validatore quindi costruisce la forma canonica dei dati firmati aggiungendo i RDATA RRSIG (escluso il campo Signature) con la forma canonica dell'RRset coperto. Infine, il validatore utilizza la chiave pubblica e la firma per autenticare i dati firmati. Le Sezioni 5.3.1, 5.3.2 e 5.3.3 descrivono ogni passaggio in dettaglio.
5.3.1. Checking the RRSIG RR Validity (Controllo della validità del RR RRSIG)
Un resolver consapevole della sicurezza può utilizzare un RR RRSIG per autenticare un RRset se tutte le seguenti condizioni sono soddisfatte:
- Il RR RRSIG e l'RRset devono (MUST) avere lo stesso nome del proprietario e la stessa classe.
- Il campo Signer's Name del RR RRSIG deve (MUST) essere il nome della zona che contiene l'RRset.
- Il campo Type Covered del RR RRSIG deve (MUST) essere uguale al tipo dell'RRset.
- Il numero di etichette nel nome del proprietario dell'RRset deve (MUST) essere maggiore o uguale al valore nel campo Labels del RR RRSIG.
- La nozione del tempo corrente del validatore deve (MUST) essere minore o uguale al tempo elencato nel campo Expiration del RR RRSIG.
- La nozione del tempo corrente del validatore deve (MUST) essere maggiore o uguale al tempo elencato nel campo Inception del RR RRSIG.
- I campi Signer's Name, Algorithm e Key Tag del RR RRSIG devono (MUST) corrispondere al nome del proprietario, all'algoritmo e al key tag di un RR DNSKEY nel RRset DNSKEY dell'apex della zona.
- Il RR DNSKEY corrispondente deve (MUST) essere presente nel RRset DNSKEY dell'apex della zona e deve (MUST) avere il bit Zone Flag (bit 7 del Flag RDATA DNSKEY) impostato.
È possibile che più di un RR DNSKEY corrisponda alle condizioni sopra. In questo caso, il validatore non può predeterminare quale RR DNSKEY utilizzare per autenticare la firma, e deve (MUST) provare ogni RR DNSKEY corrispondente fino a quando la firma viene validata o il validatore ha esaurito le chiavi pubbliche corrispondenti da provare.
Si noti che questo processo di autenticazione ha significato solo se il validatore autentica il RR DNSKEY prima di utilizzarlo per validare le firme. Il RR DNSKEY corrispondente è considerato autentico se:
- il RRset DNSKEY dell'apex contenente il RR DNSKEY è considerato autentico; o
- l'RRset coperto dal RR RRSIG è il RRset DNSKEY dell'apex stesso, e il RR DNSKEY corrisponde a un RR DS autenticato dalla zona padre o corrisponde a un'ancora di fiducia.
5.3.2. Reconstructing the Signed Data (Ricostruzione dei dati firmati)
Una volta che il RR RRSIG ha soddisfatto i requisiti di validità descritti nella Sezione 5.3.1, il validatore deve ricostruire i dati firmati originali. I dati firmati originali includono i RDATA RRSIG (escluso il campo Signature) e la forma canonica dell'RRset. Oltre a essere ordinata, la forma canonica dell'RRset può anche differire dall'RRset ricevuto a causa della compressione del nome DNS, TTL decrementati o espansione wildcard. Il validatore dovrebbe utilizzare quanto segue per ricostruire i dati firmati originali:
signed_data = RRSIG_RDATA | RR(1) | RR(2)... dove
"|" indica la concatenazione
RRSIG_RDATA è il formato wire dei campi RDATA RRSIG
con il campo Signature escluso e il Signer's Name
in forma canonica.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
name è calcolato secondo la funzione sottostante
class è la classe dell'RRset
type è il tipo dell'RRset e tutti i RR nella classe
OrigTTL è il valore del campo Original TTL RRSIG
Tutti i nomi nel campo RDATA sono in forma canonica
L'insieme di tutti i RR(i) è ordinato in ordine canonico.
Per calcolare il nome:
sia rrsig_labels = il valore del campo Labels RRSIG
sia fqdn = nome di dominio completamente qualificato dell'RRset in
forma canonica
sia fqdn_labels = conteggio delle etichette del fqdn sopra.
se rrsig_labels = fqdn_labels,
name = fqdn
se rrsig_labels < fqdn_labels,
name = "*." | le etichette rrsig_label più a destra del
fqdn
se rrsig_labels > fqdn_labels
il RR RRSIG non ha superato i controlli di validazione
necessari e non deve (MUST NOT) essere utilizzato per autenticare questo
RRset.
Le forme canoniche per i nomi e gli RRset sono definite in [RFC4034].
Gli RRset NSEC a un confine di delegazione richiedono un'elaborazione speciale. Ci sono due RRset NSEC distinti associati a un nome delegato firmato. Un RRset NSEC risiede nella zona padre e specifica quali RRset sono presenti nella zona padre. Il secondo RRset NSEC risiede nella zona figlia e identifica quali RRset sono presenti all'apex della zona figlia. Il RRset NSEC padre e il RRset NSEC figlio possono sempre essere distinti poiché solo un RR NSEC figlio indicherà che un RRset SOA esiste al nome. Quando si ricostruisce l'RRset NSEC originale per la delegazione dalla zona padre, i RR NSEC non devono (MUST NOT) essere combinati con i RR NSEC dalla zona figlia. Quando si ricostruisce l'RRset NSEC originale per l'apex della zona figlia, i RR NSEC non devono (MUST NOT) essere combinati con i RR NSEC dalla zona padre.
Si noti che ciascuno dei due RRset NSEC in un punto di delegazione ha un RR RRSIG corrispondente con un nome del proprietario che corrisponde al nome delegato, e ciascuno di questi RR RRSIG è un dato autorevole associato alla stessa zona che contiene il corrispondente RRset NSEC. Se necessario, un resolver può distinguere questi RR RRSIG controllando il campo Signer's Name.
5.3.3. Checking the Signature (Controllo della firma)
Una volta che il resolver ha validato il RR RRSIG come descritto nella Sezione 5.3.1 e ricostruito i dati firmati originali come descritto nella Sezione 5.3.2, il validatore può tentare di utilizzare la firma crittografica per autenticare i dati firmati, e quindi (finalmente!) autenticare l'RRset.
Il campo Algorithm nel RR RRSIG identifica l'algoritmo crittografico utilizzato per generare la firma. La firma stessa è contenuta nel campo Signature dei RDATA RRSIG, e la chiave pubblica utilizzata per verificare la firma è contenuta nel campo Public Key del o dei RR DNSKEY corrispondenti (trovati nella Sezione 5.3.1). [RFC4034] fornisce un elenco dei tipi di algoritmi e fornisce puntatori ai documenti che definiscono l'uso di ciascun algoritmo.
5.4. Authenticated Denial of Existence (Negazione autenticata dell'esistenza)
Un resolver può utilizzare i RR NSEC autenticati per provare che un RRset non è presente in una zona firmata. I server dei nomi consapevoli della sicurezza dovrebbero includere automaticamente tutti i RR NSEC necessari per le zone firmate nelle loro risposte ai resolver consapevoli della sicurezza.
La negazione dell'esistenza è determinata dalle seguenti regole:
-
Se il nome del RR richiesto corrisponde al nome del proprietario di un RR NSEC autenticato, allora il campo type bit map del RR NSEC elenca tutti i tipi di RR presenti a quel nome del proprietario, e un resolver può provare che il tipo di RR richiesto non esiste controllando il tipo di RR nel bit map. Se il numero di etichette nel nome del proprietario di un RR NSEC autenticato è uguale al campo Labels del RR RRSIG che copre, allora l'esistenza del RR NSEC prova che l'espansione wildcard non avrebbe potuto essere utilizzata per corrispondere alla richiesta.
-
Se il nome del RR richiesto apparirebbe dopo il nome del proprietario di un RR NSEC autenticato e prima del nome elencato nel campo Next Domain Name di quel RR NSEC secondo l'ordine canonico dei nomi DNS definito in [RFC4034], allora non esistono RRset con il nome richiesto nella zona. Tuttavia, è possibile che un wildcard possa essere utilizzato per corrispondere al nome del proprietario e al tipo del RR richiesti, quindi provare che l'RRset richiesto non esiste richiede anche di provare che non esiste alcun RRset wildcard possibile che avrebbe potuto essere utilizzato per generare una risposta positiva.
Inoltre, i resolver consapevoli della sicurezza devono (MUST) autenticare gli RRset NSEC che comprendono la prova di non esistenza come descritto nella Sezione 5.3.
Per provare la non esistenza di un RRset, il resolver deve essere in grado di verificare sia che l'RRset interrogato non esiste sia che non esiste alcun RRset wildcard rilevante. Provare ciò può richiedere più di un RRset NSEC dalla zona. Se l'insieme completo degli RRset NSEC necessari non è presente in una risposta (forse a causa del troncamento del messaggio), allora un resolver consapevole della sicurezza deve (MUST) reinviare la query al fine di tentare di ottenere la raccolta completa di RR NSEC necessari per verificare la non esistenza dell'RRset richiesto. Come per tutte le operazioni DNS, tuttavia, il resolver deve (MUST) limitare il lavoro che dedica alla risposta a una particolare query.
Poiché un RR NSEC validato prova l'esistenza sia di se stesso che del suo RR RRSIG corrispondente, un validatore deve (MUST) ignorare le impostazioni dei bit NSEC e RRSIG in un RR NSEC.
5.5. Resolver Behavior When Signatures Do Not Validate (Comportamento del resolver quando le firme non si validano)
Se per qualsiasi motivo nessuno degli RRSIG può essere validato, la risposta dovrebbe (SHOULD) essere considerata BAD. Se la validazione veniva eseguita per servire una query ricorsiva, il server dei nomi deve (MUST) restituire RCODE 2 al client originante. Tuttavia, deve (MUST) restituire la risposta completa se e solo se la query originale aveva il bit CD impostato. Vedere anche la Sezione 4.7 sulla memorizzazione nella cache delle risposte che non si validano.
5.6. Authentication Example (Esempio di autenticazione)
L'Appendice C mostra un esempio del processo di autenticazione.