8/19/2019 1680951.pdf

1/28

Gwenael BLUMFlorian LASOWYCyril GUERINCédric PFEIFFER

Protocole AAA

Principes et implantations

Encadrante ESIAL : Isabelle CHRISMENT

8/19/2019 1680951.pdf

2/28

1

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 séquence ................................................................6

1.3) DIAMETER...........................................................................................7 1.3.1) Description....................................................................................7 1.3.2) Format des paquets .......................................................................8 1.3.3) Diagramme de séquence ..............................................................10

1.3.4)

Exemple d’une application Mobile IPv6 pour Diameter......................11

1.4) Différences entre RADIUS et DIAMETER ...............................................14 2) Mise en œuvre d’un FAI utilisant RADIUS.................................16

Introduction................................................................................................16 2.1) PPPoE...............................................................................................17 2.2) Radius ..............................................................................................20 2.3) Scénarios ..........................................................................................22 Conclusion..................................................................................................26

Références..................................................................................27

8/19/2019 1680951.pdf

3/28

8/19/2019 1680951.pdf

4/28

3

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/équipementest bien celle qu’elle prétend être. Ceci est généralement réalisé en utilisant unsecret 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 bandepassante. Le serveur AAA lui autorisera ou non cette demande.

– Compte : le serveur AAA a la possibilité de collecter des informations surl’utilisation des ressources. Ceci permet à un opérateur de facturer un utilisateursuivant sa consommation.

En pratique, une architecture client-serveur AAA permet de rendre l’ensemblede ces services. Les serveurs AAA dans les domaines mère et visité permettent degérer les utilisateurs. Les clients AAA sont hébergés sur des routeurs ou sur desserveurs d’accès au réseau.

Les protocoles implémentant du AAA sont essentiellement utilisés par desopérateurs offrant des services de télécommunications à des utilisateurs. Cesprotocoles leur permettent de contrôler l’accès à leurs réseaux et de connaîtrel’utilisation de leurs ressources. Ils peuvent ainsi facturer selon le temps deconnexion 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

8/19/2019 1680951.pdf

5/28

4

1.2) RADIUS1.2.1) Description

Le protocole RADIUS est actuellement utilisé pour faire du AAA avec desutilisateurs se connectant via des modems téléphoniques à Internet. L’utilisateurutilise PPP pour accéder à un FAI via un serveur d’accès. Il envoie des informationspermettant de l’authentifier (typiquement login/password) au serveur d’accès. Celui-ci les envoie alors à un serveur RADIUS qui se charge de l’authentifier. Si l’utilisateurest correctement authentifié, le serveur RADIUS lui permet l’accès à Internet.

RADIUS a été conçu pour supporter un nombre limité d’équipements et doncun nombre limité d’utilisateurs. Actuellement, les opérateurs doivent pouvoir rendredes services et authentifier des milliers d’utilisateurs utilisant des technologies

différentes. Ils doivent aussi être capables de rendre des services à des utilisateursvenant d’opérateurs différents, de préférence de façon sécurisée. Or RADIUS ne gèrepas explicitement les communications inter-domaine.

1.2.2) 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 paquetcontient 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.

8/19/2019 1680951.pdf

6/28

5

La communication RADIUS utilise le paradigme de requête-réponse, lesrequêtes sont envoyées par le client au serveur, et les réponses sont envoyéespar le serveur au client. Les paires requête-réponse possibles sont:

• access-request , (client->serveur), requête d’accès par un utilisateur pourcertains services. Les réponses possibles à cette commande sont:

o access-accept, (serveur->client), réponse positive à une requêted’accès d’un client.

o access-reject, (serveur->client), réponse négative à une requêted’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 access-request.

• accounting request, (client->serveur), requête pour enregistrer les donnéesde comptabilité sur le serveur. La réponse à cette commande est:

o accounting response, (serveur->client), réponse vers le client lorsqueles données de comptabilité ont bien été stockées sur le serveur.

8/19/2019 1680951.pdf

7/28

6

1.2.3) Diagramme de séquence

Ci-dessous un schéma d’un diagramme de séquence lorsqu’unutilisateur accède au réseau à travers un NAS (Network Access Server) et sedéconnecte lui-même.

Fig. 3: Flux de messages RADIUS .

