Gwenael BLUM Florian LASOWY Cyril GUERIN Cdric PFEIFFER

Protocole AAA Principes et implantations

Encadrante ESIAL : Isabelle CHRISMENT

SOMMAIRE Introduction ................................................................................. 2 1) Les protocoles AAA................................................................ 3

1.1) Concepts .............................................................................................3 1.2) RADIUS...............................................................................................4 1.2.1) Description....................................................................................4 1.2.2) Format des paquets .......................................................................4 1.2.3) Diagramme de squence ................................................................6 1.3) DIAMETER...........................................................................................7 1.3.1) Description....................................................................................7 1.3.2) Format des paquets .......................................................................8 1.3.3) Diagramme de squence ..............................................................10 1.3.4) Exemple dune application Mobile IPv6 pour Diameter ......................11 1.4) Diffrences entre RADIUS et DIAMETER ...............................................14 Introduction ................................................................................................16 2.1) PPPoE...............................................................................................17 2.2) Radius ..............................................................................................20 2.3) Scnarios ..........................................................................................22 Conclusion ..................................................................................................26

2)

Mise en uvre dun FAI utilisant RADIUS.................................16

Rfrences..................................................................................27

Introduction
Laccs lInternet se fait traditionnellement depuis le domicile, luniversit, le bureau, ou les salles de confrence. Dans chacun de ces cas, la station daccs est un quipement fixe ou ventuellement mobile dans une faible mesure (infrieur 100 mtres pour lEthernet sans fil). Avec le dploiement des mobiles, il est devenu ncessaire de dvelopper des protocoles permettant des utilisateurs de se dplacer de rseau en rseau. Nous prsenterons les protocoles AAA (Authentication, Authorization, Accounting) qui permettent aux oprateurs dauthentifier des utilisateurs, de leur autoriser certains services et de collecter des informations sur lutilisation des ressources. Nous verrons en particulier que Diameter est actuellement le protocole le plus mme de satisfaire les nouveaux besoins suscits par la mobilit. En particulier, il permet aux oprateurs dauthentifier un utilisateur ayant souscrit un abonnement auprs dun autre oprateur.

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 : lauthentification consiste vrifier quune personne/quipement est bien celle quelle prtend tre. Ceci est gnralement ralis en utilisant un secret partag entre lutilisateur et le serveur mre AAAH ou laide de certificats (e.g X.509). Autorisation : lautorisation consiste permettre laccs 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 lutilisation des ressources. Ceci permet un oprateur de facturer un utilisateur suivant sa consommation. En pratique, une architecture client-serveur AAA permet de rendre lensemble de ces services. Les serveurs AAA dans les domaines mre et visit permettent de grer les utilisateurs. Les clients AAA sont hbergs sur des routeurs ou sur des serveurs daccs au rseau. Les protocoles implmentant du AAA sont essentiellement utiliss par des oprateurs offrant des services de tlcommunications des utilisateurs. Ces protocoles leur permettent de contrler laccs leurs rseaux et de connatre lutilisation de leurs ressources. Ils peuvent ainsi facturer selon le temps de connexion ou selon la quantit dinformations tlcharges. Ci-dessous un schma reprsentant larchitecture AAA la plus commune :

Fig.1 Architecture AAA

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 tlphoniques Internet. Lutilisateur utilise PPP pour accder un FAI via un serveur daccs. Il envoie des informations permettant de lauthentifier (typiquement login/password) au serveur daccs. Celuici les envoie alors un serveur RADIUS qui se charge de lauthentifier. Si lutilisateur est correctement authentifi, le serveur RADIUS lui permet laccs Internet. RADIUS a t conu pour supporter un nombre limit dquipements et donc un nombre limit dutilisateurs. Actuellement, les oprateurs doivent pouvoir rendre des services et authentifier des milliers dutilisateurs utilisant des technologies diffrentes. Ils doivent aussi tre capables de rendre des services des utilisateurs venant doprateurs diffrents, de prfrence de faon scurise. Or RADIUS ne gre pas explicitement les communications inter-domaine.

1.2.2) Format des paquets

Les donnes sont changes 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 dun paquet RADIUS

Les champs dun paquet RADIUS sont les suivants :

