RADIUS

RADIUS (Remote Authentication Dial-In User Service), in informatica e telecomunicazioni, è un protocollo AAA (authentication, authorization, accounting) utilizzato in applicazioni di accesso alle reti o di mobilità IP.

Sviluppato da Livingston Enterprises Inc., nel 1991, come server di accesso di autenticazione e come protocollo di accounting, riportato successivamente nelle norme Internet Engineering Task Force (IETF), il protocollo, dotato di un ampio supporto, è spesso utilizzato dagli ISP e dalle aziende per gestire l'accesso a Internet o reti interne, reti wireless e servizi integrati di posta elettronica. Queste reti possono incorporare modem, DSL, punti di accesso, VPN, porte di rete, server web, etc.

Viene eseguito nel livello di applicazione e può utilizzare il protocollo TCP o UDP. I server di accesso alla rete e i gateway che controllano l'accesso a una rete, di solito contengono un componente client RADIUS che comunica con il RADIUS server, che solitamente è un processo in background in esecuzione su un server UNIX o Microsoft Windows. Attualmente è lo standard de facto per l'autenticazione remota, prevalendo sia nei sistemi nuovi sia in quelli già esistenti ed è implementato in appositi server di autenticazione, in una comunicazione con un client che vuole autenticarsi (protocollo client-server).

RADIUS è un protocollo che utilizza pacchetti UDP per trasportare informazioni di autenticazione e configurazione tra l'autenticatore e il server RADIUS. L'autenticazione è basata su username, password e, opzionalmente, una risposta a una richiesta di riconoscimento (una sorta di “parola d'ordine”). Se l'autenticazione ha successo, il server RADIUS invia le informazioni di configurazione al client, inclusi i valori necessari a soddisfare il servizio richiesto, come un indirizzo IP e una maschera di sottorete per PPP o un numero di porta TCP per telnet.

Uno dei limiti del protocollo RADIUS è l'autenticazione basata esclusivamente su password: la password è trasmessa o in forma hash (utilizzando l'algoritmo di hashing MD5) oppure sotto forma di risposta a una richiesta di identificazione (CHAP-password). L'Extensible Authentication Protocol (EAP) rende RADIUS capace di lavorare con una varietà di schemi di autenticazione, inclusi chiave pubblica, Kerberos e smart card.

L'access point, ad esempio, agisce da traduttore EAP-RADIUS tra il client wireless e il RADIUS server, utilizzando il protocollo EAP per la comunicazione con il client e il protocollo RADIUS per la comunicazione con il server RADIUS. L'access point incapsula quindi le informazioni (come lo username o la chiave pubblica) in un pacchetto RADIUS che inoltra al server RADIUS. Quando il server rimanda una delle possibili risposte (Access-Accept/Reject/Challenge), l'access point spacchetta il pacchetto RADIUS e inoltra la risposta al client in un pacchetto EAP. La RFC 2869 (RADIUS Extensions) specifica gli attributi opzionali da impostare sui pacchetti RADIUS per indicare al server RADIUS che si sta utilizzando il protocollo EAP. Poiché il pacchetto EAP include un campo per specificare quale metodo di autenticazione è in uso, il server RADIUS implementa l'autenticazione richiamando un'apposita procedura.

Un pacchetto RADIUS è così formato (secondo la rispettiva RFC):

 0                   1                   2                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Code       |   Identifier  |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Authenticator                             |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Il codice stabilisce il tipo di pacchetto RADIUS. I codici sono:

• 1 = Access-Request
• 2 = Access-Accept
• 3 = Access-Reject
• 4 = Accounting-Request
• 5 = Accounting-Response
• 11 = Access-Challenge
• 12 = Status-Server (sperimentale)
• 13 = Status-Client (sperimentale)
• 255 = riservato

L’identificatore è un ottetto che permette al client RADIUS di associare una risposta RADIUS con la relativa richiesta. Il significato della stringa Authenticator, di 16 byte, verrà chiarito dopo. Nella sezione degli attributi, infine, è conservato un numero arbitrario di campi.

RADIUS è un protocollo AAA che gestisce l'accesso di rete nel seguente processo a due fasi, noto anche come una transazione AAA, sinonimo di autenticazione, autorizzazione e accounting. Autenticazione e autorizzazione sono descritte in RFC 2865, mentre l'accounting è descritto da RFC 2866.

L'intero processo ha inizio quando un client crea un pacchetto RADIUS 'Access-Request', includendo almeno gli attributi User-Name e User-Password, e generando il contenuto del campo identificatore. Il processo di generazione del campo identificatore non è specificato nel protocollo RADIUS, ma è solitamente implementato come un semplice contatore incrementato ad ogni richiesta.