1. Le NAS récupère le login/password d’un utilisateur à distance, crypte cesinformations 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 RADIUSenvoie 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 Delay time, le temps d’essai d’envoi de ce message.o Input octets, le nombre d’octets reçus par le client.o Output octets, le nombre d’octets envoyés par le client.

8/19/2019 1680951.pdf

8/28

7

o Session time, le nombre de secondes que le client s’est connecté.o Input packets, le nombre de paquets reçus par le client.o Output packets, le nombre de paquets envoyés par le client.o Reason, la raison pour laquelle le client s’est déconnecté.

6. Le serveur RADIUS répond avec un message “accounting-response” lorsquel’information de comptabilité est stockée.

1.3) DIAMETER

1.3.1) Description

Diameter est un protocole permettant à des domaines administratifs différentsde collaborer pour réaliser les fonctionnalités AAA. Il est constitué d’un protocole debase qui définit le format des messages, comment ils sont transportés, les messagesd’erreurs ainsi que les services de sécurité que toutes les implémentations doiventsupporter. À 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 utilisateurutilisant Mobile IPv4 ; l’application Diameter NAS permet l’accès au réseau viaPPP/EAP, il s’agit de l’amélioration de RADIUS ; l’application Diameter CMS permet deprotéger les échanges Diameter au niveau applicatif entre serveurs ou entre unserveur et son client.

Diameter a été conçu dans l’idée d’être facilement extensible. Pour cetteraison, le protocole de base est séparé de ses applications.

8/19/2019 1680951.pdf

9/28

8

1.3.2) Format des paquets

Les données sont échangées entre client et serveur en paquets DIAMETER. Enfait, un paquet est encapsulé dans le champ de données UDP. Chaque paquetcontient les informations suivantes :

Fig. 4: Format d’un paquet DIAMETER.

• Radius PCC (1 octet), pour une compatibilité avec RADIUS, doit êtrepositionné à 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 AVPo 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/19/2019 1680951.pdf

10/28

9

o Flag V (1 bit), Vendor-specific bit, indique si le champ optionnelvendredi field est présent.

o Flag H (1 bit), Hop bit, indique que le AVP est crypté avec le cryptageHop-by-hop.

o Flag M (1 bit), Mandatory bit, indique si le support AVP est requis.o Vendor id (4 octets, optional),o Tag (4 octets, optional),o 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’autorisationpour 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 leserveur.

o AA-Challenge-Ind (serveur->client), réponse à une “AA-request”, où leserveur attend une réponse du client encapsulée dans une “AA-request”.

8/19/2019 1680951.pdf

11/28

10

1.3.3) Diagramme de séquence

Ci-dessous un diagramme de séquence où un utilisateur accède au réseau parle biais d’un NAS et se déconnecte.Les messages affichés dans le diagramme de séquence sont envoyés en utilisant leprotocole de transport UDP. Un protocole de fenêtrage est utilisé par-dessus ceprotocole non-fiable pour garantir une transmission correcte. Ce protocole introduitun message ZLB (Zero Length Body, un message DIAMETER sans commande) quiest 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 cettecombinaison 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 DataInterchange Format) au serveur AAA .

4. Le serveur AAA répond avec un message de comptabilité pour acquitter larequê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 larequête de comptabilité.

8/19/2019 1680951.pdf

12/28

11

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 lafigure suivante :

Fig. 3

Les informations contenues dans les messages échangés sont les suivantes :

KMx,y: Matériel Cryptographique partagé entre x et yNAI: Network Access IdentifierRPI: Replay Protection IndicatorKp-x: clef publique de xHA@: Home Agent AddressH@: Home AddressSecuParam_I: Security Parameter InitiatorSecuParam_R: Security Parameter ResponderLC: aléa localKx,y : clef de session partagée entre x et yCR: CredentialsRC: Result Code

8/19/2019 1680951.pdf

13/28

12

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’infrastructureDiameter de s’échanger des informations. Il peut être situé au niveau du pointd’accès ou entre ce point d’accès et le DLS.

Le MN est le mobile utilisant Mobile IPv6 dont on souhaite authentifierl’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 lescommunications 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 enutilisant IPsec entre un client et son serveur.

Fonctionnement

Pour illustrer le fonctionnement de l’application, on prend le cas d’un mobiledémarrant dans le réseau visité et possédant déjà un agent mère (HA) ainsi qu’uneadresse dans son réseau mère.

La figure précédente illustre les échanges entre le mobile et l’infrastructureDiameter :