Code - octet contenant la requte/rponse RADIUS Identifier - octet utilis pour comparer la requte et la rponse. Length longueur du paquet (2 octets). Authenticator - Valeur utilise pour authentifier la rponse du serveur RADIUS, et utilise dans lalgorithme de masquage du password. Attributes les donnes appartenant la requte ou la rponse.

La communication RADIUS utilise le paradigme de requte-rponse, les requtes sont envoyes par le client au serveur, et les rponses sont envoyes par le serveur au client. Les paires requte-rponse possibles sont:

access-request , (client->serveur), requte daccs par un utilisateur pour certains services. Les rponses possibles cette commande sont: o access-accept, (serveur->client), rponse positive une requte daccs dun client. o access-reject, (serveur->client), rponse ngative une requte daccs dun client. o access-challenge, (serveur->client), rponse une requte daccs, o le serveur attend une rponse du client encapsule dans une accessrequest. accounting request, (client->serveur), requte pour enregistrer les donnes de comptabilit sur le serveur. La rponse cette commande est: o accounting response, (serveur->client), rponse vers le client lorsque les donnes de comptabilit ont bien t stockes sur le serveur.

1.2.3) Diagramme de squence

Ci-dessous un schma dun diagramme de squence lorsquun utilisateur accde au rseau travers un NAS (Network Access Server) et se dconnecte lui-mme.

Fig. 3: Flux de messages RADIUS .

1. Le NAS rcupre le login/password dun utilisateur distance, crypte ces informations avec une cl partage 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 supplmentaires (par exemple : adresse IP, masque de rseau, etc.) au NAS (phase Autorisation). 3. Le NAS envoie un message accounting-request (start) pour indiquer que lutilisateur est connect sur le rseau (phase Comptabilit ). 4. Le serveur RADIUS rpond avec un message Accounting-response lorsque linformation de comptabilit est stocke. 5. Lorsquun utilisateur se dconnectera, le NAS va envoyer un message Accounting-request (Stop) avec les informations suivantes :
o o o Delay time, le temps dessai denvoi de ce message. Input octets, le nombre doctets reus par le client. Output octets, le nombre doctets envoys par le client.

o o o o

Session time, le nombre de secondes que le client sest connect. Input packets, le nombre de paquets reus par le client. Output packets, le nombre de paquets envoys par le client. Reason, la raison pour laquelle le client sest dconnect.

6. Le serveur RADIUS rpond avec un message accounting-response lorsque linformation de comptabilit est stocke.

1.3) DIAMETER
1.3.1) Description
Diameter est un protocole permettant des domaines administratifs diffrents de collaborer pour raliser les fonctionnalits AAA. Il est constitu dun protocole de base qui dfinit le format des messages, comment ils sont transports, les messages derreurs ainsi que les services de scurit que toutes les implmentations doivent supporter. ce protocole de base sajoutent les applications : Mobile IP, NAS et CMS. Lapplication Diameter Mobile IPv4 permet de faire du AAA avec un utilisateur utilisant Mobile IPv4 ; lapplication Diameter NAS permet laccs au rseau via PPP/EAP, il sagit de lamlioration de RADIUS ; lapplication Diameter CMS permet de protger les changes Diameter au niveau applicatif entre serveurs ou entre un serveur et son client. Diameter a t conu dans lide dtre facilement extensible. Pour cette raison, le protocole de base est spar de ses applications.

1.3.2) Format des paquets

Les donnes sont changes entre client et serveur en paquets DIAMETER. En fait, un paquet est encapsul dans le champ de donnes UDP. Chaque paquet contient les informations suivantes :

Fig. 4: Format dun 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 requtes. W (1 bit), positionn si les champs NS et NR sont prsents (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), numro de squence utilise pour faire correspondre les requtes et leurs rponses. 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 spcifique, sinon positionn 0. o Reserved (6 bits) o Flag T (1 bit), Tag bit, utilis pour grouper les AVPs

o o o o o o

Flag V (1 bit), Vendor-specific bit, indique si le champ optionnel vendredi field est prsent. 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 lid 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), requte dauthentification et/ou dautorisation pour un utilisateur. Le serveur peut rpondre une AA-Request avec les messages suivants: o aA-Answer (serveur->client), requte accepte ou refuse par le serveur. o AA-Challenge-Ind (serveur->client), rponse une AA-request, o le serveur attend une rponse du client encapsule dans une AArequest.

