Gwenael BLUM

Florian LASOWY
Cyril GUERIN
Cédric 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 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

1
Introduction

L’accès à l’Internet se fait traditionnellement depuis le domicile, l’université, le

bureau, ou les salles de conférence. Dans chacun de ces cas, la station d’accès est
un équipement fixe ou éventuellement mobile dans une faible mesure (inférieur à
100 mètres pour l’Ethernet sans fil). Avec le déploiement des mobiles, il est devenu
nécessaire de développer des protocoles permettant à des utilisateurs de se déplacer
de réseau en réseau.

Nous présenterons les protocoles AAA (Authentication, Authorization,

Accounting) qui permettent aux opérateurs d’authentifier des utilisateurs, de leur
autoriser certains services et de collecter des informations sur l’utilisation des
ressources. Nous verrons en particulier que Diameter est actuellement le protocole le
plus à même de satisfaire les nouveaux besoins suscités par la mobilité. En
particulier, il permet aux opérateurs d’authentifier un utilisateur ayant souscrit un
abonnement auprès d’un autre opérateur.

2
 1) Les protocoles AAA
1.1) Concepts

AAA signifie Authentication, Authorization, Accounting, soit authentification,

autorisation et compte. La signification de ces termes est la suivante :

– Authentification : l’authentification consiste à vérifier qu’une personne/équipement

est bien celle qu’elle prétend être. Ceci est généralement réalisé en utilisant un
secret partagé entre l’utilisateur et le serveur mère AAAH ou à l’aide de certificats
(e.g X.509).

– Autorisation : l’autorisation consiste à permettre l’accès à certains services ou

ressources. Un utilisateur peut par exemple demander à avoir une certaine bande
passante. Le serveur AAA lui autorisera ou non cette demande.

– Compte : le serveur AAA a la possibilité de collecter des informations sur

l’utilisation des ressources. Ceci permet à un opérateur de facturer un utilisateur
suivant sa consommation.

En pratique, une architecture client-serveur AAA permet de rendre l’ensemble

de ces services. Les serveurs AAA dans les domaines mère et visité permettent de
gérer les utilisateurs. Les clients AAA sont hébergés sur des routeurs ou sur des
serveurs d’accès au réseau.

Les protocoles implémentant du AAA sont essentiellement utilisés par des

opérateurs offrant des services de télécommunications à des utilisateurs. Ces
protocoles leur permettent de contrôler l’accès à leurs réseaux et de connaître
l’utilisation de leurs ressources. Ils peuvent ainsi facturer selon le temps de
connexion ou selon la quantité d’informations téléchargées.
Ci-dessous un schéma représentant l’architecture AAA la plus commune :

Fig.1 – Architecture AAA

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

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

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

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

7
 1.3.2) Format des paquets

Les données sont échangées entre client et serveur en paquets DIAMETER. En

fait, un paquet est encapsulé dans le champ de données UDP. Chaque paquet
contient les informations suivantes :

Fig. 4: Format d’un paquet DIAMETER.

• Radius PCC (1 octet), pour une compatibilité avec RADIUS, doit être
positionné à 254 qui signifie “paquet DIAMETER”
• Flags (3 bits), utilisé pour identifier les options
• A (1 bit), le package est seulement un acquittement, et ne contient pas de
requêtes.
• W (1 bit), positionné si les champs NS et NR sont présents (utilisé lorsque
UDP est le protocole de transport).
• Version (3 bits), indique la version, doit être positionné à 1.
• Packet length (2 octets), longueur totale du paquet.
• Identifier (4 octets), numéro de séquence utilise pour faire correspondre les
requêtes et leurs réponses.
• NS (2 octets), Next Send
• NR (2 octets), Next Received
o AVP code (4 octets), commande DIAMETER (256)
o AVP length (2 octets), longueur du AVP
o Cmd flags (6 bits), peut être utilisé comme commande spécifique, sinon
positionné à 0.
o Reserved (6 bits)
o Flag T (1 bit), Tag bit, utilisé pour grouper les AVPs

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

9
 1.3.3) Diagramme de séquence

Ci-dessous un diagramme de séquence où un utilisateur accède au réseau par