1. Le mobile envoie en premier lieu un message (Attendant Solicit) afin dedécouvrir ou de sélectionner un client Diameter dans ce nouveau réseau. Les clientsDiameter lui répondent par un message (Attendant Reply) contenant un aléagénéré qui permet de détecter les éventuels rejeux.

2. Le mobile sélectionne un client Diameter et lui envoie le message(Attendant Request) contenant l’aléa local ainsi que des informations permettant sonauthentification.

3. Le client Diameter, à la réception du message < Areq > extrait les informationsutiles et les encapsule dans un message Diameter < AMR > (AA-MN-Request) àdestination du serveur Diameter du domaine visité DLS.

8/19/2019 1680951.pdf

14/28

13

4. Le DLS extrait leNetwork Access Identifier et transfère le message auserveur Diameter du domaine mère DHS s’occupant du domaine mentionné dans leNAI.

5. Le DHS extrait les informations d’authentification. Si cette authentification estcorrecte 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’agentmè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 desinformations 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 auResult Code (RC) ) etré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 (AttendantReply). Ce message est protégé grâce à l’association de sécurité nouvellement crééeentre le client Diameter et le mobile.Dans le cas où le mobile a été correctement authentifié, le message contient lesinformations fournies par le serveur mère :

•

adresse mère et adresse d’un agent mère dans le cas où le mobile lesauraient 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 (Binding Update) authentifié à sonagent mère pour enregistrer sa nouvelle adresse.

8/19/2019 1680951.pdf

15/28

14

1.4) Différences entre RADIUS et DIAMETERLe protocole DIAMETER est conçu comme la génération suivante du protocoleRADIUS, puisqu’il résout les problèmes connus posés par RADIUS. Ci-dessous uneliste 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 sonentête d’attributs.Diameter consacre deux octets pour la longueur de son champ de données(max. 16535).

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é quatreoctets 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 larequê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 quicontient des erreurs les éliminent sans avertissements. Cela peut faire croire au client que leserveur est inactif car il ne reçoit plus de réponse. Il va alors essayer de se connecter sur un autreserveur. 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érangementdepuis un certain temps.

7. Attaque par essai d’authentif ication

En utilisant PPP CHAP , chaque client Radius peut générer une séquence d’essai de réponse quipeut être interceptée par n’importe quel client Radius ou serveur proxy dans la chaîne . Cetteséquence peut être “rejouée” par un autre client Radius n’importe quand (en partie résolu parl’extension Radius utilisant le protocole EAP). Avec Diameter, ces attributs d’essais de réponsepeuvent être sécurisés en utilisant un cryptage de bout-en-bout et une authentification.

8/19/2019 1680951.pdf

16/28

15

8. Sécurité Hop-by-hop

Radius implante seulement la sécurité hop-by-hop , ce qui signifie que chaque saut peut aisémentmodifier l’information, dont on ne sait plus quelle est l’origine. Diameter implante une sécurité debout-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 attributsspé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 laplupart 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.

8/19/2019 1680951.pdf

17/28

16

2) Mise en œuvre d’un FAI utilisant RADIUS

Introduction

Cette partie concerne la mise en place, d’un point de vue pratique, desprotocoles AAA. Pour ce faire, nous avons réalisé, à petite échelle, une configurationqui 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.

Il y a trois protagonistes principaux pour la mise en place d’une configurationd’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 lesdemandes des clients vers leur destination ainsi que les réponses dans le sensinverse. 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 puisgèrera les comptes des clients du FAI.

Les clients demandent l’accès à Internet et sont connectés directement auserveur de connexion.

Le serveur AAA sera un serveur Radius. Le FAI communique avec le serveurRADIUS en UDP. Les communications entre le FAI et les clients se feront par le biaisdu protocole PPPoE qui est l’utilisation du protocole PPP sur un réseau Ethernet.

Provider

Serveur AAA

Client 1

192.168.197.64/28

.254

.78

Serveur deConnexionà Internet

Client 2

Clients

Client 3

Internet .132

192.168.197.48/28.49

.50

8/19/2019 1680951.pdf

18/28

17

2.1) PPPoE

Produits

•

FreeBSDPPPoE 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, PPPet PPPoE sont déjà implantés dans le noyau, ce qui ne nécessite aucune installationsupplémentaire, et, de plus, tous les modules nécessaires à son fonctionnement sontchargés lors de son démarrage ; il n’est plus nécessaire d’inclure des options dans lenoyau.

