1. Introduction
1. Introduction
Ce document décrit les concepts et le modèle sur lesquels est basé le système d'authentification réseau Kerberos. Il spécifie également la version 5 du protocole Kerberos. Les motivations, les objectifs, les hypothèses et la justification derrière la plupart des décisions de conception sont traités de manière sommaire; ils sont décrits plus en détail dans un article disponible dans IEEE communications [NT94] et précédemment dans la partie Kerberos du plan technique Athena [MNSS87].
Ce document n'est pas destiné à décrire Kerberos à l'utilisateur final, à l'administrateur système ou au développeur d'applications. Des articles de niveau supérieur décrivant la version 5 du système Kerberos [NT94] et documentant la version 4 [SNS88] sont disponibles ailleurs.
Le modèle Kerberos est basé en partie sur le protocole d'authentification par tiers de confiance de Needham et Schroeder [NS78] et sur les modifications suggérées par Denning et Sacco [DS81]. La conception et l'implémentation originales des versions 1 à 4 de Kerberos ont été réalisées par deux anciens membres du personnel du projet Athena, Steve Miller de Digital Equipment Corporation et Clifford Neuman (maintenant à l'Information Sciences Institute de l'Université de Californie du Sud), ainsi que Jerome Saltzer, directeur technique du projet Athena, et Jeffrey Schiller, responsable du réseau du campus du MIT. De nombreux autres membres du projet Athena ont également contribué au travail sur Kerberos.
La version 5 du protocole Kerberos (décrite dans ce document) a évolué en raison de nouvelles exigences et du désir de fonctionnalités non disponibles dans la version 4. La conception de la version 5 a été dirigée par Clifford Neuman et John Kohl avec de nombreuses contributions de la communauté. Le développement de l'implémentation de référence du MIT a été dirigé au MIT par John Kohl et Theodore Ts'o, avec l'aide et le code contribué par de nombreuses autres personnes. Depuis la publication du RFC 1510, de nombreuses personnes ont proposé des extensions et des révisions au protocole. Ce document reflète certaines de ces propositions. Lorsque de tels changements impliquaient un effort significatif, le document cite la contribution du proposant.
Des implémentations de référence des versions 4 et 5 de Kerberos sont disponibles publiquement, et des implémentations commerciales ont été développées et sont largement utilisées. Les détails sur les différences entre les versions 4 et 5 peuvent être trouvés dans [KNT94].
Les mots-clés "DOIT", "NE DOIT PAS", "REQUIRED", "SHALL", "SHALL NOT", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMENDED", "PEUT" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].
1.1. Le Protocole Kerberos
Kerberos fournit un moyen de vérifier les identités des principaux (principals) (par exemple, un utilisateur de station de travail ou un serveur réseau) sur un réseau ouvert (non protégé). Cela s'accomplit sans s'appuyer sur des 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 le long du 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 du champ d'application de ce document) peuvent prévoir 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 des 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, Authentication Server) pour des "credentials" (identifiants) pour un serveur donné. L'AS répond avec ces identifiants, chiffrés dans la clé du client. Les identifiants se composent d'un "ticket" pour le serveur et d'une clé de chiffrement temporaire (souvent appelée "clé de session", session key). 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 les communications ultérieures entre les deux parties ou pour échanger une clé de sous-session distincte à utiliser pour chiffrer les communications ultérieures. Notez que de nombreuses applications n'utilisent les fonctions de Kerberos qu'au moment de l'initiation d'une connexion réseau basée sur un 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.
L'implémentation 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 des principaux (c'est-à-dire, des utilisateurs et des 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 Generic Security Services (GSS-API) décrite dans un document séparé [RFC4121]. Ces appels entraînent la transmission des messages nécessaires pour réaliser l'authentification.
Le protocole Kerberos se compose de plusieurs sous-protocoles (ou échanges). Il existe deux méthodes de base par lesquelles un client peut demander des identifiants à 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 concerne un ticket d'octroi de tickets (TGT, Ticket-Granting Ticket), qui peut ensuite être utilisé avec le serveur d'octroi de tickets (TGS, Ticket-Granting Server). 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 des points d'entrée de protocole différents au sein d'un seul serveur Kerberos.
Une fois obtenus, les identifiants peuvent être utilisés pour vérifier l'identité des principaux dans une transaction, pour garantir l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir toute protection qui peut être nécessaire.
Pour vérifier les identités des principaux dans une transaction, le client transmet le ticket au serveur d'application. Étant donné que le ticket est envoyé "en clair" (des parties de celui-ci sont chiffrées, mais ce chiffrement ne contrecarre pas la rejouabilité) 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 à qui le ticket a été émis. Cette information (appelée l'authentificateur, authenticator) est chiffrée dans la clé de session et inclut un horodatage (timestamp). L'horodatage prouve que le message a été généré récemment et n'est pas une rejouabilité. Le chiffrement de l'authentificateur dans la clé de session prouve qu'il a été généré par une partie possédant la clé de session. Étant donné que 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 les principaux peut également être garantie en utilisant la clé de session (transmise dans le ticket et contenue dans les identifiants). Cette approche permet la détection des attaques par rejeu et des attaques de modification du 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 de condensat, hash or digest function) du message du client, indexée avec la clé de session. La confidentialité et l'intégrité des messages échangés entre les principaux 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'authentificateur.
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, par exemple lors de l'ajout de nouveaux principaux ou de la modification 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, Kerberos Administration Server). 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.
1.2. Opération Inter-Domaines
Le protocole Kerberos est conçu pour fonctionner au-delà des limites organisationnelles. Un client d'une organisation peut être authentifié auprès d'un serveur d'une autre organisation. Chaque organisation souhaitant exécuter un serveur Kerberos établit son propre "domaine" (realm). Le nom du domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider d'honorer ou non une demande.
En établissant des clés "inter-domaines", les administrateurs de deux domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs d'autres domaines. L'échange de clés inter-domaines (une clé distincte peut être utilisée pour chaque direction) enregistre le service d'octroi de tickets de chaque domaine en tant que principal dans l'autre domaine. Un client est alors capable d'obtenir un TGT pour le service d'octroi de tickets du domaine distant depuis son domaine local. Lorsque ce TGT est utilisé, le service d'octroi de tickets distant utilise la clé inter-domaines (qui diffère généralement de sa propre clé TGS normale) pour déchiffrer le TGT; ainsi il est certain que le ticket a été émis par le propre TGS du client. Les tickets émis par le service d'octroi de tickets distant indiqueront au service final que le client a été authentifié depuis un autre domaine.
Sans opération inter-domaines, et avec l'autorisation appropriée, le client peut organiser l'enregistrement d'un principal nommé séparément dans un domaine distant et s'engager dans des échanges normaux avec les services de ce domaine. Cependant, même pour un petit nombre de clients, cela devient fastidieux, et des méthodes plus automatiques comme décrites ici sont nécessaires.
On dit qu'un domaine communique avec un autre domaine si les deux domaines partagent une clé inter-domaines, ou si le domaine local partage une clé inter-domaines avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification (authentication path) est la séquence de domaines intermédiaires qui sont traversés lors de la communication d'un domaine à un autre.
Les domaines peuvent être organisés de manière hiérarchique. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaines n'est pas directement partagée par deux domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification.
Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données afin de construire un chemin d'authentification entre les domaines.
Bien que les domaines soient généralement hiérarchiques, les domaines intermédiaires peuvent être contournés pour réaliser une authentification inter-domaines via des chemins d'authentification alternatifs. (Ceux-ci pourraient être établis pour rendre la communication entre deux domaines plus efficace.) Il est important pour le service final de savoir quels domaines ont été traversés lors de la décision de la confiance à accorder au processus d'authentification. Pour faciliter cette décision, un champ dans chaque ticket contient les noms des domaines qui ont été impliqués dans l'authentification du client.
Le serveur d'application est ultimement responsable d'accepter ou de rejeter l'authentification et DEVRAIT vérifier le champ de transit (transited field). Le serveur d'application peut choisir de s'appuyer sur le Centre de Distribution de Clés (KDC, Key Distribution Center) pour le domaine du serveur d'application afin de vérifier le champ de transit. Le KDC du serveur d'application définira l'indicateur TRANSITED-POLICY-CHECKED dans ce cas. Les KDC pour les domaines intermédiaires peuvent également vérifier le champ de transit lorsqu'ils émettent des TGT pour d'autres domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas le champ de transit en définissant l'indicateur DISABLE-TRANSITED-CHECK. Les KDC DEVRAIENT honorer cet indicateur.
1.3. Choisir un Principal avec Lequel Communiquer
Le protocole Kerberos fournit les moyens de vérifier (sous réserve des hypothèses de la section 1.6) que l'entité avec laquelle on communique est la même entité qui a été enregistrée auprès du KDC en utilisant l'identité revendiquée (nom de principal). Il est toujours nécessaire de déterminer si cette identité correspond à l'entité avec laquelle on a l'intention de communiquer.
Lorsque des données appropriées ont été échangées à l'avance, l'application peut effectuer cette détermination syntaxiquement en se basant sur la spécification du protocole d'application, les informations fournies par l'utilisateur et les fichiers de configuration. Par exemple, le nom de principal du serveur (y compris le domaine) pour un serveur telnet pourrait être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande telnet), du préfixe "host/" spécifié dans la spécification du protocole d'application, et d'un mappage vers un domaine Kerberos dérivé syntaxiquement de la partie domaine du nom d'hôte spécifié et des informations de la base de données locale des domaines Kerberos.