Il campo authenticator contiene una Request-Authenticator, ovvero una stringa di 16 byte scelta in modo casuale. L'intero pacchetto è trasmesso in chiaro, a parte per l'attributo User-Password, che è protetto nel modo seguente: il client e il server condividono una chiave segreta. Tale chiave viene unita con la Request Authenticator, e l'intera stringa viene sottoposta a una funzione hash MD5 per la creazione di un valore di 16 ottetti, sottoposto a sua volta a un XOR con la password immessa dall'utente (e se tale password è più lunga di 16 ottetti, vi è un calcolo MD5 addizionale, utilizzando il testo cifrato anziché la Request Authenticator).

L'utente invia una richiesta a un Network Access Server (NAS) per ottenere l'accesso a una particolare risorsa di rete utilizzando le credenziali di accesso. Le credenziali vengono passate al dispositivo NAS tramite il protocollo del livello di collegamento (link-layer) per esempio nel caso di molti fornitori di dialup o DSL viene utilizzato il Point-to-Point Protocol (PPP), oppure viene pubblicato in forma web HTTPS.

A sua volta, il NAS invia un messaggio di richiesta di accesso al server RADIUS, richiedendo l'autorizzazione che consente l'accesso tramite il protocollo RADIUS.

Questa richiesta include le credenziali di accesso, in genere sotto forma di username e password o certificato di sicurezza fornito dall'utente. La richiesta inoltre, può contenere ulteriori informazioni che il NAS conosce riguardo l'utente, come ad esempio l'indirizzo di rete o il numero di telefono, e le informazioni riguardanti il punto fisico di collegamento dell'utente al NAS.

Il server verifica che le informazioni siano corrette utilizzando schemi di autenticazione come il PAP, CHAP o EAP. L'identificazione dell'utente è verificata, insieme, eventualmente, ad altre informazioni relative alla richiesta. Storicamente, il server controllava le informazioni dell'utente in un database memorizzato localmente, attualmente i server sono in grado inoltre di far riferimento a risorse esterne, come SQL, Kerberos, LDAP al fine di verificare le credenziali inviate dal client.

Il server riceve il pacchetto Access-Request e verifica di possedere la chiave segreta per il client. In caso negativo, il pacchetto viene silenziosamente ignorato. Poiché anche il server è in possesso del segreto condiviso, è possibile utilizzare una versione modificata del processo di protezione del client per ottenere la password in chiaro. Quindi il server RADIUS consulta il database per convalidare username e password e restituisce una delle tre seguenti risposte al NAS:

• Access Reject - All'utente viene negato l'accesso a tutte le risorse di rete richieste, ciò accade quando vengono forniti dati di autenticazione errati o se si cerca di utilizzare un account sconosciuto o inattivo.
• Access Challenge - Sollecita informazioni da parte dell'utente come una password, PIN o token. Access Challenge è utilizzato anche negli schemi di autenticazione più complessi in cui viene stabilita una connessione sicura tra la macchina utente e il server RADIUS in modo che le credenziali di accesso siano nascoste al NAS.
• Access Accept - Viene concesso l'accesso all'utente, una volta autenticato il server RADIUS verifica che il client sia autorizzato ad utilizzare il servizio di rete richiesto. Ad esempio può succedere che un utente sia autorizzato ad accedere alla rete wireless di un'azienda ma non al suo servizio VPN. Di nuovo queste informazioni possono essere salvate localmente su un server RADIUS oppure in una risorsa esterna come LDAP.

Ciascuna di queste tre risposte può includere un attributo Reply-Message che giustifica il tipo di messaggio di ritorno, il testo nell'attributo può essere trasmesso all'utente in una pagina web. Gli attributi di autorizzazione vengono inviati al NAS stabilendo le condizioni di accesso da concedere.

Ad esempio in un Access Accept possono essere inclusi i seguenti attributi di autorizzazione:

• L'indirizzo IP da assegnare all'utente
• Il tempo massimo in cui il client può rimanere connesso
• Una lista di accesso, priorità di coda o altre restrizioni sull'accesso
• Parametri L2TP
• Parametri VLAN
• Parametri Quality of Service (QoS)

Quando il client riceve un pacchetto di risposta, si accerta che esso combaci con una precedente richiesta utilizzando il campo identificatore. Se non esiste alcuna richiesta con lo stesso identificatore, la risposta è silenziosamente ignorata. Quindi il client verifica la Response Authenticator utilizzando lo stesso calcolo effettuato dal server, ed infine comparando il risultato con il campo Authenticator. Se la Response Authenticator non coincide, il pacchetto è silenziosamente ignorato.

Se il client riceve un pacchetto Access-Accept verificato, username e password sono considerati corretti, e l'utente è autenticato. Se invece riceve un pacchetto Access-Reject verificato, username e password non sono corretti e di conseguenza l'utente non è autenticato.