Typiquement, les options à rajouter dans le noyau, qui ne sont plusnécessaires, sont les suivantes :

options NETGRAPHoptions NETGRAPH_PPPOEoptions NETGRAPH_SOCKET

Si vous souhaitez avoir la dernière version de PPP, les instructionsd’installation sont fournies à cette adresse : http://www.freebsd-fr.org/doc/fr/books/handbook/ppp-and-slip.html

• Linux

Pour linux, on trouve une implémentation de PPP surhttp://www.samba.org/ppp. La dernière version, téléchargeable par CVS(http://www.cvshome.org), inclue un plugin pour utiliser PPPoE (RoaringPenguinhttp://www.roaringpenguin.com/pppoe/) et un plugin pour communiqueravec 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.tgzcd ppp_xxx#éditer le makefile et décommenter la ligne pour permettre l’utilisation du plugin./configuremake ; make install

Aussi nous avons téléchargé la version 3.5-1 du logiciel Roaring Penguin quicontient un serveur PPPoEhttp://www.roaringpenguin.com/pppoe/.

# lancement du serveur PPPoE$ pppoe-server

8/19/2019 1680951.pdf

19/28

18

Avec la version 2.4.1.2b depppd , nous n’avons pas réussi à établir uneconnexion PPPoE entre une machine serveur PPPoE sous Linux Mandrake 9.0 et uneautre client PPPoE sous FreeBSD 4.7. Après un première échange PPPoE, la machinelinux 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 supporterPPPoE. 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.confpppoe:set device PPPoE:fxp0:pppoe-inenable lqrset cd 5set dialset loginset redial 0 0set authname cyrilset authkey jesuisclientenable pap chap

add default HISADDR # Add a (sticky) default routeenable 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 lefichier /etc/rc.conf sont les suivants :

/etc/rc.confppp_enable="YES"

ppp_mode="ddial"ppp_profile="pppoe" # nom d'étiquette de configuration dans le ppp.conf

8/19/2019 1680951.pdf

20/28

19

Les paramètres du serveur sont les suivants :

/etc/ppp/ppp.confpppoe-in:allow mode directenable lqr proxy # Enable LQR and proxy-arpenable chap pap passwdauth # Force client authenset ifaddr 192.168.197.78 192.168.197.65-192.168.197.77 # @IP accordéeaccept dns # Allow DNS negotiationset authname faiset 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'optionenable 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.confpppoed_enable="YES" # lance le démon PPPoEpppoed_provider="pppoe-in" # étiquette de configuration dans ppp.confpppoed_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 PPPpeuvent être établies par n’importe quel utilisateur d’un système.

L’authentification PAP se fait de manière unidirectionnelle (le client auprès duFAI), cependant elle peut éventuellement se faire de manière bidirectionnelle (le FAIauprès du client aussi). Avec CHAP elle se fait impérativement de manièrebidirectionnelle. Cette dernière nécessite donc que le client s'authentifie mais aussique le FAI fasse de même. Ceci permet, entre autre, pour un client, de gérerplusieurs comptes vers des FAI différents.

Les nom de login et mot de passe peuvent être inscrit dans leppp.conf pourl'utilisateur et s'écrivent dans le fichier /etc/ppp/ppp.secret pour les parties devants'identifier à la machine locale.

8/19/2019 1680951.pdf

21/28

20

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 Callbackfai jesuisfai

Le serveur :

/etc/ppp/ppp.secret# Authname Authkey Peer's IP address Label Callbackcyril jesuisclient

2.2) RadiusProduits libre

• FreeRadiushttp://www.freeradius.org o Développement original pour linuxo ports FreeBSD : /usr/ports/net/freeradius/work/freeradius-0.8.1/o Semble le plus complet

• OpenRadiushttp://www.xs4all.nl/~evbergen/radius-pppd.html

Installation du serveur FreeRadius 8.1

L’installation sous Linux ou sous FreeBSD se passe sans problème. Nous n’avons paseu le temps de tenter de configurer. Sous Linux, par défaut la configuration se trouvedans 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 1814.

• 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èmespour le chargement de modules notamment du module CHAP.

8/19/2019 1680951.pdf

22/28

21

Installation de OpenRadius

Comme précédemment, nous n’avons pas eu le temps de nous occuper de laconfiguration. 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, deuxmanipulations 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’authentificationutilisé, l’adresse de la machine serveur Radius ainsi que le numéro de port où lecontacter.

