Protocollo RADIUS
Per gestire il controllo degli accessi alla rete, nello scenario più generale previsto dall’architettura IEEE 802.1X, occorre prevedere l’implementazione di uno o più Authentication server.
Sia che si tratti di stabilire l’identità di chi richiede accesso tramite linee dial-up o del processo di autenticazione previsto per utilizzare le risorse radio condivise di Access Point wireless aziendali, la massima flessibilità può essere conseguita soltanto utilizzando un server dedicato alla valutazione delle credenziali e all’attribuzione puntuale dei privilegi su base utente.
Il server centrale, oltre ad assolvere al compito di verificare le credenziali, svolge normalmente anche funzioni di Authorization e Accounting (in accordo allo schema denominato AAA).
I vantaggi di avere una gestione degli accessi centralizzata sono molteplici.
La presenza di un server AAA centrale elimina la necessità di avere database di credenziali distribuiti su più dispositivi, che possono risultare tra loro inconsistenti.
Un altro importante beneficio, offerto da una procedura di autenticazione centralizzata, è la possibilità di controllare gli accessi a molteplici Authenticator secondo una Security Policy uniforme.
In questo modo si elimina la possibilità che un utente possa connettersi contemporaneamente a più dispositivi di rete, sfruttando un singolo account legittimo (controllo essenziale per evitare la sostituzione di identità o Identity Spoofing).
La soluzione standard, prevista per mettere in comunicazione gli Authenticator con i server AAA centrali, è il protocollo RADIUS.
Il protocollo utilizza la porta servizio 1812/udp per il servizio di Authentication/Authorization, e la porta 1813/udp per quello di Accounting.
Le porte 1645/udp e 1646/udp possono essere talvolta utilizzate, al posto delle precedenti, da alcuni dispositivi un po’ datati.
Il formato di un messaggio RADIUS prevede i seguenti campi:
- il campo Code (di 8 bit) per indicare il tipo cui si riferisce il messaggio RADIUS stesso.
Per regolare il processo di autenticazione sono definiti 4 tipi: Access-Request, Access-Challenge, Access-Accept, Access-Reject. - Il campo Identifier (di 8 bit) per semplificare il processo di associazione delle risposte alle Request pendenti.
- Il campo Length (di 16 bit) per indicare la lunghezza complessiva del messaggio RADIUS, compresa l’intestazione fissa.
- Il campo Authenticator (di 128 bit), utilizzato per verificare i messaggi RADIUS trasmessi e per evitare di trasmettere in chiaro eventuali password acquisite via PAP.
Segue un numero variabile di attributes (ciascuno di lunghezza variabile)attraverso i quali si trasmettono tutte le informazioni necessarie per supportare il processo di autenticazione.
Il numero di messaggi RADIUS scambiati dipende dallo schema di autenticazione adottato.
Nell’ipotesi di utilizzare un generico schema basato su meccanismo challenge/response (a supporto per esempio del CHAP o di EAP-MD5), i messaggi scambiati tra dispositivo di rete e server RADIUS sono mostrati nella FIGURA:
All’interno del messaggio Access Challenge il server RADIUS generalmente inserisce come sfida un numero casuale, che deve essere opportunamente trasformato, utilizzando una prestabilita funzione crittografica, dal software a bordo della stazione che agisce da Supplicant.
Non occorre che l’Authenticator sia reso partecipe della password condivisa tra utente e server RADIUS.
L’Authenticator è chiamato solo ad agire da intermediario nel passaggio di dati tra Supplicant e Authentication Server.
L’Authenticator possiede invece una chiave segreta da utilizzare nel processo per la verifica dell’autenticità di tutti i messaggi scambiati con il server RADIUS.
Una volta che la fase di autenticazione è completata con successo, l’Authenticator riceve dal server un insieme di parametri sulla base dei quali regolare l’accesso alla rete dell’utente.
Tali parametri sono in parte da passare al Supplicant a in parte da utilizzare localmente sul dispositivo di rete, al fine di configurare dinamicamente la porta entrata in stato controlled (assegnazione dinamica della VLAN, applcazione di ACL).
Anche se trova la sua naturale collocazione a supporto di uno schema di autenticazione robusta basato su EAP, il protocollo RADIUS può essere utilizzato anche nel caso di protocollo PAP.
In tal caso è necessario che il dispositivo di rete propaghi al server RADIUS la password (ricevuta in chiaro) dell’utente senza comprometterne la riservatezza.
Per questo è definito un attributo specifico denominato “User-password” (diverso da quello utilizzato in caso di adozione del CHAP, che è denominato CHAP-password).
Se le password utente venissero copiate all’interno dell’attributo User-password, senza alcuna trasformazione crittografica, sarebbe estremamente semplice per un attaccante acquisire credenziali valide tramite packet sniffing dei messaggi RADIUS trasmessi sulla rete IP.
Per evitare questo la RFC 2865 definisce un approccio standard da utilizzare per garantire la riservatezza di tale attributo.
La trasformazione è di seguito descritta.
Per prima cosa la password P viene segmentata in blocchi (p1 , p2 … pN) di 128 bit ciascuno.
Nel processo crittografico viene utilizzato KS, un segreto condiviso tra Authenticator e RADIUS server, e RA (valore pseudo random inserito nel campo Request Authenticator).
Usando questi due valori iniziali viene prodotto tramite digest MD5, b1 = HMD5(KS || RA).
Applicando alla funzione logica XOR p1 e b1 viene prodotto c1 = p1 XOR b1 che rappresenta il primo blocco in uscita.
Il blocco c1 serve anche per produrre b2 = HMD5(KS || c1). Il processo viene reiterato fino a processare ogni blocco pN in ingresso.
Il risultato finale, copiato nell’attributo User password, è la concatenazione di c1 || c2 … cN.
Lo schema precedente pur scongiurando l’invio di password utente in chiaro all’interno di messaggi RADIUS è stato duramente criticato dai crittoanalisti.
Due sono le principali limitazioni attribuite a RADIUS in tema di riservatezza dei dati trasmessi.
La prima critica nasce dal fatto che il protocollo originale prevede che solo per l’attributo User-password sia prevista la trasformazione crittografica descritta.
La seconda critica, in qualche modo ancor più rilevante, scaturisce invece dalla relativa debolezza dimostrata dal processo di offuscamento della password contro attacchi per forza bruta.
Ciò è dovuto dall’uso di una funzione di digest fissa (MD5) non modificabile e dal fatto che ogni blocco in uscita è ottenuto da una singola iterazione della funzione HMD5().
Il protocollo RADIUS inoltre non prevede nessun meccanismo per verificare l’autenticità dei messaggi spediti dall’Authenticator al RADIUS server.
E’ prevista solo la validazione delle risposte spedite dal server al dispositivo di rete. Nel processo è usato un segreto condiviso e la funzione di digest MD5.
Un Authenticator configurato per propagare le richieste di accesso utente è tenuto a inviare un numero casuale unico nella vita di ogni segreto condiviso al RADIUS server.
Il numero casuale viene indicato come Request Authenticator e deve essere esattamente pari a 128 bit.
Il server, ricevuta una Access-Request utilizza il Request Authenticator come input di una funzione di digest MD5 assieme al segreto condiviso.
Il risultato del digest viene usato come Response Authenticator.
Il dispositivo di rete che riceve la risposta del server può estrarre tale valore e verificarlo localmente.
Visto lo scarso livello di sicurezza assicurato dal RADIUS, il trasporto affidabile dei messaggi EAP è stato realizzato senza modificare le regole previste dallo standard.
Ciò è reso possibile dall’implementazione di una soluzione autonoma che consente di verificare e proteggere ogni singolo parametro EAP, indipendentemente dall’affidabilità della protezione offerta dal protocollo sottostante.
La soluzione si chiama EAP over RADIUS.
Per la verifica dell’integrità degli attributi EAP, ci si avvale di un meccanismo addizionale rispetto a quello descritto per il RADIUS.
Questo meccanismo prevede che possa essere validata anche la richiesta inviata al server AAA e non solo la risposta da questo generata.
In caso di messaggi EAP molto lunghi è previsto che ciascun messaggio venga frammentato in blocchi di lunghezza massima non superiore a 255 byte, ciascuno dei quali viene inserito in un attributo RADIUS.
Il messaggio EAP eventualmente frammentato può essere riassemblato a destinazione dal ricevente.
Ogni frammento EAP contenuto in un attributo RADIUS porta con sé un EAP Message Authenticator, generato usando la funzione HMAC-MD5 (128 byte).
L’autenticazione tramite server centrale richiede che le credenziali utente vengano spedite dall’Authenticator al server centrale responsabile della valutazione attraverso una rete IP.
Nel caso di RADIUS i messaggi devono essere contenuti in datagrammi UDP.
L’uso di tale protocollo di trasporto presenta due principali limitazioni.
La prima è che non si può trasmettere molti attributi in un solo datagramma UDP. Questa limitazione viene generalmente aggirata inviando i parametri in più messaggi consecutivi.
La seconda problematica è legata alla semplicità di condurre attacchi di tipo DoS (previo IP spoofing) contro servizi basati su UDP.
Anche se occorre conoscere la chiave condivisa per instaurare un canale di comunicazione bidirezionale con il server RADIUS, non occorre disporre di nessun segreto per tentare di bloccare un server, tramite invio di messaggi artefatti.
La soluzione più frequentemente adottata per scongiurare attacchi DoS contro i server RADIUS è limitare la loro raggiungibilità da parte dei soli indirizzi IP sorgente appartenenti ai dispositivi di rete che fungono da Authenticator.
In alternativa al protocollo RADIUS esistono soluzioni diverse, meno sensibili alle problematiche precedentemente descritte.
Tra quelle che hanno ricevuto maggiore interesse si può citare:
- il protocollo TACACS+ (soluzione proprietaria proposta da Cisco Systems, ma oramai in declino);
- l’emergente protocollo DIAMETER (soluzione che rappresenta sostanzialmente l’implementazione del RADIUS su TCP).
Il protocollo DIAMETER può essere utilizzato ogni qualvolta si ritiene necessario seguire un approccio statefull per l’accesso al servizio di autenticazione.
Esso non è esente da possibili attacchi DoS (per esempio SYN Flooding, come ogni altro generico servizio basato su TCP).
Le porte servizio associate ai due protocolli sono: 49/udp per il TACACS+, 3868/tcp per DIAMETER.
