CONCLUSION
Au terme du travail qui a été le nôtre, il
y'a lieu de faire remarquer que pour développer un client
d'authentification au bénéfice d'un FAI, il est nécessaire
de :
- mettre en place un système d'authentification
établi conformément aux normes et standards actuellement en
vigueur, à l'instar de l'utilisation du protocole triple-A RADIUS,
utiliser pour la gestion du contrôle d'accès au réseau, par
autorisation et authentification;
- utiliser un protocole complémentaire aux protocoles
triple-A, du type PPPoE, pour assurer la confidentialité des
échanges entre client et FAI, afin de fiabiliser la facturation à
l'usage des ressources.
Ainsi, la mise en uvre d'un client d'authentification via PPPoE,
permettant à un utilisateurclient de préserver son
identité d'une usurpation, tout en assurant la confidentialité de
ses échanges, passe par les points suivants :
1. la définition de l'architecture logicielle : en
choisissant le style architecturale permettant d'assurer, entre autres, la
réutilisabilité et l'extensibilité de l'application;
2. le choix ou la mise en uvre d'un Framework définissant
les concepts clés du style architecturale défini à
l'étape précédente;
3. la définition et la mise en uvre d'une interface de
communication entre le serveur d'accès distant et le système
d'exploitation hôte. Ladite interface devant faire usage du protocole
PPPoE;
4. la conception et la mise en uvre du client
d'authentification, en prenant en compte les points précités.
Perspectives d'améliorations
Il est annoté que dans la solution proposée,
l'on fait usage du protocole PAP1 pour l'authentification, ce qui ne
joue pas en faveur du renforcement de la sécurité lors du
transfert des paramètres d'authentification (login/password). En effet,
avec le protocole PAP les mots de passe sont véhiculés en texte
clair dans le tunnel PPPoE, ce qui ouvre la voie à une
possibilité d'attaque par « rejeu ». Ainsi, pense-t-on qu'il
est préférable, dans une version ultérieure du dialeur, de
faire usage du protocole CHAP pour améliorer la sécurité
lors du transfert des paramètres de connexion via le tunnel PPPoE.
De plus, bien que le protocole PPPoE permette d'éviter
certaines attaques, du fait de la création du tunnel entre
utilisateur-client et NAS, il n'en demeure pas moins vrai que, du fait de
l'usage du médium wifi sur de l'Ethernet, une attaque, certes
coûteuse par sa mise en oeuvre, tel que le Roque AP2 reste
possible. Toutefois, en raison de sa capacité à transporter des
trames d'autres protocoles, le protocole PPPoE offre des possibilités
énormes que le portail captif ne peut mettre à disposition.
En effet, avec le transport des trames d'autres protocoles,
l'on peut envisager que le client d'authentification RingoDialer puisse, dans
le temps, s'étendre à un certain nombre de modules au rang
desquels : la voix sur IP, la vidéoconférence et la messagerie
instantanée. Pour y parvenir, il y'a lieu de procéder, entre
autres, aux contrôles d'intégrité, de
confidentialité et de disponibilité. Cette étude
n'étant pas consacrée à conduire une telle approche, elle
pourrait faire l'objet d'une étude approfondie ultérieure.
1. À la date de la présentation de ce
mémoire, il est bon de noter que :
- l'entreprise Ringo S.A. fait désormais usage du
protocole HTTPS (HTTP Secure) pour ses transactions en intranet et extranet;
- le protocole utilisée par le « RingoDialer »,
pour authentifier les client-utilisateurs via PPPoE, est désormais le
protocole CHAP;
- l'usage du « RingoDialer » est désormais
prépondérant à celui fait avec le portail captif.
2. Voir l'annexe F à la page 77 pour de plus amples
informations
| 