/etc/radius.confauth 192.168.197.50 1812

Nous indiquons ici que nous utilisons l’authentification système et que leserveur Radius se trouve à l’adresse IP 192.168.197.50 sur le port UDP 1812.

8/19/2019 1680951.pdf

23/28

22

2.3) Scénarios

Initialement, le client ne possède pas de configuration de routage propre (pasd’adresse IP, ni de route par défaut, ni de serveur DNS connu), mais est en liaisonphysique 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§ ifconfigfxp0: flags=8843 mtu 1500

inet6 fe80::2d0:b7ff:fedd:1a77%fxp0 prefixlen 64 scopeid 0x1inet 192.168.197.132 netmask 0xffffff00 broadcast 192.168.197.255ether 00:d0:b7:dd:1a:77media: Ethernet autoselect (100baseTX )status: active

fxp1: flags=8843 mtu 1500inet 192.168.197.78 netmask 0xfffffff0 broadcast 192.168.197.79ether 00:d0:b7:85:f3:d6media: Ethernet autoselect (100baseTX )status: active

fxp2: flags=8843 mtu 1500inet 192.168.197.49 netmask 0xfffffff0 broadcast 192.168.197.63ether 00:d0:b7:85:28:05media: Ethernet autoselect (100baseTX )status: active

lo0: flags=8049 mtu 16384inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6inet 127.0.0.1 netmask 0xff000000

ppp0: flags=8010 mtu 1500

§ netstat -nrInternet:Destination Gateway Flags Refs Use Netif Expiredefault 192.168.197.254 UGSc 0 0 fxp0127.0.0.1 127.0.0.1 UH 0 24 lo0192.168.197 link#1 UC 1 0 fxp0192.168.197.64/28 link#2 UC 1 0 fxp1192.168.197.48/28 link#3 UC 1 0 fxp2192.168.197.254 link#1 UHLW 1 0 fxp0

§ cat /etc/resolv.confdomain esial.uhp-nancy.frnameserver 193.50.40.1

8/19/2019 1680951.pdf

24/28

23

côté client§ ifconfigfxp0: flags=8802 mtu 1500

ether 00:d0:b7:8f:4f:0amedia: Ethernet autoselect (100baseTX )status: active

ppp0: flags=8010 mtu 1500lo0: flags=8049 mtu 16384

inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7inet 127.0.0.1 netmask 0xff000000

§ netstat -nrInternet:Destination Gateway Flags Refs Use Netif Expire127.0.0.1 127.0.0.1 UH 0 0 lo0

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

Scénario sans serveur RadiusCôté serveur PPP

ü Lancement du daemon « pppoed »

Coté Client

ü Lancement du client « ppp »

Résultat :

ü Connexion PPPoE entre le client et le serveur PPPü Connexion PPP du client vers le serveurü Demande d’authentification CHAP de la part du clientü Succès de l’authentificationü Affectation d’une adresse IP au client par le serveur PPPü Attribution d’une route par défaut par le serveur au client (192.168.197.78)ü Possibilité deping du client vers n’importe quelle machine du réseauü Accès à Internet disponible pour le clientü Résolution de nom effective lorsqu’il n’y a rien dans /etc/resolv.conf chez le

client. Le serveur y ajoute l’adresse de DNS qu’il utilise.

8/19/2019 1680951.pdf

25/28

24

On obtient donc les configurations suivantes :

côté serveur PPP§ ifconfigxp0: flags=8843 mtu 1500

inet6 fe80::2d0:b7ff:fedd:1a77%fxp0 prefixlen 64 scopeid 0x1inet 192.168.197.132 netmask 0xffffff00 broadcast 192.168.197.255ether 00:d0:b7:dd:1a:77media: Ethernet autoselect (100baseTX )status: active

fxp1: flags=8843 mtu 1500inet 192.168.197.78 netmask 0xfffffff0 broadcast 192.168.197.79ether 00:d0:b7:85:f3:d6media: Ethernet autoselect (100baseTX )status: active

fxp2: flags=8843 mtu 1500inet 192.168.197.49 netmask 0xfffffff0 broadcast 192.168.197.63ether 00:d0:b7:85:28:05media: Ethernet autoselect (100baseTX )status: active

lo0: flags=8049 mtu 16384inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6

inet 127.0.0.1 netmask 0xff000000ppp0: flags=8010 mtu 1500tun0: flags=8051 mtu 1492