1.3.3) Diagramme de squence

Ci-dessous un diagramme de squence o un utilisateur accde au rseau par le biais dun NAS et se dconnecte. Les messages affichs dans le diagramme de squence sont envoys en utilisant le protocole de transport UDP. Un protocole de fentrage 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 reu. Ces messages nont pas t inclus au diagramme de squence.

Fig. 2: Flux de messages DIAMETER.

1. Le NAS rcupre le login/password dun 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 dautorisation 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 rpond avec un message de comptabilit pour acquitter la requte de comptabilit. 5. Lorsque lutilisateur se dconnecte, le NAS envoie un message de comptabilit en format ADIF au serveur AAA. 6. Le serveur AAA rpond avec un message de comptabilit pour acquitter la requte de comptabilit.

10

1.3.4) Exemple dune application Mobile IPv6 pour Diameter Architecture

Larchitecture de lapplication Mobile IPv6 pour Diameter est reprsente sur la figure suivante :

Fig. 3 Les informations contenues dans les messages changs sont les suivantes :
KMx,y: Matriel 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: ala local Kx,y : clef de session partage entre x et y CR: Credentials RC: Result Code

11

Larchitecture de lapplication est constitue de deux serveurs Diameter : le serveur Diameter du domaine visit DLS (Diameter Local Server) le serveur Diameter du domaine mre DHS (Diameter Home Server) Le client Diameter est linterface permettant au mobile et linfrastructure Diameter de schanger des informations. Il peut tre situ au niveau du point daccs ou entre ce point daccs et le DLS. Le MN est le mobile utilisant Mobile IPv6 dont on souhaite authentifier lutilisateur. Dans cette architecture, on suppose que : Le mobile et le DHS possdent un secret partag permettant au serveur dauthentifier son mobile. Les communications entre serveurs Diameter sont scurises. Les communications entre le client Diameter et le DLS ainsi que les communications entre le DHS et lagent mre sont scuriss. Ces communications sont scurises en utilisant TLS entre les serveurs et en utilisant IPsec entre un client et son serveur.

Fonctionnement
Pour illustrer le fonctionnement de lapplication, on prend le cas dun mobile dmarrant dans le rseau visit et possdant dj un agent mre (HA) ainsi quune adresse dans son rseau mre. La figure prcdente illustre les changes entre le mobile et linfrastructure Diameter :

1. Le mobile envoie en premier lieu un message <AS> (Attendant Solicit) afin de dcouvrir ou de slectionner un client Diameter dans ce nouveau rseau. Les clients Diameter lui rpondent par un message <AR> (Attendant Reply) contenant un ala gnr qui permet de dtecter les ventuels rejeux. 2. Le mobile slectionne un client Diameter et lui envoie le message <AReq> (Attendant Request) contenant lala local ainsi que des informations permettant son authentification. 3. Le client Diameter, la rception 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

4. Le DLS extrait le Network Access Identifier et transfre le message <AMR> au serveur Diameter du domaine mre DHS soccupant du domaine mentionn dans le NAI. 5. Le DHS extrait les informations dauthentification. Si cette authentification est correcte il vrifie que lagent mre existe bien et que ladresse fournie est valide. Le message <AHR> (AA-HA-Request) permet au DHS de communiquer lagent mre les informations qui vont lui permettre de crer une association de scurit avec son mobile. 6. Lagent mre rpond au mobile par le message <AHA>. 7. Le DHS peut maintenant rpondre au DLS par le message <AMA > (AA-MNAnswer). Il linforme du succs ou non de lauthentification et fournit aussi des informations permettant la cration dassociations de scurit entre le mobile et son agent mre et entre le mobile et le client Diameter. 8. Le DLS vrifie que le mobile est bien authentifi (grce au Result Code (RC)) et rpond son client Diameter en incluant ce que le DHS lui a envoy. 9. Le client Diameter rpond alors au mobile avec le message <ARep> (Attendant Reply). Ce message est protg grce lassociation de scurit nouvellement cre 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 mre : adresse mre et adresse dun agent mre dans le cas o le mobile les auraient demandes les informations permettant de mettre en place lassociation de scurit entre le mobile et son agent mre 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 mre pour enregistrer sa nouvelle adresse.

