2. Utilisations et demandes de drapeaux de ticket

Chaque ticket Kerberos contient un ensemble de drapeaux qui sont utilisés pour indiquer les attributs de ce ticket. La plupart des drapeaux 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 drapeaux et donnent des exemples de raisons de les utiliser. À l'exception du drapeau INVALID, les clients DOIVENT ignorer les drapeaux de ticket qui ne sont pas reconnus. Les KDCs DOIVENT ignorer les options KDC qui ne sont pas reconnues. Certaines implémentations du RFC 1510 sont connues pour rejeter les options KDC inconnues, de sorte que 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. Parce que les nouveaux KDCs 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 configuration ou 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 retourner 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 retour d'une erreur ou d'une raison.

2.1. Tickets initiaux, pré-authentifiés et authentifiés par matériel

Le drapeau INITIAL indique qu'un ticket a été délivré en utilisant le protocole AS, plutôt que délivré 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 ce drapeau 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 drapeaux PRE-AUTHENT et HW-AUTHENT fournissent des informations supplémentaires sur l'authentification initiale, que le ticket actuel ait été délivré directement (auquel cas INITIAL sera également défini) ou délivré sur la base d'un TGT (auquel cas le drapeau INITIAL est effacé, mais les drapeaux PRE-AUTHENT et HW-AUTHENT sont transmis depuis le TGT).

2.2. Tickets invalides

Le drapeau INVALID indique qu'un ticket est invalide. Les serveurs d'application DOIVENT rejeter les tickets qui ont ce drapeau défini. Un ticket postdaté sera délivré 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 starttime soit passé. La validation est requise afin que les tickets postdatés qui ont été volés avant leur starttime puissent être rendus définitivement invalides (par un mécanisme de liste chaude) (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 credentials à un vol potentiel pendant des périodes tout aussi longues, et ces credentials volés seraient valides jusqu'à la date d'expiration du/des ticket(s). Utiliser simplement 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 du vol. Les tickets renouvelables ont deux "dates d'expiration": la première est lorsque l'instance actuelle du ticket expire, et la seconde est la dernière valeur permissible pour une date d'expiration individuelle. Un client d'application doit périodiquement (c'est-à-dire avant qu'il n'expire) présenter un ticket renouvelable au KDC, avec l'option RENEW définie dans la demande KDC. Le KDC délivrera un nouveau ticket avec une nouvelle clé de session et une date 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 date d'expiration permissible arrive, le ticket expire définitivement. À chaque renouvellement, le KDC PEUT consulter une liste chaude pour déterminer si le ticket avait été signalé comme 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.

Le drapeau 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 sa date d'expiration, le KDC ne renouvellera pas le ticket. Le drapeau 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 que les tickets soient 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 par 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é entre-temps, le KDC refuserait de valider le ticket, et le voleur serait déjoué.

Le drapeau 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. Ce drapeau DOIT être défini dans un TGT afin de délivrer 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. Ce drapeau ne permet pas à un client d'obtenir un TGT postdaté; les TGTs postdatés ne peuvent être obtenus qu'en demandant la postdatation dans le message KRB_AS_REQ. La vie (endtime-starttime) d'un ticket postdaté sera la vie restante du TGT au moment de la demande, sauf si l'option RENEWABLE est également définie, auquel cas elle peut être la vie complète (endtime-starttime) du TGT. Le KDC PEUT limiter à quelle distance dans le futur un ticket peut être postdaté.

Le drapeau 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 délivre 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 proxy et proxiables

Parfois, 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 uniquement pour un objectif 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 drapeaux proxy et proxiable est utilisé pour fournir des credentials à utiliser avec des services spécifiques. Bien que conceptuellement aussi un proxy, les utilisateurs souhaitant déléguer leur identité sous une forme utilisable à toutes fins DOIVENT utiliser le mécanisme de transfert de ticket décrit dans la section suivante pour transférer un TGT.

Le drapeau 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, ce drapeau indique au serveur d'octroi de tickets qu'il est OK de délivrer un nouveau ticket (mais pas un TGT) avec une adresse réseau différente basée sur ce ticket. Ce drapeau 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.

Ce drapeau 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 de credentials volés, les tickets Kerberos sont souvent valides uniquement à partir des adresses réseau spécifiquement incluses dans le ticket, mais il est permis comme option de politique d'autoriser les demandes et de délivrer 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 délivré pour une utilisation depuis n'importe quelle adresse.