le biais d’un NAS et se déconnecte.
Les messages affichés dans le diagramme de séquence sont envoyés en utilisant le
protocole de transport UDP. Un protocole de fenêtrage est utilisé par-dessus ce
protocole non-fiable pour garantir une transmission correcte. Ce protocole introduit
un message ZLB (Zero Length Body, un message DIAMETER sans commande) qui
est utilisé pour envoyer un acquittement de message reçu. Ces messages n’ont pas
été inclus au diagramme de séquence.

Fig. 2: Flux de messages DIAMETER.

1. Le NAS récupère le login/password d’un utilisateur distant, et cette

combinaison avec un message “AA-Request” vers le serveur DIAMETER
(phase Authentification).
2. Si cette combinaison est valide, alors le serveur DIAMETER envoie un message
“AA-Response” avec une information d’autorisation au NAS (phase
Autorisation).
3. Le NAS envoie un message de comptabilité en format ADIF(Accounting Data
Interchange Format) au serveur AAA .
4. Le serveur AAA répond avec un message de comptabilité pour acquitter la
requête de comptabilité.
5. Lorsque l’utilisateur se déconnecte, le NAS envoie un message de comptabilité
en format ADIF au serveur AAA.
6. Le serveur AAA répond avec un message de comptabilité pour acquitter la
requête de comptabilité.

10
 1.3.4) Exemple d’une application Mobile IPv6 pour Diameter

Architecture

L’architecture de l’application Mobile IPv6 pour Diameter est représentée sur la

figure suivante :

Fig. 3

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

KMx,y: Matériel Cryptographique partagé entre x et y

NAI: Network Access Identifier
RPI: Replay Protection Indicator
Kp-x: clef publique de x
HA@: Home Agent Address
H@: Home Address
SecuParam_I: Security Parameter Initiator
SecuParam_R: Security Parameter Responder
LC: aléa local
Kx,y : clef de session partagée entre x et y
CR: Credentials
RC: Result Code

11
 L’architecture de l’application est constituée de deux serveurs Diameter :
• le serveur Diameter du domaine visité DLS (Diameter Local Server)
• le serveur Diameter du domaine mère DHS (Diameter Home Server)

Le client Diameter est l’interface permettant au mobile et à l’infrastructure

Diameter de s’échanger des informations. Il peut être situé au niveau du point
d’accès ou entre ce point d’accès et le DLS.

Le MN est le mobile utilisant Mobile IPv6 dont on souhaite authentifier

l’utilisateur.

Dans cette architecture, on suppose que :

• Le mobile et le DHS possèdent un secret partagé permettant au serveur
d’authentifier son mobile.
• Les communications entre serveurs Diameter sont sécurisées.
• Les communications entre le client Diameter et le DLS ainsi que les
communications entre le DHS et l’agent mère sont sécurisés.

Ces communications sont sécurisées en utilisant TLS entre les serveurs et en

utilisant IPsec entre un client et son serveur.

Fonctionnement

Pour illustrer le fonctionnement de l’application, on prend le cas d’un mobile

démarrant dans le réseau visité et possédant déjà un agent mère (HA) ainsi qu’une
adresse dans son réseau mère.
La figure précédente illustre les échanges entre le mobile et l’infrastructure
Diameter :

1. Le mobile envoie en premier lieu un message <AS> (Attendant Solicit) afin de

découvrir ou de sélectionner un client Diameter dans ce nouveau réseau. Les clients
Diameter lui répondent par un message <AR> (Attendant Reply) contenant un aléa
généré qui permet de détecter les éventuels rejeux.

2. Le mobile sélectionne un client Diameter et lui envoie le message <AReq>

(Attendant Request) contenant l’aléa local ainsi que des informations permettant son
authentification.

3. Le client Diameter, à la réception du message <Areq> extrait les informations

utiles et les encapsule dans un message Diameter <AMR> (AA-MN-Request) à
destination du serveur Diameter du domaine visité DLS.

12
4. Le DLS extrait le Network Access Identifier et transfère le message <AMR> au
serveur Diameter du domaine mère DHS s’occupant du domaine mentionné dans le
NAI.

5. Le DHS extrait les informations d’authentification. Si cette authentification est

correcte il vérifie que l’agent mère existe bien et que l’adresse fournie est valide.
Le message <AHR> (AA-HA-Request) permet au DHS de communiquer à l’agent
mère les informations qui vont lui permettre de créer une association de sécurité
avec son mobile.

6. L’agent mère répond au mobile par le message <AHA>.

