5.4. Spécifications pour les échanges AS et TGS

Cette section spécifie le format des messages utilisés dans l'échange entre le client et le serveur Kerberos. Le format des messages d'erreur possibles apparaît dans la section 5.9.1.

5.4.1. Définition de KRB_KDC_REQ

Le message KRB_KDC_REQ n'a pas son propre numéro de balise d'application. Au lieu de cela, il est incorporé soit dans KRB_AS_REQ soit dans KRB_TGS_REQ, chacun ayant une balise d'application, selon que la requête concerne un ticket initial ou un ticket supplémentaire. Dans les deux cas, le message est envoyé du client au KDC pour demander des informations d'identification pour un service.

Les champs du message sont les suivants:

AS-REQ          ::= [APPLICATION 10] KDC-REQ

TGS-REQ         ::= [APPLICATION 12] KDC-REQ

KDC-REQ         ::= SEQUENCE {
        -- NOTE: la première balise est [1], pas [0]
        pvno            [1] INTEGER (5) ,
        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
                            -- NOTE: non vide --,
        req-body        [4] KDC-REQ-BODY
}

KDC-REQ-BODY    ::= SEQUENCE {
        kdc-options             [0] KDCOptions,
        cname                   [1] PrincipalName OPTIONAL
                                    -- Utilisé uniquement dans AS-REQ --,
        realm                   [2] Realm
                                    -- Royaume du serveur
                                    -- Aussi celui du client dans AS-REQ --,
        sname                   [3] PrincipalName OPTIONAL,
        from                    [4] KerberosTime OPTIONAL,
        till                    [5] KerberosTime,
        rtime                   [6] KerberosTime OPTIONAL,
        nonce                   [7] UInt32,
        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
                                    -- par ordre de préférence --,
        addresses               [9] HostAddresses OPTIONAL,
        enc-authorization-data  [10] EncryptedData OPTIONAL
                                    -- AuthorizationData --,
        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
                                       -- NOTE: non vide
}

KDCOptions      ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
-- 15 est réservé pour canonicalize
        -- unused15(15),
-- 26 n'était pas utilisé dans 1510
        -- disable-transited-check(26),
--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

Les champs de ce message sont les suivants:

pvno
Ce champ est inclus dans chaque message et spécifie le numéro de version du protocole. Ce document spécifie la version de protocole 5.

msg-type
Ce champ indique le type d'un message de protocole. Il sera presque toujours le même que l'identifiant d'application associé à un message. Il est inclus pour rendre l'identifiant plus facilement accessible à l'application. Pour le message KDC-REQ, ce type sera KRB_AS_REQ ou KRB_TGS_REQ.

padata
Contient des données de pré-authentification. Les requêtes pour des tickets supplémentaires (KRB_TGS_REQ) DOIVENT contenir un padata de PA-TGS-REQ.

Le champ padata (données de pré-authentification) contient une séquence d'informations d'authentification qui peuvent être nécessaires avant que les informations d'identification puissent être émises ou déchiffrées.

req-body
Ce champ est un espace réservé délimitant l'étendue des champs restants. Si une somme de contrôle doit être calculée sur la requête, elle est calculée sur un encodage de la séquence KDC-REQ-BODY qui est incluse dans le champ req-body.

kdc-options
Ce champ apparaît dans les requêtes KRB_AS_REQ et KRB_TGS_REQ au KDC et indique les drapeaux que le client souhaite définir sur les tickets ainsi que d'autres informations qui doivent modifier le comportement du KDC. Le cas échéant, le nom d'une option peut être le même que le drapeau défini par cette option. Bien que dans la plupart des cas, le bit dans le champ options sera le même que celui dans le champ flags, cela n'est pas garanti, il n'est donc pas acceptable de simplement copier le champ options dans le champ flags. Il y a diverses vérifications qui doivent être effectuées avant qu'une option ne soit honorée de toute façon.

Le champ kdc_options est un champ de bits, où les options sélectionnées sont indiquées par le bit défini (1), et les options non sélectionnées et les champs réservés étant réinitialisés (0). L'encodage des bits est spécifié dans la section 5.2. Les options sont décrites plus en détail ci-dessus dans la section 2. Les significations des options sont les suivantes:

Bits	Nom	Description
0	RESERVED	Réservé pour l'extension future de ce champ
1	FORWARDABLE	L'option FORWARDABLE indique que le ticket à émettre doit avoir son drapeau forwardable défini. Elle ne peut être définie que sur la requête initiale, ou dans une requête ultérieure si le TGT sur lequel elle est basée est également forwardable
2	FORWARDED	L'option FORWARDED n'est spécifiée que dans une requête au serveur d'octroi de tickets et ne sera honorée que si le TGT dans la requête a son bit FORWARDABLE défini. Cette option indique qu'il s'agit d'une requête de transfert. L'adresse ou les adresses de l'hôte à partir duquel le ticket résultant doit être valide sont incluses dans le champ addresses de la requête
3	PROXIABLE	L'option PROXIABLE indique que le ticket à émettre doit avoir son drapeau proxiable défini. Elle ne peut être définie que sur la requête initiale, ou une requête ultérieure si le TGT sur lequel elle est basée est également proxiable
4	PROXY	L'option PROXY indique qu'il s'agit d'une requête de proxy. Cette option ne sera honorée que si le TGT dans la requête a son bit PROXIABLE défini. L'adresse ou les adresses de l'hôte à partir duquel le ticket résultant doit être valide sont incluses dans le champ addresses de la requête
5	ALLOW-POSTDATE	L'option ALLOW-POSTDATE indique que le ticket à émettre doit avoir son drapeau MAY-POSTDATE défini. Elle ne peut être définie que sur la requête initiale, ou dans une requête ultérieure si le TGT sur lequel elle est basée a également son drapeau MAY-POSTDATE défini
6	POSTDATED	L'option POSTDATED indique qu'il s'agit d'une requête de ticket postdaté. Cette option ne sera honorée que si le TGT sur lequel elle est basée a son drapeau MAY-POSTDATE défini. Le ticket résultant aura également son drapeau INVALID défini, et ce drapeau peut être réinitialisé par une requête ultérieure au KDC après que le starttime dans le ticket ait été atteint
7	RESERVED	Cette option est actuellement inutilisée
8	RENEWABLE	L'option RENEWABLE indique que le ticket à émettre doit avoir son drapeau RENEWABLE défini. Elle ne peut être définie que sur la requête initiale, ou lorsque le TGT sur lequel la requête est basée est également renouvelable. Si cette option est demandée, alors le champ rtime dans la requête contient le temps d'expiration absolu souhaité pour le ticket
9	RESERVED	Réservé pour PK-Cross
10	RESERVED	Réservé pour utilisation future
11	RESERVED	Réservé pour opt-hardware-auth
12-25	RESERVED	Réservés pour utilisation future
26	DISABLE-TRANSITED-CHECK	Par défaut, le KDC vérifiera le champ transited d'un TGT par rapport à la politique du royaume local avant d'émettre des tickets dérivés basés sur le TGT. Si ce drapeau est défini dans la requête, la vérification du champ transited est désactivée. Les tickets émis sans l'exécution de cette vérification seront notés par la valeur réinitialisée (0) du drapeau TRANSITED-POLICY-CHECKED, indiquant au serveur d'application que le champ transited doit être vérifié localement. Les KDC sont encouragés mais non obligés d'honorer l'option DISABLE-TRANSITED-CHECK. Ce drapeau est nouveau depuis RFC 1510
27	RENEWABLE-OK	L'option RENEWABLE-OK indique qu'un ticket renouvelable sera acceptable si un ticket avec la durée de vie demandée ne peut pas être fourni autrement, auquel cas un ticket renouvelable peut être émis avec un renew-till égal au endtime demandé. La valeur du champ renew-till peut encore être limitée par des limites locales, ou des limites sélectionnées par le principal ou le serveur individuel
28	ENC-TKT-IN-SKEY	Cette option n'est utilisée que par le service d'octroi de tickets. L'option ENC-TKT-IN-SKEY indique que le ticket pour le serveur final doit être chiffré dans la clé de session du TGT supplémentaire fourni
29	RESERVED	Réservé pour utilisation future
30	RENEW	Cette option n'est utilisée que par le service d'octroi de tickets. L'option RENEW indique que la requête actuelle est pour un renouvellement. Le ticket fourni est chiffré dans la clé secrète du serveur sur lequel il est valide. Cette option ne sera honorée que si le ticket à renouveler a son drapeau RENEWABLE défini et si le temps dans son champ renew-till n'est pas passé. Le ticket à renouveler est passé dans le champ padata dans le cadre de l'en-tête d'authentification
31	VALIDATE	Cette option n'est utilisée que par le service d'octroi de tickets. L'option VALIDATE indique que la requête est de valider un ticket postdaté. Elle ne sera honorée que si le ticket présenté est postdaté, a actuellement son drapeau INVALID défini, et serait autrement utilisable à ce moment. Un ticket ne peut pas être validé avant son starttime. Le ticket présenté pour validation est chiffré dans la clé du serveur pour lequel il est valide et est passé dans le champ padata dans le cadre de l'en-tête d'authentification

cname et sname
Ces champs sont les mêmes que ceux décrits pour le ticket dans la section 5.3. Le sname ne peut être absent que lorsque l'option ENC-TKT-IN-SKEY est spécifiée. Si le sname est absent, le nom du serveur est pris du nom du client dans le ticket passé comme additional-tickets.

enc-authorization-data
Le enc-authorization-data, s'il est présent (et il ne peut être présent que sous la forme TGS_REQ), est un encodage des authorization-data désirées chiffrées sous la sous-clé de session si présente dans l'Authenticator, ou alternativement à partir de la clé de session dans le TGT (l'Authenticator et le TGT proviennent tous deux du champ padata dans le KRB_TGS_REQ). La valeur d'utilisation de clé utilisée lors du chiffrement est 5 si une sous-clé de session est utilisée, ou 4 si la clé de session est utilisée.

realm
Ce champ spécifie la partie royaume de l'identifiant principal du serveur. Dans l'échange AS, c'est également la partie royaume de l'identifiant principal du client.

from
Ce champ est inclus dans les requêtes de tickets KRB_AS_REQ et KRB_TGS_REQ lorsque le ticket demandé doit être postdaté. Il spécifie le starttime souhaité pour le ticket demandé. Si ce champ est omis, alors le KDC DEVRAIT utiliser l'heure actuelle à la place.

till
Ce champ contient la date d'expiration demandée par le client dans une requête de ticket. Il n'est pas optionnel, mais si le endtime demandé est "19700101000000Z", le ticket demandé doit avoir le endtime maximum autorisé selon la politique du KDC. Note d'implémentation: Cet horodatage spécial correspond à une valeur time_t UNIX de zéro sur la plupart des systèmes.

rtime
Ce champ est le temps renew-till demandé envoyé d'un client au KDC dans une requête de ticket. Il est optionnel.

nonce
Ce champ fait partie de la requête et de la réponse du KDC. Il est destiné à contenir un nombre aléatoire généré par le client. Si le même nombre est inclus dans la réponse chiffrée du KDC, cela fournit la preuve que la réponse est fraîche et n'a pas été rejouée par un attaquant. Les nonces NE DOIVENT JAMAIS être réutilisés.

etype
Ce champ spécifie l'algorithme de chiffrement souhaité à utiliser dans la réponse.

addresses
Ce champ est inclus dans la requête initiale de tickets, et il est optionnellement inclus dans les requêtes de tickets supplémentaires au serveur d'octroi de tickets. Il spécifie les adresses à partir desquelles le ticket demandé doit être valide. Normalement, il inclut les adresses de l'hôte du client. Si un proxy est demandé, ce champ contiendra d'autres adresses. Le contenu de ce champ est généralement copié par le KDC dans le champ caddr du ticket résultant.

additional-tickets
Des tickets supplémentaires PEUVENT être optionnellement inclus dans une requête au serveur d'octroi de tickets. Si l'option ENC-TKT-IN-SKEY a été spécifiée, alors la clé de session du ticket supplémentaire sera utilisée à la place de la clé du serveur pour chiffrer le nouveau ticket. Lorsque l'option ENC-TKT-IN-SKEY est utilisée pour l'authentification utilisateur-à-utilisateur, ce ticket supplémentaire PEUT être un TGT émis par le royaume local ou un TGT inter-royaume émis pour le royaume du KDC actuel par un KDC distant. Si plus d'une option qui nécessite des tickets supplémentaires a été spécifiée, alors les tickets supplémentaires sont utilisés dans l'ordre spécifié par l'ordre des bits d'options (voir kdc-options, ci-dessus).

Le numéro de balise d'application sera soit dix (10) soit douze (12) selon que la requête concerne un ticket initial (AS-REQ) ou un ticket supplémentaire (TGS-REQ).

Les champs optionnels (addresses, authorization-data et additional-tickets) ne sont inclus que s'ils sont nécessaires pour effectuer l'opération spécifiée dans le champ kdc-options.

Notez que dans KRB_TGS_REQ, le numéro de version du protocole apparaît deux fois et deux types de messages différents apparaissent: le message KRB_TGS_REQ contient ces champs ainsi que l'en-tête d'authentification (KRB_AP_REQ) qui est passé dans le champ padata.

5.4.2. Définition de KRB_KDC_REP

Le format de message KRB_KDC_REP est utilisé pour la réponse du KDC pour soit une requête initiale (AS) soit une requête ultérieure (TGS). Il n'y a pas de type de message pour KRB_KDC_REP. Au lieu de cela, le type sera soit KRB_AS_REP soit KRB_TGS_REP. La clé utilisée pour chiffrer la partie texte chiffré de la réponse dépend du type de message. Pour KRB_AS_REP, le texte chiffré est chiffré dans la clé secrète du client, et le numéro de version de clé du client est inclus dans le numéro de version de clé pour les données chiffrées. Pour KRB_TGS_REP, le texte chiffré est chiffré dans la sous-clé de session de l'Authenticator; si elle est absente, le texte chiffré est chiffré dans la clé de session du TGT utilisé dans la requête. Dans ce cas, aucun numéro de version ne sera présent dans la séquence EncryptedData.

Le message KRB_KDC_REP contient les champs suivants:

   AS-REP          ::= [APPLICATION 11] KDC-REP

   TGS-REP         ::= [APPLICATION 13] KDC-REP

   KDC-REP         ::= SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
                                   -- NOTE: non vide --,
           crealm          [3] Realm,
           cname           [4] PrincipalName,
           ticket          [5] Ticket,
           enc-part        [6] EncryptedData
                                   -- EncASRepPart ou EncTGSRepPart,
                                   -- selon le cas
   }

   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart

   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart

   EncKDCRepPart   ::= SEQUENCE {
           key             [0] EncryptionKey,
           last-req        [1] LastReq,
           nonce           [2] UInt32,
           key-expiration  [3] KerberosTime OPTIONAL,
           flags           [4] TicketFlags,
           authtime        [5] KerberosTime,
           starttime       [6] KerberosTime OPTIONAL,
           endtime         [7] KerberosTime,
           renew-till      [8] KerberosTime OPTIONAL,
           srealm          [9] Realm,
           sname           [10] PrincipalName,
           caddr           [11] HostAddresses OPTIONAL
   }

   LastReq         ::=     SEQUENCE OF SEQUENCE {
           lr-type         [0] Int32,
           lr-value        [1] KerberosTime
   }

pvno et msg-type
Ces champs sont décrits ci-dessus dans la section 5.4.1. msg-type est soit KRB_AS_REP soit KRB_TGS_REP.

padata
Ce champ est décrit en détail dans la section 5.4.1. Une utilisation possible est d'encoder une chaîne "salt" alternative à utiliser avec un algorithme string-to-key. Cette capacité est utile pour faciliter les transitions si un nom de royaume doit changer (par exemple, lorsqu'une entreprise est acquise); dans un tel cas, toutes les entrées dérivées de mot de passe existantes dans la base de données KDC seraient marquées comme nécessitant une chaîne salt spéciale jusqu'au prochain changement de mot de passe.

crealm, cname, srealm et sname
Ces champs sont les mêmes que ceux décrits pour le ticket dans la section 5.3.

ticket
Le ticket nouvellement émis, de la section 5.3.

enc-part
Ce champ est un espace réservé pour le texte chiffré et les informations connexes qui forment la partie chiffrée d'un message. La description de la partie chiffrée du message suit chaque apparition de ce champ.

La valeur d'utilisation de clé pour chiffrer ce champ est 3 dans un message AS-REP, en utilisant la clé à long terme du client ou une autre clé sélectionnée via des mécanismes de pré-authentification. Dans un message TGS-REP, la valeur d'utilisation de clé est 8 si la clé de session TGS est utilisée, ou 9 si une sous-clé d'authentificateur TGS est utilisée.