inet 192.168.197.78 --> 192.168.197.65 netmask 0xffffffffinet6 fe80::2d0:b7ff:fedd:1a77%tun0 --> fe80::2d0:b7ff:fe8f:4f0a%tun0 prefixlen 128

scopeid 0xeOpened by PID 318

§ netstat -nrInternet:Destination Gateway Flags Refs Use Netif Expiredefault 192.168.197.254 UGSc 2 0 fxp0127.0.0.1 127.0.0.1 UH 0 24 lo0192.168.197 link#1 UC 1 0 fxp0192.168.197.64/28 link#2 UC 1 0 fxp1192.168.197.48/28 link#3 UC 1 0 fxp2

192.168.197.254 link#1 UHLW 1 0 fxp0192.168.197.65 192.168.197.78 UH 0 0 tun0

côté client§ ifconfigfxp0: flags=8843 mtu 1500

inet6 fe80::2d0:b7ff:fe8f:4f0a%fxp0 prefixlen 64 scopeid 0x1ether 00:d0:b7:8f:4f:0amedia: Ethernet autoselect (100baseTX )status: active

ppp0: flags=8010 mtu 1500lo0: flags=8049 mtu 16384

inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7inet 127.0.0.1 netmask 0xff000000

tun0: flags=8051 mtu 1492inet6 fe80::2d0:b7ff:fe8f:4f0a%tun0 --> fe80::2d0:b7ff:fedd:1a77%tun0 prefixlen 128

scopeid 0x8inet 192.168.197.65 --> 192.168.197.78 netmask 0xffffffffOpened by PID 229

§ netstat -nrInternet:Destination Gateway Flags Refs Use Netif Expiredefault 192.168.197.78 UGSc 0 0 tun0127.0.0.1 127.0.0.1 UH 0 0 lo0192.168.197.78 192.168.197.65 UH 1 0 tun0

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

#nameserver 193.50.40.1nameserver 255.255.255.255nameserver 193.50.40.1

8/19/2019 1680951.pdf

26/28

25

Avec le serveur Radius

Coté serveur Radius

ü Lancement du daemon « radiusd »

Côté serveur PPP

ü Ajout de l’option d’utilisation de Radius dans ppp.confü Lancement du daemon « pppoed »

Coté Client

ü Lancement du client « ppp »

Résultat :

ü Connexion PPPoE du client vers le serveur PPPü Connexion PPP du client vers le serveur PPPü Demande d’authentification CHAP de la part du clientü Le serveur PPP vérifie la requête d’authentification auprès du serveur AAAü Echec de l’authentification de la part du serveur AAAü Connexion refusée de la part du serveur PPP auprès du clientü Fermeture de la connexion PPPü Fermeture de la connexion PPPoE

Aucune configuration du client n’a été faite.

8/19/2019 1680951.pdf

27/28

26

Conclusion

La connexion PPP entre un client et le FAI s’établie et l’attribution d’uneadresse IP du pool fonctionne. Tout cela sans RADIUS.

En utilisant RADIUS, les requêtes 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 serveurFreeRADIUS.

8/19/2019 1680951.pdf

28/28

Références

•

Adaptation et implémentation de Diameter/AAA pour Mobile IPv6(2002-2003)Julien Bournelle et Maryline Laurent-Maknaviciushttp://www-rp.lip6.fr/dnac/5.1-bournelle-article.pdf

• Daemon Newshttp://www.daemonnews.org/200101/pppoe.html

• Site officiel de DIAMETERhttp://www.diameter.org/

• FreeBSD Handbookhttp://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

• FreeRadiushttp://www.freeradius.org

• Howto PPP Linuxhttp://developpeur.journaldunet.com/ressource/howtos/PPP-HOWTO-13.shtml

• Implementing PPPoE in a Network (août 2002)Fine Point Technologies, Inc. White Paper Serieshttp://www.finepoint.com/coinfo/pdf/Implementing-PPPoE-in-a-Network.pdf

• Protocole L2TPRoutage.orghttp://www.routage.org/l2tp1.html

• Linux Mandrakehttp://www.mandrakelinux.com

• RFC AAAhttp://www.ietf.org/html.charters/aaa-charter.html

• Samba PPPhttp://dp.samba.org/ppp/

• Overview Radius & Diameter

http://ing.ctit.utwente.nl/WU5/D5.1/Technology/