5.3. Tickets

Cette section décrit le format et les paramètres de chiffrement des tickets et des authentificateurs. Lorsqu'un ticket ou un authentificateur est inclus dans un message de protocole, il est traité comme un objet opaque. Un ticket est un enregistrement qui aide un client à s'authentifier auprès d'un service.

Structure du ticket

Ticket          ::= [APPLICATION 1] SEQUENCE {
        tkt-vno         [0] INTEGER (5),
        realm           [1] Realm,
        sname           [2] PrincipalName,
        enc-part        [3] EncryptedData -- EncTicketPart
}

Description des champs

tkt-vno
Ce champ spécifie le numéro de version du format de ticket. Ce document décrit la version numéro 5.

realm
Ce champ spécifie le royaume qui a émis le ticket. Il est également utilisé pour identifier la partie royaume de l'identifiant principal du serveur. Puisqu'un serveur Kerberos ne peut émettre que des tickets pour les serveurs dans son royaume, les deux seront toujours identiques.

sname
Ce champ spécifie tous les composants de la partie nom de l'identité du serveur, y compris ceux qui identifient l'instance spécifique du service.

enc-part
Ce champ contient l'encodage chiffré de la séquence EncTicketPart. Il est chiffré en utilisant la clé partagée entre Kerberos et le serveur final (la clé du serveur), avec une valeur d'utilisation de clé de 2.

Partie chiffrée du ticket (EncTicketPart)

EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
        flags                   [0] TicketFlags,
        key                     [1] EncryptionKey,
        crealm                  [2] Realm,
        cname                   [3] PrincipalName,
        transited               [4] TransitedEncoding,
        authtime                [5] KerberosTime,
        starttime               [6] KerberosTime OPTIONAL,
        endtime                 [7] KerberosTime,
        renew-till              [8] KerberosTime OPTIONAL,
        caddr                   [9] HostAddresses OPTIONAL,
        authorization-data      [10] AuthorizationData OPTIONAL
}

-- Champ transited encodé
TransitedEncoding       ::= SEQUENCE {
        tr-type         [0] Int32 -- doit être enregistré --,
        contents        [1] OCTET STRING
}

TicketFlags     ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- may-postdate(5),
        -- postdated(6),
        -- invalid(7),
        -- renewable(8),
        -- initial(9),
        -- pre-authent(10),
        -- hw-authent(11),
-- Les drapeaux suivants sont nouveaux depuis 1510
        -- transited-policy-checked(12),
        -- ok-as-delegate(13)

Drapeaux de ticket (TicketFlags)

Ce champ indique quelles options ont été utilisées ou demandées lors de l'émission du ticket. La signification des drapeaux est la suivante:

Bit	Nom	Description
0	reserved	Réservé pour l'extension future de ce champ
1	forwardable	Le drapeau FORWARDABLE est généralement interprété uniquement par le TGS et peut être ignoré par le serveur final. Lorsqu'il est défini, ce drapeau indique au service d'octroi de tickets qu'un nouveau TGT avec une adresse réseau différente peut être émis basé sur le ticket présenté
2	forwarded	Lorsqu'il est défini, ce drapeau indique que le ticket a été transféré ou a été émis basé sur une authentification impliquant un TGT transféré
3	proxiable	Le drapeau PROXIABLE est généralement interprété uniquement par le TGS et peut être ignoré par le serveur final. L'interprétation du drapeau PROXIABLE est identique à celle du drapeau FORWARDABLE, sauf que le drapeau PROXIABLE indique au service d'octroi de tickets que seuls des non-TGT avec des adresses réseau différentes peuvent être émis
4	proxy	Lorsqu'il est défini, ce drapeau indique que le ticket est un proxy
5	may-postdate	Le drapeau MAY-POSTDATE est généralement interprété uniquement par le TGS et peut être ignoré par le serveur final. Ce drapeau indique au service d'octroi de tickets que des tickets postdatés peuvent être émis basés sur ce TGT
6	postdated	Ce drapeau indique que ce ticket a été postdaté. Le service final peut vérifier le champ authtime pour voir quand l'authentification originale a eu lieu
7	invalid	Ce drapeau indique que le ticket est invalide et doit être validé par le KDC avant utilisation. Les serveurs d'application doivent rejeter les tickets avec ce drapeau défini
8	renewable	Le drapeau RENEWABLE est généralement interprété uniquement par le TGS et peut généralement être ignoré par le serveur final (certains serveurs particulièrement prudents peuvent ne pas autoriser les tickets renouvelables). Les tickets renouvelables peuvent être utilisés pour obtenir des tickets de remplacement qui expirent à une date ultérieure
9	initial	Ce drapeau indique que ce ticket a été émis en utilisant le protocole AS, plutôt que basé sur un TGT
10	pre-authent	Ce drapeau indique que lors de l'authentification initiale, le client a été authentifié par le KDC avant l'émission du ticket. La force de la méthode de pré-authentification n'est pas indiquée, mais était acceptable pour le KDC
11	hw-authent	Ce drapeau indique que le protocole utilisé pour l'authentification initiale nécessitait l'utilisation de matériel censé être possédé uniquement par le client nommé. La méthode d'authentification matérielle est choisie par le KDC et la force de la méthode n'est pas indiquée
12	transited-policy-checked	Ce drapeau indique que le KDC du royaume a vérifié le champ transited par rapport à une politique d'authentificateurs de confiance définie par le royaume. Si ce drapeau est réinitialisé (0), le serveur d'application doit vérifier le champ transited lui-même, et s'il ne peut pas le faire, il doit rejeter l'authentification. Si le drapeau est défini (1), le serveur d'application peut ignorer sa propre vérification du champ transited, en s'appuyant sur la vérification effectuée par le KDC. Le serveur d'application peut choisir d'appliquer quand même sa propre vérification en fonction d'une politique d'acceptation séparée. Ce drapeau est nouveau depuis RFC 1510
13	ok-as-delegate	Ce drapeau indique que le serveur (pas le client) spécifié dans le ticket a été déterminé par la politique du royaume comme étant un destinataire approprié de délégation. Le client peut utiliser la présence de ce drapeau pour l'aider à décider s'il doit déléguer des informations d'identification (octroyer un proxy ou un TGT transféré) à ce serveur. Le client est libre d'ignorer la valeur de ce drapeau. Lors de la définition de ce drapeau, les administrateurs doivent considérer la sécurité et l'emplacement du serveur sur lequel le service s'exécutera, ainsi que si le service a besoin d'utiliser des informations d'identification déléguées. Ce drapeau est nouveau depuis RFC 1510
14-31	reserved	Réservés pour utilisation future

