Protocole AAA Principes et implantations

Transcription

1 Gwenael BLUM Florian LASOWY Cyril GUERIN Cédric PFEIFFER Protocole AAA Principes et implantations Encadrante ESIAL : Isabelle CHRISMENT

2 SOMMAIRE Introduction ) Les protocoles AAA ) Concepts ) RADIUS ) Description ) Format des paquets ) Diagramme de séquence ) DIAMETER ) Description ) Format des paquets ) Diagramme de séquence ) Exemple d une application Mobile IPv6 pour Diameter ) Différences entre RADIUS et DIAMETER ) Mise en œuvre d un FAI utilisant RADIUS...16 Introduction ) PPPoE ) Radius ) Scénarios...22 Conclusion...26 Références

3 Introduction L accès à l Internet se fait traditionnellement depuis le domicile, l université, le bureau, ou les salles de conférence. Dans chacun de ces cas, la station d accès est un équipement fixe ou éventuellement mobile dans une faible mesure (inférieur à 100 mètres pour l Ethernet sans fil). Avec le déploiement des mobiles, il est devenu nécessaire de développer des protocoles permettant à des utilisateurs de se déplacer de réseau en réseau. Nous présenterons les protocoles AAA (Authentication, Authorization, Accounting) qui permettent aux opérateurs d authentifier des utilisateurs, de leur autoriser certains services et de collecter des informations sur l utilisation des ressources. Nous verrons en particulier que Diameter est actuellement le protocole le plus à même de satisfaire les nouveaux besoins suscités par la mobilité. En particulier, il permet aux opérateurs d authentifier un utilisateur ayant souscrit un abonnement auprès d un autre opérateur. 2

4 1) Les protocoles AAA 1.1) Concepts AAA signifie Authentication, Authorization, Accounting, soit authentification, autorisation et compte. La signification de ces termes est la suivante : Authentification : l authentification consiste à vérifier qu une personne/équipement est bien celle qu elle prétend être. Ceci est généralement réalisé en utilisant un secret partagé entre l utilisateur et le serveur mère AAAH ou à l aide de certificats (e.g X.509). Autorisation : l autorisation consiste à permettre l accès à certains services ou ressources. Un utilisateur peut par exemple demander à avoir une certaine bande passante. Le serveur AAA lui autorisera ou non cette demande. Compte : le serveur AAA a la possibilité de collecter des informations sur l utilisation des ressources. Ceci permet à un opérateur de facturer un utilisateur suivant sa consommation. En pratique, une architecture client-serveur AAA permet de rendre l ensemble de ces services. Les serveurs AAA dans les domaines mère et visité permettent de gérer les utilisateurs. Les clients AAA sont hébergés sur des routeurs ou sur des serveurs d accès au réseau. Les protocoles implémentant du AAA sont essentiellement utilisés par des opérateurs offrant des services de télécommunications à des utilisateurs. Ces protocoles leur permettent de contrôler l accès à leurs réseaux et de connaître l utilisation de leurs ressources. Ils peuvent ainsi facturer selon le temps de connexion ou selon la quantité d informations téléchargées. Ci-dessous un schéma représentant l architecture AAA la plus commune : Fig.1 Architecture AAA 3

5 1.2) RADIUS 1.2.1) Description Le protocole RADIUS est actuellement utilisé pour faire du AAA avec des utilisateurs se connectant via des modems téléphoniques à Internet. L utilisateur utilise PPP pour accéder à un FAI via un serveur d accès. Il envoie des informations permettant de l authentifier (typiquement login/password) au serveur d accès. Celuici les envoie alors à un serveur RADIUS qui se charge de l authentifier. Si l utilisateur est correctement authentifié, le serveur RADIUS lui permet l accès à Internet. RADIUS a été conçu pour supporter un nombre limité d équipements et donc un nombre limité d utilisateurs. Actuellement, les opérateurs doivent pouvoir rendre des services et authentifier des milliers d utilisateurs utilisant des technologies différentes. Ils doivent aussi être capables de rendre des services à des utilisateurs venant d opérateurs différents, de préférence de façon sécurisée. Or RADIUS ne gère pas explicitement les communications inter-domaine ) Format des paquets Les données sont échangées entre un client et le serveur en paquets RADIUS. En fait, un paquet RADIUS est encapsulé dans un paquet UDP. Chaque paquet contient les informations suivantes : Fig. 2: Format d un paquet RADIUS Les champs d un paquet RADIUS sont les suivants : Code - octet contenant la requête/réponse RADIUS Identifier - octet utilisé pour comparer la requête et la réponse. Length longueur du paquet (2 octets). Authenticator - Valeur utilisée pour authentifier la réponse du serveur RADIUS, et utilisée dans l algorithme de masquage du password. Attributes les données appartenant à la requête ou à la réponse. 4

6 La communication RADIUS utilise le paradigme de requête-réponse, les requêtes sont envoyées par le client au serveur, et les réponses sont envoyées par le serveur au client. Les paires requête-réponse possibles sont: access-request, (client->serveur), requête d accès par un utilisateur pour certains services. Les réponses possibles à cette commande sont: o access-accept, (serveur->client), réponse positive à une requête d accès d un client. o access-reject, (serveur->client), réponse négative à une requête d accès d un client. o access-challenge, (serveur->client), réponse à une requête d accès, où le serveur attend une réponse du client encapsulée dans une accessrequest. accounting request, (client->serveur), requête pour enregistrer les données de comptabilité sur le serveur. La réponse à cette commande est: o accounting response, (serveur->client), réponse vers le client lorsque les données de comptabilité ont bien été stockées sur le serveur. 5

7 1.2.3) Diagramme de séquence Ci-dessous un schéma d un diagramme de séquence lorsqu un utilisateur accède au réseau à travers un NAS (Network Access Server) et se déconnecte lui-même. Fig. 3: Flux de messages RADIUS. 1. Le NAS récupère le login/password d un utilisateur à distance, crypte ces informations avec une clé partagée et envoie cela avec une access-request à un serveur (phase Authentification). 2. Lorsque la combinaison login/password est valide, alors le serveur RADIUS envoie un message accept-accept avec des informations supplémentaires (par exemple : adresse IP, masque de réseau, etc.) au NAS (phase Autorisation). 3. Le NAS envoie un message accounting-request (start) pour indiquer que l utilisateur est connecté sur le réseau (phase Comptabilité ). 4. Le serveur RADIUS répond avec un message Accounting-response lorsque l information de comptabilité est stockée. 5. Lorsqu un utilisateur se déconnectera, le NAS va envoyer un message Accounting-request (Stop) avec les informations suivantes : o o o Delay time, le temps d essai d envoi de ce message. Input octets, le nombre d octets reçus par le client. Output octets, le nombre d octets envoyés par le client. 6

8 o o o o Session time, le nombre de secondes que le client s est connecté. Input packets, le nombre de paquets reçus par le client. Output packets, le nombre de paquets envoyés par le client. Reason, la raison pour laquelle le client s est déconnecté. 6. Le serveur RADIUS répond avec un message accounting-response lorsque l information de comptabilité est stockée. 1.3) DIAMETER 1.3.1) Description Diameter est un protocole permettant à des domaines administratifs différents de collaborer pour réaliser les fonctionnalités AAA. Il est constitué d un protocole de base qui définit le format des messages, comment ils sont transportés, les messages d erreurs ainsi que les services de sécurité que toutes les implémentations doivent supporter. À ce protocole de base s ajoutent les applications : Mobile IP, NAS et CMS. L application Diameter Mobile IPv4 permet de faire du AAA avec un utilisateur utilisant Mobile IPv4 ; l application Diameter NAS permet l accès au réseau via PPP/EAP, il s agit de l amélioration de RADIUS ; l application Diameter CMS permet de protéger les échanges Diameter au niveau applicatif entre serveurs ou entre un serveur et son client. Diameter a été conçu dans l idée d être facilement extensible. Pour cette raison, le protocole de base est séparé de ses applications. 7

9 1.3.2) Format des paquets Les données sont échangées entre client et serveur en paquets DIAMETER. En fait, un paquet est encapsulé dans le champ de données UDP. Chaque paquet contient les informations suivantes : Fig. 4: Format d un paquet DIAMETER. Radius PCC (1 octet), pour une compatibilité avec RADIUS, doit être positionné à 254 qui signifie paquet DIAMETER Flags (3 bits), utilisé pour identifier les options A (1 bit), le package est seulement un acquittement, et ne contient pas de requêtes. W (1 bit), positionné si les champs NS et NR sont présents (utilisé lorsque UDP est le protocole de transport). Version (3 bits), indique la version, doit être positionné à 1. Packet length (2 octets), longueur totale du paquet. Identifier (4 octets), numéro de séquence utilise pour faire correspondre les requêtes et leurs réponses. NS (2 octets), Next Send NR (2 octets), Next Received o AVP code (4 octets), commande DIAMETER (256) o AVP length (2 octets), longueur du AVP o Cmd flags (6 bits), peut être utilisé comme commande spécifique, sinon positionné à 0. o Reserved (6 bits) o Flag T (1 bit), Tag bit, utilisé pour grouper les AVPs 8

10 o o o o o o Flag V (1 bit), Vendor-specific bit, indique si le champ optionnel vendredi field est présent. Flag H (1 bit), Hop bit, indique que le AVP est crypté avec le cryptage Hop-by-hop. Flag M (1 bit), Mandatory bit, indique si le support AVP est requis. Vendor id (4 octets, optional), Tag (4 octets, optional), Command code, contient l id de la commande DIAMETER diameter attributes (AVP's) Commandes DIAMETER: Message-Reject-Ind (serveur->client) Device-Reboot-Ind (serveur->client) Device-Watchdog-Ind (serveur->client) AA-Request (client->serveur), requête d authentification et/ou d autorisation pour un utilisateur. Le serveur peut répondre à une AA-Request avec les messages suivants: o aa-answer (serveur->client), requête acceptée ou refusée par le serveur. o AA-Challenge-Ind (serveur->client), réponse à une AA-request, où le serveur attend une réponse du client encapsulée dans une AArequest. 9

11 1.3.3) Diagramme de séquence Ci-dessous un diagramme de séquence où un utilisateur accède au réseau par le biais d un NAS et se déconnecte. Les messages affichés dans le diagramme de séquence sont envoyés en utilisant le protocole de transport UDP. Un protocole de fenêtrage est utilisé par-dessus ce protocole non-fiable pour garantir une transmission correcte. Ce protocole introduit un message ZLB (Zero Length Body, un message DIAMETER sans commande) qui est utilisé pour envoyer un acquittement de message reçu. Ces messages n ont pas été inclus au diagramme de séquence. Fig. 2: Flux de messages DIAMETER. 1. Le NAS récupère le login/password d un utilisateur distant, et cette combinaison avec un message AA-Request vers le serveur DIAMETER (phase Authentification). 2. Si cette combinaison est valide, alors le serveur DIAMETER envoie un message AA-Response avec une information d autorisation au NAS (phase Autorisation). 3. Le NAS envoie un message de comptabilité en format ADIF(Accounting Data Interchange Format) au serveur AAA. 4. Le serveur AAA répond avec un message de comptabilité pour acquitter la requête de comptabilité. 5. Lorsque l utilisateur se déconnecte, le NAS envoie un message de comptabilité en format ADIF au serveur AAA. 6. Le serveur AAA répond avec un message de comptabilité pour acquitter la requête de comptabilité. 10

12 1.3.4) Exemple d une application Mobile IPv6 pour Diameter Architecture L architecture de l application Mobile IPv6 pour Diameter est représentée sur la figure suivante : Fig. 3 Les informations contenues dans les messages échangés sont les suivantes : KMx,y: Matériel Cryptographique partagé entre x et y NAI: Network Access Identifier RPI: Replay Protection Indicator Kp-x: clef publique de x HA@: Home Agent Address H@: Home Address SecuParam_I: Security Parameter Initiator SecuParam_R: Security Parameter Responder LC: aléa local Kx,y : clef de session partagée entre x et y CR: Credentials RC: Result Code 11