Quando l'accesso alla rete viene concesso all'utente da parte del NAS un Accounting Start (un pacchetto contenente un attributo Acct-Status-Type con il valore " start" ) viene inviato dal NAS al server RADIUS per segnalare l'inizio di accesso di rete dell'utente. Tipicamente i record "Start" contengono l'identificazione dell'utente, un indirizzo di rete e un unico session identifier.

Periodicamente, aggiornare i record intermedi (un pacchetto contenente un attributo Acct-Status-Type con il valore "interim - update") possono essere inviati dal NAS al server RADIUS, per aggiornarlo sullo stato di una sessione attiva. In genere questi record trasmettono la durata della sessione corrente e informazioni sull'utilizzo di dati corrente.

Infine, quando l'accesso alla rete è chiuso, il NAS emette un record finale di Accounting Stop (un pacchetto di richiesta contenente un attributo Acct-Status-Type con il valore " stop") al server RADIUS , che fornisce informazioni sull'uso finale in termini di tempo, i pacchetti trasmessi, i dati trasferiti e altre informazioni relative all'accesso di rete dell'utente.

In genere, il client invia pacchetti di tipo Accounting-Request fino a quando non riceve un ack Accounting-Response, utilizzando un certo intervallo di tentativi. Lo scopo principale di questi dati è che all'utente possono essere addebitati dei costi a seconda delle operazioni effettuate; il dato è anche comunemente usato per fini statistici e per il monitoraggio di rete generale.

Il protocollo RADIUS trasmette le password utilizzando l'algoritmo di hashing MD5, dato che questa particolare implementazione fornisce una debole protezione per le credenziali dell'utente, dovrebbe essere utilizzata un'ulteriore protezione, come ad esempio i tunnel IPsec o le reti data-center fisicamente protette, per proteggere il traffico RADIUS tra il dispositivo NAS e il server RADIUS. Inoltre, le credenziali dell'utente sono l'unica parte protetta da RADIUS stesso, sebbene altri attributi specifici per l'utente possono essere considerati sensibili (utile a un attacker) oppure allo stesso modo informazioni private (sufficienti per identificare il singolo utente). Il protocollo RadSec si occupa di risolvere i problemi di sicurezza sopracitati.

RADIUS è comunemente utilizzato per facilitare il roaming tra fornitori di servizi Internet, ad esempio:

• Da parte delle imprese che forniscono un unico insieme globale di credenziali che sono utilizzabili su molte reti pubbliche;
• Da parte di istituti che emettono le proprie credenziali ai propri utenti, che permettono ai visitatori di essere autenticati dal loro istituto di appartenenza, come ad esempio in Eduroam.

Radius facilita questo con l'uso dei reami, che identificano dove il server RADIUS deve inoltrare le richieste AAA per l'elaborazione.

Un reame è comunemente aggiunto allo user name di un utente e delimitato con il simbolo '@' che assomiglia ad un nome di dominio indirizzo di posta elettronica, questo è noto come notazione postfix per il reame. Un'altra opzione disponibile è la notazione prefix, in cui si antepone il reame al nome utente usando '\' come delimitatore. I server RADIUS moderni consentono di utilizzare qualsiasi carattere come segno delimitatore sebbene vengano utilizzati solitamente i simboli '@' e '\'.

I reami possono anche essere composti utilizzando sia la notazione prefix sia la postfix, per consentire scenari di roaming complicati; per esempio somedomain.com\username@anotherdomain.com potrebbe essere un valido username per due reami.

Sebbene i reami assomigliano spesso ai domini, è importante notare che i reami sono testo arbitrario e non devono contenere nomi di dominio reali. I formati di un reame sono standardizzati in RFC 4282, che definisce un Network Access Identifier (NAI) sotto forma di 'user@reame'. In tale specificazione, la porzione 'reame' è necessaria per essere un nome di dominio, tuttavia, questa pratica non è sempre seguita.

RFC 7542 sostituisce RFC 4282 in Maggio 2015.

Quando un server RADIUS riceve una richiesta AAA per uno user name contenente un reame, il Server riferirà una tabella di reami configurati. Se il reame è noto, il Server quindi delegherà la richiesta al Server principale configurato per il dominio. Il comportamento del Server proxy riguardo alla rimozione del reame dalla richiesta ("stripping") è dipendente dalla configurazione nella maggior parte dei Server. Inoltre, il server proxy può essere configurato per aggiungere, rimuovere o riscrivere richieste AAA quando vengono inoltrate nel tempo.

In RADIUS è possibile utilizzare il Proxy Chaining e i pacchetti di Autenticazione-Autorizzazione e Accounting vengono solitamente indirizzati tra un dispositivo NAS e un server di casa attraverso una serie di deleghe. Alcuni vantaggi nell'utilizzare catene Proxy includono miglioramenti di scalabilità, di procedure operative e modifiche di capacità, ma in scenari di roaming, il NAS, Proxy e Home Server potrebbero essere tipicamente gestiti da diverse entità amministrative; quindi, il fattore di fiducia tra le deleghe guadagna più importanza in tali applicazioni inter-dominio. Inoltre, l'assenza di sicurezza end-to-end in RADIUS aggiunge problemi di fiducia tra i Proxy coinvolti.