13

1.4) Diffrences entre RADIUS et DIAMETER

Le protocole DIAMETER est conu comme la gnration suivante du protocole RADIUS, puisquil rsout les problmes connus poss par RADIUS. Ci-dessous une liste des problmes connus de RADIUS et de comment DIAMETER les rsout :
1. Limitation stricte des attributs de donnes Radius a seulement un octet rserv pour la longueur du champ de donnes (max. 255) dans son entte dattributs.Diameter consacre deux octets pour la longueur de son champ de donnes (max. 16535). 2. Algorithme de retransmission inefficace Radius a seulement un octet comme champ identificateur pour identifier les retransmissions. Cela limite le nombre de requtes qui peuvent tre traites (max. 255). Diameter a rserv quatre octets dans ce but (max. 2^32). 3. Incapacit contrler le flux vers les serveurs Radius sopre sur UDP et na pas de schmas standards pour rguler son flux de messages. Diameter possde un schma qui rgule le flux des paquets UDP (windowing scheme). 4. Acquittement de message bout-en-bout Un client Radius attend un rponse positive ou ngative aprs une requte, mais ne sait pas si la requte a t reue par le serveur. Un client Diameter attend un rponse positive ou ngative ou juste un acquittement de la requte reue par le serveur. 5. Refus silencieux de paquets Un serveur Radius qui reoit des paquets qui ne contiennent pas linformation attendue ou qui contient des erreurs les liminent sans avertissements. Cela peut faire croire au client que le serveur est inactif car il ne reoit plus de rponse. Il va alors essayer de se connecter sur un autre serveur. Un serveur Diameter peut envoyer un message derreur au client indiquant un problme. 6. Aucun support derreur serveur Un serveur Radius na aucun moyen dindiquer si il est inactif ou si il est disponible. Diameter implante des messages Keep-alive qui indiquent que le serveur est en drangement depuis un certain temps. 7. Attaque par essai dauthentification En utilisant PPP CHAP , chaque client Radius peut gnrer une squence dessai de rponse qui peut tre intercepte par nimporte quel client Radius ou serveur proxy dans la chane . Cette squence peut tre rejoue par un autre client Radius nimporte quand (en partie rsolu par lextension Radius utilisant le protocole EAP). Avec Diameter, ces attributs dessais de rponse peuvent tre scuriss en utilisant un cryptage de bout-en-bout et une authentification.

14

8. Scurit Hop-by-hop Radius implante seulement la scurit hop-by-hop , ce qui signifie que chaque saut peut aisment modifier linformation, dont on ne sait plus quelle est lorigine. Diameter implante une scurit de bout-en-bout qui garantit que linformation ne peut tre modifi sans avertissement. 9. Aucun support pour les commandes spcifiques lutilisateur Radius nimplante pas de commande spcifiques lutilisateur, mais seulement des attributs spcifiques. Diameter ne possde pas de code pour les commandes spcifiques lutilisateur 10. Cot des processeurs levs Le protocole Radius nimpose pas dobligations dalignement, qui ajoutent une charge inutile sur la plupart des processeurs. Le protocole Diameter possde une obligation dalignement de 32 bits, qui peut tre plus facilement supporte par la plupart des processeurs.

15

2) Mise en uvre dun FAI utilisant RADIUS

Introduction
Cette partie concerne la mise en place, dun point de vue pratique, des protocoles AAA. Pour ce faire, nous avons ralis, petite chelle, une configuration qui peut tre utilise par un fournisseur daccs un rseau (notamment Internet). La configuration mise en pace est illustre par le schma ci-dessous. Provider Internet
.254 .132 .78 192.168.197.64/28

Serveur de Connexion Internet

.49 .50

Serveur AAA
192.168.197.48/28

Client 1 Clients

Client 2

Client 3

Il y a trois protagonistes principaux pour la mise en place dune configuration dun Fournisseur dAccs Internet (FAI) : un serveur de connexion un serveur AAA les clients Le serveur de connexion permet laccs au rseau Internet. Il routera les demandes des clients vers leur destination ainsi que les rponses dans le sens inverse. Cest le point daccs Internet pour tous les clients du FAI. Le serveur AAA vrifiera lauthentification et les autorisations des clients puis grera les comptes des clients du FAI. Les clients demandent laccs Internet et sont connects 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 lutilisation du protocole PPP sur un rseau Ethernet.

