In questa sezione viene descritto brevemente il protocollo TACACS+ e le sue principali funzionalità.
Per ulteriori dettagli è possibile consultare il Draft accessibile dalla sezione Riferimenti (cfr. Riferimenti - 1. Internet Draft) che contiene tutte le specifiche relative ad esso.
2.1 Introduzione
TACACS+ deriva da una serie di miglioramenti/estensioni apportate da Cisco System al protocollo TACACS e al successore XTACACS (cfr. Cap. 3).
In questo modo a seguito di
una completa riscrittura e riorganizzazione, quello che era un semplice e
poco potente protocollo di autenticazione, si e' trasformato in un potente
sistema di Autenticazione, Autorizzazione
ed Accounting con la possibilità di
fornire il controllo di accesso per i routers
(instradatori), per i server e per altri dispositivi di rete.
Queste sono alcune delle caratteristiche fondamentali del protocollo TACACS+:
Sicurezza
Tutte le transazioni TACACS+, siano esse di Autenticazione, Autorizzazione o Accounting, vengono cifrate con un algoritmo a chiave condivisa da 128 bit.
L'ID e il numero di sequenza della sessione vengono utilizzati per rendere protette e non replicabili le sessioni nei confronti di un eventuale intruso.
In pratica i dati (ossia il corpo del pacchetto) vengono cifrati nel seguente modo:
Dati cifrati = Dati XOR Pad
Pad è una stringa pseudo casuale ottenuta concatenando una serie di funzioni hash MD5 (ognuna lunga 16 bytes) e troncando il risultato alla lunghezza del testo da cifrare.
Più precisamente si ha:
Pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} troncato a lenght(dati)
La prima funzione hash viene generata concatenando l'id di sessione, la chiave segreta, il numero di versione e il numero di sequenza ed eseguendo sulla stringa risultante l'algoritmo MD5 di RSA Data Security, Inc. (cfr. Riferimenti - 4. Request for Comments):
MD5_1 = MD5{session_id, key, version, seq_no}
I dati sono tutti recuperabili dall'header del pacchetto tranne la chiave segreta che è condivisa tra il client e il daemon (cfr. Riferimenti - 1. Internet Draft).
Le restanti funzioni hash vengono generate nel seguente modo:
MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}
. . .
MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}
Il flusso di input utilizzato nella generazione di ogni singola funzione hash è lo stesso utilizzato per la prima (MD5_1) e l'unica differenza sta nell'aggiunta (concatenazione), alla fine di tale flusso, del valore hash calcolato al passo precedente.
TCP/IP
A differenza delle versioni
precedenti (TACACS/XTACACS), il protocollo TACACS+ non utilizza UDP come trasporto,
ma si avvale di connessioni TCP ereditandone
le caratteristiche di affidabilita'.
Autenticazione, Autorizzazione, Accounting
La seguente figura da una visione generale dell'ambiente basato sull'architettura AAA di Cisco (ma costituisce anche uno scenario generale), caratterizzato da un server AAA e da un NAS.
AAA-Based, Secure Network Access Scenario
Dopo che il client si sarà autenticato presso l'AAA Server potrà richiedere opportune autorizzazioni per usare determinati servizi.
Nel protocollo TACACS+, le fasi di autenticazione, autorizzazione e accounting vengono gestite separatamente. Questo permette di avere maggiore controllo e flessibilita' nella gestione di tutte le richieste.
L'autenticazione e' essenzialmente la fase nella quale viene accertata l'identita' di chi si sta autenticando.
Cio' puo' essere ottenuto attraverso una semplice coppia username/password o con sistemi piu' sofisticati quali Kerberos, OTP o CHAP.
Dopo essere stato autenticato, e' normale che l'utente richieda di poter utilizzare alcuni servizi. A seguito della richiesta di utilizzo di un servizio, il NAS richiede al server TACACS+ la relativa autorizzazione accludendo l'identita' (gia' accertata nella fase di autenticazione) dell'utente.
A questo punto, in base alle proprie policies, il server TACACS+ decide se concedere o meno l'autorizzazione e risponde di conseguenza.
Infine, il server TACACS+ viene informato dell'inizio e della fine del servizio attraverso delle richieste di accounting che includono anche i dati della sessione, quali data/ora di inizio, durata, bytes trasferiti etc.
Il protocollo prevede anche l'invio di dati di accounting periodici per informare il server dell'evolversi di una sessione.
2.2 L’header del pacchetto TACACS+
Tutti i pacchetti iniziano sempre con i seguenti 12 byte:
|
major version
|
minor version
|
type
|
seq_no
|
flags
|
|
session_id
|
|
length
|
Brevemente seguono i significati dei vari campi del record:
Major_version (4 bit): indica il numero di versione del protocollo;
Minor_version (4 bit): indica, se diverso da 0x1, eventuali revisioni effettuate alla versione originale indicata dal Major_version; ovviamente la nuova versione mantiene ugualmente la compatibilità con la versione di origine;
Type (8 bit): indica il tipo di pacchetto (di autorizzazione, autenticazione, o accounting);
Seq_no (8 bit): indica il numero di sequenza del pacchetto corrente (per l'attuale sessione); ogni pacchetto ha un numero pari a quello precedente più uno (il primo parte da 1); sia il client che il server incrementano tale valore ogni volta che si inviano reciprocamente i pacchetti;
Flags (8 bit): il I° indica se il testo del pacchetto deve essere cifrato o meno, il II° indica se il NAS supporta sessioni multiple su una singola connessione TCP;
Session_id (32 bit): indica l’id per la sessione corrente di TACACS+. Dovrebbe essere scelto casualmente e in modo appropriato dato che altrimenti potrebbe compromettere la sicurezza del protocollo. Inoltre il suo valore non può essere cambiato durante una sessione;
Lenght (32 bit): indica la lunghezza totale del pacchetto (header escluso).
2.3 Il corpo del pacchetto TACACS+
Ve ne sono di vari tipi e ogni tipo viene specificato nell’header del pacchetto. In ogni caso il corpo è protetto da un meccanismo di cifratura; i dati ed i messaggi non vengono terminati con "Null" e non viene effettuato padding in nessun campo, nè alla fine di un pacchetto (cfr. Riferimenti - 1. Internet Draft).
Per la cifratura dei dati il protocollo utilizza la funzione hash MD5.
Il corpo cifrato
Quando il corpo viene cifrato, una sola chiave segreta deve essere nota sia al client che al daemon, o più chiavi per ogni client/daemon che comunicano.
Successivamente, quando esso verrà decifrato, le lunghezze dei campi presenti al suo interno verranno sommate ed il risultato sarà confrontato con il valore nel campo Length memorizzato nell' header; per ogni verifica senza successo verrà scartato il pacchetto associato.
Viene effettuata con tre tipi di pacchetti: Start, Continue e Reply; i primi due sono sempre inviati dal client, il terzo dal daemon.
L’autenticazione inizia con l’invio del messaggio Start al daemon. Esso descrive il tipo di autenticazione da eseguire e può contenere l’username e qualche dato a riguardo.
In risposta il daemon invia un Reply per indicare se l’autenticazione è finita o deve continuare: solo in quest’ultimo caso il client invierà il messaggio Continue con le nuove richieste per il daemon.
Per esempio in meccanismi di autenticazione che utilizzano query Challange Response, saranno necessari più scambi di pacchetti.
Il corpo del pacchetto Start
|
action
|
priv_lvl
|
authen_type
|
service
|
|
user len
|
port len
|
rem_addr len
|
data len
|
| user ... |
| port ... |
| rem_addr ... |
| data ... |
I campi sono:
action (8 bit): descrive l’azione da eseguire (per es. LOGIN);
priv_lvl (8 bit): indica il livello di privilegio da 0-15 che è stato assegnato all’utente, determinando l'insieme delle operazioni che può eseguire in base alle politiche del server; vengono creati così dei domini di applicazione in cui ogni livello di privilegio inferiore è un sottoinsieme di ogni livello superiore;
authen_type (8 bit): indica il tipo di autenticazione che deve essere eseguito (ASCII, PAP, CHAP, ARAP, MS-CHAP (cfr. Riferimenti - 1. Internet Draft));
service (8 bit): indica il servizio che sta richiedendo l’autenticazione (Login, PPP, ARA, NASI, ecc.);
user (max 32 bit): contiene l’username;
port (max 32 bit): è una stringa ASCII che identifica la porta del client dalla quale si sta effettuando l'autenticazione;
rem_addr (max 32 bit): è una stringa ASCII che descrive la locazione remota dalla quale l’utente si è connesso al Client; questo campo è opzionale dato che l'informazione potrebbe non essere disponibile;
data (max 32 bit): è utilizzato per spedire dati appropriati in base all'azione (action) ed al tipo di autenticazione (authen_type) indicati (per es. una password);
Il corpo dell’autenticazione è determinato dai campi action e authen_type nel pacchetto Start, che determinano quale tipo di autenticazione eseguire ed in quale modalità (cfr. Riferimenti - 1. Internet Draft).
Il corpo del pacchetto di autenticazione Reply
|
status
|
flags
|
server_msg len
|
|
data len
|
server_msg ...
|
| data ... |
I campi sono:
status (8 bit): indica lo stato corrente dell’autenticazione (PASS per avvenuta autenticazione, FAIL per non avvenuta autenticazione, ERROR per condizioni di errore o altri valori che segnalano la continuazione dell'autenticazione perchè il server richiede più informazioni);
flags (8 bit): sono utili per indicare determinate azioni da compiere verso il client. Le funzioni dei flag attualmente definiti dal protocollo possono essere trovate sul Draft;
server_msg (16 bit): contiene un messaggio da visualizzare all’utente;
data (max 32 bit): contiene dati per il cambio di autenticazione;
Il corpo del pacchetto di autenticazione Continue
|
user_msg len
|
data len
|
|
flags
|
user_msg ... |
| data ... |
I campi sono:
user_msg (max 24bit): è una stringa immessa dall’utente o dal NAS per conto dell’utente; quando l'autenticazione richiede più scambi di pacchetti, il campo server_msg viene usato dal client per trasmettere al server le nuove informazioni richieste all'utente per completare l'autenticazione;
flags (8 bit): indicano al server determinate azioni da compiere. Le funzioni dei flag attualmente definiti dal protocollo possono essere trovate sul Draft;
data (max 32 bit): questo campo porta informazioni che sono specifiche all’azione (action) e al tipo di autenticazione (authen_type) per la sessione corrente;
"Aborto" di una sessione
Il client può terminare prima una sessione settando un opportuno flag nel messaggio Continue; in tal caso vi è la possibilità di spiegare la ragione della terminazione prematura inserendola nel campo dati.
In questo modo la sessione viene immediatamente terminata e non ci sarà più nessun messaggio di risposta da parte del server.
Inoltre vi sono tre possibili valori di stato di ritorno che possono essere usati nel pacchetto Reply per indicare la fine di una sessione. In tal caso è il server che la chiude (per es. utente non riconosciuto) e il campo server_msg può contenere un messaggio da visualizzare all’utente.
Il TACACS+ può eseguire in modo alternativo l’autenticazione con altri protocolli quali ad esempio Radius e Kerberos. In tal modo è garantita una forte flessibilità e compatibilità a tutto vantaggio dell'utente finale.
Comunque se non viene indicato nessun protocollo alternativo da utilizzare per l'autenticazione allora per default viene eseguita la modalità prevista dal protocollo.
Il TACACS+ può provvedere anche servizi di autorizzazione remoti. Una sessione di autorizzazione è definita come una singola coppia di messaggi: una Richiesta seguita da una Risposta.
Il messaggio di Richiesta contiene un set fissato di campi che descrivono l’autenticità dell’utente, ed un set variabile di argomenti che descrivono i servizi per i quali l’autorizzazione è richiesta.
Il messaggio Risposta contiene un set variabile di argomenti che restringono o modificano le azioni permesse al client.
Il corpo del pacchetto di autorizzazione Request
|
authen_method
|
priv_lvl
|
authen_type
|
authen_service
|
|
user len
|
port len
|
rem_addr len
|
arg_cnt
|
|
arg 1 len
|
arg 2 len
|
...
|
arg N len
|
| user ... |
| port ... |
| rem_addr ... |
| arg 1 ... |
| arg 2 ... |
| ... |
| arg N ... |
I campi sono:
authen_method (8 bit): indica il metodo di autenticazione usato dal client per acquisire le informazione dell’utente (Kerberos 5, Radius, ecc.);
priv_lvl (8 bit): indica il livello corrente di privilegio;
authen_type (8 bit): indica il tipo di autenticazione che è stato eseguito;
authen_service (8 bit): indica il servizio attraverso il quale l’utente è stato autenticato;
user (max 32 bit): contiene il nome dell’utente;
port (max 32 bit): corrisponde al campo port indicato nella sezione di autenticazione;
rem_addr (max 32 bit): corrisponde al campo rem_addr indicato nella sezione di autenticazione;
arg_cnt (8 bit): indica il numero di argomenti di autorizzazione contenuti nel pacchetto;
arg x (max 32 bit): una coppia valore-attributo che descrive il comando da eseguire; una descrizione dettagliata delle coppie valore-attributo (AVP) può essere trovata nel Draft relativo al protocollo (cfr. Riferimenti - 1. Internet Draft).
Il corpo del pacchetto di autorizzazione Response
|
status
|
arg_cnt
|
server_msg len
|
|
data len
|
arg 1 len
|
arg 2 len
|
|
...
|
arg N len
|
server_msg ...
|
| data ... |
| arg 1 ... |
| arg 2... |
| ... |
| arg N ... |
I campi sono:
status (8 bit): indica lo stato dell'autorizzazione (PASS_ADD, PASS_REPL, FAIL, ERROR, FOLLOW): in base al valore di tale campo viene permesso o negato all'utente di eseguire le azioni che ha richiesto e in caso di errore non viene eseguita nessuna operazione (per ulteriori dettagli cfr. Riferimenti - 1. Internet Draft);
arg x (max 32 bit): una coppia valore-attributo che descrive il comando da eseguire tenendo in considerazione il campo status (aggiunta/variazioni/cambio degli argomenti);
I restanti campi hanno un significato analogo a quelli con lo stesso nome descritti in precedenza.
L' Accounting è l’azione per memorizzare che cosa un utente sta facendo e\o ha fatto. In TACACS+ può servire per due scopi: tenere conto dei servizi usati, o fornire supporto per controlli di sicurezza. Per quest’ultimo scopo il TACACS+ supporta tre tipi di records: a) start record che indica quale tipo di servizio sta per iniziare; b) update record che fornisce informazioni sullo stato di esecuzione del servizio; c) stop record che indica quale servizio sta per terminare. Ovviamente l'accounting è un'operazione trasparente all'utente, ed è gestita automaticamente dal protocollo che provvede a informare opportunamente il server.
Il formato del pacchetto è molto simile a quello per l’autorizzazione: vi è una porzione fissata e una porzione estensibile; quest’ultima parte usa tutte le stesse coppie valore-attributo che usa l’autorizzazione, e ne aggiunge molte altre.
Il corpo del pacchetto di account Request
|
flags
|
authen_method
|
priv_lvl
|
authen_type
|
|
authen_service
|
user len
|
port len
|
rem_addr len
|
|
arg_cnt
|
arg 1 len
|
arg 2len
|
...
|
|
arg N len
|
user ... |
| port ... |
| rem_addr ... |
| arg 1 ... |
| arg 2... |
| ... |
| arg N ... |