Protocole AAA Principes et implantations

(1)

Gwenael BLUM Florian LASOWY Cyril GUERIN Cédric PFEIFFER

Protocole AAA

Principes et implantations

Encadrante ESIAL : Isabelle CHRISMENT

(2)

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

(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.

(4)

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/é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

(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. Celui- ci 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.

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 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.

(6)

5 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 access- request.

• 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.

(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 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)

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” 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.

(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

(10)

9

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

o Flag H (1 bit), Hop bit, indique que le AVP est crypté avec le cryptage Hop-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’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 “AA- request”.

(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é.

(12)

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

(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.

(14)

13 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.

(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. 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é 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.

(16)

15

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.

(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.

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.

Provider

Serveur AAA

Client 1

192.168.197.64/28 .254

.78

Serveur de Connexion à Internet

Client 2 Clients

Client 3

Internet ^.132

192.168.197.48/28

.49 .50

(18)

17

2.1) PPPoE

Produits

• 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 : http://www.freebsd- fr.org/doc/fr/books/handbook/ppp-and-slip.html

• Linux

Pour linux, on trouve une implémentation de PPP sur http://www.samba.org/ppp. La dernière version, téléchargeable 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.

# 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 3.5-1 du logiciel Roaring Penguin qui contient un serveur PPPoE http://www.roaringpenguin.com/pppoe/.

# lancement du serveur PPPoE

$ pppoe-server

(19)

Avec la version 2.4.1.2b 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

(20)

19 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 192.168.197.78 192.168.197.65-192.168.197.77 # @IP 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.

(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 http://www.freeradius.org o Développement 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

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

(22)

21 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 192.168.197.50 1812

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

(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 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

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

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 Gateway Flags Refs Use Netif Expire default 192.168.197.254 UGSc 0 0 fxp0 127.0.0.1 127.0.0.1 UH 0 24 lo0 192.168.197 link#1 UC 1 0 fxp0 192.168.197.64/28 link#2 UC 1 0 fxp1 192.168.197.48/28 link#3 UC 1 0 fxp2 192.168.197.254 link#1 UHLW 1 0 fxp0

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

(24)

23

côté client

§ ifconfig

fxp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:d0:b7:8f:4f:0a

Destination Gateway Flags Refs Use Netif Expire 127.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 Radius

Cô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é de ping 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.

(25)

On obtient donc les configurations suivantes :

côté 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

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

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

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

Destination Gateway Flags Refs Use Netif Expire default 192.168.197.254 UGSc 2 0 fxp0 127.0.0.1 127.0.0.1 UH 0 24 lo0 192.168.197 link#1 UC 1 0 fxp0 192.168.197.64/28 link#2 UC 1 0 fxp1 192.168.197.48/28 link#3 UC 1 0 fxp2 192.168.197.254 link#1 UHLW 1 0 fxp0 192.168.197.65 192.168.197.78 UH 0 0 tun0

côté 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

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

Destination Gateway Flags Refs Use Netif Expire default 192.168.197.78 UGSc 0 0 tun0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.197.78 192.168.197.65 UH 1 0 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

(26)

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.

(27)

Conclusion

La connexion PPP entre un client et le FAI s’établie et l’attribution d’une adresse 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 serveur FreeRADIUS.

(28)

27

Références

• Adaptation et implémentation 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 (août 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/