1.1. Le Protocole Kerberos
1.1. Le Protocole Kerberos
Kerberos fournit un moyen de vérifier les identités des principals (par exemple, un utilisateur de station de travail ou un serveur réseau) sur un réseau ouvert (non protégé). Cela est accompli sans se fier aux assertions du système d'exploitation hôte, sans baser la confiance sur les adresses d'hôte, sans exiger la sécurité physique de tous les hôtes sur le réseau, et sous l'hypothèse que les paquets voyageant sur le réseau peuvent être lus, modifiés et insérés à volonté. Kerberos effectue l'authentification dans ces conditions en tant que service d'authentification tiers de confiance en utilisant la cryptographie conventionnelle (clé secrète partagée). Les extensions à Kerberos (en dehors de la portée de ce document) peuvent permettre l'utilisation de la cryptographie à clé publique pendant certaines phases du protocole d'authentification. Ces extensions prennent en charge l'authentification Kerberos pour les utilisateurs enregistrés auprès d'autorités de certification à clé publique et offrent certains avantages de la cryptographie à clé publique dans les situations où ils sont nécessaires.
Le processus d'authentification Kerberos de base se déroule comme suit: Un client envoie une demande au serveur d'authentification (AS) pour des "credentials" pour un serveur donné. L'AS répond avec ces credentials, chiffrés dans la clé du client. Les credentials consistent en un "ticket" pour le serveur et une clé de chiffrement temporaire (souvent appelée "clé de session"). Le client transmet le ticket (qui contient l'identité du client et une copie de la clé de session, le tout chiffré dans la clé du serveur) au serveur. La clé de session (maintenant partagée par le client et le serveur) est utilisée pour authentifier le client et peut éventuellement être utilisée pour authentifier le serveur. Elle peut également être utilisée pour chiffrer d'autres communications entre les deux parties ou pour échanger une clé de sous-session distincte à utiliser pour chiffrer d'autres communications. Notez que de nombreuses applications n'utilisent les fonctions de Kerberos que lors de l'initiation d'une connexion réseau basée sur flux. À moins qu'une application n'effectue un chiffrement ou une protection d'intégrité pour le flux de données, la vérification d'identité ne s'applique qu'à l'initiation de la connexion, et elle ne garantit pas que les messages ultérieurs sur la connexion proviennent du même principal.
La mise en œuvre du protocole de base consiste en un ou plusieurs serveurs d'authentification fonctionnant sur des hôtes physiquement sécurisés. Les serveurs d'authentification maintiennent une base de données de principals (c'est-à-dire, utilisateurs et serveurs) et de leurs clés secrètes. Les bibliothèques de code fournissent le chiffrement et implémentent le protocole Kerberos. Afin d'ajouter l'authentification à ses transactions, une application réseau typique ajoute des appels à la bibliothèque Kerberos directement ou via l'Interface de Programmation d'Application des Services de Sécurité Génériques (GSS-API) décrite dans un document séparé [RFC4121]. Ces appels résultent en la transmission des messages nécessaires pour réaliser l'authentification.
Le protocole Kerberos consiste en plusieurs sous-protocoles (ou échanges). Il existe deux méthodes de base par lesquelles un client peut demander des credentials à un serveur Kerberos. Dans la première approche, le client envoie une demande en texte clair pour un ticket pour le serveur désiré à l'AS. La réponse est envoyée chiffrée dans la clé secrète du client. Habituellement, cette demande est pour un ticket d'octroi de ticket (TGT), qui peut ensuite être utilisé avec le serveur d'octroi de tickets (TGS). Dans la deuxième méthode, le client envoie une demande au TGS. Le client utilise le TGT pour s'authentifier auprès du TGS de la même manière que s'il contactait tout autre serveur d'application nécessitant une authentification Kerberos. La réponse est chiffrée dans la clé de session du TGT. Bien que la spécification du protocole décrive l'AS et le TGS comme des serveurs séparés, en pratique ils sont implémentés comme différents points d'entrée de protocole au sein d'un seul serveur Kerberos.
Une fois obtenus, les credentials peuvent être utilisés pour vérifier l'identité des principals dans une transaction, pour assurer l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir quelle protection peut être nécessaire.
Pour vérifier les identités des principals dans une transaction, le client transmet le ticket au serveur d'application. Parce que le ticket est envoyé "en clair" (certaines parties sont chiffrées, mais ce chiffrement n'empêche pas la relecture) et pourrait être intercepté et réutilisé par un attaquant, des informations supplémentaires sont envoyées pour prouver que le message provient du principal auquel le ticket a été délivré. Cette information (appelée l'authenticator) est chiffrée dans la clé de session et inclut un horodatage. L'horodatage prouve que le message a été récemment généré et n'est pas une relecture. Le chiffrement de l'authenticator dans la clé de session prouve qu'il a été généré par une partie possédant la clé de session. Puisque personne sauf le principal demandeur et le serveur ne connaît la clé de session (elle n'est jamais envoyée sur le réseau en clair), cela garantit l'identité du client.
L'intégrité des messages échangés entre principals peut également être garantie en utilisant la clé de session (passée dans le ticket et contenue dans les credentials). Cette approche fournit la détection à la fois des attaques de relecture et des attaques de modification de flux de messages. Elle est accomplie en générant et en transmettant une somme de contrôle résistante aux collisions (appelée ailleurs fonction de hachage ou digest) du message du client, clé avec la clé de session. La confidentialité et l'intégrité des messages échangés entre principals peuvent être sécurisées en chiffrant les données à transmettre en utilisant la clé de session contenue dans le ticket ou la clé de sous-session trouvée dans l'authenticator.
Les échanges d'authentification mentionnés ci-dessus nécessitent un accès en lecture seule à la base de données Kerberos. Parfois, cependant, les entrées dans la base de données doivent être modifiées, comme lors de l'ajout de nouveaux principals ou du changement de la clé d'un principal. Cela se fait en utilisant un protocole entre un client et un troisième serveur Kerberos, le Serveur d'Administration Kerberos (KADM). Il existe également un protocole pour maintenir plusieurs copies de la base de données Kerberos. Aucun de ces protocoles n'est décrit dans ce document.