13 L architecture de l application est constituée de deux serveurs Diameter : le serveur Diameter du domaine visité DLS (Diameter Local Server) le serveur Diameter du domaine mère DHS (Diameter Home Server) Le client Diameter est l interface permettant au mobile et à l infrastructure Diameter de s échanger des informations. Il peut être situé au niveau du point d accès ou entre ce point d accès et le DLS. Le MN est le mobile utilisant Mobile IPv6 dont on souhaite authentifier l utilisateur. Dans cette architecture, on suppose que : Le mobile et le DHS possèdent un secret partagé permettant au serveur d authentifier son mobile. Les communications entre serveurs Diameter sont sécurisées. Les communications entre le client Diameter et le DLS ainsi que les communications entre le DHS et l agent mère sont sécurisés. Ces communications sont sécurisées en utilisant TLS entre les serveurs et en utilisant IPsec entre un client et son serveur. Fonctionnement Pour illustrer le fonctionnement de l application, on prend le cas d un mobile démarrant dans le réseau visité et possédant déjà un agent mère (HA) ainsi qu une adresse dans son réseau mère. La figure précédente illustre les échanges entre le mobile et l infrastructure Diameter : 1. Le mobile envoie en premier lieu un message <AS> (Attendant Solicit) afin de découvrir ou de sélectionner un client Diameter dans ce nouveau réseau. Les clients Diameter lui répondent par un message <AR> (Attendant Reply) contenant un aléa généré qui permet de détecter les éventuels rejeux. 2. Le mobile sélectionne un client Diameter et lui envoie le message <AReq> (Attendant Request) contenant l aléa local ainsi que des informations permettant son authentification. 3. Le client Diameter, à la réception du message <Areq> extrait les informations utiles et les encapsule dans un message Diameter <AMR> (AA-MN-Request) à destination du serveur Diameter du domaine visité DLS. 12

14 4. Le DLS extrait le Network Access Identifier et transfère le message <AMR> au serveur Diameter du domaine mère DHS s occupant du domaine mentionné dans le NAI. 5. Le DHS extrait les informations d authentification. Si cette authentification est correcte il vérifie que l agent mère existe bien et que l adresse fournie est valide. Le message <AHR> (AA-HA-Request) permet au DHS de communiquer à l agent mère les informations qui vont lui permettre de créer une association de sécurité avec son mobile. 6. L agent mère répond au mobile par le message <AHA>. 7. Le DHS peut maintenant répondre au DLS par le message <AMA > (AA-MN- Answer). Il l informe du succès ou non de l authentification et fournit aussi des informations permettant la création d associations de sécurité entre le mobile et son agent mère et entre le mobile et le client Diameter. 8. Le DLS vérifie que le mobile est bien authentifié (grâce au Result Code (RC)) et répond à son client Diameter en incluant ce que le DHS lui a envoyé. 9. Le client Diameter répond alors au mobile avec le message <ARep> (Attendant Reply). Ce message est protégé grâce à l association de sécurité nouvellement créée entre le client Diameter et le mobile. Dans le cas où le mobile a été correctement authentifié, le message contient les informations fournies par le serveur mère : adresse mère et adresse d un agent mère dans le cas où le mobile les auraient demandées les informations permettant de mettre en place l association de sécurité entre le mobile et son agent mère un RPI (Replay Protection Indicator) pour éviter que ce paquet ne soit rejoué et éventuellement une adresse IPv6 locale. Le mobile peut alors envoyer un message <BU> (Binding Update) authentifié à son agent mère pour enregistrer sa nouvelle adresse. 13

