2. Ticket Flag Uses and Requests (Utilisations et Demandes des Indicateurs de Ticket)

2. Utilisations et Demandes des Indicateurs de Ticket

Chaque ticket Kerberos contient un ensemble d'indicateurs (flags) qui sont utilisés pour indiquer les attributs de ce ticket. La plupart des indicateurs peuvent être demandés par un client lorsque le ticket est obtenu; certains sont automatiquement activés et désactivés par un serveur Kerberos selon les besoins. Les sections suivantes expliquent ce que signifient les différents indicateurs et donnent des exemples de raisons de les utiliser. À l'exception de l'indicateur INVALID, les clients DOIVENT ignorer les indicateurs de ticket qui ne sont pas reconnus. Les KDC DOIVENT ignorer les options KDC qui ne sont pas reconnues. Certaines implémentations du RFC 1510 sont connues pour rejeter les options KDC inconnues, donc les clients peuvent avoir besoin de renvoyer une demande sans les nouvelles options KDC si la demande a été rejetée lorsqu'elle a été envoyée avec des options ajoutées depuis le RFC 1510. Étant donné que les nouveaux KDC ignoreront les options inconnues, les clients DOIVENT confirmer que le ticket retourné par le KDC répond à leurs besoins.

Notez qu'il n'est pas, en général, possible de déterminer si une option n'a pas été honorée parce qu'elle n'a pas été comprise ou parce qu'elle a été rejetée par la configuration ou la politique. Lors de l'ajout d'une nouvelle option au protocole Kerberos, les concepteurs devraient considérer si la distinction est importante pour leur option. Si c'est le cas, un mécanisme permettant au KDC de renvoyer une indication que l'option a été comprise mais rejetée doit être fourni dans la spécification de l'option. Souvent dans de tels cas, le mécanisme doit être suffisamment large pour permettre le renvoi d'une erreur ou d'une raison.

2.1. Tickets Initiaux, Pré-authentifiés et Authentifiés par Matériel

L'indicateur INITIAL indique qu'un ticket a été émis en utilisant le protocole AS, plutôt qu'émis sur la base d'un TGT. Les serveurs d'application qui veulent exiger la connaissance démontrée de la clé secrète d'un client (par exemple, un programme de changement de mot de passe) peuvent insister pour que cet indicateur soit défini dans tous les tickets qu'ils acceptent, et peuvent ainsi être assurés que la clé du client a été récemment présentée au serveur d'authentification.

Les indicateurs PRE-AUTHENT et HW-AUTHENT fournissent des informations supplémentaires sur l'authentification initiale, que le ticket actuel ait été émis directement (auquel cas INITIAL sera également défini) ou émis sur la base d'un TGT (auquel cas l'indicateur INITIAL est clair, mais les indicateurs PRE-AUTHENT et HW-AUTHENT sont transmis depuis le TGT).

2.2. Tickets Invalides

L'indicateur INVALID indique qu'un ticket est invalide. Les serveurs d'application DOIVENT rejeter les tickets qui ont cet indicateur défini. Un ticket postdaté sera émis sous cette forme. Les tickets invalides DOIVENT être validés par le KDC avant utilisation, en étant présentés au KDC dans une demande TGS avec l'option VALIDATE spécifiée. Le KDC ne validera les tickets qu'après que leur heure de début (starttime) soit passée. La validation est requise afin que les tickets postdatés qui ont été volés avant leur heure de début puissent être rendus définitivement invalides (via un mécanisme de liste noire, hot-list) (voir Section 3.3.3.1).

2.3. Tickets Renouvelables

Les applications peuvent souhaiter détenir des tickets qui peuvent être valides pendant de longues périodes. Cependant, cela peut exposer leurs identifiants à un vol potentiel pendant des périodes tout aussi longues, et ces identifiants volés seraient valides jusqu'à l'heure d'expiration du ou des tickets. Simplement utiliser des tickets de courte durée et en obtenir de nouveaux périodiquement nécessiterait que le client ait un accès à long terme à sa clé secrète, un risque encore plus grand. Les tickets renouvelables peuvent être utilisés pour atténuer les conséquences d'un vol. Les tickets renouvelables ont deux "heures d'expiration": la première est lorsque l'instance actuelle du ticket expire, et la seconde est la dernière valeur permissible pour une heure d'expiration individuelle. Un client d'application doit périodiquement (c'est-à-dire, avant son expiration) présenter un ticket renouvelable au KDC, avec l'option RENEW définie dans la demande KDC. Le KDC émettra un nouveau ticket avec une nouvelle clé de session et une heure d'expiration ultérieure. Tous les autres champs du ticket sont laissés non modifiés par le processus de renouvellement. Lorsque la dernière heure d'expiration permissible arrive, le ticket expire définitivement. À chaque renouvellement, le KDC PEUT consulter une liste noire pour déterminer si le ticket a été signalé volé depuis son dernier renouvellement; il refusera de renouveler les tickets volés, et ainsi la durée de vie utilisable des tickets volés est réduite.

