1.6. Environmental Assumptions (Hypothèses Environnementales)

1.6. Hypothèses Environnementales

Kerberos impose quelques hypothèses sur l'environnement dans lequel il peut fonctionner correctement, notamment les suivantes:

• Les attaques par "déni de service" ne sont pas résolues avec Kerberos. Il existe des endroits dans les protocoles où un intrus peut empêcher une application de participer aux étapes d'authentification appropriées. La détection et la résolution de telles attaques (dont certaines peuvent apparaître comme des modes de défaillance "normaux" pas si rares pour le système) sont généralement mieux laissées aux administrateurs et utilisateurs humains.

• Les principaux DOIVENT garder leurs clés secrètes secrètes. Si un intrus parvient à voler la clé d'un principal, il sera capable de se faire passer pour ce principal ou d'usurper l'identité de n'importe quel serveur auprès du principal légitime.

• Les attaques par "devinette de mot de passe" ne sont pas résolues par Kerberos. Si un utilisateur choisit un mauvais mot de passe, il est possible pour un attaquant de monter avec succès une attaque par dictionnaire hors ligne en tentant à plusieurs reprises de déchiffrer, avec des entrées successives d'un dictionnaire, des messages obtenus qui sont chiffrés sous une clé dérivée du mot de passe de l'utilisateur.

• Chaque hôte sur le réseau DOIT avoir une horloge qui est "faiblement synchronisée" avec le temps des autres hôtes; cette synchronisation est utilisée pour réduire les besoins de comptabilité des serveurs d'application lorsqu'ils effectuent la détection de rejeu. Le degré de "faiblesse" peut être configuré sur une base par serveur, mais il est généralement de l'ordre de 5 minutes. Si les horloges sont synchronisées sur le réseau, le protocole de synchronisation d'horloge DOIT lui-même être sécurisé contre les attaquants réseau.

• Les identifiants de principal ne sont pas recyclés sur une base à court terme. Un mode d'accès de contrôle typique utilisera des listes de contrôle d'accès (ACL, Access Control Lists) pour accorder des permissions à des principaux particuliers. Si une entrée ACL obsolète reste pour un principal supprimé et que l'identifiant de principal est réutilisé, le nouveau principal héritera des droits spécifiés dans l'entrée ACL obsolète. En ne réutilisant pas les identifiants de principal, le danger d'accès involontaire est supprimé.