16

2.1) PPPoE
Produits FreeBSD

PPPoE peut tre utilis sur Unix. Nous avons travaill sur la version 4.7 de FreeBSD. Lutilisation de PPPoE sur cet environnement est assez simple. En effet, PPP et PPPoE sont dj implants dans le noyau, ce qui ne ncessite aucune installation supplmentaire, et, de plus, tous les modules ncessaires son fonctionnement sont chargs lors de son dmarrage ; il nest plus ncessaire dinclure des options dans le noyau. Typiquement, les options rajouter dans le noyau, qui ne sont plus ncessaires, sont les suivantes :
options NETGRAPH options NETGRAPH_PPPOE options NETGRAPH_SOCKET

Si vous souhaitez avoir la dernire version de PPP, les instructions dinstallation sont fournies cette adresse : http://www.freebsdfr.org/doc/fr/books/handbook/ppp-and-slip.html Linux

Pour linux, on trouve une implmentation de PPP sur http://www.samba.org/ppp. La dernire version, tlchargeable par CVS (http://www.cvshome.org), inclue un plugin pour utiliser PPPoE (Roaring Penguin http://www.roaringpenguin.com/pppoe/) et un plugin pour communiquer avec un serveur RADIUS.
# tlcharger la dernire 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 dcommenter la ligne pour permettre lutilisation du plugin ./configure make ; make install

Aussi nous avons tlcharg la version 3.5-1 du logiciel Roaring Penguin qui contient un serveur PPPoE http://www.roaringpenguin.com/pppoe/.
# lancement du serveur PPPoE $ pppoe-server

17

Avec la version 2.4.1.2b de pppd, nous navons pas russi tablir une connexion PPPoE entre une machine serveur PPPoE sous Linux Mandrake 9.0 et une autre client PPPoE sous FreeBSD 4.7. Aprs un premire change PPPoE, la machine linux semble ne pas parvenir envoyer ses paquets au client, elle affiche lerreur : timeout sending message . Configuration client et serveur La configuration de PPP se fait par le fichier /etc/ppp/ppp.conf. Nous avons dfinir les paramtres chez le client et chez le serveur afin quils puissent supporter PPPoE. Des exemples de configurations peuvent tre trouvs dans le rpertoire /var/share/exemples/ppp/ sous Unix. Pour le client, nous donnons les paramtres 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 dfinition de l'adresse de route par dfaut 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 dmarrage 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

Les paramtres 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 192.168.197.78 192.168.197.65-192.168.197.77 # @IP accorde accept dns # Allow DNS negotiation set authname fai set authkey jesuisfai

Les options principales en plus de celles indiques chez le client : enable passwdauth : on accepte l'authentification systme set ifaddr : indique l'adresse du serveur et le pool d'adresses alloues 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 linterface connecte aux clients.
/etc/rc.conf pppoed_enable="YES" # lance le dmon 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 rseau sur laquelle lancer pppoed

Authentification PPP PPP utilise plusieurs protocoles pour lauthentification qui sont : l'authentification systme, PAP (Password Authentification Protocol) et CHAP (Challenge/Handshake Authentication Protocol). Ces deux derniers protocoles ont t conus pour authentifier les ordinateurs, pas les utilisateurs. Ainsi les connexions PPP peuvent tre tablies par nimporte quel utilisateur dun systme. Lauthentification PAP se fait de manire unidirectionnelle (le client auprs du FAI), cependant elle peut ventuellement se faire de manire bidirectionnelle (le FAI auprs du client aussi). Avec CHAP elle se fait imprativement de manire bidirectionnelle. Cette dernire ncessite donc que le client s'authentifie mais aussi que le FAI fasse de mme. Ceci permet, entre autre, pour un client, de grer plusieurs comptes vers des FAI diffrents. 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

Dans notre cas, ces fichiers se composent comme suit pour le client et le serveur. Le client :
/etc/ppp/ppp.secret # Authname Authkey fai jesuisfai Peer's IP address Label Callback

Le serveur :
/etc/ppp/ppp.secret # Authname Authkey cyril jesuisclient Peer's IP address Label Callback

2.2) Radius
Produits libre FreeRadius http://www.freeradius.org o Dveloppement original pour linux o ports FreeBSD : /usr/ports/net/freeradius/work/freeradius-0.8.1/ o Semble le plus complet OpenRadius http://www.xs4all.nl/~evbergen/radius-pppd.html

Installation du serveur FreeRadius 8.1 Linstallation sous Linux ou sous FreeBSD se passe sans problme. Nous navons pas eu le temps de tenter de configurer. Sous Linux, par dfaut la configuration se trouve dans le rpertoire /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 1814. lancement en mode debug : radiusd X test (normalement) : radtest test test localhost 0 testing123

Nous navons pas russi faire fonctionner le test. Il semble y avoir des problmes pour le chargement de modules notamment du module CHAP.

20

Installation de OpenRadius Comme prcdemment, nous navons pas eu le temps de nous occuper de la configuration. Sous Linux, le rpertoire 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 navons pas russi faire fonctionner le script test.

Configuration du NAS Afin que le serveur PPP puisse communiquer avec le serveur Radius, deux manipulations sont faire. Lutilisation de Radius est prcise 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 dauthentification utilis, ladresse de la machine serveur Radius ainsi que le numro de port o le contacter.
/etc/radius.conf auth 192.168.197.50 1812

Nous indiquons ici que nous utilisons lauthentification systme et que le serveur Radius se trouve ladresse IP 192.168.197.50 sur le port UDP 1812.

21

2.3) Scnarios
Initialement, le client ne possde pas de configuration de routage propre (pas dadresse IP, ni de route par dfaut, ni de serveur DNS connu), mais est en liaison physique directe avec le serveur. Le serveur PPP est connect au rseau des clients, Internet, ainsi quau serveur Radius. Les trames sont captures grce Ethereal. Les configurations initiales sont donc les suivantes :
ct 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 192.168.197.132 netmask 0xffffff00 broadcast 192.168.197.255 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 192.168.197.78 netmask 0xfffffff0 broadcast 192.168.197.79 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 192.168.197.49 netmask 0xfffffff0 broadcast 192.168.197.63 ether 00:d0:b7:85:28:05 media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 netstat -nr Internet: Destination default 127.0.0.1 192.168.197 192.168.197.64/28 192.168.197.48/28 192.168.197.254

Gateway 192.168.197.254 127.0.0.1 link#1 link#2 link#3 link#1

Flags UGSc UH UC UC UC UHLW

Refs 0 0 1 1 1 1

Use 0 24 0 0 0 0

Netif Expire fxp0 lo0 fxp0 fxp1 fxp2 fxp0

cat /etc/resolv.conf domain esial.uhp-nancy.fr nameserver 193.50.40.1

22

ct client
ifconfig fxp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:d0:b7:8f:4f:0a media: Ethernet autoselect (100baseTX <full-duplex>) status: active ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet 127.0.0.1 netmask 0xff000000 netstat -nr Internet: Destination 127.0.0.1

Gateway 127.0.0.1

Flags UH

Refs 0

Use 0

Netif Expire lo0

cat /etc/resolv.conf #domain esial.uhp-nancy.fr #nameserver 193.50.40.1

Scnario sans serveur Radius Ct serveur PPP Lancement du daemon pppoed Cot Client Lancement du client ppp Rsultat : Connexion PPPoE entre le client et le serveur PPP Connexion PPP du client vers le serveur Demande dauthentification CHAP de la part du client Succs de lauthentification Affectation dune adresse IP au client par le serveur PPP Attribution dune route par dfaut par le serveur au client (192.168.197.78) Possibilit de ping du client vers nimporte quelle machine du rseau Accs Internet disponible pour le client Rsolution de nom effective lorsquil ny a rien dans /etc/resolv.conf chez le client. Le serveur y ajoute ladresse de DNS quil utilise.

23

On obtient donc les configurations suivantes :