Note de compatibilité: Certaines implémentations envoient inconditionnellement un EncTGSRepPart chiffré (numéro de balise d'application 26) dans ce champ, que la réponse soit un AS-REP ou un TGS-REP. Dans l'intérêt de la compatibilité, les implémenteurs PEUVENT assouplir la vérification sur le numéro de balise de l'ENC-PART déchiffré.

key
Ce champ est le même que celui décrit pour le ticket dans la section 5.3.

last-req
Ce champ est retourné par le KDC et spécifie le ou les temps de la dernière requête par un principal. Selon les informations disponibles, cela peut être la dernière fois qu'une requête de TGT a été faite, ou la dernière fois qu'une requête basée sur un TGT a réussi. Cela peut également couvrir tous les serveurs d'un royaume, ou juste le serveur particulier. Certaines implémentations PEUVENT afficher ces informations à l'utilisateur pour aider à découvrir l'utilisation non autorisée de son identité. C'est similaire en esprit au temps de dernière connexion affiché lors de la connexion aux systèmes de temps partagé.

lr-type
Ce champ indique comment le champ lr-value suivant doit être interprété. Les valeurs négatives indiquent que l'information concerne uniquement le serveur répondant. Les valeurs non négatives concernent tous les serveurs du royaume.

Si le champ lr-type est zéro (0), alors aucune information n'est transmise par le sous-champ lr-value. Si la valeur absolue du champ lr-type est un (1), alors le sous-champ lr-value est le temps de la dernière requête initiale de TGT. Si c'est deux (2), alors le sous-champ lr-value est le temps de la dernière requête initiale. Si c'est trois (3), alors le sous-champ lr-value est le temps d'émission du TGT le plus récent utilisé. Si c'est quatre (4), alors le sous-champ lr-value est le temps du dernier renouvellement. Si c'est cinq (5), alors le sous-champ lr-value est le temps de la dernière requête (de tout type). Si c'est (6), alors le sous-champ lr-value est le temps auquel le mot de passe expirera. Si c'est (7), alors le sous-champ lr-value est le temps auquel le compte expirera.

lr-value
Ce champ contient le temps de la dernière requête. Le temps DOIT être interprété selon le contenu du sous-champ lr-type accompagnant.

nonce
Ce champ est décrit ci-dessus dans la section 5.4.1.

key-expiration
Le champ key-expiration fait partie de la réponse du KDC et spécifie le temps auquel la clé secrète du client doit expirer. L'expiration peut être le résultat du vieillissement du mot de passe ou d'une expiration de compte. S'il est présent, il DEVRAIT être défini au plus tôt entre l'expiration de la clé de l'utilisateur et l'expiration du compte. L'utilisation de ce champ est dépréciée, et le champ last-req DEVRAIT être utilisé pour transmettre cette information à la place. Ce champ sera généralement laissé en dehors de la réponse TGS puisque la réponse à la requête TGS est chiffrée dans une clé de session et aucune information client ne doit être récupérée de la base de données KDC. Il appartient au client d'application (généralement le programme de connexion) de prendre les mesures appropriées (comme notifier l'utilisateur) si le temps d'expiration est imminent.

flags, authtime, starttime, endtime, renew-till et caddr
Ces champs sont des duplicatas de ceux trouvés dans la partie chiffrée du ticket attaché (voir section 5.3), fournis pour que le client PUISSE vérifier qu'ils correspondent à la requête prévue et afin d'aider à une mise en cache correcte des tickets. Si le message est de type KRB_TGS_REP, le champ caddr ne sera rempli que si la requête concernait un ticket proxy ou transféré, ou si l'utilisateur substitue un sous-ensemble des adresses du TGT. Si les adresses demandées par le client ne sont pas présentes ou non utilisées, alors les adresses contenues dans le ticket seront les mêmes que celles incluses dans le TGT.