Le drapeau PROXY est défini dans un ticket par le TGS lorsqu'il délivre un ticket proxy. Les serveurs d'application PEUVENT vérifier ce drapeau; et à leur discrétion ils PEUVENT exiger une authentification supplémentaire de l'agent présentant le proxy afin de fournir une piste d'audit.

2.6. Tickets transférables

Le transfert d'authentification est une instance d'un proxy où le service qui est accordé est l'utilisation complète de l'identité du client. Un exemple de son utilisation possible 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.

Le drapeau 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. Le drapeau FORWARDABLE a une interprétation similaire à celle du drapeau PROXIABLE, sauf que les TGTs peuvent également être délivrés avec différentes adresses réseau. Ce drapeau 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.

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

Le drapeau FORWARDED est défini par le TGS lorsqu'un client présente un ticket avec le drapeau FORWARDABLE défini et demande un ticket transféré 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 délivrés sur la base de tickets avec le drapeau 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 transférés d'un système à un autre, les clients DEVRAIENT toujours utiliser cette option pour obtenir un nouveau TGT afin d'avoir différentes clés de session 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 KDCs convenablement fiables sont utilisés pour authentifier un principal. Le champ transited dans le ticket identifie quels realms (et donc quels KDCs) 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 realm), la tentative d'authentification DOIT être rejetée. La présence de KDCs 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 realm du serveur final PEUT appliquer une politique spécifique au realm pour valider le champ transited et accepter les credentials pour l'authentification inter-realm. Lorsque le KDC applique de telles vérifications et accepte une telle authentification inter-realm, il définira le drapeau TRANSITED-POLICY-CHECKED dans les tickets de service qu'il délivre sur la base du TGT inter-realm. Un client PEUT demander que les KDCs ne vérifient pas le champ transited en définissant le drapeau DISABLE-TRANSITED-CHECK. Les KDCs sont encouragés mais non tenus d'honorer ce drapeau.

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

2.8. OK comme délégué

Pour certaines applications, un client peut avoir besoin de déléguer l'autorité à un serveur pour agir en son nom en contactant d'autres services. Cela nécessite que le client transfère des credentials à un serveur intermédiaire. La capacité pour un client d'obtenir un ticket de service pour un serveur ne transmet aucune information au client quant à savoir si le serveur devrait être digne de confiance pour accepter des credentials délégués. Le OK-AS-DELEGATE fournit un moyen pour un KDC de communiquer la politique du realm local à un client concernant si un serveur intermédiaire est digne de confiance pour accepter de tels credentials.

La copie des drapeaux de ticket dans la partie chiffrée de la réponse KDC peut avoir le drapeau 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 realm comme étant un destinataire approprié de délégation. Un client peut utiliser la présence de ce drapeau pour l'aider à décider s'il doit déléguer des credentials (accorder soit un proxy soit un TGT transféré) à ce serveur. Il est acceptable d'ignorer la valeur de ce drapeau. Lors de la définition de ce drapeau, 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 de credentials délégués.

2.9. Autres options KDC

Il existe trois options supplémentaires qui PEUVENT être définies dans une 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 délivrer un ticket renouvelable avec un renew-till égal au endtime demandé. La valeur du champ renew-till PEUT toujours être limitée par la politique locale, mais le client devrait vérifier la valeur de ce champ et traiter le ticket comme ayant initialement la plus courte des deux durées de vie.

2.9.2. ENC-TKT-IN-SKEY

L'option ENC-TKT-IN-SKEY est honorée uniquement par le service d'octroi de tickets. Elle indique que le ticket à délivrer pour le serveur final doit être chiffré dans la clé de session du ticket-granting ticket supplémentaire fourni avec la demande. Voir la section 3.3.3 pour des détails spécifiques.

2.9.3. Authentification matérielle sans mot de passe

L'option HARDWARE-AUTH supplémentaire est honorée uniquement par le serveur d'authentification. Il indique que le client doit être authentifié sans utilisation d'un mot de passe. Le serveur pourra alors définir le drapeau HW-AUTHENT dans le ticket TGT délivré si le client peut être authentifié d'une autre manière, peut-être via un périphérique d'authentification matérielle détenu par le client.