Autres champs

key
Ce champ est présent dans les tickets et les réponses KDC pour transmettre la clé de session de Kerberos au serveur d'application et au client.

crealm
Ce champ contient le nom du royaume dans lequel le client est enregistré et où l'authentification initiale a eu lieu.

cname
Ce champ contient la partie nom de l'identifiant principal du client.

transited
Ce champ liste les noms des royaumes Kerberos qui ont participé à l'authentification de l'utilisateur pour lequel ce ticket a été émis. Il ne spécifie pas l'ordre dans lequel les royaumes ont été traversés. Voir la section 3.3.3.2 pour des détails sur la façon dont ce champ encode les royaumes traversés. Lorsque le nom d'une CA doit être incorporé dans le champ transited (comme spécifié pour certaines extensions du protocole), le nom X.500 de la CA devrait être mappé dans une entrée dans le champ transited en utilisant le mappage défini par RFC 2253.

authtime
Ce champ spécifie le temps d'authentification initiale du principal nommé. C'est le temps d'émission du ticket original sur lequel ce ticket est basé. Il est inclus dans le ticket pour fournir des informations supplémentaires au service final et pour fournir les informations nécessaires au KDC pour mettre en œuvre un service de "liste noire". Les services finaux particulièrement paranoïaques peuvent refuser d'accepter des tickets dont l'authentification initiale s'est produite "il y a trop longtemps". Ce champ est également retourné dans le cadre de la réponse KDC. Lorsqu'il est retourné dans le cadre de la réponse à l'authentification initiale (KRB_AS_REP), c'est l'heure actuelle sur le serveur Kerberos. Il n'est pas recommandé d'utiliser cette valeur de temps pour ajuster l'horloge de la station de travail, car la station de travail ne peut pas déterminer de manière fiable qu'un tel KRB_AS_REP provient effectivement du KDC correct en temps opportun.

starttime
Ce champ dans le ticket spécifie le temps à partir duquel le ticket est valide. Avec endtime, ce champ spécifie la durée de vie du ticket. Si le champ starttime est absent dans le ticket, le champ authtime devrait être utilisé à sa place pour déterminer la durée de vie du ticket.