L'indicateur RENEWABLE dans un ticket n'est normalement interprété que par le service d'octroi de tickets (discuté ci-dessous dans la Section 3.3). Il peut généralement être ignoré par les serveurs d'application. Cependant, certains serveurs d'application particulièrement prudents PEUVENT interdire les tickets renouvelables.

Si un ticket renouvelable n'est pas renouvelé avant son heure d'expiration, le KDC ne renouvellera pas le ticket. L'indicateur RENEWABLE est réinitialisé par défaut, mais un client PEUT demander qu'il soit défini en définissant l'option RENEWABLE dans le message KRB_AS_REQ. S'il est défini, alors le champ renew-till dans le ticket contient l'heure après laquelle le ticket ne peut plus être renouvelé.

2.4. Tickets Postdatés

Les applications peuvent occasionnellement avoir besoin d'obtenir des tickets pour une utilisation bien ultérieure; par exemple, un système de soumission par lots aurait besoin de tickets valides au moment où le travail par lots est traité. Cependant, il est dangereux de détenir des tickets valides dans une file d'attente de lots, car ils seront en ligne plus longtemps et plus sujets au vol. Les tickets postdatés fournissent un moyen d'obtenir ces tickets du KDC au moment de la soumission du travail, mais de les laisser "dormants" jusqu'à ce qu'ils soient activés et validés par une demande ultérieure au KDC. Si un vol de ticket était signalé dans l'intervalle, le KDC refuserait de valider le ticket, et le voleur serait déjoué.

L'indicateur MAY-POSTDATE dans un ticket n'est normalement interprété que par le service d'octroi de tickets. Il peut être ignoré par les serveurs d'application. Cet indicateur DOIT être défini dans un TGT afin d'émettre un ticket postdaté basé sur le ticket présenté. Il est réinitialisé par défaut; un client PEUT le demander en définissant l'option ALLOW-POSTDATE dans le message KRB_AS_REQ. Cet indicateur ne permet pas à un client d'obtenir un TGT postdaté; les TGT postdatés ne peuvent être obtenus qu'en demandant le postdatage dans le message KRB_AS_REQ. La durée de vie (endtime-starttime) d'un ticket postdaté sera la durée de vie restante du TGT au moment de la demande, sauf si l'option RENEWABLE est également définie, auquel cas elle peut être la durée de vie complète (endtime-starttime) du TGT. Le KDC PEUT limiter jusqu'à quel point dans le futur un ticket peut être postdaté.

L'indicateur POSTDATED indique qu'un ticket a été postdaté. Le serveur d'application peut vérifier le champ authtime dans le ticket pour voir quand l'authentification originale a eu lieu. Certains services PEUVENT choisir de rejeter les tickets postdatés, ou ils peuvent seulement les accepter dans une certaine période après l'authentification originale. Lorsque le KDC émet un ticket POSTDATED, il sera également marqué comme INVALID, de sorte que le client d'application DOIT présenter le ticket au KDC pour être validé avant utilisation.

2.5. Tickets Proxyables et Proxy

Par moments, il peut être nécessaire pour un principal de permettre à un service d'effectuer une opération en son nom. Le service doit être capable d'assumer l'identité du client, mais seulement dans un but particulier. Un principal peut permettre à un service de le faire en lui accordant un proxy.

Le processus d'octroi d'un proxy en utilisant les indicateurs proxy et proxiable est utilisé pour fournir des identifiants à utiliser avec des services spécifiques. Bien que conceptuellement également un proxy, les utilisateurs souhaitant déléguer leur identité sous une forme utilisable à toutes fins DOIVENT utiliser le mécanisme de transmission de tickets décrit dans la section suivante pour transmettre un TGT.

