Network Working Group S. Bellovin, Ed. Request for Comments: 3631 J. Schiller, Ed. Category: Informational C. Kaufman, Ed. Internet Architecture Board December 2003 Meccanismi di Sicurezza Internet Traduzione a cura di ComiSAT Brescia, Set. 2007 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questo Documento Questo documento fornisce informazioni per la comunita' Internet. Non specifica uno standard Internet di alcun genere. La distribuzione di questo documento non e' soggetta a limitazioni. Nota di Copyright Copyright (C) The Internet Society (2003). All Rights Reserved. Sunto La sicurezza dev'essere sviluppata all'interno dei Protocolli Internet affinche' tali protocolli offrano servizi sicuri. Molte problematiche di sicurezza possono essere evidenziate per migliorare le implementazioni. Ad ogni modo, anche una corretta implementazione puo' avere problemi di sicurezza se il protocollo di base e' vulnerabile in se'. Le precise modalita' di come la sicurezza dev'essere implementata in un protocollo sono variabili, in funzione della struttura dello stesso protocollo. Vi sono tuttavia protocolli per i quali possono essere applicati i meccanismi di sicurezza Internet standard gia' sviluppati. Il giusto ed appropriato meccanismo per una data situazione e' variabile. Qui facciamo una panoramica di un certo numero di differenti possibilita', spiegandone le proprieta' di ciscuna. 1. Introduzione I problemi di Sicurezza Internet si possono suddividere in svariate categorie, che vanno dal Denial of Service alla compromissione di un host. Gli attacchia Denial of Service basati sul puro volume di traffico vanno oltre lo scopo del presente documento, benche' siano oggetto di continua discussione e ricerca. E' importante notare come molti di questi attacchi siano resi particolarmente difficili da portare a compimento se vengono adottate buone pratiche di sicurezza. La compromissione di un host (molto spesso causata da Buffer Overflows non rilevati) simboleggia dei difetti nelle implementazioni individuali piuttosto che nei protocolli. Comunque sia, protocolli progettati con cura possono rendere piu' difficile il verificarsi di tali difetti e incrementare la difficolta' di un exploit. Bellovin, et al. Informational [Page 1] RFC 3631 Security Mechanisms for the Internet December 2003 Vi sono ad ogni modo falle di sicurezza che sono facilitate da molti protocolli in uso su Internet. Se un problema di sicurezza riguarda un protocollo, non vi e' modo che un'implementazione sia in grado di arginare il problema. E' quindi di vitale importanza che i protocolli sviluppati per Internet forniscano tale sicurezza fondamentale. Il modo esatto in cui un protocollo dev'essere reso sicuro dipende dal protocollo in se' cosi' come la sicurezza stessa necessita del protocollo. All'IETF abbiamo tuttavia sviluppato un numero di meccanismi di sicurezza standard. In molti casi l'applicazione corretta di tali meccanismi puo' fornire ad un protocollo la sicurezza necessaria. Per offrire sicurezza su Internet puo' essere utilizzato un certo numero di meccanismi possibili. Quale va scelto dipende da molti fattori diversi. Con questo documento cerchiamo di fornire dei consigli, spiegandone i fattori e le soluzioni che sono attulmente uno standard (o quasi), come discusso all'IAB Security Architecture Workshop [RFC2316]. La sicurezza e' ad ogni modo un'arte, non una scienza. Cercare di seguire ciecamente una ricetta puo' condurre al disastro. Come sempre, ci vuole testa nella progettazione di un protocollo. Infine, i meccanismi di sicurezza non sono la polverina magica di un folletto che puo' essere spruzzata su protocolli gia' completati. E' raro che la sicurezza possa essere introdotta a posteriori. Una buona progettazione -- ovvero, sicura, pulita ed efficente -- si ottiene qualora i meccanismi di sicurezza vadano di pari passo con il protocollo. Nessun esercizio crittografico puo' rendere sicuro un protocollo in presenza di falle nei presupposti semantici. 2. Fattori Determinanti 2.1. Il Modello della Minaccia Il piu' importante fattore nella scelta di un meccanismo di sicurezza e' il modello della minaccia. Ovvero, chi si puo' prevedere che attacchi cosa, e usando quale sorta di meccanismo ? Un obiettivo di basso valore, come un sito web che offre solamente informazioni pubbliche, puo' non meritare grande protezione. Per contro, una risorsa che se compromessa potrebbe esporre parti significative dell'infrastruttura di Internet, diciamo un grande nodo router o un server DNS di alto livello, dovrebbe essere protetta con meccanismi molto robusti. Il valore di un obiettivo per un attaccante dipende dallo scopo dell'attacco. Se lo scopo e' avere accesso ad un'informazione sensibile, ciascun sistema che gestisce tale informazione o che ne media l'accesso e' importante. Se lo scopo e' arrecare danni considerevoli, i sistemi sui quali dipende gran parte di Internet sono estremamente importanti. Bellovin, et al. Informational [Page 2] RFC 3631 Security Mechanisms for the Internet December 2003 Anche se su un sito web vi sono postate soltanto informazioni pubbliche, cambiarne i contenuti puo' comportare l'imbarazzo del proprietario e potrebbe causare un danno sostanziale. Nella progettazione di un protocollo e' difficile prevederne gli usi che se ne potranno fare un giorno. Tutti i sistemi connessi ad Internet richiedono un minimo di protezione. Dal 2000 ad oggi, siamo stati testimoni dell'avvento di un nuovo tipo di attacco alla sicurezza Internet: un programma "worm" Internet che cerca e attacca automaticamente sistemi da compromettere che ne sono vulnerabili attraverso un numero di attacchi inserito all'interno dello stesso worm. Tali programmi worm possono compromettere letteralmente migliaia di sistemi in un periodo di tempo davvero breve. Si noti che il primo Worm di Internet fu il "Morris" nel 1988. Tuttavia, non si ebbe il seguito di programmi analoghi per ben 12 anni! Fino alla data di scrittura del presente documento, tutti questi worms hanno sfruttato errori di programmazione nell'implementazione di protocolli altrimenti ragionevolmente sicuri. Ad ogni modo, non e' difficile prevedere un attacco che miri ad una falla di sicurezza fondamentale in un protocollo ampiamente diffuso. E' dunque di importanza vitale che ci sforziamo per minimalizzare tali falle nei protocolli che sviluppiamo. Il valore di un bersaglio per un attaccante puo' dipendere da dove questo si trova. Una stazione di monitoraggio di rete che si trova fisicamente su una backbone e' un bersaglio molto importante, dal momento che potrebbe essere facilmente trasformata in una stazione d'ascolto non autorizzato. La stessa macchina, se locata in una rete troncata e utilizzata per elaborazione di testo, risulterebbe di bassissimo utilizzo per un attaccante sofisticato, e quindi sarebbe a minor rischio in modo significativo. Dev'essere inoltre preso in cosiderazione il tipo di attacco che ci si puo' aspettare. Un ascolto non autorizzato va visto, come minimo, come una grave minaccia; dal 1993 vi sono stati veramente tanti incidenti di questo tipo. Spesso gli attacchi attivi, ovvero quelli che implicano l'aggiunta o la rimozione di pacchetti da parte dell'attaccante, sono di per se' un rischio. E' importante notare che tali attacchi possono essere lanciati attraverso tools belli che pronti, e sono stati di fatto osservati "in territori selvaggi". Di particolare interesse e' una forma di attacco chiamata "session hijacking" (N.d.T. dirottamento della sessione), in cui qualcuno in un collegamento tra due parti in comunicazione attende il completamento dell'autenticazione e poi prende il posto di una delle due parti e continua la connessione con l'altra. Uno dei piu' importanti strumenti che abbiamo a disposizione per la sicurezza dei protocolli e' la crittografia. Essa ci consente di applicare diversi tipi di protezione ai dati come se attraversassero la rete, senza dover dipendere da una qualsiasi proprieta' di sicurezza della stessa rete. Questo e' molto importante dal momento che la sola Internet, per la sua caratteristica di Bellovin, et al. Informational [Page 3] RFC 3631 Security Mechanisms for the Internet December 2003 gestione e controllo distribuiti, non puo' essere considerata un mezzo fidato. La sua sicurezza deriva dai meccanismi che noi inseriamo all'interno degli stessi protocolli, a prescindere dai mezzi di base o dagli operatori di rete. Per concludere, vi e' naturalmente un prezzo da pagare per la protezione mediante l'uso della crittografia. Tale prezzo sta cadendo rapidamente; la Legge di Moore, insieme ai toolkit e ai componenti crittografici facilmente reperibili, rende robuste tecniche di protezione relativamente semplici da utilizzare. Sebbene vi siano eccezioni, operazioni a chiave pubblica sono ancora costose, cosi' se il costo di ciascuna operazione a chiave pubblica viene rivolto ad un numero troppo basso di transazioni, progetti di ingegneria accurati possono generalmente consentirci di disperdere tale costo tra molte transazioni. In generale, l'attuale pratica comune dovrebbe essere l'uso della crittografia piu' robusta disponibile in ciascun protocollo. La crittografia forte spesso non costa di piu' di quella debole, e a volte ancora meno. Il costo delle prestazioni reali di un algoritmo e' spesso non correlato alla sicurezza che fornisce. In base all'hardware disponibile, la crittografia puo' essere ottenuta a livelli altissimi (1+Gbps), e persino nel software l'incidenza delle sue prestazioni si va ad esaurire col tempo. 2.2. Due Parole sui Meccanismi Obbligatori All'IETF abbiamo evoluto la notazione di meccanismi ad "implementazione obbligatoria". Questa filosofia si evolve dal nostro desiderio primario di assicurare interoperabilita' tra implementazioni differenti di un protocollo. Se un protocollo offre molte opzioni su come effettuare una particolare operazione, ma non riesce a fare in modo che almeno una di esse possa essere implementata da tutti, e' possibile che possano generarsi implementazioni multiple, non interoperabili. Questa e' la conseguenza della selezione di meccanismi non sovrapponibili che sono stati utilizzati in implementazioni diverse. Sebbene un dato protocollo possa far uso solamente di uno o di pochi meccanismi di sicurezza, tali meccanismi possono spesso far uso loro stessi di svariati sistemi crittografici. I vari sistemi crittografici differiscono in robustezza e prestazioni. Tuttavia, in molti protocolli c'e' bisogno di specificare una "implementazione obbligatoria" per garantire che qualsiasi implementazione sia eventualmente in grado di negoziare un comune sistema crittografico con le altre. Vi sono alcuni protocolli che furono progettati in origine per essere utilizzati in un dominio molto ristretto. Si discute spesso che il dominio di un'implementazione per un particolare protocollo sia sufficientemente ben definito e sicuro che il protocollo in se' non necessita di fornire alcun meccanismo di sicurezza. Bellovin, et al. Informational [Page 4] RFC 3631 Security Mechanisms for the Internet December 2003 La storia ha dimostrato quanto questa tesi sia sbagliata. Inevitabilmente, protocolli di successo - anche se sviluppati per usi ristretti - sono utilizzati in ambienti piu' ampi, nei quali i presupposti iniziali di sicurezza non reggono piu'. Per risolvere questo problema, l'IETF richiede che *TUTTI* i protocolli forniscano meccanismi di sicurezza appropriati, anche quando il loro dominio d'applicazione iniziale e' ritenuto molto ristretto. E' importante capire che i meccanismi obbligatori sono obbligatori da *implementare*. Non e' necessariamente obbligatorio che l'utente finale utilizzi tali meccanismi. Se un utente finale e' conscio di utilizzare un protocollo in una rete "sicura", potrebbe scegliere di disabilitare i meccanismi di sicurezza che ritiene superflui in relazione al costo delle loro prestazioni. (Noi siamo generalmente scettici sulle decisioni di disabilitare meccanismi di sicurezza robusti in ogni caso, ma questo esula dallo scopo del presente documento). Insistere sul fatto che alcuni meccanismi devono essere obbligatoriamente implementati vuol dire che quegli utenti finali che hanno bisogno del protocollo, fornito insieme a meccanismi di sicurezza, li avranno a disposizione qualora gli servano. Specificatamente ai meccanismi di sicurezza, il solo fatto che un meccanismo sia obbligatorio da implementare non implica il fatto esso debba essere un meccanismo di default o che non possa essere disabilitato per configurazione. Se un algoritmo obbligatorio da implementare e' vecchio e poco robusto, e' meglio che sia disabilitato se vi e' a disposizione un algoritmo piu' solido. 2.3. Granularita' della Protezione Alcuni meccanismi di sicurezza possono proteggere un'intera rete. Mentre questo economizza a livello di hardware, puo' lasciare tali reti vulnerabili ad attacchi dall'interno. Altri meccanismi possono fornire protezione fino all'utente individuale di una macchina multiutente, sebbene lasci aperto il rischio di una possibile impersonificazione d'utente nel caso in cui la macchina sia stata compromessa. Nel valutare il livello di protezione desiderato, gli sviluppatori dei protocolli dovrebbero considerare i modelli di probabile utilizzo, i livelli di implementazione (vedasi piu' avanti), e la diffusione. Se un protocollo e' probabile che venga utilizzato soltanto all'interno di un cluster sicuro (diciamo un Network Operations Center), la granularita' della sottorete potrebbe essere adeguata. Al contrario, un meccanismo di sicurezza peculiare per una singola applicazione viene inglobato al meglio in quella stessa applicazione, piuttosto che all'interno del TCP; la diffusione sara' diversamente molto difficile. Bellovin, et al. Informational [Page 5] RFC 3631 Security Mechanisms for the Internet December 2003 2.4. Livello di Implementazione I meccanismi di sicurezza possono essere posti in un qualsiasi livello. In generale, porre un meccanismo al livello piu' basso protegge un'ampia gamma di protocolli di livelli superiore, ma potrebbe pure non essere in grado di farlo. Un cifratore a livello di collegamento (link) puo' proteggere non solamente i pacchetti IP, ma anche quelli ARP. La sua estensione e' ad ogni modo quella di quel collegamento. Per contro, un messaggio email firmato e' protetto anche se spedito attraverso molti gateway di rimbalzo, puo' identificare il mittente e la firma puo' essere verificata dopo che il messaggio e' stato recapitato. Tuttavia, solamente quel messaggio risulta protetto. I messaggi in formati analoghi, come i post di alcune reti di News, non risultano protetti se tale meccanismo non viene specificatamente adottato ed implementato nei programmi che gestiscono le news. 3. Meccanismi di Sicurezza Standard 3.1. One-Time Passwords Gli schemi di password one-time (N.d.T. usa e getta), come quelli descritti in [RFC2289] sono molto piu' robusti rispetto alle password convenzionali. L'host non necessita di memorizzare una copia della password utente, ne' viene mai trasmessa in rete. Vi sono comunque alcuni rischi. Dal momento che le stringhe trasmesse derivano da una password di tipo utente, sono ancora fattibili gli attacchi che si basano sull'indovinare le password. (Di fatto un programma in grado di lanciare questo tipo di attacco esiste ed e' disponibile). Ancora, la possibilita' dell'utente di loggarsi scade necessariamente dopo un determinato numero di accessi. Sebbene in molti casi questo sia una feature, un'implementazione necessita piu' probabilmente di fornire un metodo per reinizzializzare il database di autenticazione senza richiedere che la nuova password sia inviata in chiaro attraverso la rete. Vi sono elementi di autenticazione hardware commerciali. Al di la' della questione del dirottamento della sessione (session hijacking), il supporto per tali elementi (specialmente quelli di richiesta/risposta, ove il server invia un diverso numero random per ciasun tentativo di autenticazione) puo' richiedere messaggi extra protocollo. 3.2. HMAC (N.d.T.: keyed-hash message authentication code) L'HMAC [RFC2104] e' la tecnica di autenticazione segreta-condivisa che si preferisce. Se entrambi i lati conoscono la medesima chiave segreta, l'HMAC puo' essere utilizzato per autenticare qualsiasi messaggio arbitrario. Questo comprende i tentativi casuali, che significa che l'HMAC puo' essere adottato per evitare il ripetersi di vecchie sessioni. Bellovin, et al. Informational [Page 6] RFC 3631 Security Mechanisms for the Internet December 2003 Uno svantaggio dell'uso dell'HMAC per l'autenticazione della connessione e' che il segreto dev'essere conosciuto in chiaro da entrambe le parti, e questo e' poco desiderabile nei casi in cui le chiavi siano di lunga durata. Se utilizzabile, l'HMAC dovrebbe essere utilizzato al posto di tecniche piu' vetuste, funzioni di hash considerevolmente chiuse a chiave. Semplici hash protetti con MD5 [RFC1321], come quelli utilizzati nei meccanismi di sicurezza delle sessioni BGP [RFC2385], devono essere in particolar modo evitati nei nuovi protocolli, considerati i fattori di debolezza dell'MD5. L'HMAC puo' essere implementato utilizzando una qualsiasi funzione di hash sicura, compresa l'MD5 e l'SHA-1 [RFC3174]. L'SHA-1 e' preferibile per i nuovi protocolli poiche' e' piu' frequentemente utilizzata per tale scopo e puo' risultare piu' sicura. E' importante comprendere che i meccanismi basati su HMAC hanno bisogno di essere impiegati su ciasuna unita' di dati del protocollo (ovvero su ogni pacchetto). E' un errore utilizzare sistemi basati su HMAC per autenticare l'inizio di una sessione TCP per poi spedire tutti i dati rimanenti senza alcuna protezione. Esistono programmi di attacco che consentono di carpire una sessione TCP. Un attaccante avrebbe soltanto bisogno di utilizzare un tale tool per impossessarsi di una sessione dopo che viene eseguito il lavoro dell'HMAC. 3.3. IPsec (N.d.T.: IP security) L'IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] e' il protocollo generico di cifratura ed autenticazione a livello IP. Come tale, esso protegge tutti i livelli superiori, compresi sia il TCP che l'UDP. La sua normale granularita' di protezione e' host-a-host, host-a-gateway e gateway- a-gateway. La specifica consente protezione a livello di granularita'-utente, ma questa e' tutto sommato rara. L'IPsec e' dunque attualmente inappropriato quando la granularita'-host e' troppo generica. Dal momento che l'IPsec viene installato a livello IP, risulta abbastanza intrusivo nel codice di rete. L'implementazione richiede solitamente o nuovo hardware o una nuova pila di protocolli. D'altro canto e' ragionevolmente trasparente alle applicazioni. Le applicazioni che girano sull'IPsec possono vedersi migliorato il livello di sicurezza senza modificare affatto i loro protocolli. Ma fintanto che l'IPsec non sara' ampiamente diffuso, la maggior parte delle applicazioni non dovrebbe presupporre che il fatto di girare sull'IPsec sia un'alternativa ai propri meccanismi specifici di sicurezza. I sistemi operativi piu' moderni dispongono dell'IPsec; la maggior parte dei routers non ne dispone, almeno per quanto riguarda il controllo dei percorsi. Un'applicazione che utilizza il TLS e' in grado di asserire con maggiore probabilita' che le applicazioni specifiche possono trarre vantaggio dalla sua autenticazione. Bellovin, et al. Informational [Page 7] RFC 3631 Security Mechanisms for the Internet December 2003 La gestione della chiave con IPsec puo' utilizzare o i certificati o la condivisione dei segreti. Per ogni ovvia ragione, e' preferibile l'uso dei certificati; essi possono ad ogni modo essere la causa di molti mal di testa per i responsabili del sistema. Esiste una forte possibilita' di conflitto tra l'IPsec e il NAT [RFC2993]. Il NAT non coesiste facilmente con un altro protocollo contenente indirizzi IP inglobati; con l'IPsec, ciasun pacchetto, per ciascun protocollo, contiene tali indirizzi, anche se soltanto negli headers. Il conflitto puo' a volte essere evitato utilizzando la modalita' tunnel, ma per altre ragioni non e' sempre la scelta appropriata. Si sta lavorando per fare in modo che l'IPsec attraversi piu' facilmente il NAT [NATIKE]. La maggior parte degli attuali usi dell'IPsec avviene per reti private virtuali. Supponendo di riscontrare gli altri vincoli, l'IPsec e' il protocollo di sicurezza scelto per situazioni di tipo VPN, compresi gli scenari d'accesso remoto nei quali una singola macchina torna indietro alla sua rete d'appartenenza attraverso internet utilizzando l'IPsec. 3.4. TLS (N.d.T.: Transport Layer Security) Il TLS [RFC2246] fornisce un canale cifrato e autenticato che gira sul TCP. Sebbene il TLS fu in origine sviluppato per essere utilizzato dai browsers web, esso non si limita affatto soltanto a questo. Anche se, in generale, ogni applicazione che desideri l'uso del TLS avra' bisogno di essere convertita individualmente. Solitamente il lato server e' sempre autenticato da un certificato. Anche i client possono possedere certificati, fornendo autenticazione reciproca, ma questo si verifica in casi eccezionali. Il fatto che anche l'autenticazione lato server non sia sicura nella pratica quanto lo e' la crittografia e' la cruda realta', poiche' la maggior parte delle implementazioni consente agli utenti di ignorare autenticazioni errate (cliccando OK su un avviso) e la maggior parte di utenti e' abituata a farlo di routine [Bell98]. Gli sviluppatori dovrebbero dunque pensarci due volte prima di fare in modo che vengano richieste password in chiaro, anche se su connessioni protette tramite TLS. (Tale requisito potrebbe essere piu' elastico se fosse probabile che le implementazioni siano in grado di verificare l'autenticita' e l'autorizzazione del certificato del server). Sebbene la modifica ad un'applicazione e' generalmente necessaria per far uso del TLS, esistono toolkit, sia commerciali che liberi, che ne forniscono implementazioni. Questi sono stati concepiti per essere incorporati all'interno del codice dell'applicazione. Un'applicazione che utilizza il TLS e' piu' facilmente in grado di verificare le politiche di uno specifico certificato di un'applicazione rispetto ad una che utilizza invece l'IPsec. Bellovin, et al. Informational [Page 8] RFC 3631 Security Mechanisms for the Internet December 2003 3.5. SASL (N.d.T.: Simple Authentication and Security Layer) Il SASL [RFC2222] e' un ambiente di lavoro per la negoziazione di un'autenticazione e un meccanismo di cifratura che viene utilizzato su flussi TCP. Come tale, le sue caratteristiche di sicurezza sono quelle di un meccanismo negoziato. Nello specifico, a meno che il meccanismo negoziato autentichi tutti i messaggi successivi o vengano utilizzati protocolli di protezione come il TLS, le connessioni TCP sono vulnerabili di intercettazione della sessione. Ma se avete bisogno di utilizzare il TLS (o l'IPsec) sotto il SASL, perche' rompersi le scatole con il SASL ? Perche' non utilizzare semplicemente gli strumenti di autenticazione del TLS e basta ? La risposta e' sottile. Il TLS fa un uso massiccio di certificati per l'autenticazione. Come comunemente diffuso, soltanto i server hanno certificati, mentre i client rimangono privi di autenticazione (almeno dall'elaborazione dello stesso TLS). Il SASL consente l'uso di tecnologie di autorizzazione client piu' tradizionali, come le password (one-time o di altra specie). Una potente combinazione e' l'uso del TLS come protezione sottostante e come autenticazione del server, e di sistemi basati su SASL per l'autenticazione dei client. Si deve porre attenzione per evitare vulnerabilita' nel mezzo quando teniche di autenticazione differenti sono utlizzate in diverse direzioni. 3.6. GSS-API Il GSS-API [RFC2744] fornisce un ambiente di lavoro per applicazioni da utilizzarsi quand'esse richiedono autenticazione, integrita' e/o confidenzialita'. A differenza del SASL, il GSS-API puo' essere impiegato facilmente con applicazioni basate sull'UDP. Esso provvede alla creazione di elementi di autenticazione opachi (conosciuti come chunks of memory - pezzi di memoria) che possono essere incorporati nelle unita' dati di un protocollo. Si noti che la sicurezza dei protocolli protetti con GSS-API dipende dai meccanismi di sicurezza sottostanti; questo va valutato in modo indipendente. Considerazioni analoghe si applicano, ovviamente, all'interoperabilita'. 3.7. DNSSEC Il DNSSEC [RFC2535] firma in modo digitale le voci del DNS. E' un tool fondamentale per la protezione contro gli attacchi di contaminazione della cache DNS [Bell95]; questi possono anche essere utilizzati per sconfiggere l'autenticazione basata sul nome e per redirigere il traffico a od oltre l'attaccante. A posteriori si puo' considerare il DNSSEC un componente essenziale per alcuni altri meccanismi di sicurezza, in particolare per l'IPsec. Anche se non largamente diffuso su Internet al momento della scrittura del presente documento, esso offre la capacita' di fornire un meccanismo sicuro per mappare i nomi di dominio agli indirizzi IP. Puo' inoltre essere utilizzato per associare in modo sicuro altre informazioni ai nomi DNS. Bellovin, et al. Informational [Page 9] RFC 3631 Security Mechanisms for the Internet December 2003 Queste informazioni possono essere semplici come il servizio supportato su un dato nodo, oppure una chiave da utilizzare con Ipsec per negoziare una sessione sicura. Si tenga presente che il concetto di memorizzare nel DNS chiavi di applicazioni per usi generali e' considerato deprecabile [RFC3445], ma l'abitudine di immagazzinare chiavi per particolari applicazioni - soprattutto per Ipsec - sta continuando. 3.8. Sicurezza/Multiparte I meccanismi Sicurezza/Multiparte [RFC1847] sono i preferiti per la protezione di email. Piu' precisamente, e' all'interno dell'ambiente MIME che sono conglobati cifratura e/o firme digitali. Sia l'S/MIME che l'OpenPGP (vedasi a seguire) utilizzano Sicurezza/Multiparte per le loro codifiche. I lettori di mail conformi possono facilmente riconoscere e processare le parti cifrate dell'email. La Sicurezza/Multiparte rappresenta una forma di "sicurezza dell'oggetto", in cui un oggetto di interesse per l'utente finale viene protetto indipendentemente dal meccanismo di trasporto, archiviazione intermedia, eccetera. Attualmente, non vi e' alcuna forma generale di protezione dell'oggetto disponibile in Internet. Per un buon esempio dell'utilizzo del S/MIME al di fuori del contesto della posta elettronica, si veda il Protocollo di Iniziazione della Sessione (SIP) [RFC3261]. 3.9. Firma digitale Una delle piu' robuste forme di autenticazione richiesta/risposta e' basata sulla firma digitale. L'uso della crittografia a chiave pubblica e' preferibile agli schemi basati sulla cifratura di chiavi segrete poiche' nessun server necessita una copia del segreto dell'utente. Il client ha piuttosto una chiave privata; i server hanno la corrispondente chiave pubblica. L'uso della firma digitale e' correttamente ingannevole. Un client non dovrebbe mai firmare l'esatta richiesta da inviare, dal momento che si possono essere svariati attacchi numero-teoretici che possono essere lanciati in tali situazioni. La Firma Digitale Standard [DSS] e l'RSA] sono entrambe buone scelte; ciascuna ha i suoi vantaggi. La firma mediante RSA richiede l'uso di numeri random buoni [RFC1750]. Se il nemico puo' recuperare il numero random utilizzato per una qualsiasi firma, o se usaste lo stesso numero random per due documenti diversi, la vostra chiave privata potrebbe essere recuperata. La DSS ha prestazioni migliori rispetto alla RSA per quanto riguarda la generazione di nuove chiavi private, e prestazioni un po' piu' performanti nella generazione delle firme, mentre l'RSA offre prestazioni maggiori nella verifica delle stesse. Bellovin, et al. Informational [Page 10] RFC 3631 Security Mechanisms for the Internet December 2003 3.10. OpenPGP e S/MIME Le firme digitali possono essere utilizzare per costruire applicazioni di "sicurezza dell'oggetto", le quali possono essere usate per proteggere dati memorizzati e protocolli di inoltro come la posta elettronica. Alla data del presente documento, due diversi protocolli di posta sicura, OpenPGP [OpenPGP] e S/MIME [S/MIME], sono stati proposti per rimpiazzare il PEM [PEM]. Non e' chiaro quale dei due, se vi sara', sara' il successore. Nonostante siano concepiti ai fini di posta sicura, entrambi possono essere adattati per proteggere dati trasportati con altri protocolli. Entrambi utilizzano certificati per identificare gli utenti; entrambi possono fornire segretezza ed autenticazione dei messaggi di posta; ad ogni modo, i formati di certificato sono molto diversi. Storicamente, la differenza tra la posta basata su PGP e quella basata su S/MIME e' stata lo stile di concatenamento del certificato. Nel S/MIME, gli utenti posseggono ceritificato X.509; il diagramma di certificazione e' un albero con un numero molto piccolo di radici. Al contrario, il PGP utilizza la cosiddetta "rete di fiducia" ("web of trust"), dove ciascun utente puo' firmare il certificato di chiunque altro. Questo diagramma di certificazione e' veramente un diagramma arbitrario od un insieme di diagrammi. Con qualsivoglia schema di certificato, la fiducia dipende da due caratteristiche fondamentali. Per prima cosa, essa deve iniziare da una fonte di affidabilita' nota, come un nodo X.509 o qualcuno siglato da chi lo verifica come altamente affidabile, spesso lui stesso. In secondo luogo, la catena di firme dev'essere affidabile. Difatti, ciascun nodo nello schema di certificazione e' cruciale; se esso non e' onesto o e' stato compromesso, ogni certificato che esso garantisce non puo' essere considerato affidabile. Tutti gli altri fattori sono uguali (e lo sono raramente), e sono preferibili catene piu' corte. Alcune delle differenze riflettono una tensione tra due posizioni filosofiche rappresentate da queste tecnologie. Altre sono il risultato di team di sviluppo separati. L'S/MIME e' stato concepito per essere "a prova di stupido". E' cosi' richiesta una configurazione minima per l'utente finale. Nello specifico, gli utenti finali non necessitano di porre attenzione ai rapporti di fiducia, ecc. L'idea e' che se un client S/MIME dice "Questa firma e' valida" l'utente dovrebbe poter "fidarsi" di tale dichiarazione senza aver bisogno di comprendere le implicazioni che stanno al di sotto. Per far questo, l'S/MIME e' generalmente basato su un limitato numero di Autorita' Certificanti (CA) dei nodi. L'obiettivo e' costruire un'infrastruttura globale di ceritificati affidabili. La nota dolente di questo approccio e' che esso richeide lo schieramento di una infrastruttura a chiave pubblica prima che possa funzionare. Due utenti finali potrebbero non essere in grado di ottenere con semplicita' del software S/MIME e iniziare cosi' a comunicare in sicurezza. Questo non e' un limite del protocollo, ma una tipica restrizione di configurazione per i piu' Bellovin, et al. Informational [Page 11] RFC 3631 Security Mechanisms for the Internet December 2003 comuni software disponibili. Uno di essi, o entrambi, potrebbe aver bisogno di ottenere un certificato da un CA affidabile per entrambi; in piu', tale CA dev'essere considerato sicuro dai loro software di gestione della posta. Questo processo puo' implicare costi e obbligazioni legali. Questo fa infine modo che la tecnologia prenda piede difficilmente, in particolar modo in un ambiente dove gli utenti finali non devono necessariamente apprezzare il valore ricevuto per le scocciature incontrate. L'approccio della "rete di affidabilita'" PGP ha il vantaggio che due utenti finali possono semplicemente ottenere il software PGP e iniziare immediatamente a comunicare in sicurezza. Non e' richiesta alcuna infrastruttura, nessuna parcella e nessun accordo legale da firmare, per poter procedere. Cosi' il PGP si appella alle persone che necessitano di stabilire associazioni di sicurezza ad-hoc. La nota dolente del PGP e' che esso richiede che gli utenti finali abbiano una conoscenza della tecnologia di sicurezza che sta sotto, in modo da farne un uso effettivo. Nello specifico, e' ragionevolmente semplice imbrogliare un utente ingenuo ad accettare un messaggio "firmato" che di fatto e' un falso. Fino ad oggi il PGP ha trovato grande accoglimento tra persone con cognizioni di sicurezza che hanno necessita' di posta sicura in un ambiente privo dell'infrastruttura globale necessaria. Per contro, l'S/MIME lavora bene in un ambiente corporativo nel quale puo' essere schierato all'interno un sistema CA sicuro. Esso non richiede agli utenti finali particolari conoscenze in ambito di sicurezza. L'S/MIME puo' anche essere utilizzato tra istituzioni impostando con attenzione certificati incrociati, sebbene questo sia piu' complesso da realizzare di quanto possa sembrare. Per questo motivo, la scrittura di un'infrastruttura globale di certificazione continua ad eluderci. Domande relative al modello di business appropriato, al pari di considerazioni sulla privacy, possono impedirle di affermarsi. 3.11. Firewalls e Topologia I firewalls sono un meccanismo di difesa topologica. Essi si affidano ad un confine ben definito tra cio' che e' affidabile all'"interno" e non affidabile all'"esterno" di un dato dominio, e mdiano il passaggio delle informazioni. Sebbene i firewall possono essere molto utili se propriamente impiegati, vi sono dei limiti alla loro capacita' di proteggere una rete. Il primo limite, ovviamente, e' che i firewall non possono proteggere da attacchi interni. Sebbene non sia noto l'attuale tasso di incidenza di tali attacchi (e non lo si puo' probabilmente conoscere), non vi e' dubbio che sia sostanziale, e che costituisca verosimilmente uno dei maggiori problemi legati alla sicurezza. In via piu' generica, dato che i firewalls richiedono la delineazione di un confine ben preciso, fino al punto in cui non esiste tale confine i firewalls non sono di alcun aiuto. Qualsiasi connessione Bellovin, et al. Informational [Page 12] RFC 3631 Security Mechanisms for the Internet December 2003 esterna, se si tratta di protocolli che deliberatamente passano attraverso il firewall, collegamenti che sono portati attraverso tunnel, LAN wireless non protette, o connessioni esterne dirette da host interni a livello di nome, indeboliscono la protezione. I firewalls tendono a diventare meno efficaci nel tempo qualora gli utenti si portino dietro protocolli in modalita' tunnel. Se i tunnel sono cifrati non vi e' modo per i firewall di bloccarli. Uno dei vantaggi spesso citato dei firewall e' quello di nascondere l'esistenza di host interni agli occhi di un esterno. Considerato ad ogni modo l'ammontare delle perdite, la probabilita' di nascondere le macchine con successo e' piuttosto bassa. In parole piu' sottili, i firewall colpiscono il modello end-to-end di Internet ed i suoi protocolli. Non tutti i protocolli possono difatti passare in modo sicuro o semplice attraverso un firewall. I siti che fanno affidamento sui firewall ai fini della sicurezza posono trovarsi tagliati fuori da nuovi ed utili aspetti di Internet. I firewall lavorano al meglio quando vengono impiegati come elemento di una struttura di sicurezza totale. Ad esempio un firewall restrittivo potrebbe venir utilizzato per separare un web server esposto da un database che sta dietro, aprendo soltanto il canale di comunicazione tra i due. In modo analogo, un firewall che consente soltanto tunnel di traffico cifrato potrebbe essere utilizzato per mettere in sicurezza una parte di una VPN. D'altro canto, in quel caso, l'altro capo della VPN avrebbe bisogno di essere messo in sicurezza allo stesso modo. 3.12. Kerberos Il Kerberos [RFC1510] fornisce a due entita' un meccanismo per autenticarsi a vicenda e scambiarsi keys. Sul lato client, un applicazione ottiene un "ticket" e un "autenticatore" Kerberos. Tali elementi, che dovrebbero essere considerati dati opachi, vengono poi comunicati dal client al server. Il server puo' quindi verificarne la loro autenticita'. Entrambi i lati possono dunque chiedere al software Kerberos di fornire loro una chiave di sessione che puo' essere utilizzata per proteggere o per cifrare dati. Il Kerberos da solo puo' essere utilizzato in un protocollo. Ad ogni modo e' anche disponibile come meccanismo sotto SASL e GSSAPI. Esso ha alcune vulnerabilita' note [KRBATTACK] [KRBLIM] [KRB4WEAK], ma puo' essere utilizzato in modo sicuro. 3.13. SSH (N.d.T.: Secure SHell) L'SSH fornisce una connessione sicura client e server. Esso opera in modo molto simile al TLS; e' tuttavia ottimizzato come protocollo per connessioni remote su dispositivi di tipo terminale. Una delle sue caratteristiche piu' innovative e' il supporto al "tunneling" per altri protocolli su connessioni TCP protette con SSH. Tale caratteristica ha permesso a coloro informati Bellovin, et al. Informational [Page 13] RFC 3631 Security Mechanisms for the Internet December 2003 sulla sicurezza di eseguire azioni come leggere ed inviare email o news per mezzo di server non sicuri su reti non sicure. Non e' un sostituto di una vera VPN, ma puo' essere spesso utilizzato al suo posto. 4. Meccanismi di Non Sicurezza Alcuni comuni meccanismi di sicurezza fanno parte del problema piuttosto che della soluzione. 4.1. Passwords in chiaro Le passwords in chiaro sono il piu' comune meccanismo di sicurezza in uso al giorno d'oggi. Sfortunatamente, sono anche il piu' vulnerabile. Quando non protette da un livello di crittografia, essere sono completamente non accettabili. Anche qualora usate insieme alla crittografia, le passwords in chiaro sono abbastanza vulnerabili, dal momento che devono essere trasmesse al sistema remoto. Se quel sistema e' stato compromesso o se il livello di crittografia non comprende autenticazione effettiva del server al client, un nemico puo' far collezione di passwords e verosimilmente utilizzarle contro altri obiettivi. Un'altra vulnerabilita' si presenta a causa di comuni tecniche di implementazione. E' considerata buona cosa [MT79] per l'host di memorizzare un hash a senso unico delle passwords d'utente, piuttosto che la loro forma in chiaro. Questo preclude tuttavia la migrazione verso meccanismi di autenticazione piu' forti, come la richiesta/risposta basata su HMAC. Il piu' potente attacco contro le passwords, oltre che l'intercettazione, e' quello di indovinare le password. Con un programma adatto ed un dizionario (e questi sono ampiamente disponibili), il 20-30% delle password possono essere indovinate in molti ambienti [Klein90]. 4.2. Autenticazione basata sull'Indirizzo Un altro meccanismo di sicurezza comune e' l'autenticazione basata sull'indirizzo. Nel migliore dei casi essa puo' lavorare in ambienti altamente ristretti. Se il vostro ambiente consiste in un piccolo numero di macchine, tutte strettamente amministrate, con sistemi di sicurezza utilizzati da utenti fidati, con la rete monitorata da un router che blocca percorsi di origine e previene lo spoofing dei vostri indirizzi sorgente, siete sicuri che non vi siano ponti wireless, e restringete l'autenticazione basata sugli indirizzi alle macchine di quella rete, siete probabilmente al sicuro. Ma queste condizioni si incontrano di rado. Bellovin, et al. Informational [Page 14] RFC 3631 Security Mechanisms for the Internet December 2003 Fra le minacce vi sono l'ARP-spoofing, l'abuso di proxy locali, la renumerazione, gli attacchi o la corruzione alla tabella di routing, lo spoofing di indirizzi IP e DHCP (con particolar rischio per i protocolli basati su UDP), i tentativi di indovinare i numeri di sequenza e i pacchetti provenienti dalla sorgente. Ognuna di queste e' piuttosto potente. 4.3. Autenticazione basata sul Nome L'autenticazione basata sul nome ha tutte le problematiche dell'autenticazione basata sull'indirizzo e ne aggiunge di nuove: attacchi al DNS [Bell95] e mancanza di mappatura uno ad uno tra indirizzi e nomi. Come minimo un processo che riconduce il nome di un host dal DNS dovrebbe ricondurne l'indirizzo e fare una verifica incrociata. Tecniche come la contaminazione della cache del DNS possono spesso negare tali verifiche. Il DNSSEC fornisce protezione contro questo genere di attacchi. Ad ogni modo, non fa nulla per aumentare l'affidabilita' degli indirizzi sottostanti. Questo meccanismo genera inoltre una serie di falsi allarmi. Tali lookups non forniscono ad una macchina informazioni affidabili, sebbene possano costituire un comodo tool di debug ed essere utili nei log quando si cerca di ricostruire il modo in cui e' avvenuto un attacco. 5. Considerazioni sulla Sicurezza Nessun meccanismo di sicurezza e' perfetto. Se non vi e' altro, qualsiasi meccanismo di sicurezza basato su rete puo' essere contrastato dalla compromissione dei punti finali della connessione. Ognuno dei meccanismi descritti in questo documento ha le sue limitazioni. Qualsiasi scelta d'adozione di un dato meccanismo dovrebbe soppesare tutte le possibili modalita' di raggiro. Queste dovrebbero a loro volta essere soppesate verso i rischi per il punto finale di un fallimento della sicurezza. 6. Considerazioni IANA Non vi sono considerazioni IANA in merito al presente documento. 7. Ringraziamenti Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful suggestions. Much of the substance comes from the participants in the IAB Security Architecture Workshop. Bellovin, et al. Informational [Page 15] RFC 3631 Security Mechanisms for the Internet December 2003 8. Riferimenti Informativi [Bell95] "Using the Domain Name System for System Break-Ins". Proc. Fifth Usenix Security Conference, 1995. [Bell98] "Cryptography and the Internet", S.M. Bellovin, in Proceedings of CRYPTO '98, August 1998. [DSS] "Digital Signature Standard". NIST. May 1994. FIPS 186. [Klein90] "Foiling the Cracker: A Survey of, and Implications to, Password Security". D. Klein. Usenix UNIX Security Workshop, August 1990. [KRBATTACK] "A Real-World Analysis of Kerberos Password Security". T. Wu. Network and Distributed System Security Symposium (NDSS '99). January 1999. [KRBLIM] "Limitations of the Kerberos Authentication System". Proceedings of the 1991 Winter USENIX Conference, 1991. [KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings of the Internet Society Network and Distributed Systems Security Symposium, March 1997. [MT79] "UNIX Password Security", R.H. Morris and K. Thompson, Communications of the ACM. November 1979. [NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. Bellovin, et al. Informational [Page 16] RFC 3631 Security Mechanisms for the Internet December 2003 [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One- Time Password System", STD 61, RFC 2289, February 1998. [RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. [RFC2385] Hefferman, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2744] Wray, J., "Generic Security Service API Version 2: C- bindings", RFC 2744, January 2000. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Bellovin, et al. Informational [Page 17] RFC 3631 Security Mechanisms for the Internet December 2003 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. [RSA] Rivest, R., Shamir, A. and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, February 1978. 9. Dichiarazione di Proprieta' Intellettuale (in lingua originale) The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Bellovin, et al. Informational [Page 18] RFC 3631 Security Mechanisms for the Internet December 2003 10. Informazioni sull'Autore Il presente documento e' una pubblicazione dell'Internet Architecture Board. I membri dell'Internet Architecture Board Members al momento della scrittura del presente documento erano: Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle, Chair Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael StJohns Internet Architecture Board EMail: iab@iab.org Steven M. Bellovin, Editor EMail: bellovin@acm.org Jeffrey I. Schiller, Editor EMail: jis@mit.edu Charlie Kaufman, Editor EMail: charliek@microsoft.com Bellovin, et al. Informational [Page 19] RFC 3631 Security Mechanisms for the Internet December 2003 11. Dichiarazione Completa di Copyright (in lingua originale) Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ringraziamenti Funding for the RFC Editor function is currently provided by the Internet Society. Bellovin, et al. Informational [Page 20]