3.3. The Ticket-Granting Service (TGS) Exchange (L'Échange du Service d'Octroi de Tickets)
3.3. L'Échange du Service d'Octroi de Tickets (TGS)
Résumé
| Direction du message | Type de message | Section |
|---|---|---|
| 1. Client vers Kerberos | KRB_TGS_REQ | 5.4.1 |
| 2. Kerberos vers client | KRB_TGS_REP ou KRB_ERROR | 5.4.2, 5.9.1 |
L'échange TGS entre un client et le serveur TGS Kerberos est initié par un client lorsqu'il cherche à obtenir des identifiants d'authentification pour un serveur donné (qui peut être enregistré dans un domaine distant), lorsqu'il cherche à renouveler ou à valider un ticket existant, ou lorsqu'il cherche à obtenir un ticket proxy. Dans le premier cas, le client doit avoir déjà acquis un ticket pour le service d'octroi de tickets en utilisant l'échange AS (le TGT est généralement obtenu lorsqu'un client s'authentifie initialement au système, comme lorsqu'un utilisateur se connecte). Le format du message pour l'échange TGS est presque identique à celui de l'échange AS. La principale différence est que le chiffrement et le déchiffrement dans l'échange TGS ne se font pas sous la clé du client. Au lieu de cela, la clé de session du TGT ou du ticket renouvelable, ou la clé de sous-session de l'Authenticator est utilisée. Comme c'est le cas pour tous les serveurs d'application, les tickets expirés ne sont pas acceptés par le TGS, donc une fois qu'un ticket renouvelable ou TGT expire, le client doit utiliser un échange séparé pour obtenir des tickets valides.
L'échange TGS consiste en deux messages: une demande (KRB_TGS_REQ) du client vers le serveur d'octroi de tickets Kerberos, et une réponse (KRB_TGS_REP ou KRB_ERROR). Le message KRB_TGS_REQ inclut des informations authentifiant le client ainsi qu'une demande d'identifiants. Les informations d'authentification consistent en l'en-tête d'authentification (KRB_AP_REQ), qui inclut le ticket d'octroi de tickets, renouvelable ou invalide précédemment obtenu par le client. Dans les cas TGT et proxy, la demande PEUT inclure un ou plusieurs des éléments suivants: une liste d'adresses réseau, une collection de données d'autorisation typées à sceller dans le ticket pour une utilisation d'autorisation par le serveur d'application, ou des tickets supplémentaires (dont l'utilisation est décrite plus tard). La réponse TGS (KRB_TGS_REP) contient les identifiants demandés, chiffrés dans la clé de session du TGT ou du ticket renouvelable, ou, si présente, dans la clé de sous-session de l'Authenticator (partie de l'en-tête d'authentification). Le message KRB_ERROR contient un code d'erreur et un texte expliquant ce qui n'a pas fonctionné. Le message KRB_ERROR n'est pas chiffré. Le message KRB_TGS_REP contient des informations qui peuvent être utilisées pour détecter les rejeux et pour l'associer au message auquel il répond. Le message KRB_ERROR contient également des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Les mêmes commentaires sur la protection de l'intégrité des messages KRB_ERROR mentionnés dans la Section 3.1 s'appliquent à l'échange TGS.
3.3.1. Génération du Message KRB_TGS_REQ
Avant d'envoyer une demande au service d'octroi de tickets, le client DOIT déterminer dans quel domaine le serveur d'application est censé être enregistré. Cela peut être accompli de plusieurs façons. Il peut être connu à l'avance (puisque le domaine fait partie de l'identifiant de principal), il peut être stocké dans un serveur de noms, ou il peut être obtenu à partir d'un fichier de configuration. Si le domaine à utiliser est obtenu à partir d'un serveur de noms, il existe un danger d'être trompé si le service de noms fournissant le nom de domaine n'est pas authentifié. Cela pourrait résulter en l'utilisation d'un domaine qui a été compromis, ce qui donnerait à un attaquant la capacité de compromettre l'authentification du serveur d'application auprès du client.
Si le client connaît le nom de principal de service et le domaine et qu'il ne possède pas déjà un TGT pour le domaine approprié, alors un doit être obtenu. Cela est d'abord tenté en demandant un TGT pour le domaine de destination à partir d'un serveur Kerberos pour lequel le client possède un TGT (en utilisant le message KRB_TGS_REQ de manière récursive). Le serveur Kerberos PEUT renvoyer un TGT pour le domaine désiré, auquel cas on peut procéder. Alternativement, le serveur Kerberos PEUT renvoyer un TGT pour un domaine qui est 'plus proche' du domaine désiré (plus loin le long du chemin hiérarchique standard entre le domaine du client et le domaine du serveur de domaine demandé). Notez que dans ce cas, une mauvaise configuration des serveurs Kerberos peut causer des boucles dans le chemin d'authentification résultant, que le client devrait être prudent de détecter et d'éviter.
Si le serveur Kerberos renvoie un TGT pour un domaine 'plus proche' que le domaine désiré, le client PEUT utiliser la configuration de politique locale pour vérifier que le chemin d'authentification utilisé est acceptable. Alternativement, un client PEUT choisir son propre chemin d'authentification, plutôt que de s'appuyer sur le serveur Kerberos pour en sélectionner un. Dans les deux cas, toute politique ou information de configuration utilisée pour choisir ou valider les chemins d'authentification, que ce soit par le serveur Kerberos ou par le client, DOIT être obtenue à partir d'une source de confiance.
Lorsqu'un client obtient un TGT qui est 'plus proche' du domaine de destination, le client PEUT mettre en cache ce ticket et le réutiliser dans de futurs échanges KRB-TGS avec des services dans le domaine 'plus proche'. Cependant, si le client devait obtenir un TGT pour le domaine 'plus proche' en commençant au KDC initial plutôt que dans le cadre de l'obtention d'un autre ticket, alors un chemin plus court vers le domaine 'plus proche' pourrait être utilisé. Ce chemin plus court peut être souhaitable car moins de KDC intermédiaires connaîtraient la clé de session du ticket impliqué. Pour cette raison, les clients DEVRAIENT évaluer s'ils font confiance aux domaines traversés pour obtenir le ticket 'plus proche' lors de la prise d'une décision d'utiliser le ticket à l'avenir.
Une fois que le client obtient un TGT pour le domaine approprié, il détermine quels serveurs Kerberos servent ce domaine et en contacte un. La liste peut être obtenue via un fichier de configuration ou un service réseau, ou elle PEUT être générée à partir du nom du domaine. Tant que les clés secrètes échangées par les domaines sont gardées secrètes, seul un déni de service résulte de l'utilisation d'un faux serveur Kerberos.
Comme dans l'échange AS, le client PEUT spécifier un certain nombre d'options dans le message KRB_TGS_REQ. L'une de ces options est l'option ENC-TKT-IN-SKEY utilisée pour l'authentification utilisateur-à-utilisateur. Un aperçu de l'authentification utilisateur-à-utilisateur peut être trouvé dans la Section 3.7. Lors de la génération du message KRB_TGS_REQ, cette option indique que le client inclut un TGT obtenu du serveur d'application dans le champ de tickets supplémentaires de la demande et que le KDC DEVRAIT chiffrer le ticket pour le serveur d'application en utilisant la clé de session de ce ticket supplémentaire, au lieu d'une clé de serveur de la base de données principale.
Le client prépare le message KRB_TGS_REQ, fournissant un en-tête d'authentification comme élément du champ padata, et incluant les mêmes champs que ceux utilisés dans le message KRB_AS_REQ ainsi que plusieurs champs optionnels: le champ enc-authorization-data pour l'utilisation du serveur d'application et les tickets supplémentaires requis par certaines options.
Lors de la préparation de l'en-tête d'authentification, le client peut sélectionner une clé de sous-session sous laquelle la réponse du serveur Kerberos sera chiffrée. Si le client sélectionne une clé de sous-session, il faut veiller à assurer le caractère aléatoire de la clé de sous-session sélectionnée.
Si la clé de sous-session n'est pas spécifiée, la clé de session du TGT sera utilisée. Si l'enc-authorization-data est présent, il DOIT être chiffré dans la clé de sous-session, si présente, de la partie authentificateur de l'en-tête d'authentification, ou, si non présente, en utilisant la clé de session du TGT.
Une fois préparé, le message est envoyé à un serveur Kerberos pour le domaine de destination.
3.3.2. Réception du Message KRB_TGS_REQ
Le message KRB_TGS_REQ est traité de manière similaire au message KRB_AS_REQ, mais il existe de nombreuses vérifications supplémentaires à effectuer. Tout d'abord, le serveur Kerberos DOIT déterminer pour quel serveur le ticket accompagnant est destiné, et il DOIT sélectionner la clé appropriée pour le déchiffrer. Pour un message KRB_TGS_REQ normal, il sera pour le service d'octroi de tickets, et la clé du TGS sera utilisée. Si le TGT a été émis par un autre domaine, alors la clé inter-domaines appropriée DOIT être utilisée. Si (a) le ticket accompagnant n'est pas un TGT pour le domaine actuel, mais est pour un serveur d'application dans le domaine actuel, (b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans la demande, et (c) le serveur pour lequel un ticket est demandé est le serveur nommé dans le ticket accompagnant, alors le KDC déchiffrera le ticket dans l'en-tête d'authentification en utilisant la clé du serveur pour lequel il a été émis. Si aucun ticket ne peut être trouvé dans le champ padata, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est renvoyée.
Une fois que le ticket accompagnant a été déchiffré, la somme de contrôle fournie par l'utilisateur dans l'Authenticator DOIT être vérifiée par rapport au contenu de la demande, et le message DOIT être rejeté si les sommes de contrôle ne correspondent pas (avec un code d'erreur KRB_AP_ERR_MODIFIED) ou si la somme de contrôle n'est pas résistante aux collisions (avec un code d'erreur KRB_AP_ERR_INAPP_CKSUM). Si le type de somme de contrôle n'est pas pris en charge, l'erreur KDC_ERR_SUMTYPE_NOSUPP est renvoyée. Si les données d'autorisation sont présentes, elles sont déchiffrées en utilisant la clé de sous-session de l'Authenticator.
Si l'un des déchiffrements indique des vérifications d'intégrité échouées, l'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée.
Comme discuté dans la Section 3.1.2, le KDC DOIT envoyer un message KRB_TGS_REP valide s'il reçoit un message KRB_TGS_REQ identique à un qu'il a récemment traité. Cependant, si l'authentificateur est un rejeu, mais que le reste de la demande n'est pas identique, alors le KDC DEVRAIT renvoyer KRB_AP_ERR_REPEAT.
3.3.3. Génération du Message KRB_TGS_REP
Le message KRB_TGS_REP partage son format avec le KRB_AS_REP (KRB_KDC_REP), mais avec son champ de type défini sur KRB_TGS_REP. La spécification détaillée se trouve dans la Section 5.4.2.
La réponse inclura un ticket pour le serveur demandé ou pour un serveur d'octroi de tickets d'un KDC intermédiaire à contacter pour obtenir le ticket demandé. La base de données Kerberos est interrogée pour récupérer l'enregistrement du serveur approprié (y compris la clé avec laquelle le ticket sera chiffré). Si la demande est pour un TGT pour un domaine distant, et si aucune clé n'est partagée avec le domaine demandé, alors le serveur Kerberos sélectionnera le domaine 'le plus proche' du domaine demandé avec lequel il partage une clé et utilisera ce domaine à la place. C'est le seul cas où la réponse du KDC sera pour un serveur différent de celui demandé par le client.
Par défaut, le champ d'adresse, le nom et le domaine du client, la liste des domaines traversés, l'heure d'authentification initiale, l'heure d'expiration et les données d'autorisation du ticket nouvellement émis seront copiés du TGT ou du ticket renouvelable. Si le champ transité doit être mis à jour, mais que le type transité n'est pas pris en charge, l'erreur KDC_ERR_TRTYPE_NOSUPP est renvoyée.
Si la demande spécifie un endtime, alors l'endtime du nouveau ticket est défini sur le minimum de (a) cette demande, (b) l'endtime du TGT, et (c) le starttime du TGT plus le minimum de la durée de vie maximale pour le serveur d'application et la durée de vie maximale pour le domaine local (la durée de vie maximale pour le principal demandeur a déjà été appliquée lorsque le TGT a été émis). Si le nouveau ticket doit être un renouvellement, alors l'endtime ci-dessus est remplacé par le minimum de (a) la valeur du champ renew_till du ticket et (b) le starttime du nouveau ticket plus la durée de vie (endtime-starttime) de l'ancien ticket.
Si l'option FORWARDED a été demandée, alors le ticket résultant contiendra les adresses spécifiées par le client. Cette option ne sera honorée que si l'indicateur FORWARDABLE est défini dans le TGT. L'option PROXY est similaire; le ticket résultant contiendra les adresses spécifiées par le client. Elle ne sera honorée que si l'indicateur PROXIABLE dans le TGT est défini. L'option PROXY ne sera pas honorée sur les demandes de TGT supplémentaires.
Si le starttime demandé est absent, indique une heure dans le passé, ou est dans la fenêtre de décalage d'horloge acceptable pour le KDC et que l'option POSTDATE n'a pas été spécifiée, alors le starttime du ticket est défini sur l'heure actuelle du serveur d'authentification. S'il indique une heure dans le futur au-delà du décalage d'horloge acceptable, mais que l'option POSTDATED n'a pas été spécifiée ou que l'indicateur MAY-POSTDATE n'est pas défini dans le TGT, alors l'erreur KDC_ERR_CANNOT_POSTDATE est renvoyée. Sinon, si le TGT a l'indicateur MAY-POSTDATE défini, alors le ticket résultant sera postdaté, et le starttime demandé est vérifié par rapport à la politique du domaine local. S'il est acceptable, le starttime du ticket est défini comme demandé, et l'indicateur INVALID est défini. Le ticket postdaté DOIT être validé avant utilisation en le présentant au KDC après que le starttime soit atteint. Cependant, en aucun cas le starttime, l'endtime ou le renew-till time d'un ticket postdaté nouvellement émis ne peut s'étendre au-delà du renew-till time du TGT.
Si l'option ENC-TKT-IN-SKEY a été spécifiée et qu'un ticket supplémentaire a été inclus dans la demande, cela indique que le client utilise l'authentification utilisateur-à-utilisateur pour prouver son identité à un serveur qui n'a pas accès à une clé persistante. La Section 3.7 décrit l'effet de cette option sur l'ensemble du protocole Kerberos. Lors de la génération du message KRB_TGS_REP, cette option dans le message KRB_TGS_REQ indique au KDC de déchiffrer le ticket supplémentaire en utilisant la clé du serveur auquel le ticket supplémentaire a été émis et de vérifier qu'il s'agit d'un TGT. Si le nom du serveur demandé est manquant dans la demande, le nom du client dans le ticket supplémentaire sera utilisé. Sinon, le nom du serveur demandé sera comparé au nom du client dans le ticket supplémentaire. S'il est différent, la demande sera rejetée. Si la demande réussit, la clé de session du ticket supplémentaire sera utilisée pour chiffrer le nouveau ticket qui est émis au lieu d'utiliser la clé du serveur pour lequel le nouveau ticket sera utilisé.
Si (a) le nom du serveur dans le ticket qui est présenté au KDC dans le cadre de l'en-tête d'authentification n'est pas celui du TGS lui-même, (b) le serveur est enregistré dans le domaine du KDC, et (c) l'option RENEW est demandée, alors le KDC vérifiera que l'indicateur RENEWABLE est défini dans le ticket, que l'indicateur INVALID n'est pas défini dans le ticket, et que le renew_till time est encore dans le futur. Si l'option VALIDATE est demandée, le KDC vérifiera que le starttime est passé et que l'indicateur INVALID est défini. Si l'option PROXY est demandée, alors le KDC vérifiera que l'indicateur PROXIABLE est défini dans le ticket. Si les tests réussissent et que le ticket passe la vérification de liste noire décrite dans la section suivante, le KDC émettra le nouveau ticket approprié.
La partie texte chiffré de la réponse dans le message KRB_TGS_REP est chiffrée dans la clé de sous-session de l'Authenticator, si présente, ou dans la clé de session du TGT. Elle n'est pas chiffrée en utilisant la clé secrète du client. De plus, la date d'expiration de la clé du client et les champs de numéro de version de clé sont omis puisque ces valeurs sont stockées avec l'enregistrement de base de données du client, et cet enregistrement n'est pas nécessaire pour satisfaire une demande basée sur un TGT.
3.3.3.1. Vérification des Tickets Révoqués
Chaque fois qu'une demande est faite au serveur d'octroi de tickets, le(s) ticket(s) présenté(s) est (sont) vérifié(s) par rapport à une liste noire de tickets qui ont été annulés. Cette liste noire pourrait être implémentée en stockant une plage d'horodatages d'émission pour les 'tickets suspects'; si un ticket présenté avait un authtime dans cette plage, il serait rejeté. De cette façon, un TGT volé ou un ticket renouvelable ne peut pas être utilisé pour obtenir des tickets supplémentaires (renouvellements ou autres) une fois que le vol a été signalé au KDC pour le domaine dans lequel le serveur réside. Tout ticket normal obtenu avant qu'il ne soit signalé volé sera toujours valide (parce que les tickets ne nécessitent aucune interaction avec le KDC), mais seulement jusqu'à son heure d'expiration normale. Si des TGT ont été émis pour l'authentification inter-domaines, l'utilisation du TGT inter-domaines ne sera pas affectée sauf si la liste noire est propagée aux KDC pour les domaines pour lesquels de tels tickets inter-domaines ont été émis.
3.3.3.2. Codage du Champ Transité
Si l'identité du serveur dans le TGT qui est présenté au KDC dans le cadre de l'en-tête d'authentification est celle du service d'octroi de tickets, mais que le TGT a été émis depuis un autre domaine, le KDC recherchera la clé inter-domaines partagée avec ce domaine et utilisera cette clé pour déchiffrer le ticket. Si le ticket est valide, alors le KDC honorera la demande, sous réserve des contraintes décrites ci-dessus dans la section décrivant l'échange AS. La partie domaine de l'identité du client sera prise du TGT. Le nom du domaine qui a émis le TGT, s'il n'est pas le domaine du principal client, sera ajouté au champ transité du ticket à émettre. Cela est accompli en lisant le champ transité du TGT (qui est traité comme un ensemble non ordonné de noms de domaines), en ajoutant le nouveau domaine à l'ensemble, puis en construisant et en écrivant sa forme codée (abrégée) (cela peut impliquer un réarrangement du codage existant).
Notez que le service d'octroi de tickets n'ajoute pas le nom de son propre domaine. Au lieu de cela, sa responsabilité est d'ajouter le nom du domaine précédent. Cela empêche un serveur Kerberos malveillant d'omettre intentionnellement son propre nom (il pourrait, cependant, omettre les noms d'autres domaines).
Les noms du domaine local et du domaine du principal ne doivent pas être inclus dans le champ transité. Ils apparaissent ailleurs dans le ticket et tous deux sont connus pour avoir pris part à l'authentification du principal. Parce que les points de terminaison ne sont pas inclus, l'authentification locale et inter-domaines à un seul saut résultent en un champ transité qui est vide.
Parce que ce champ a le nom de chaque domaine traversé qui lui est ajouté, il pourrait potentiellement être très long. Pour diminuer la longueur de ce champ, son contenu est codé. Le codage initialement pris en charge est optimisé pour le cas normal de communication inter-domaines: un arrangement hiérarchique de domaines utilisant soit des noms de domaine de style domaine soit X.500. Ce codage (appelé DOMAIN-X500-COMPRESS) est maintenant décrit.
Les noms de domaine dans le champ transité sont séparés par une ",". Les caractères ",", "", les "." de fin et les espaces de début (" ") sont des caractères spéciaux, et s'ils font partie d'un nom de domaine, ils DOIVENT être cités dans le champ transité en les précédant d'un "".
Un nom de domaine se terminant par un "." est interprété comme étant ajouté en préfixe au domaine précédent. Par exemple, nous pouvons coder la traversée de EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU et CS.WASHINGTON.EDU comme:
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS."
Notez que si ATHENA.MIT.EDU ou CS.WASHINGTON.EDU étaient des points de terminaison, ils ne seraient pas inclus dans ce champ, et nous aurions:
"EDU,MIT.,WASHINGTON.EDU"
Un nom de domaine commençant par un "/" est interprété comme étant ajouté en suffixe au domaine précédent. Pour les besoins de l'ajout, le domaine précédant le premier domaine listé est considéré comme le domaine null (""). Si un nom de domaine commençant par un "/" doit être autonome, alors il DEVRAIT être précédé d'un espace (" "). Par exemple, nous pouvons coder la traversée de /COM/HP/APOLLO, /COM/HP, /COM et /COM/DEC comme:
"/COM,/HP,/APOLLO, /COM/DEC"
Comme dans l'exemple ci-dessus, si /COM/HP/APOLLO et /COM/DEC étaient des points de terminaison, ils ne seraient pas inclus dans ce champ, et nous aurions:
"/COM,/HP"
Un sous-champ null précédant ou suivant une "," indique que tous les domaines entre le domaine précédent et le domaine suivant ont été traversés. Pour les besoins de l'interprétation des sous-champs null, le domaine du client est considéré comme précédant ceux du champ transité, et le domaine du serveur est considéré comme les suivant. Ainsi, "," signifie que tous les domaines le long du chemin entre le client et le serveur ont été traversés. ",EDU, /COM," signifie que tous les domaines depuis le domaine du client jusqu'à EDU (dans une hiérarchie de style domaine) ont été traversés, et que tout depuis /COM jusqu'au domaine du serveur dans un style X.500 a également été traversé. Cela pourrait se produire si le domaine EDU dans une hiérarchie partage une clé inter-domaines directement avec le domaine /COM dans une autre hiérarchie.
3.3.4. Réception du Message KRB_TGS_REP
Lorsque le KRB_TGS_REP est reçu par le client, il est traité de la même manière que le traitement KRB_AS_REP décrit ci-dessus. La principale différence est que la partie texte chiffré de la réponse doit être déchiffrée en utilisant la clé de sous-session de l'Authenticator, si elle a été spécifiée dans la demande, ou la clé de session du TGT, plutôt que la clé secrète du client. Le nom de serveur renvoyé dans la réponse est le vrai nom de principal du service.