15 1.4) Différences entre RADIUS et DIAMETER Le protocole DIAMETER est conçu comme la génération suivante du protocole RADIUS, puisqu il résout les problèmes connus posés par RADIUS. Ci-dessous une liste des problèmes connus de RADIUS et de comment DIAMETER les résout : 1. Limitation stricte des attributs de données Radius a seulement un octet réservé pour la longueur du champ de données (max. 255) dans son entête d attributs.diameter consacre deux octets pour la longueur de son champ de données (max ). 2. Algorithme de retransmission inefficace Radius a seulement un octet comme champ identificateur pour identifier les retransmissions. Cela limite le nombre de requêtes qui peuvent être traitées (max. 255). Diameter a réservé quatre octets dans ce but (max. 2^32). 3. Incapacité à contrôler le flux vers les serveurs Radius s opère sur UDP et n a pas de schémas standards pour réguler son flux de messages. Diameter possède un schéma qui régule le flux des paquets UDP (windowing scheme). 4. Acquittement de message bout-en-bout Un client Radius attend un réponse positive ou négative après une requête, mais ne sait pas si la requête a été reçue par le serveur. Un client Diameter attend un réponse positive ou négative ou juste un acquittement de la requête reçue par le serveur. 5. Refus silencieux de paquets Un serveur Radius qui reçoit des paquets qui ne contiennent pas l information attendue ou qui contient des erreurs les éliminent sans avertissements. Cela peut faire croire au client que le serveur est inactif car il ne reçoit plus de réponse. Il va alors essayer de se connecter sur un autre serveur. Un serveur Diameter peut envoyer un message d erreur au client indiquant un problème. 6. Aucun support d erreur serveur Un serveur Radius n a aucun moyen d indiquer si il est inactif ou si il est disponible. Diameter implante des messages Keep-alive qui indiquent que le serveur est en dérangement depuis un certain temps. 7. Attaque par essai d authentification En utilisant PPP CHAP, chaque client Radius peut générer une séquence d essai de réponse qui peut être interceptée par n importe quel client Radius ou serveur proxy dans la chaîne. Cette séquence peut être rejouée par un autre client Radius n importe quand (en partie résolu par l extension Radius utilisant le protocole EAP). Avec Diameter, ces attributs d essais de réponse peuvent être sécurisés en utilisant un cryptage de bout-en-bout et une authentification. 14

16 8. Sécurité Hop-by-hop Radius implante seulement la sécurité hop-by-hop, ce qui signifie que chaque saut peut aisément modifier l information, dont on ne sait plus quelle est l origine. Diameter implante une sécurité de bout-en-bout qui garantit que l information ne peut être modifié sans avertissement. 9. Aucun support pour les commandes spécifiques à l utilisateur Radius n implante pas de commande spécifiques à l utilisateur, mais seulement des attributs spécifiques. Diameter ne possède pas de code pour les commandes spécifiques à l utilisateur 10. Coût des processeurs élevés Le protocole Radius n impose pas d obligations d alignement, qui ajoutent une charge inutile sur la plupart des processeurs. Le protocole Diameter possède une obligation d alignement de 32 bits, qui peut être plus facilement supportée par la plupart des processeurs. 15

17 2) Mise en œuvre d un FAI utilisant RADIUS Introduction Cette partie concerne la mise en place, d un point de vue pratique, des protocoles AAA. Pour ce faire, nous avons réalisé, à petite échelle, une configuration qui peut être utilisée par un fournisseur d accès à un réseau (notamment Internet). La configuration mise en pace est illustrée par le schéma ci-dessous. Provider Internet Serveur de Connexion à Internet Serveur AAA / /28 Clients Client 1 Client 2 Client 3 Il y a trois protagonistes principaux pour la mise en place d une configuration d un Fournisseur d Accès à Internet (FAI) : un serveur de connexion un serveur AAA les clients Le serveur de connexion permet l accès au réseau Internet. Il routera les demandes des clients vers leur destination ainsi que les réponses dans le sens inverse. C est le point d accès à Internet pour tous les clients du FAI. Le serveur AAA vérifiera l authentification et les autorisations des clients puis gèrera les comptes des clients du FAI. Les clients demandent l accès à Internet et sont connectés directement au serveur de connexion. Le serveur AAA sera un serveur Radius. Le FAI communique avec le serveur RADIUS en UDP. Les communications entre le FAI et les clients se feront par le biais du protocole PPPoE qui est l utilisation du protocole PPP sur un réseau Ethernet. 16