ct serveur PPP
ifconfig xp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::2d0:b7ff:fedd:1a77%fxp0 prefixlen 64 scopeid 0x1 inet 192.168.197.132 netmask 0xffffff00 broadcast 192.168.197.255 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 192.168.197.78 netmask 0xfffffff0 broadcast 192.168.197.79 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 192.168.197.49 netmask 0xfffffff0 broadcast 192.168.197.63 ether 00:d0:b7:85:28:05 media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492 inet 192.168.197.78 --> 192.168.197.65 netmask 0xffffffff inet6 fe80::2d0:b7ff:fedd:1a77%tun0 --> fe80::2d0:b7ff:fe8f:4f0a%tun0 prefixlen 128 scopeid 0xe Opened by PID 318 netstat -nr Internet: Destination default 127.0.0.1 192.168.197 192.168.197.64/28 192.168.197.48/28 192.168.197.254 192.168.197.65

Gateway 192.168.197.254 127.0.0.1 link#1 link#2 link#3 link#1 192.168.197.78

Flags UGSc UH UC UC UC UHLW UH

Refs 2 0 1 1 1 1 0

Use 0 24 0 0 0 0 0

Netif Expire fxp0 lo0 fxp0 fxp1 fxp2 fxp0 tun0

ct client
ifconfig fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::2d0:b7ff:fe8f:4f0a%fxp0 prefixlen 64 scopeid 0x1 ether 00:d0:b7:8f:4f:0a media: Ethernet autoselect (100baseTX <full-duplex>) status: active ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492 inet6 fe80::2d0:b7ff:fe8f:4f0a%tun0 --> fe80::2d0:b7ff:fedd:1a77%tun0 prefixlen 128 scopeid 0x8 inet 192.168.197.65 --> 192.168.197.78 netmask 0xffffffff Opened by PID 229 netstat -nr Internet: Destination default 127.0.0.1 192.168.197.78

Gateway 192.168.197.78 127.0.0.1 192.168.197.65

Flags UGSc UH UH

Refs 0 0 1

Use 0 0 0

Netif Expire tun0 lo0 tun0

cat /etc/resolv.conf #domain esial.uhp-nancy.fr #nameserver 193.50.40.1 nameserver 255.255.255.255 nameserver 193.50.40.1

24

Avec le serveur Radius Cot serveur Radius Lancement du daemon radiusd Ct serveur PPP Ajout de loption dutilisation de Radius dans ppp.conf Lancement du daemon pppoed Cot Client Lancement du client ppp Rsultat : Connexion PPPoE du client vers le serveur PPP Connexion PPP du client vers le serveur PPP Demande dauthentification CHAP de la part du client Le serveur PPP vrifie la requte dauthentification auprs du serveur AAA Echec de lauthentification de la part du serveur AAA Connexion refuse de la part du serveur PPP auprs du client Fermeture de la connexion PPP Fermeture de la connexion PPPoE

Aucune configuration du client na t faite.

25

Conclusion
La connexion PPP entre un client et le FAI stablie et lattribution dune adresse IP du pool fonctionne. Tout cela sans RADIUS. En utilisant RADIUS, les requtes du FAI parviennent bien au serveur RADIUS, mais celui-ci rejette toutes les demandes. Pour la suite du projet il faudrait travailler sur la configuration du serveur FreeRADIUS.

26

Rfrences
Adaptation et implmentation de Diameter/AAA pour Mobile IPv6 (2002-2003) Julien Bournelle et Maryline Laurent-Maknavicius http://www-rp.lip6.fr/dnac/5.1-bournelle-article.pdf Daemon News http://www.daemonnews.org/200101/pppoe.html Site officiel de DIAMETER http://www.diameter.org/ FreeBSD Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html http://www.freebsd-fr.org/doc/fr/books/handbook/ppp-and-slip.html http://www.freebsd.org/handbook/pppoe.html http://free.mine.nu/~squirrel/PPPoE/FreeBSD%20PPPoE%20Howto.htm FreeRadius http://www.freeradius.org Howto PPP Linux http://developpeur.journaldunet.com/ressource/howtos/PPP-HOWTO-13.shtml Implementing PPPoE in a Network (aot 2002) Fine Point Technologies, Inc. White Paper Series http://www.finepoint.com/coinfo/pdf/Implementing-PPPoE-in-a-Network.pdf Protocole L2TP Routage.org http://www.routage.org/l2tp1.html Linux Mandrake http://www.mandrakelinux.com RFC AAA http://www.ietf.org/html.charters/aaa-charter.html Samba PPP http://dp.samba.org/ppp/ Overview Radius & Diameter http://ing.ctit.utwente.nl/WU5/D5.1/Technology/

27