endtime
Ce champ contient le temps après lequel le ticket ne sera plus accepté (son temps d'expiration). Notez que les services individuels peuvent définir leurs propres limites sur la durée de vie des tickets et peuvent rejeter des tickets qui n'ont pas encore expiré. En tant que tel, c'est effectivement une limite supérieure sur le temps d'expiration du ticket.

renew-till
Ce champ n'est présent que dans les tickets dont le drapeau RENEWABLE est défini dans le champ flags. Il indique l'endtime maximum qui peut être inclus dans un renouvellement. Il peut être considéré comme le temps d'expiration absolu du ticket, incluant tous les renouvellements.

caddr
Ce champ dans le ticket contient zéro (s'il est omis) ou plusieurs (s'il est présent) adresses hôtes. Ce sont les adresses à partir desquelles le ticket peut être utilisé. S'il n'y a pas d'adresses, le ticket peut être utilisé depuis n'importe où. La décision du KDC d'émettre ou du serveur final d'accepter des tickets sans adresse est une décision de politique laissée aux administrateurs Kerberos et de service final; ils peuvent refuser d'émettre ou d'accepter de tels tickets. En raison du déploiement généralisé de la traduction d'adresse réseau, il est recommandé que la politique permette l'émission et l'acceptation de tels tickets.

L'inclusion d'adresses réseau dans les tickets vise à rendre plus difficile pour un attaquant l'utilisation d'informations d'identification volées. Parce que la clé de session n'est pas transmise en texte clair sur le réseau, les informations d'identification ne peuvent pas être volées simplement en écoutant le réseau; un attaquant doit obtenir un accès à la clé de session (peut-être par une faille de sécurité du système d'exploitation ou une session sans surveillance d'un utilisateur négligent) pour utiliser un ticket volé.

Notez qu'il n'est pas possible de déterminer de manière fiable l'adresse réseau de réception d'une connexion. Même si c'était possible, un attaquant qui a déjà compromis une station de travail client peut utiliser les informations d'identification à partir de là. L'inclusion d'adresses réseau rend seulement plus difficile (et non impossible) pour un attaquant de voler des informations d'identification puis de les utiliser à partir d'un emplacement "sûr".

authorization-data
Le champ authorization-data est utilisé pour transmettre des données d'autorisation du principal auquel le ticket a été émis au serveur d'application. Si aucune donnée d'autorisation n'est incluse, ce champ sera omis. L'expérience a montré que le nom de ce champ est trompeur et qu'un meilleur nom serait "restrictions". Malheureusement, il n'est actuellement pas possible de changer le nom.

Ce champ contient des restrictions sur les privilèges obtenus basés sur l'authentification utilisant le ticket. Tout principal possédant des informations d'identification peut ajouter des entrées au champ authorization data, car ces entrées restreignent davantage ce qui peut être fait avec le ticket. De tels ajouts peuvent être effectués en spécifiant des entrées supplémentaires lors de l'obtention d'un nouveau ticket pendant l'échange TGS, ou ils peuvent être ajoutés lors de la délégation en chaîne en utilisant le champ authorization data de l'authentificateur.

Parce que des entrées peuvent être ajoutées à ce champ par le détenteur d'informations d'identification, à moins qu'une entrée ne soit authentifiée séparément par encapsulation dans un élément émis par le KDC, la présence d'une entrée dans le champ authorization data du ticket n'est pas autorisée à élargir les privilèges qui seraient obtenus avec l'utilisation du ticket.

Les données dans ce champ peuvent être spécifiques au service final; le champ contiendrait le nom d'objets spécifiques au service et les autorisations sur ces objets. Le format de ce champ est décrit dans la section 5.2.6. Bien que Kerberos ne se soucie pas du format du contenu des sous-champs, il transporte des informations de type (ad-type).

En utilisant le champ authorization_data, un principal peut émettre un proxy valide pour un usage spécifique. Par exemple, un client qui souhaite imprimer un fichier peut obtenir un proxy de serveur de fichiers à transmettre au serveur d'impression. En spécifiant le nom du fichier dans le champ authorization_data, le serveur de fichiers sait que le serveur d'impression ne peut utiliser les privilèges du client que lors de l'accès au fichier spécifique à imprimer.

Le champ authorization-data peut être utilisé pour construire des services séparés qui fournissent l'autorisation ou l'authentification de l'appartenance à un groupe. Dans ce cas, l'entité accordant l'autorisation (et non l'entité autorisée) peut obtenir un ticket en son propre nom (par exemple, un ticket est émis au nom du serveur privilégié), et cette entité ajoute des restrictions sur ses propres privilèges et délègue les privilèges restreints au client via un proxy. Le client présente ensuite ces informations d'identification d'autorisation séparément de l'échange d'authentification au serveur d'application. Alternativement, lorsque l'autorisation est authentifiée séparément en utilisant un élément de données d'autorisation émis par le KDC (voir 5.2.6.2), de telles informations d'identification d'autorisation peuvent être incorporées dans le ticket authentifiant l'entité d'autorisation.

De même, si le champ authorization-data du proxy est spécifié et que les adresses hôtes sont laissées vides, le ticket et la clé de session résultants peuvent être considérés comme une capacité. Voir [Neu93] pour certaines utilisations proposées de ce champ.

Le champ authorization-data est optionnel et n'a pas besoin d'être inclus dans le ticket.