7. Le DHS peut maintenant répondre au DLS par le message <AMA > (AA-MN-
Answer). Il l’informe du succès ou non de l’authentification et fournit aussi des
informations permettant la création d’associations de sécurité entre le mobile et son
agent mère et entre le mobile et le client Diameter.

8. Le DLS vérifie que le mobile est bien authentifié (grâce au Result Code (RC)) et
répond à son client Diameter en incluant ce que le DHS lui a envoyé.

9. Le client Diameter répond alors au mobile avec le message <ARep> (Attendant

Reply). Ce message est protégé grâce à l’association de sécurité nouvellement créée
entre le client Diameter et le mobile.
Dans le cas où le mobile a été correctement authentifié, le message contient les
informations fournies par le serveur mère :
• adresse mère et adresse d’un agent mère dans le cas où le mobile les
auraient demandées
• les informations permettant de mettre en place l’association de sécurité
entre le mobile et son agent mère
• un RPI (Replay Protection Indicator) pour éviter que ce paquet ne soit
rejoué
• et éventuellement une adresse IPv6 locale.

Le mobile peut alors envoyer un message <BU> (Binding Update) authentifié à son
agent mère pour enregistrer sa nouvelle adresse.

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

14
8. Sécurité Hop-by-hop

Radius implante seulement la sécurité hop-by-hop , ce qui signifie que chaque saut peut aisément
modifier l’information, dont on ne sait plus quelle est l’origine. Diameter implante une sécurité de
bout-en-bout qui garantit que l’information ne peut être modifié sans avertissement.

9. Aucun support pour les commandes spécifiques à l’utilisateur

Radius n’implante pas de commande spécifiques à l’utilisateur, mais seulement des attributs
spécifiques. Diameter ne possède pas de code pour les commandes spécifiques à l’utilisateur

10. Coût des processeurs élevés

Le protocole Radius n’impose pas d’obligations d’alignement, qui ajoutent une charge inutile sur la
plupart des processeurs. Le protocole Diameter possède une obligation d’alignement de 32 bits,
qui peut être plus facilement supportée par la plupart des processeurs.

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

Introduction

Cette partie concerne la mise en place, d’un point de vue pratique, des
protocoles AAA. Pour ce faire, nous avons réalisé, à petite échelle, une configuration
qui peut être utilisée par un fournisseur d’accès à un réseau (notamment Internet).
La configuration mise en pace est illustrée par le schéma ci-dessous.

Provider
Serveur de
Internet .254 .132 Connexion
à Internet Serveur AAA
.50
.78 .49
192.168.197.48/28

192.168.197.64/28

Client 1 Client 2 Client 3

Clients

Il y a trois protagonistes principaux pour la mise en place d’une configuration

d’un Fournisseur d’Accès à Internet (FAI) :
Ø un serveur de connexion
Ø un serveur AAA
Ø les clients

Le serveur de connexion permet l’accès au réseau Internet. Il routera les

demandes des clients vers leur destination ainsi que les réponses dans le sens
inverse. C’est le point d’accès à Internet pour tous les clients du FAI.

Le serveur AAA vérifiera l’authentification et les autorisations des clients puis

gèrera les comptes des clients du FAI.

Les clients demandent l’accès à Internet et sont connectés directement au

serveur de connexion.

Le serveur AAA sera un serveur Radius. Le FAI communique avec le serveur

RADIUS en UDP. Les communications entre le FAI et les clients se feront par le biais
du protocole PPPoE qui est l’utilisation du protocole PPP sur un réseau Ethernet.

16
 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

17
 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

18
 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"
pppoed_provider="pppoe-in"
pppoed_flags="-P /var/run/pppoed.pid"
pppoed_interface="fxp1"
# lance le démon PPPoE
# étiquette de configuration dans ppp.conf
# Flags to pppoed (if enabled).
# interface réseau sur laquelle lancer pppoed

Authentification PPP

PPP utilise plusieurs protocoles pour l’authentification qui sont :

l'authentification système, PAP (Password Authentification Protocol) et CHAP
(Challenge/Handshake Authentication Protocol). Ces deux derniers protocoles ont été
conçus pour authentifier les ordinateurs, pas les utilisateurs. Ainsi les connexions PPP
peuvent être établies par n’importe quel utilisateur d’un système.

L’authentification PAP se fait de manière unidirectionnelle (le client auprès du

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

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

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

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

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

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

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

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

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

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

27