DNSSEC

DNSSEC
Security of Domain Name Systems
Venezia, 27 maggio 2003
Enrico Martin
782142
1. Introduzione - perché DNSSEC
Il protocollo DNS [Domain Name System] definisce le specifiche per fornire un servizio di
risoluzione dei nomi, il quale, non avendo forme di autenticazione, è stato spesso oggetto
di attacchi.
Per ovviare a questi problemi è stata proposta una sua estensione: il protocollo DNSSEC.
Questa soluzione è pensata come un metodo che possa fornire sia un sistema sicuro per
mantenere l’integrità dei dati che come una forma di autenticazione per resolver o
applicazioni sicure attraverso l’uso di firme digitali crittografate.
Queste firme digitali sono incluse nelle zone sicure come resources record1 (RR). In alcuni
casi la sicurezza può essere fornita anche attraverso server non sicuri.
Le estensioni offrono un metodo per la memorizzazione nel DNS di chiavi pubbliche
autenticate. Questa memorizzazione di chiavi può supportare servizi di distribuzione di
chiavi pubbliche generiche ed anche la sicurezza del DNS stesso.
Le chiavi forniscono ai resolver sicuri la capacità di autenticare chiavi di zona oltre a quelle
per cui sono stati inizialmente configurati.
Le chiavi associate ai nomi del DNS possono essere recuperate per il supporto di altri
protocolli. É stato previsto,infatti, il supporto per molti tipi di chiave ed algoritmi.
Le estensioni sicure forniscono, infine, un metodo opzionale di autenticazione del
protocollo DNS per le transazioni e le richieste.
2. Distribuzione delle chiavi
Avendo necessità, un servizio di risoluzione dei nomi che implementa il protocollo
DNSSEC, di utilizzare chiavi pubbliche per la crittazione dei dati, un servizio di questo tipo
permette la possibilità di essere utilizzato anche come servizio di distribuzione delle chiavi
oltre che per lo stesso, anche per altri servizi.
3. Integrità dei dati ed autenticazione dell’origine
L’autenticazione è effettuata associando le firme digitali, generate crittograficamente, con
insiemi di Recource Record [ RRset ] nel DNS.
Una singola chiave privata viene, generalmente, utilizzata per autenticare un’intera zona,
ma potrebbero esistere chiavi private multiple per differenti algoritmi, differenti firme e così
via.
Se un resolver sicuro ottiene una chiave pubblica della zona di cui si fida può autenticare i
dati autenticati, letti a partire da quella zona, se è autorizzato a farlo.
Il metodo più sicuro per garantire che una zona sia sicura è tenere le chiavi private off-line
e rifirmare tutti i record della propria zona periodicamente, anche se questa operazione
non è sempre possibile. Nel caso,ad esempio, in cui si dovessero fare aggiornamenti
dinamici le chiavi privare devono essere necessariamente on-line.
1
Ogni informazione è identificata come resource record. Tale risorsa è distinguibile in base ad un campo
che ne identifica il tipo associato.
2
Le chiavi per l’autenticazione dell’origine dei dati sono associate ad una zona e non al
server che mantiene le copie dei dati. Questo metodo e necessario perché qualora il
server secondario risultasse compromesso o persino quello primario, se le chiavi fossero
tenute off-line, il resolver non potrebbe determinare se un dato è “genuino”.
Un resolver può apprendere la chiave pubblica di una zona sia leggendola dal DNS sia
avendola configurata staticamente. Per potersi fidare di una chiave pubblica letta dal DNS,
la chiave stessa deve essere firmata con una chiave di cui il resolver si fida.
Il resolver deve essere configurato con almeno una chiave pubblica che autentica una
zona come punto d'inizio. A questo punto può leggere le chiavi pubbliche delle altre zone,
se le zone intermedie nell'albero del DNS sono sicure e le loro chiavi (firmate) accessibili.
Il fatto di aggiungere l’autenticazione dell’origine dei dati e l'integrità non richiede
cambiamenti al protocollo DNS presente al di là di aggiungere il contrassegno del tipo di
risorsa necessario per la distribuzione della chiave.
Questo servizio può essere supportato dal resolver esistente e dall'implementazione di un
server di caching fatta in modo che possano supportare i tipi di risorsa addizionali.
L'unica eccezione è che i CNAME2 riferiti in una zona sicura non possono essere
autenticati se provengono da un server non sicuro.
4. Autenticazione sulle transazioni e sulle risposte
Il servizio di autenticazione dell'origine dei dati, fornisce garanzia sulla correttezza dei
resource record [RR] o, se non dovessero esistere, sulla non esistenza di questi.
Se i campi dell'intestazione di una risposta sono falsati da un server non autorizzato, non
c'è molto da fare, ma è possibile aggiungere autenticazione alle transazioni.
Questa autenticazione garantisce ad un resolver almeno di ricevere il messaggio dal
server che ha effettivamente interrogato e che la risposta è relativa alla richiesta che ha
effettivamente spedito.
La risposta può essere accompagnata da un SIG resource record, aggiunto alla fine della
risposta, che è la firma digitale. Questa, firma tutta la catena di risoluzioni e la richiesta del
resolver.
Anche le richieste possono essere autenticate includendo uno speciale SIG resource
record alla fine della stessa. Per quanto riguarda l'autenticazione delle richieste, non
essendo ancora implementato ovunque DNSSEC, potrebbero verificarsi degli errori o non
funzionare affatto con servizi DNS obsoleti.
É comunque presente nel protocollo DNSSEC questa sintassi per poter effettuare richieste
di update dinamico sicure oppure per utilizzi futuri che richiederanno una forma di
autenticazione.
2
I descrittori di tipo CNAME [CANONICAL NAME] permettono di creare alias per i nomi di dominio in modo
da associare più nomi di dominio allo stesso indirizzo di rete.
3
5. I campi delle estensioni
5.1 Il KEY Resource Record
Il tipo RR KEY è usato per memorizzare la chiave pubblica associata al nome del DNS.
Quest’ultima può essere la chiave pubblica di una zona, un utente, un host o altro.
L’implementazione di un DNS sicuro deve gestire almeno due chiavi, valide
simultaneamente, dello stesso tipo e associate simultaneamente.
Il Resource Record di tipo KEY ha numero 25.
Una chiave RR è, come ogni altro RR, autenticata da un SIG RR. Le RR KEY devono
essere firmate da una chiave del livello di zona.
Gli RDATA per la chiave RR consistono di:
flags,un ottetto per il protocollo,l'ottetto per il numero di algoritmo e,infine, la chiave
pubblica stessa. Il formato è il seguente:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
flags
|
protocol
|
algorithm
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
/
/
public key
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
La chiave non è fatta per la memorizzazione del certificato e un certificato è stato
sviluppato separatamente per lo scopo.
I flags e gli algoritmi devono essere esaminati prima di ogni dato successivo all'ottetto
dell’algoritmo, dato che essi controllano l'esistenza e il formato di ogni dato successivo.
Il formato della chiave pubblica dipende solamente dall'algoritmo.
Le chiavi RR non specificano il loro periodo di validità ma il loro SIG RR di autenticazione.
La chiave pubblica in un KEY RR è destinata all'oggetto nominato nel nome del
proprietario, un nome DNS può essere riferito:
- ad una zona;
- ad un host od ad un’altra entità;
- o per mappare il nome DNS ad un account.
Per verificare questo fatto ci sono dei flags per indicare nel RR KEY a quale di questi ruoli
il proprietario del nome e la chiave pubblica sono associati.
Un’appropriata KEY RR di zona deve essere riferita all'apice del nodo di una zona sicura e
le KEY RR di zona sono riferite solo al delegation point3.
3
Un “delegation point” è un particolare nodo nell’albero della struttura a zone del DNS che è, nel contempo,
foglia per i livelli superiori ed apice per i nodi di tutta la sottozona.
4
I campi dei flags:
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |
SIG
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
bit 0 e 1 sono riferiti al tipo di chiave i cui valori hanno i seguenti significati:
bit 2 è riservato e deve essere settato a zero;
bit 3 è riservato come bit flag di estensione;
Se è settato a uno, un secondo campo di flag a 16 bit è aggiunto dopo l’ottetto
dell’algoritmo e prima dei dati della chiave. Questo bit non deve essere settato a
meno che uno o più di questi bit addizionali siano stati definiti e siano diversi da
zero;
bit 4-5 sono riservati e devono essere settati a zero.
bit 6 e 7 formano un campo che codifica il tipo di nome i cui valori hanno i seguenti
significati:
bit 8-11 sono riservati e devono essere settati a zero;
bit 12-15 sono i “firmatari” del campo. Se sono diversi da zero indica che la chiave
può firmare validamente record come specificato nel aggiornamento dinamico4 del
DNS. Da notare che la chiave di zona ha sempre l’autorità per firmare ogni RR nella
zona senza badare al valore del campo firmatario.
Il Protocol Octet è una possibile estensione per il futuro dell’ottetto del protocollo con bit
flags non usati. I seguenti valori dell’ottetto del protocollo sono riservati come indicato:
VALORE
Protocollo
0
1
2
3
4
5-254
255
riservato
TLS
email
DNSSEC
IPSEC
disponibile per assegnamenti dello IANA
TUTTI
4
Nel considerare l’aggiornamento dinamico, bisogna tener conto delle problematiche introdotte dai
meccanismi di autenticazione.
5
Il campo “algorithm”
VALORE
Algoritmo
0
1
2
3
4
5-251
252
253
254
255
riservato;
RSA/MD5 [RFC 2537] – raccomandato;
Diffie-Hellman [RFC 2539] – opzionale;
DSA [RFC 2536] – MANDATORY;
riservato;
disponibili;
riservato per chiavi indirette;
privato – riservato ai nomi di dominio;
privato – OID;
riservato;
Significato delle associazioni tra flags, algoritmi e protocolli
NK = nessuna chiave
AL = algoritmo
PR = protocolli
X
AL
0
0
0
0
x
x
x
x
rappresenta un qualunque valore valido (non zero).
PR
0
0
x
x
0
0
x
x
NK
0
1
0
1
0
1
0
1
SIGNIFICATO
Illegale, algoritmo errato
Mancanza totale di sicurezza per la zona del proprietario.
Illegale, algoritmo errato.
Specifica un protocollo insicuro.
E’ fornita la chiave ma manca il protocollo.
Chiave non accessibile.
Specifica una chiave associata ad un protocollo.
Algoritmo non conosciuto per quel protocollo.
Per ogni algoritmo utilizzato, una zona può assumere diversi status, che possono essere:
sicuro
Indica che ogni RR recuperato deve essere autenticato da un SIG RR
altrimenti sarà scartato come non valido;
non sicuro
Indica che SIG RR non sono richiesti o attesi da una zona;
sperimentalmente Indica che i SIG RR potrebbero essere o meno presenti, ma che
sicuro
devono essere controllati.
6
c e r t - a u t h . e x a m p l e
KEY RRs|
None
| NoKeys
| Mixed
|
Keys
|
--+-----------+-----------+----------+----------+
None
| illegal
| unsecured | experim. | secure
|
--+-----------+-----------+----------+----------+
NoKeys | unsecured | unsecured | experim. | secure
|
--+-----------+-----------+----------+----------+
Mixed | experim. | experim. | experim. | secure
|
--+-----------+-----------+----------+----------+
Keys
| secure
| secure
| secure
| secure
|
+-----------+-----------+----------+----------+
S
u
p
e
r
Z
o
n
e
Nella costruzione della risposta, non viene inviata informazione aggiuntiva, eccetto il SIG
RR. Un server che adotta questa politica di sicurezza, aggiunge nella risposta una KEY
RR, se questa è disponibile. Questo può accadere nei seguenti casi:
1)
Nel ritornare un RR di tipo SOA o NS, viene aggiunta la KEY RR con lo stesso
nome, se c’è spazio disponibile per farlo, altrimenti i tipi RR A e AAAA avranno priorità
maggiore della KEY RR.
2)
Se, invece, oltre ai tipi RR A e AAAA, c’è spazio per ritornare anche altre
informazioni addizionali, viene ritornata la KEY RR ma con priorità minore delle prime.
5.2 Il SIG Resource Record
Il SIG Resource Record contiene firme digitali, ottenute tramite tecniche crittografiche a
chiave pubblica. Un server DNSSEC, rispondendo ad un'interrogazione, oltre ai record
richiesti fornirà anche i corrispondenti record SIG, in modo da autenticare i dati forniti.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
type covered
| algorithm
|
labels
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
original TTL
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
signature expiration
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
signature inception
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
key tag
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
signer's name
+
|
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/
/
/
signature
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7
Type covered field:
Il tipo “covered” è il tipo degli altri RR coperti dal SIG RR.
Algorithm number field:
Ottetto descritto nel KEY RR.
Labels Field:
l’ottetto “label” è un intero senza segno che conteggia il numero di labels
che sono presenti nel SIG RR originale, escludendo la label nulla di “root”
e qualsiasi “*” iniziale che verrà considerato come wildcard. Questo è necessario
per capire se stiamo trattando un recupero sicuro o meno. Quando dobbiamo
risolvere una wildcard, è necessario utilizzare la forma non contratta per il recupero
e la verifica della firma digitale. Se il nome recuperato dall’ RR è più lungo di
quanto indicato nel campo “label” il resolver può dire che è il risultato di una
sostituzione di wildcard e trattarlo come tale, altrimenti, se è più corto, verrà
considerato corrotto e quindi ignorato, come illustrato in figura.
labels= | 0 |
1 |
2
|
3
|
4
|
--------+-----+------+--------+----------+----------+
.|
. | bad | bad
|
bad
|
bad
|
d.| *. |
d. | bad
|
bad
|
bad
|
c.d.| *. | *.d. |
c.d. |
bad
|
bad
|
b.c.d.| *. | *.d. | *.c.d. |
b.c.d. |
bad
|
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
Original TTL filed:
Questo campo è incluso in RDATA per evitare da una parte i problemi di sicurezza
dovuti a server che potrebbero manipolare il campo TTL, falsandolo. Questo campo
è protetto da firma digitale mentre quello reale non lo è. D’altra parte si evitano
anche problemi di autenticazione che i cache server incontrerebbero decrementando il TTL5 reale.
Signature expiration and inception fields:
Il SIG RR ha validità a partire dal tempo di signature inception e fino al signature
expiration, questo determina se una zona è cambiata o meno.
Key tag field:
La “key tag” consiste in due ottetti per selezionare in modo efficiente le chiavi
multiple che possono essere applicate e così controllare che la chiave pubblica
sia effettivamente valida.
5
Il TTL [Time To Live] indica il massimo tempo di vita per un record, scaduto il quale, l’informazione descritta
dal record si può assumere obsoleta e quindi da aggiornare.
8
Signer’s name field:
Questo campo identifica il nome di dominio che ha generato la firma del SIG RR ed
è il nome del proprietario della KEY RR pubblica che può essere usato per
verificarne la firma. Solitamente è la zona che conteneva gli RRset autenticati.
Signature field:
La porzione effettiva dell’ RR SIG lega gli altri campi dell’RDATA ai RRset del type
covered dell’RR con quello del nome del proprietario e della classe. Questo RRset
coperto è perciò autenticato. Per fare ciò, una sequenza di dati è così costruita:
data = RDATA | RR(s)... dove "|" indica la concatenazione
5.3 Il NXT Resource Record
Il meccanismo dei SIG resource record fornisce forte autenticazione per i RR che esistono
in una determinata zona, ma non riesce a dare autenticazione per un certo nome o per
tipo di RR, se questo non esiste in quella zona.
L'inesistenza di un nome o di un tipo in una zona è segnalata dal RR NXT [ next ]. Se un
nome richiesto non esiste in quella zona, viene inviata una risposta contenente RR NXT e
il proprio SIG assieme all'errore. La stessa cosa accade per un tipo non esistente, eccetto
al fatto che non c'è indicazione di errore, ma un campo vuoto6.
Il resource record NXT è utilizzato per indicare in modo sicuro che non esistono RR per un
certo nome in quella zona e per indicare quali tipi RR sono presenti per un nome
esistente.
Il proprietario di un NXT RR è un nome esistente in una zona, il proprio campo RDATA
contiene il "prossimo" nome. Il NXT RR in una certa zona crea quindi una catena che
implica un ordinamento dei nomi di dominio.
Il formato del NXT Resource Record consiste nel nome di dominio seguito da una bitmap,
come mostrato in figura sotto.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
next domain name
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
type bit map
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6
Viene inviata risposta con campo vuoto poiché quel particolare servizio potrebbe non prevedere un tipo di
record richiesto dal resolver, ma questo esistere in generale per altri servizi.
9
Il formato della bitmap rappresenta il tipo della risorsa se esiste il next domain name. Un
bit ad 1 indica che almeno un RR di questo tipo è presente per quel nome. Uno 0 indica
che quel RR non è presente. Tutti i bit non specificati, perché oltre la fine della bitmap,
sono considerati a 0.
Se da una parte possiamo verificare l’esistenza di un nome in una zona, verificare la
correttezza di una risposta in presenza di espansioni di wildcard non è così semplice.
Questo aspetto, infatti, introduce alcune problematiche da considerare.
In particolare, quando viene restituita una risposta che attesta che non esiste un certo
nome, viene ritornato un NXT indicante che l'esatto nome richiesto non esiste e, in
generale, è necessario inviare uno o più NXT addizionali che provino anch'essi che non
c'erano espansioni che corrispondessero ad alcuna espansione della wildcars. In realtà
non vengono spedite copie multiple dello stesso NXT. Questi NXT, se esistono, vengono
inclusi nell’ "authority section" della risposta.
5.4 Il CERT Resource Record
Questo record permette di immagazzinare dei certificati, del tipo X.509 e PGP. Il record
KEY (che contiene solo una chiave pubblica, non è un certificato) non è destinato ad
immagazzinare chiavi pubbliche “personali”, per le quali si utilizza quindi CERT. Questo
aspetto non è però trattato perché non fa parte del protocollo DNSSEC.
6. Quello che il protocollo DNSSEC non fornisce
Il DNS fu originariamente progettato con l’idea che dovesse ritornare la stessa risposta per
qualsiasi richiesta, senza tener conto di chi l’avesse fatta. Senza fornire, quindi, risposte
differenziate sulla base dell’origine della richiesta. In questo modo, è chiaro che tutti i dati
contenuti in un DNS sono visibili da chiunque. DNSSEC mantiene la stessa linea di DNS
non fornendo riservatezza, Access Control Lists [ ACLs ] o altri metodi per differenziare le
risposte in base al richiedente.
Non fornisce, inoltre, protezione contro gli attacchi di tipo Denial of Service [DoS] e quindi i
resolver e i server che implementano la politica di sicurezza dettata dal protocollo
DNSSEC, sono vulnerabili agli attacchi di questo tipo basati su operazioni crittografiche.
In particolare, un attaccante potrebbe utilizzare il meccanismo del DNSSEC per
consumare le risorse di una vittima in due differenti maniere: da una parte potrebbe
obbligare un resolver, inondandolo di SIG RR, a risolvere complesse catene di firme,
d’altra parte potrebbe attaccare un server DNS che implementa l’update dinamico,
costringendolo a rifirmare di continuo gli RRset della propria zona.
10
6. GLOSSARIO
resolver sicuro
Un’entità che supporta le estensioni DNSSEC e che in particolare è in grado di
effettuate richieste DNSSEC e comprendere risposte che utilizzano lo stesso
protocollo.
name server sicuro
Un’entità che supporta le estensioni DNSSEC e che in particolare è in grado di ricevere
ed interpretare richieste DNSSEC e generare risposte che utilizzano questo protocollo.
recursive name server
Un’entità che può comportarsi sia come un resolver che come un name server
utilizzando il protocollo DNSSEC.
catena di autenticazioni
Nel modello DNSSEC si utilizza una strutturazione a livelli per quanto riguarda le
autenticazioni, firmando passo passo le risposte successive. Si viene così a creare una
catena di firmatari che fanno da garanti per chi ha firmato prima di loro.
chiave di autenticazione
Chiave pubblica di cui un server sicuro si fida e che quindi userà per verificare i dati.
chiave che “firma la chiave”
Una chiave di autenticazione usata per firmare la/le altre chiavi di autenticazione.
11