Proxy Chains sono spiegate in RFC 2607.

Il Roaming con RADIUS espone gli utenti a vari problemi di sicurezza e privacy. Più in generale, alcuni partner di roaming stabiliscono un canale di connessione sicuro tra i server RADIUS per garantire che le credenziali degli utenti non possano essere intercettate mentre vengono delegate nella rete Internet. Questo è un problema così come l'hash MD5 integrato in RADIUS è considerato insicuro.

RADIUS è un protocollo ampiamente utilizzato negli ambienti distribuiti. È comunemente usato per dispositivi di rete integrati come router, server modem, switch, ecc, per svariate ragioni:

• I sistemi integrati generalmente non riescono a gestire un gran numero di utenti con informazioni di autenticazione distinte, poiché questo richiederebbe molta più memoria di massa di quanta ne possiedano la maggior parte di essi.
• RADIUS facilita l'amministrazione utente centralizzata, che è importante per diverse applicazioni. Molti ISP hanno decine di migliaia, centinaia di migliaia o anche milioni di utenti, aggiunti e cancellati di continuo durante una giornata, e le informazioni di autenticazione cambiano costantemente. L'amministrazione centralizzata degli utenti è un requisito operativo.
• RADIUS fornisce alcuni livelli di protezione contro attacchi attivi e di sniffing. Altri protocolli di autenticazione remota offrono una protezione intermittente, inadeguata o addirittura inesistente.
• Un supporto RADIUS è quasi onnipresente. Altri protocolli di autenticazione remota non hanno un consistente supporto da parte dei fornitori di hardware, quando invece RADIUS è uniformemente supportato. Poiché le piattaforme sulle quali è implementato RADIUS sono spesso sistemi integrati, vi sono limitate possibilità di supportare protocolli addizionali. Qualsiasi cambiamento al protocollo RADIUS dovrebbe quantomeno avere una compatibilità minima con client e server RADIUS preesistenti (e non modificati).

Nonostante ciò, è stato messo a punto un nuovo protocollo, DIAMETER, candidato a rimpiazzare RADIUS: utilizza infatti TCP anziché UDP ed è di conseguenza considerato più sicuro ed affidabile.

RADIUS offre la possibilità di eseguire l'autenticazione di utenti remoti anche per particolari siti web che richiedono la protezione dall'accesso del pubblico generale. In particolare c'è un modulo che prevede l'integrazione con il server web Apache, ovviando all'uso dei file .htaccess e .htpasswd con le istruzioni Allow e Deny, che rende l'accesso alle risorse web protetto con le caratteristiche AAA viste precedentemente.

Il modulo è stato sviluppato per Apache e si chiama mod_auth_radius. In questo modo Apache diventa un client del server RADIUS, sostituendosi al NAS nell'usuale schema di autenticazione, e dando in out-sourcing la gestione dell'autorizzazione e dell'accounting.

Il protocollo RADIUS è definito in:

• RFC 2865 Remote Authentication Dial In User Service (RADIUS)
• RFC 2866 RADIUS Accounting

Altre RFC rilevanti sono:

• RFC 2548 Microsoft Vendor-specific RADIUS Attributes
• RFC 2607 Proxy Chaining and Policy Implementation in Roaming
• RFC 2618 RADIUS Authentication Client MIB
• RFC 2619 RADIUS Authentication Server MIB
• RFC 2620 RADIUS Accounting Client MIB
• RFC 2621 RADIUS Accounting Server MIB
• RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS
• RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support
• RFC 2868 RADIUS Attributes for Tunnel Protocol Support
• RFC 2869 RADIUS Extensions
• RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices
• RFC 3162 RADIUS and IPv6
• RFC 3575 IANA Considerations for RADIUS
• RFC 3576 Dynamic Authorization Extensions to RADIUS
• RFC 3579 RADIUS Support for EAP
• RFC 3580 IEEE 802.1X RADIUS Usage Guidelines
• RFC 4014 RADIUS Attributes Suboption for the DHCP Relay Agent Information Option

• DIAMETER
• protocollo AAA

• Wikimedia Commons contiene immagini o altri file su RADIUS

• (EN) An Analysis of the RADIUS Authentication Protocol, su untruth.org.
• (EN) List of RADIUS attributes, su freeradius.org.
• (EN) The History of the RADIUS Server, su interlinknetworks.com.

Controllo di autorità	LCCN (EN) sh2003003477 · GND (DE) 4708071-1 · J9U (EN, HE) 987007544665705171