L'indicateur PROXIABLE dans un ticket n'est normalement interprété que par le service d'octroi de tickets. Il peut être ignoré par les serveurs d'application. Lorsqu'il est défini, cet indicateur indique au serveur d'octroi de tickets qu'il est acceptable d'émettre un nouveau ticket (mais pas un TGT) avec une adresse réseau différente basée sur ce ticket. Cet indicateur est défini s'il est demandé par le client lors de l'authentification initiale. Par défaut, le client demandera qu'il soit défini lors de la demande d'un TGT, et qu'il soit réinitialisé lors de la demande de tout autre ticket.

Cet indicateur permet à un client de passer un proxy à un serveur pour effectuer une demande distante en son nom (par exemple, un client de service d'impression peut donner au serveur d'impression un proxy pour accéder aux fichiers du client sur un serveur de fichiers particulier afin de satisfaire une demande d'impression).

Afin de compliquer l'utilisation des identifiants volés, les tickets Kerberos ne sont souvent valides qu'à partir des adresses réseau spécifiquement incluses dans le ticket, mais il est permis comme option de politique d'autoriser les demandes et d'émettre des tickets sans adresses réseau spécifiées. Lors de l'octroi d'un proxy, le client DOIT spécifier la nouvelle adresse réseau à partir de laquelle le proxy doit être utilisé ou indiquer que le proxy doit être émis pour une utilisation depuis n'importe quelle adresse.

L'indicateur PROXY est défini dans un ticket par le TGS lorsqu'il émet un ticket proxy. Les serveurs d'application PEUVENT vérifier cet indicateur; et à leur option, ils PEUVENT exiger une authentification supplémentaire de l'agent présentant le proxy afin de fournir une piste d'audit.

2.6. Tickets Transmissibles

La transmission d'authentification est une instance d'un proxy où le service accordé est l'utilisation complète de l'identité du client. Un exemple où cela pourrait être utilisé est lorsqu'un utilisateur se connecte à un système distant et souhaite que l'authentification fonctionne depuis ce système comme si la connexion était locale.

L'indicateur FORWARDABLE dans un ticket n'est normalement interprété que par le service d'octroi de tickets. Il peut être ignoré par les serveurs d'application. L'indicateur FORWARDABLE a une interprétation similaire à celle de l'indicateur PROXIABLE, sauf que les TGT peuvent également être émis avec des adresses réseau différentes. Cet indicateur est réinitialisé par défaut, mais les utilisateurs PEUVENT demander qu'il soit défini en définissant l'option FORWARDABLE dans la demande AS lorsqu'ils demandent leur TGT initial.

Cet indicateur permet la transmission d'authentification sans exiger que l'utilisateur entre à nouveau un mot de passe. Si l'indicateur n'est pas défini, alors la transmission d'authentification n'est pas permise, mais le même résultat peut toujours être obtenu si l'utilisateur s'engage dans l'échange AS, spécifie les adresses réseau demandées et fournit un mot de passe.

L'indicateur FORWARDED est défini par le TGS lorsqu'un client présente un ticket avec l'indicateur FORWARDABLE défini et demande un ticket transmis en spécifiant l'option KDC FORWARDED et en fournissant un ensemble d'adresses pour le nouveau ticket. Il est également défini dans tous les tickets émis sur la base de tickets avec l'indicateur FORWARDED défini. Les serveurs d'application peuvent choisir de traiter les tickets FORWARDED différemment des tickets non-FORWARDED.

Si des tickets sans adresse sont transmis d'un système à un autre, les clients DEVRAIENT toujours utiliser cette option pour obtenir un nouveau TGT afin d'avoir des clés de session différentes sur les différents systèmes.

2.7. Vérification de la Politique de Transit

Dans Kerberos, le serveur d'application est ultimement responsable d'accepter ou de rejeter l'authentification, et il DEVRAIT vérifier que seuls des KDC convenablement fiables sont utilisés pour authentifier un principal. Le champ transité (transited field) dans le ticket identifie quels domaines (et donc quels KDC) ont été impliqués dans le processus d'authentification, et un serveur d'application vérifierait normalement ce champ. Si l'un d'entre eux n'est pas fiable pour authentifier le principal client indiqué (probablement déterminé par une politique basée sur le domaine), la tentative d'authentification DOIT être rejetée. La présence de KDC fiables dans cette liste ne fournit aucune garantie; un KDC non fiable peut avoir fabriqué la liste.

Bien que le serveur final décide ultimement si l'authentification est valide, le KDC pour le domaine du serveur final PEUT appliquer une politique spécifique au domaine pour valider le champ transité et accepter les identifiants pour l'authentification inter-domaines. Lorsque le KDC applique de telles vérifications et accepte une telle authentification inter-domaines, il définira l'indicateur TRANSITED-POLICY-CHECKED dans les tickets de service qu'il émet basés sur le TGT inter-domaines. Un client PEUT demander que les KDC ne vérifient pas le champ transité en définissant l'indicateur DISABLE-TRANSITED-CHECK. Les KDC sont encouragés mais pas obligés d'honorer cet indicateur.

Les serveurs d'application DOIVENT soit effectuer eux-mêmes les vérifications de domaine transité, soit rejeter les tickets inter-domaines sans TRANSITED-POLICY-CHECKED défini.

2.8. OK as Delegate

Pour certaines applications, un client peut avoir besoin de déléguer l'autorité à un serveur pour agir en son nom lors du contact avec d'autres services. Cela nécessite que le client transmette des identifiants à un serveur intermédiaire. La capacité pour un client d'obtenir un ticket de service vers un serveur ne transmet aucune information au client sur si le serveur devrait être fiable pour accepter des identifiants délégués. L'indicateur OK-AS-DELEGATE fournit un moyen pour un KDC de communiquer la politique du domaine local à un client concernant si un serveur intermédiaire est fiable pour accepter de tels identifiants.

La copie des indicateurs de ticket dans la partie chiffrée de la réponse KDC peut avoir l'indicateur OK-AS-DELEGATE défini pour indiquer au client que le serveur spécifié dans le ticket a été déterminé par la politique du domaine comme étant un destinataire approprié de délégation. Un client peut utiliser la présence de cet indicateur pour l'aider à décider s'il doit déléguer des identifiants (accorder soit un proxy soit un TGT transmis) à ce serveur. Il est acceptable d'ignorer la valeur de cet indicateur. Lors de la définition de cet indicateur, un administrateur devrait considérer la sécurité et l'emplacement du serveur sur lequel le service s'exécutera, ainsi que si le service nécessite l'utilisation d'identifiants délégués.

2.9. Autres Options KDC

Il existe trois options supplémentaires qui PEUVENT être définies dans la demande d'un client au KDC.

2.9.1. Renewable-OK

L'option RENEWABLE-OK indique que le client acceptera un ticket renouvelable si un ticket avec la durée de vie demandée ne peut pas être fourni autrement. Si un ticket avec la durée de vie demandée ne peut pas être fourni, alors le KDC PEUT émettre un ticket renouvelable avec un renew-till égal à l'endtime demandé. La valeur du champ renew-till PEUT toujours être ajustée par des limites déterminées par le site ou des limites imposées par le principal individuel ou le serveur.

2.9.2. ENC-TKT-IN-SKEY

Dans sa forme de base, le protocole Kerberos prend en charge l'authentification dans un contexte client-serveur et n'est pas bien adapté à l'authentification dans un environnement pair-à-pair car la clé à long terme de l'utilisateur ne reste pas sur la station de travail après la connexion initiale. L'authentification de tels pairs peut être prise en charge par Kerberos dans sa variante utilisateur-à-utilisateur. L'option ENC-TKT-IN-SKEY prend en charge l'authentification utilisateur-à-utilisateur en permettant au KDC d'émettre un ticket de service chiffré en utilisant la clé de session d'un autre TGT émis à un autre utilisateur. L'option ENC-TKT-IN-SKEY n'est honorée que par le service d'octroi de tickets. Elle indique que le ticket à émettre pour le serveur final doit être chiffré dans la clé de session du deuxième TGT supplémentaire fourni avec la demande. Voir Section 3.3.3 pour des détails spécifiques.

2.9.3. Authentification par Matériel sans Mot de Passe

L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser une forme d'authentification matérielle au lieu ou en plus du mot de passe du client ou d'une autre clé de chiffrement à longue durée de vie. OPT-HARDWARE-AUTH n'est honorée que par le service d'authentification. Si elle est prise en charge et autorisée par la politique, le KDC renverra un code d'erreur KDC_ERR_PREAUTH_REQUIRED et inclura les METHOD-DATA requis pour effectuer une telle authentification.