1.16 3.4. PROTOCOLES D'AUTHENTIFICATION COURAMMENT
UTILISES
3.4.1. Protocole RADIUS
Le protocole RADIUS (RemoteAuthentication
Dial-In User Service) développé par Livingston Enterprise et
standardisé par l'IETF (cf. RFC 2865 et 2866) s'appuie sur une
architecture client/serveur et permet de fournir des services
d'authentification, d'autorisation et de gestion des comptes lors
d'accès à distance.
Prenons le cas pratique d'un utilisateur nomade, souhaitant se
raccorder via Internet au réseau interne d'une entité du CNRS par
un canal protégé (circuit virtuel protégé CVP -
virtualprivate network VPN). Le principe de l'authentification de cet
utilisateur avec RADIUS est le suivant :
1. L'utilisateur exécute une requête de
connexion. Le routeur d'accès à distance (client RADIUS)
récupère les informations d'identification et d'authentification
de l'utilisateur (son identifiant et son mot de passe par exemple).
2. Le client RADIUS transmet ces informations au serveur
RADIUS.
3. Le serveur RADIUS reçoit la requête de
connexion de l'utilisateur, la contrôle, et retourne l'information de
configuration nécessaire au client RADIUS pour fournir ou non
l'accès au réseau interne à l'utilisateur.
4. Le client RADIUS renvoie à l'utilisateur un message
d'erreur en cas d'échec de l'authentification ou un message
d'accès au réseau si l'utilisateur a pu être
authentifié avec succès.
3.4.2. Protocole SSL
Le protocole SSL (Secure Socket Layer)
développé par Netscape Communications Corp. avec RSA Data
Security Inc. permet théoriquement de sécuriser tout protocole
applicatif s'appuyant sur TCP/IP i.e. HTTP, FTP, LDAP, SNMP, Telnet, etc. mais
en pratique ses implémentations les plus répandues sont LDAPS et
HTTPS.
Le protocole SSL permet non seulement de fournir les services
d'authentification du serveur, d'authentification du client (par certificat
à partir de SSL version 3) mais également les services de
confidentialité et d'intégrité.
Le principe d'une authentification du serveur avec SSL est le
suivant :
1. Le navigateur du client fait une demande de transaction
sécurisée au serveur.
2. Suite à la requête du client, le serveur
envoie son certificat au client.
3. Le serveur fournit la liste des algorithmes
cryptographiques qui peuvent être utilisés pour la
négociation entre le client et le serveur.
4. Le client choisit l'algorithme.
5. Le serveur envoie son certificat avec les clés
cryptographiques correspondantes au client.
6. Le navigateur vérifie que le certificat
délivré est valide.
7. Si la vérification est correcte alors le navigateur
du client envoie au serveur une clé secrète chiffrée
à l'aide de la clé publique du serveur qui sera donc le seul
capable de déchiffrer puis d'utiliser cette clé secrète.
Cette clé est un secret uniquement partagé entre le client et le
serveur afin d'échanger des données en toute
sécurité.
Afin d'éviter des attaques, il est recommandé
d'utiliser la double authentification c'est-à-dire non seulement
l'authentification du serveur mais également celle du client, bien que
l'authentification du client avec SSL soit facultative.
Le protocole TLS version 1.0 (Transport
Security Layer) est la version normalisée de SSL version 3.0 (cf. RFC
2246 de l'IETF). Les versions de TLS sont amenées à
évoluer, au moins au fur et à mesure que de nouvelles attaques
apparaissent. En Février dernier, une faiblesse majeure a
été identifiée dans le protocole SSL : des chercheurs de
l'Ecole Polytechnique de Lausanne ont montré qu'il est possible en moins
d'une heure de trouver le mot de passe d'un internaute connecté à
un service d'e-Commerce. Que l'URL (Uniform Resource
Locator) soit « sûre » ou pas, c'est-à-dire qu'une
société dont la réputation n'est plus à faire
héberge ce site Internet ou bien qu'il s'agisse d'une compagnie dont la
sécurité des transactions n'est pas une priorité, la
faille de sécurité basée sur une usurpation
d'identité était bien présente pour les plates-formes
Linux, Unix, Solaris et dérivés. L'information a
été rapidement transmise à l'organisation OpenSSL afin de
mettre à jour le protocole et développer une nouvelle
Version de SSL qui résiste à cette attaque (cf.
le site www.openssl.org pour les différentes mises à
jour).
|