18 Produits 2.1) PPPoE FreeBSD PPPoE peut être utilisé sur Unix. Nous avons travaillé sur la version 4.7 de FreeBSD. L utilisation de PPPoE sur cet environnement est assez simple. En effet, PPP et PPPoE sont déjà implantés dans le noyau, ce qui ne nécessite aucune installation supplémentaire, et, de plus, tous les modules nécessaires à son fonctionnement sont chargés lors de son démarrage ; il n est plus nécessaire d inclure des options dans le noyau. Typiquement, les options à rajouter dans le noyau, qui ne sont plus nécessaires, sont les suivantes : options NETGRAPH options NETGRAPH_PPPOE options NETGRAPH_SOCKET Si vous souhaitez avoir la dernière version de PPP, les instructions d installation sont fournies à cette adresse : Linux Pour linux, on trouve une implémentation de PPP sur La dernière version, téléchargeable par CVS ( inclue un plugin pour utiliser PPPoE (Roaring Penguin et un plugin pour communiquer avec un serveur RADIUS. # télécharger la dernière version de ppp $ cvs -z5 -d :pserver:cvs@pserver.samba.org:/cvsroot co ppp # installation tar xvzf ppp_xxx.tgz cd ppp_xxx #éditer le makefile et décommenter la ligne pour permettre l utilisation du plugin./configure make ; make install Aussi nous avons téléchargé la version du logiciel Roaring Penguin qui contient un serveur PPPoE # lancement du serveur PPPoE $ pppoe-server 17

19 Avec la version b de pppd, nous n avons pas réussi à établir une connexion PPPoE entre une machine serveur PPPoE sous Linux Mandrake 9.0 et une autre client PPPoE sous FreeBSD 4.7. Après un première échange PPPoE, la machine linux semble ne pas parvenir à envoyer ses paquets au client, elle affiche l erreur : «timeout sending message». Configuration client et serveur La configuration de PPP se fait par le fichier /etc/ppp/ppp.conf. Nous avons à définir les paramètres chez le client et chez le serveur afin qu ils puissent supporter PPPoE. Des exemples de configurations peuvent être trouvés dans le répertoire /var/share/exemples/ppp/ sous Unix. Pour le client, nous donnons les paramètres suivants : /etc/ppp/ppp.conf pppoe: set device PPPoE:fxp0:pppoe-in enable lqr set cd 5 set dial set login set redial 0 0 set authname cyril set authkey jesuisclient enable pap chap add default HISADDR # Add a (sticky) default route enable dns # request DNS info (for resolv.conf) Les options principales sont : set device : l'utilisation de PPPoE sur l'interface fxp0 set authname, set authkey : l'indication du nom d'utilisateur et du mot de passe enable pap chap : la possibilité d'authentification par PAP ou CHAP (voir section suivante) add default HISADDR : la définition de l'adresse de route par défaut comme étant celle du serveur enable dns : la possibilité pour le serveur d'écrire dans le fichier /etc/resolv.conf l'adresse de son serveur DNS Le lancement du client se fait par la commande : ppp ddial pppoe Pour le lancement du client au démarrage de l'ordinateur, les ajouts dans le fichier /etc/rc.conf sont les suivants : /etc/rc.conf ppp_enable="yes" ppp_mode="ddial" ppp_profile="pppoe" # nom d'étiquette de configuration dans le ppp.conf 18

20 Les paramètres du serveur sont les suivants : /etc/ppp/ppp.conf pppoe-in: allow mode direct enable lqr proxy # Enable LQR and proxy-arp enable chap pap passwdauth # Force client authen set ifaddr accordée accept dns # Allow DNS negotiation set authname fai set authkey jesuisfai Les options principales en plus de celles indiquées chez le client : enable passwdauth : on accepte l'authentification système set ifaddr : indique l'adresse du serveur et le pool d'adresses allouées aux clients accept dns : on accepte l'option enable dns chez les clients (voir au-dessus) Le serveur se lance par la commande /usr/libexec/pppoed -p pppoe-in fxp1. fxp1 est le nom de l interface connectée aux clients. /etc/rc.conf pppoed_enable="yes" # lance le démon PPPoE pppoed_provider="pppoe-in" # étiquette de configuration dans ppp.conf pppoed_flags="-p /var/run/pppoed.pid" # Flags to pppoed (if enabled). pppoed_interface="fxp1" # interface réseau sur laquelle lancer pppoed Authentification PPP PPP utilise plusieurs protocoles pour l authentification qui sont : l'authentification système, PAP (Password Authentification Protocol) et CHAP (Challenge/Handshake Authentication Protocol). Ces deux derniers protocoles ont été conçus pour authentifier les ordinateurs, pas les utilisateurs. Ainsi les connexions PPP peuvent être établies par n importe quel utilisateur d un système. L authentification PAP se fait de manière unidirectionnelle (le client auprès du FAI), cependant elle peut éventuellement se faire de manière bidirectionnelle (le FAI auprès du client aussi). Avec CHAP elle se fait impérativement de manière bidirectionnelle. Cette dernière nécessite donc que le client s'authentifie mais aussi que le FAI fasse de même. Ceci permet, entre autre, pour un client, de gérer plusieurs comptes vers des FAI différents. Les nom de login et mot de passe peuvent être inscrit dans le ppp.conf pour l'utilisateur et s'écrivent dans le fichier /etc/ppp/ppp.secret pour les parties devant s'identifier à la machine locale. 19

21 Dans notre cas, ces fichiers se composent comme suit pour le client et le serveur. Le client : /etc/ppp/ppp.secret # Authname Authkey Peer's IP address Label Callback fai jesuisfai Le serveur : /etc/ppp/ppp.secret # Authname Authkey Peer's IP address Label Callback cyril jesuisclient 2.2) Radius Produits libre FreeRadius o Développement original pour linux o ports FreeBSD : /usr/ports/net/freeradius/work/freeradius-0.8.1/ o Semble le plus complet OpenRadius Installation du serveur FreeRadius 8.1 L installation sous Linux ou sous FreeBSD se passe sans problème. Nous n avons pas eu le temps de tenter de configurer. Sous Linux, par défaut la configuration se trouve dans le répertoire /usr/local/etc/raddb/ et les fichiers importants sont radiusd.conf, clients.conf, etc. La configuration standard ouvre le serveur sur les ports UDP 1812, 1813 et lancement en mode debug : radiusd X test (normalement) : radtest test test localhost 0 testing123 Nous n avons pas réussi à faire fonctionner le test. Il semble y avoir des problèmes pour le chargement de modules notamment du module CHAP. 20

22 Installation de OpenRadius Comme précédemment, nous n avons pas eu le temps de nous occuper de la configuration. Sous Linux, le répertoire standard de configuration est : /usr/local/etc/openradius/. Le fichier de configuration est «configuration». lancement en mode debug : /usr/local/sbin/radiusd -dall b Nous n avons pas réussi à faire fonctionner le script test. Configuration du NAS Afin que le serveur PPP puisse communiquer avec le serveur Radius, deux manipulations sont à faire. L utilisation de Radius est précisée dans le fichier /etc/ppp/ppp.conf. /etc/ppp/ppp.conf set radius /etc/radius.conf Le fichier de configuration /etc/radius.conf indique le mode d authentification utilisé, l adresse de la machine serveur Radius ainsi que le numéro de port où le contacter. /etc/radius.conf auth Nous indiquons ici que nous utilisons l authentification système et que le serveur Radius se trouve à l adresse IP sur le port UDP

23 2.3) Scénarios Initialement, le client ne possède pas de configuration de routage propre (pas d adresse IP, ni de route par défaut, ni de serveur DNS connu), mais est en liaison physique directe avec le serveur. Le serveur PPP est connecté au réseau des clients, à Internet, ainsi qu au serveur Radius. Les trames sont capturées grâce à Ethereal. Les configurations initiales sont donc les suivantes : côté serveur PPP ifconfig fxp0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 inet6 fe80::2d0:b7ff:fedd:1a77%fxp0 prefixlen 64 scopeid 0x1 inet netmask 0xffffff00 broadcast ether 00:d0:b7:dd:1a:77 media: Ethernet autoselect (100baseTX <full-duplex>) status: active fxp1: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 inet netmask 0xfffffff0 broadcast ether 00:d0:b7:85:f3:d6 media: Ethernet autoselect (100baseTX <full-duplex>) status: active fxp2: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500 inet netmask 0xfffffff0 broadcast ether 00:d0:b7:85:28:05 media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<up,loopback,running,multicast> mtu inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet netmask 0xff ppp0: flags=8010<pointopoint,multicast> mtu 1500 netstat -nr Internet: Destination Gateway Flags Refs Use Netif Expire default UGSc 0 0 fxp UH 0 24 lo link#1 UC 1 0 fxp /28 link#2 UC 1 0 fxp /28 link#3 UC 1 0 fxp link#1 UHLW 1 0 fxp0 cat /etc/resolv.conf domain esial.uhp-nancy.fr nameserver