Sommaire. 1
Introduction. 2
Protocoles d'authentification. 3
Authentication. 3
Authorization. 3
Accounting. 3
Le protocole TACACS+ (Terminal Access
Controller Access Control System) 5
Session. 5
Authentification avec TACACS+. 5
Autorisation avec TACACS+. 6
Accounting avec TACACS+. 6
Les attributs de TACACS+. 6
Le protocole RADIUS (Remote Access Dial-In
User Service) 8
Authentification avec RADIUS. 8
Autorisation avec RADIUS. 9
Accounting avec RADIUS. 9
Les attributs de RADIUS. 10
Comparaison entre TACACS+ et RADIUS.
11
TACACS+. 11
L'authentification est un besoin bien défini aujourd'hui. Mais en parallèle
de cette authentification, vient se greffer l'autorisation. Enfin, la notion
d'accounting peut se rajouter aux deux précédentes.
Ce sont les AAA ou triple A.
Les serveurs d'authentifications tels que Cisco Secure Access Control Server
proposent ces AAA. Ils sont basés sur des protocoles d'authentification tels
que TACACS+ ou RADIUS.
Ce document a pour but de présenter et d'expliquer ces deux protocoles.
Un protocole d’authentification est un moyen de contrôle d’accès.
Il comprend les trois A (AAA) :
·
Authentication (authentification)
·
Authorization (autorisation)
·
Accounting (rapports)
Cela correspond à l’identification de l’utilisateur, que ce soit
une personne physique ou un service. Cette identification passe par la présentation
de l’identité de l’utilisateur. Cette information est unique à chaque utilisateur
et non secrète. Elle sert de référence dans la base des utilisateurs.
Le contrôle de cette information consiste à vérifier un secret partagé entre
l’utilisateur et le serveur d’authentification. Elle peut être de plusieurs
types :
statique : l’information transmise est alors la même lors d’authentifications
successives : mot de passe type UNIX par exemple.
Dynamique : on passe alors par un challenge entre le serveur et
l’utilisateur, ce qui permet d’avoir une information différente à chaque nouvelle
authentification : calculette, carte à puce, badge...
Physique : reconnaissance vocale, empreintes, iris...
C’est le fait de déterminer quels sont les droits de l’utilisateur.
Par exemple, après s’être loggué, l’utilisateur peut essayer d’utiliser certaines
commandes. L’autorisation détermine alors si l’utilisateur peut ou non les utiliser.
Dans certaines implémentations, l’identification et l’autorisation sont regroupés
en une seule étape.
Cela consiste à mesurer les ressources qu’un utilisateur consomme,
en terme d’échange réseau, de ressources système,... Cela sert en fait à logguer
un certain nombre d’informations sur l’utilisateur. Cela permet de connaître
à la fois les services demandés par l’utilisateur et la quantité de ressources
requises.
Les trois points définis ci-dessus sont importants pour une bonne
gestion et une bonne sécurité d’un réseau. Ils devraient être disponibles au
point d’entrée d’un réseau.
Tous les utilisateurs distants accèdent au réseau au travers d’un NAS (Network
Access Server), aussi appelé Remote Access Server, ou Terminal Server. Un NAS
est une interface qui accepte un accès distant à travers une ligne téléphonique
ou RNIS. Le NAS connecte les utilisateurs distants au réseau interne (Local
Area Network).
Après s’être connecté, l’utilisateur distant a accès à toutes les ressources
du réseau interne (serveurs, partages, communication avec les autres utilisateurs,
...)
La mise en place des AAA au point d’entrée du réseau garantit un
contrôle sur les connexions des utilisateurs au réseau, ainsi que sur ce qu’ils
sont autorisés ou non à faire.
TACACS+ est la dernière version du protocole TACACS développé à
l’origine par BBN, puis repris par Cisco qui va l’étendre une première fois
par XTACACS (eXtended TACACS) compatible avec TACACS, puis par TACACS+. Mais
cette dernière version n’est plus compatible avec les versions originelles,
bien que basée sur celles-ci.
TACACS+ utilise TCP pour son transport (contrairement à TACACS qui était basé
sur l’UDP). Il utilise le port 49 (login). Il gère séparément les trois fonctions
AAA (authentification, autorisation, accounting), contrairement à d’autres protocoles
d’authentification.
TACACS+ prévoit une implémentation pour chacune des trois, mais une configuration
n'exige pas de toutes les utiliser
TACACS+ utilise la notion de session pour ses communications entre
le client (NAS) et le serveur. Une session ne contient qu’un échange, ou d’authentification,
ou d’autorisation, ou d’accounting. TACACS+ peut utiliser l’identifiant des
sessions pour chiffrer les paquets.
Si le client et le serveur le supportent, plusieurs sessions peuvent être réalisées
sur la même connexion TCP. Mais, pour des raisons de compatibilité, ce dispositif
est à éviter, et il vaut mieux rouvrir une nouvelle connexion pour chaque session.
TACACS+ peut aussi bien utiliser des techniques d’authentification
classiques type login/mot de passe statique, ou bien des procédés plus évolués
à base de challenge avec authentification réciproque, par exemple.
Lors d’une nouvelle connexion, le NAS émet un message START au serveur décrivant
le type d’authentification à utiliser. En retour, le démon envoie un message
REPLY. Ce type de message peut indiquer ou bien que l’authentification est terminée,
ou bien qu’elle doit continuer, auquel cas, le client récupère l’information
manquante et la retourne dans un message CONTINUE.
Le type de requête provenant du serveur peut être une demande GETDATA, GETUSER
ou GETPASS. GETDATA est une requête générique de récupération d’information
du profil utilisateur.
Lors d’un accès à un service particulier, le NAS ouvre une session
d’autorisation. Cette session consiste juste en l’échange d’une paire de messages :
REQUEST/RESPONSE. La requête décrit l’authentification pour l’utilisateur ou
le processus qui demande l’accès au service.
La réponse du serveur contient un ensemble d’attributs pouvant restreindre
ou modifier les actions du client, plutôt qu’une simple réponse affirmative
de type oui/non.
Les échanges utilisés lors de l’accounting sont similaires à ceux
employés lors de l’autorisation (REQUEST/RESPONSE).
Au démarrage et à la terminaison d’un service, on émet un paquet START et STOP.
De plus, le protocole TACACS+ propose l’émission de paquets UPDATE servant
à confirmer qu’un service est en cours d’utilisation.
On peut retrouver les spécifications du fonctionnement du protocole TACACS+
dans le draft draft-grant-tacacs-02.txt
Les serveurs d'authentification supportent les paires "attribut-valeur"
(AV pair) de TACACS+. Ce sont des couples 'attribut'='valeur' qui permettent
de définir tous les paramètres d'autorisation que l'on désire mettre en œuvre.
Le but de TACACS+ est de fournir une méthodologie permettant de gérer les différents
points d'accès distants depuis un simple ensemble de services de gestion. La
famille de serveurs d'accès et de routeurs de Cisco peuvent être des points
d'accès distants.
Les points d'accès distants permettent aux terminaux basiques, aux émulateurs
de terminaux, aux stations de travail, aux PCs et aux routeurs, de communiquer
en utilisant des protocoles sur les lignes séries comme le PPP (Point-to-Point
Protocol), le SLIP (Serial Line Internet Protocol), le CSLIP (Compressed SLIP)
ou l'ARAP (AppleTalk Remote Access Protocol). En d'autres termes, un point d'accès
distant fournit des connexions à un simple utilisateur, vers un réseau. Les
entités connectées par l'intermédiaire d'un point d'accès distant sont appelées
clients distants (network access clients).
Les services de sécurité réseau AAA accomplissent les fonctions suivantes :
·
Authentification – Fournit un contrôle complet de l'authentification
à travers un échange de login et mot de passe, un challenge et une réponse,
un support de transmission de messages, et un système de chiffrement utilisant
l'algorithme MD5 (Message Digest 5).
Le mécanisme d'authentification donne la possibilité, après la transaction
du login et du mot de passe, de vérifier son identité en lui posant un certain
nombre de questions, par exemple son adresse postale ou le nom de jeune fille
de sa mère… L'administrateur TACACS+ peut augmenter l'intégrité de l'authentification
en changeant régulièrement ces questions (challenge). Le service d'authentification
TACACS+ est assez flexible pour pouvoir envoyer des messages sur l'écran de
l'utilisateur. Par exemple, un message peut prévenir les utilisateurs qu'ils
doivent changer leur mot de passe à cause de la politique de gestion de leur
durée de vie.
·
Autorisation – Fournit un contrôle d'accès distant incluant une
seule autorisation globale ou bien une autorisation pour chaque service, un
support pour les groupes d'utilisateurs et un support pour IP, IPX, ARA et telnet.
En plus de cela, on peut créer des permissions et des restrictions d'accès ou
de commandes.
Pour de plus grands niveaux de contrôles sur les actions des utilisateurs après
qu'ils se soient authentifiés, la composante d'autorisation de TACACS+ permet
de créer différents groupes basés sur les fonctionnalités des utilisateurs.
Avec l'autorisation TACACS+, un administrateur réseau peut limiter un utilisateur
à un nombre restreint de fonctions sur l'interface utilisateur d'un routeur
(autocommands).
·
Accounting – Rassemble et envoie les informations regroupant les
actions des utilisateurs.
Les administrateurs réseau peuvent utiliser cette fonctionnalité pour tracer
l'activité d'un utilisateur pour un audit de sécurité ou simplement pour des
statistiques.
Un rapport peut être réalisé pour fournir différentes informations comme l'identité
de l'utilisateur, les heures de début et de fin de sessions, les commandes exécutées
(comme PPP), les nombres de paquets et les nombres d'octets échangés.
Le protocole RADIUS (Remote Authentication Dial In User Service)
a été créé par Livingston et normalisé par l’IETF (Internet Engineering Task
Force) sous la forme de RFC (Request For Comments). Actuellement il s’agit des
RFC 2138 et 2139.
Tous les clients RADIUS communiquent généralement à travers le réseau local
sur un serveur unique, ce qui rend la tâche de l’administrateur plus simple.
La gestion des utilisateurs et de leurs droits est alors plus facile par rapport
à plusieurs serveurs qu’il faudrait mettre à jour simultanément sur le réseau.
Le standard RADIUS est basé sur un ensemble d’attributs relatifs aux utilisateurs.
Ils sont tous stockés dans la base RADIUS du serveur. Au cours d’une connexion,
un échange d’information a lieu entre le serveur et le client (NAS). Le standard
RADIUS propose un certain nombre d’attributs qui doivent être mis en œuvre.
Mais beaucoup d’implémentations spécifiques du protocole apportent leur propre
jeu d’attributs.
Le protocole RADIUS permet une authentification utilisateur/mot de passe
ou utilisateur/challenge/réponse ou les deux, qui peut être configurée spécifiquement
pour chaque utilisateur. La vérification est réalisée par le serveur RADIUS,
qui retourne alors un “authentication reply” au NAS qui a émis la requête.
L’autorisation, elle, est réalisée par le NAS, en utilisant les informations
sur l’utilisateur retournées par le serveur.
Le protocole RADIUS est basé sur un échange de paquets utilisant
le protocole UDP. Le port généralement employé est le 1645, bien qu’il devrait
être normalement configuré sur le port 1812 pour éviter des conflits avec le
service Datametrics. Il existe 4 types de paquets différents :
·
“Access-Request”
·
“Access-Accept”
·
“Access-Reject”
·
“Access-Challenge”
Afin de se connecter au NAS, le client RADIUS récupère d’abord
toutes les informations nécessaires (login, mot de passe). La méthode de récupération
de ces informations dépend de la configuration du client. Il peut s’agir directement
d’un prompt invitant l’utilisateur à entrer ces informations, ou bien d’utiliser
les valeurs transmises par le protocole de communication (ex : PPP).
A la suite de cela, le client RADIUS crée un paquet de type “Access-Request”
contenant les informations dont le serveur RADIUS a besoin (nom, mot de passe,
ID du client, ID du port). Si un mot de passe est présent, il sera chiffré en
utilisant MD5.
Une fois que le serveur reçoit la requête, il vérifie d’abord que le client
partage un secret avec lui, puis récupère les informations concernant l’utilisateur.
Celles-ci sont extraites d’une base de données qui peut être locale au serveur
RADIUS, ou bien appartenir à un autre serveur du réseau (dans ce cas, le serveur
RADIUS jouera lui-même le rôle de client). Si un mot de passe doit être communiqué,
il sera vérifié par le serveur.
D’autres vérifications peuvent être effectuées sur l’ID du client ou du port
selon le contenu de la base concernant l’utilisateur.
Dans le cas où l’une des conditions ne seraient pas remplies, le serveur retourne
un paquet “Access-Reject” qui indiquerait au client que la connexion a été refusée
et pourrait contenir un message d’explication. Sinon, le serveur retourne un
“Access-Challenge”. Le paquet contient un nombre aléatoire que le client doit
chiffrer. Pour cela, il peut utiliser une calculette, ou un logiciel permettant
de faciliter le calcul de la réponse.
En retour, le client émet de nouveau le paquet “Access-Request” mais contenant
cette fois la réponse au challenge. Le serveur peut alors renvoyer :
·
un “Access-Accept” si l’authentification est validée
·
un “Access-Reject” dans le cas contraire
·
un “Access-Challenge” si un complément d’information est nécessaire
Lors de l’ “Access-Accept”, le serveur ajoute, dans le paquet,
une liste de valeurs correspondant aux paramètres de l’utilisateur. Elles sont
utilisées par le NAS qui réalise la phase d’autorisation.
Si elles sont valides, l’utilisateur est alors connecté. Suivant la configuration
du Network Access Server, elle peut ne pas être réalisée, auquel cas, aucune
autorisation ne sera effectuée.
Au démarrage d’un service, le NAS émet un paquet “Accounting-Start”
au serveur RADIUS. Le NAS centralise les informations, puis les envoie au serveur
au moment de la fermeture du service dans un paquet “Accounting Stop” (quantité
transmise, débit, bande passante, temps d’émission, ...).
Tout comme TACACS+, RADIUS (Remote Dial-In User Service) fonctionne
à l'aide des AV-pairs.
Contrairement à TACACS+, RADIUS intègre, dans son implémentation, une notion
de type de donnée.
| |
TACACS+
|
RADIUS
|
|
Protocole
|
TCP : port 49
|
UDP : port 1645
(1812 normalement)
|
|
Chiffrement
|
Chiffrement du paquet entier
|
Chiffrement du mot de passe
|
|
Architecture AAA
|
Les AAA sont indépendants
|
Autorisation
liée à l’authentification
|
|
Emission du profile
|
Profil émis champs par champs
à la demande du NAS
|
Profil global envoyé au NAS lors
de la fin de l’authentification
|
|
Protocoles supportés
|
Support complet
|
Pas de ARA
ni de NetBEUI
|
|
Challenge / Réponse
|
Bidirectionnel
|
Unidirectionnel
|