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 record 1 (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 CNAME 2 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 point 3. 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 dinamico 4 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 riservato 1 TLS 2 email 3 DNSSEC 4 IPSEC 5-254 disponibile per assegnamenti dello IANA 255 TUTTI 4 Nel considerare l aggiornamento dinamico, bisogna tener conto delle problematiche introdotte dai meccanismi di autenticazione. 5
Il campo algorithm VALORE Algoritmo 0 riservato; 1 RSA/MD5 [RFC 2537] raccomandato; 2 Diffie-Hellman [RFC 2539] opzionale; 3 DSA [RFC 2536] MANDATORY; 4 riservato; 5-251 disponibili; 252 riservato per chiavi indirette; 253 privato riservato ai nomi di dominio; 254 privato OID; 255 riservato; Significato delle associazioni tra flags, algoritmi e protocolli NK = nessuna chiave AL = algoritmo PR = protocolli X rappresenta un qualunque valore valido (non zero). AL PR NK SIGNIFICATO 0 0 0 Illegale, algoritmo errato 0 0 1 Mancanza totale di sicurezza per la zona del proprietario. 0 x 0 Illegale, algoritmo errato. 0 x 1 Specifica un protocollo insicuro. x 0 0 E fornita la chiave ma manca il protocollo. x 0 1 Chiave non accessibile. x x 0 Specifica una chiave associata ad un protocollo. x x 1 Algoritmo non conosciuto per quel protocollo. Per ogni algoritmo utilizzato, una zona può assumere diversi status, che possono essere: sicuro non sicuro sperimentalmente sicuro Indica che ogni RR recuperato deve essere autenticato da un SIG RR altrimenti sarà scartato come non valido; Indica che SIG RR non sono richiesti o attesi da una zona; Indica che i SIG RR potrebbero essere o meno presenti, ma che 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 S --+-----------+-----------+----------+----------+ u None illegal unsecured experim. secure p --+-----------+-----------+----------+----------+ e NoKeys unsecured unsecured experim. secure r --+-----------+-----------+----------+----------+ Z Mixed experim. experim. experim. secure o --+-----------+-----------+----------+----------+ n Keys secure secure secure secure 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 TTL 5 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 vuoto 6. 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