Faiblesses du protocole d'authentification Radius

Date : 07 Juillet 2005

Introduction :

Le protocole RADIUS (Remote Authentication Dial-in User Service) est le protocole standard pour l'authentification à distance.

Un paquet RADIUS est constitué de plusieurs champs, parmi lesquels figure un certain nombre d'attributs. Les attributs utiles à cette étude sont les attributs "User-Name" et "User-Password". Pour s'authentifier auprès d'un serveur RADIUS, un client va construire un paquet "Access-Request" contenant au moins les attributs "User-Name" et "User-Password", permettant au serveur d'authentifier ou non l'utilisateur. Si la requête du client est acceptée, le serveur va renvoyer un paquet "Access-Accept", si elle est refusée, il va renvoyer un paquet "Access-Reject".

Cette analyse traite des faiblesses de l'attribut "User-Password" qui, selon le mode d'authentification utilisé, peuvent compromettre ou non la sécurité du système d'authentification situé au-dessous du protocole Radius (PAP ou CHAP). Le protocole PAP (Password Authentication Protocol) est moins sécurisé car il utilise des mots de passe, qui sont envoyés en clair sur le réseau. Le protocole CHAP (Challenge Handshake Authentication Protocol) utilise lui un mécanisme de type "challenge / response" où aucun mot de passe ne circule sur le réseau. Ainsi :

  • Avec PAP : l'accés à l'attribut "User-Password" entraînerait une compromission du mécanisme d'authentification (usurpation d'identité), utilisant une authentification de type "Username-Password" ou PAP, car ces systèmes incluent les données d'authentification sans protection (sans chiffrement) dans l'attribut "User-Password".

  • Avec CHAP : par contre, lorsque le protocole CHAP ou une authentification de type "Challenge/Response" est utilisé, l'accés à l'attribut "User-Password" n'exposerait que les informations du protocole CHAP ou de celui de type "Challenge/Response" à une attaque, qui pourrait ensuite entrainer ou non une compromission du mécanisme d'authentification par des attaques de type "brute force"..

Le protocole RADIUS possède ainsi plusieurs failles de conception se trouvant à l'origine de problèmes de sécurité :

  • La technique de protection "User-Password" ne devrait pas utiliser la fonction MD5 comme primitive de chiffrement qui est plutôt réservé pour des opération de signature.

  • La génération du champ "Response Authenticator" présente des faiblesses.

  • Le paquet "Access-Request" n'est pas authentifié.

  • De nombreuses implémentations clientes ne créent pas des requêtes d'authentification "Request Authenticator" suffisament aléatoires.

  • Beaucoup d'administrateurs choisissent des "secrets partagés" identiques pour différents clients. De nombreuses implémentations clientes limitent artificiellement le nombre de caractères possibles du secret partagé.

Des modifications du protocole RADIUS sont suggérées par Joshua Hill pour améliorer la sécurité :

  • Utiliser un nouvel attribut "User-Password" protégé par un autre algorithme d'encryption, comme TDES, en mode CBC.

  • Utiliser une primitive HMAC ("Keyed-Hashing for Message Authentication") pour protéger le "Response Authenticator".

  • Afin de protéger les paquets "Access-Request", "Access-Accept" et "Access-Deny", créer un nouvel attribut contenant une empreinte SHA-1-HMAC du paquet RADIUS entier.

  • La spécification RADIUS devrait forcer à utiliser un algorithme cryptographique fort pour la génération de l'aléa (PRNG - PseudoRandom Number Generator) du "Request-Authenticator".

  • Cette spécification devrait également obliger un secret partagé différent pour chaque client RADIUS.

Pour plus d'information :

·         "An analysis of the RADIUS authentication protocol", Joshua Hill, InfoGard Laboratories, http://www.untruth.org/~josh/security/radius ou http://cert.uni-stuttgart.de/archive/bugtraq/2001/11/msg00080.html

·         Avis Cert-IST concernant le protocole RADIUS :

·         RFC concernant le protocole RADIUS : http://www.ietf.org/rfc/rfc2138.txt 

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST