3.2. The Client/Server Authentication Exchange (L'Échange d'Authentification Client/Serveur)

3.2. L'Échange d'Authentification Client/Serveur

Résumé

Direction du message	Type de message	Section
Client vers serveur d'application	KRB_AP_REQ	5.5.1
[optionnel] Serveur d'application vers client	KRB_AP_REP ou KRB_ERROR	5.5.2, 5.9.1

L'échange d'authentification client/serveur (CS) est utilisé par les applications réseau pour authentifier le client auprès du serveur et vice versa. Le client DOIT avoir déjà acquis des identifiants pour le serveur en utilisant l'échange AS ou TGS.

3.2.1. Le Message KRB_AP_REQ

Le KRB_AP_REQ contient des informations d'authentification qui DEVRAIENT faire partie du premier message dans une transaction authentifiée. Il contient un ticket, un authentificateur et quelques informations de comptabilité supplémentaires (voir Section 5.5.1 pour le format exact). Le ticket seul est insuffisant pour authentifier un client, car les tickets sont transmis sur le réseau en texte clair (les tickets contiennent à la fois une partie chiffrée et non chiffrée, donc texte clair ici fait référence à l'unité entière, qui peut être copiée d'un message et rejouée dans un autre sans aucune compétence cryptographique). L'authentificateur est utilisé pour empêcher la rejouabilité invalide des tickets en prouvant au serveur que le client connaît la clé de session du ticket et a donc le droit d'utiliser le ticket. Le message KRB_AP_REQ est référencé ailleurs comme "en-tête d'authentification".

3.2.2. Génération d'un Message KRB_AP_REQ

Lorsqu'un client souhaite initier l'authentification auprès d'un serveur, il obtient (soit via un cache d'identifiants, l'échange AS ou l'échange TGS) un ticket et une clé de session pour le service désiré. Le client PEUT réutiliser tous les tickets qu'il détient jusqu'à leur expiration. Pour utiliser un ticket, le client construit un nouvel Authenticator à partir de l'heure système et de son nom, et éventuellement à partir d'une somme de contrôle spécifique à l'application, d'un numéro de séquence initial à utiliser dans les messages KRB_SAFE ou KRB_PRIV, et/ou d'une sous-clé de session à utiliser dans les négociations pour une clé de session unique à cette session particulière. Les authentificateurs NE DOIVENT PAS être réutilisés et DEVRAIENT être rejetés s'ils sont rejoués à un serveur. Notez que cela peut rendre les applications basées sur des transports non fiables difficiles à coder correctement. Si le transport pourrait livrer des messages dupliqués, soit un nouvel authentificateur DOIT être généré pour chaque nouvelle tentative, soit le serveur d'application DOIT faire correspondre les demandes et les réponses et rejouer la première réponse en réponse à un duplicata détecté.

Si un numéro de séquence doit être inclus, il DEVRAIT être choisi aléatoirement de sorte que même après l'échange de nombreux messages, il ne soit pas susceptible d'entrer en collision avec d'autres numéros de séquence en cours d'utilisation.

Le client PEUT indiquer une exigence d'authentification mutuelle ou l'utilisation d'un ticket basé sur une clé de session (pour l'authentification utilisateur-à-utilisateur, voir section 3.7) en définissant le(s) indicateur(s) approprié(s) dans le champ ap-options du message.

L'Authenticator est chiffré dans la clé de session et combiné avec le ticket pour former le message KRB_AP_REQ, qui est ensuite envoyé au serveur final avec toute information supplémentaire spécifique à l'application.

3.2.3. Réception du Message KRB_AP_REQ

L'authentification est basée sur l'heure actuelle du serveur (les horloges DOIVENT être faiblement synchronisées), l'authentificateur et le ticket. Plusieurs erreurs sont possibles. Si une erreur se produit, le serveur est censé répondre au client avec un message KRB_ERROR. Ce message PEUT être encapsulé dans le protocole d'application si sa forme brute n'est pas acceptable pour le protocole. Le format des messages d'erreur est décrit dans la Section 5.9.1.

L'algorithme pour vérifier les informations d'authentification est le suivant. Si le type de message n'est pas KRB_AP_REQ, le serveur renvoie l'erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé indiquée par le Ticket dans le KRB_AP_REQ n'est pas une que le serveur peut utiliser (par exemple, elle indique une ancienne clé, et le serveur ne possède plus une copie de l'ancienne clé), l'erreur KRB_AP_ERR_BADKEYVER est renvoyée. Si l'indicateur USE-SESSION-KEY est défini dans le champ ap-options, il indique au serveur que l'authentification utilisateur-à-utilisateur est en cours d'utilisation, et que le ticket est chiffré dans la clé de session du TGT du serveur plutôt que dans la clé secrète du serveur. Voir Section 3.7 pour une description plus complète de l'effet de l'authentification utilisateur-à-utilisateur sur tous les messages du protocole Kerberos.

Étant donné qu'il est possible que le serveur soit enregistré dans plusieurs domaines, avec des clés différentes dans chacun, le champ srealm dans la partie non chiffrée du ticket dans le KRB_AP_REQ est utilisé pour spécifier quelle clé secrète le serveur doit utiliser pour déchiffrer ce ticket. Le code d'erreur KRB_AP_ERR_NOKEY est renvoyé si le serveur n'a pas la clé appropriée pour déchiffrer le ticket.

Le ticket est déchiffré en utilisant la version de la clé du serveur spécifiée par le ticket. Si les routines de déchiffrement détectent une modification du ticket (chaque système de chiffrement DOIT fournir des garde-fous pour détecter le texte chiffré modifié), l'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée (les chances sont bonnes que des clés différentes aient été utilisées pour chiffrer et déchiffrer).

L'authentificateur est déchiffré en utilisant la clé de session extraite du ticket déchiffré. Si le déchiffrement montre qu'il a été modifié, l'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée. Le nom et le domaine du client du ticket sont comparés aux mêmes champs dans l'authentificateur. S'ils ne correspondent pas, l'erreur KRB_AP_ERR_BADMATCH est renvoyée; normalement cela est causé par une erreur client ou une tentative d'attaque. Les adresses dans le ticket (le cas échéant) sont ensuite recherchées pour une adresse correspondant à l'adresse rapportée par le système d'exploitation du client. Si aucune correspondance n'est trouvée ou si le serveur insiste sur les adresses de ticket mais qu'aucune n'est présente dans le ticket, l'erreur KRB_AP_ERR_BADADDR est renvoyée. Si l'heure locale (serveur) et l'heure client dans l'authentificateur diffèrent de plus que le décalage d'horloge autorisé (par exemple, 5 minutes), l'erreur KRB_AP_ERR_SKEW est renvoyée.

À moins que le serveur d'application ne fournisse ses propres moyens appropriés pour se protéger contre la rejouabilité (par exemple, une séquence défi-réponse initiée par le serveur après l'authentification, ou l'utilisation d'une sous-clé de chiffrement générée par le serveur), le serveur DOIT utiliser un cache de rejeu pour mémoriser tout authentificateur présenté dans le décalage d'horloge autorisé. Une analyse minutieuse du protocole d'application et de l'implémentation est recommandée avant d'éliminer ce cache. Le cache de rejeu stockera au moins le nom du serveur, ainsi que le nom du client, l'heure et les champs de microsecondes des authentificateurs récemment vus, et si un tuple correspondant est trouvé, l'erreur KRB_AP_ERR_REPEAT est renvoyée. Notez que le rejet ici est limité aux authentificateurs du même principal vers le même serveur. Les autres principaux clients communiquant avec le même principal serveur ne devraient pas voir leurs authentificateurs rejetés si les champs d'heure et de microsecondes correspondent à l'authentificateur d'un autre client.

Si un serveur perd la trace des authentificateurs présentés dans le décalage d'horloge autorisé, il DOIT rejeter toutes les demandes jusqu'à ce que l'intervalle de décalage d'horloge soit passé, fournissant l'assurance que tous les authentificateurs perdus ou rejoués tomberont en dehors du décalage d'horloge autorisé et ne pourront plus être rejoués avec succès. Si cela n'était pas fait, un attaquant pourrait subvertir l'authentification en enregistrant le ticket et l'authentificateur envoyés sur le réseau à un serveur et en les rejouant suite à un événement qui a causé la perte de trace par le serveur des authentificateurs récemment vus.

Note d'implémentation: Si un client génère plusieurs demandes au KDC avec le même horodatage, y compris le champ de microsecondes, toutes les demandes reçues sauf la première seront rejetées comme des rejeux. Cela pourrait se produire, par exemple, si la résolution de l'horloge du client est trop grossière. Les implémentations client DEVRAIENT s'assurer que les horodatages ne sont pas réutilisés, éventuellement en incrémentant le champ de microsecondes dans l'horodatage lorsque l'horloge renvoie la même heure pour plusieurs demandes.

Si plusieurs serveurs (par exemple, différents services sur une machine, ou un seul service implémenté sur plusieurs machines) partagent un principal de service (une pratique que nous ne recommandons pas en général, mais que nous reconnaissons sera utilisée dans certains cas), soit ils DOIVENT partager ce cache de rejeu, soit le protocole d'application DOIT être conçu de manière à éliminer le besoin de celui-ci. Notez que cela s'applique à tous les services. Si l'un des protocoles d'application n'a pas de protection contre la rejouabilité intégrée, un authentificateur utilisé avec un tel service pourrait plus tard être rejoué à un service différent avec le même principal de service mais sans protection contre la rejouabilité, si le premier n'enregistre pas les informations de l'authentificateur dans le cache de rejeu commun.

Si un numéro de séquence est fourni dans l'authentificateur, le serveur le sauvegarde pour une utilisation ultérieure dans le traitement des messages KRB_SAFE et/ou KRB_PRIV. Si une sous-clé est présente, le serveur soit la sauvegarde pour une utilisation ultérieure, soit l'utilise pour aider à générer son propre choix pour une sous-clé à renvoyer dans un message KRB_AP_REP.

Le serveur calcule l'âge du ticket: heure locale (serveur) moins le starttime à l'intérieur du Ticket. Si le starttime est ultérieur à l'heure actuelle de plus que le décalage d'horloge autorisé, ou si l'indicateur INVALID est défini dans le ticket, l'erreur KRB_AP_ERR_TKT_NYV est renvoyée. Sinon, si l'heure actuelle est ultérieure à l'heure de fin de plus que le décalage d'horloge autorisé, l'erreur KRB_AP_ERR_TKT_EXPIRED est renvoyée.

Si toutes ces vérifications réussissent sans erreur, le serveur est assuré que le client possède les identifiants du principal nommé dans le ticket, et donc, que le client a été authentifié auprès du serveur.

Réussir ces vérifications ne fournit que l'authentification du principal nommé; cela n'implique pas l'autorisation d'utiliser le service nommé. Les applications DOIVENT prendre une décision d'autorisation distincte basée sur le nom authentifié de l'utilisateur, l'opération demandée, les informations de contrôle d'accès local telles que celles contenues dans un fichier .k5login ou .k5users, et éventuellement un service d'autorisation distribué distinct.

3.2.4. Génération d'un Message KRB_AP_REP

Généralement, la demande d'un client inclura à la fois les informations d'authentification et sa demande initiale dans le même message, et le serveur n'a pas besoin de répondre explicitement au KRB_AP_REQ. Cependant, si l'authentification mutuelle (authentifiant non seulement le client auprès du serveur, mais aussi le serveur auprès du client) est en cours, le message KRB_AP_REQ aura MUTUAL-REQUIRED défini dans son champ ap-options, et un message KRB_AP_REP est requis en réponse. Comme pour le message d'erreur, ce message PEUT être encapsulé dans le protocole d'application si sa forme "brute" n'est pas acceptable pour le protocole de l'application. L'horodatage et le champ de microsecondes utilisés dans la réponse DOIVENT être l'horodatage et le champ de microsecondes du client (tels que fournis dans l'authentificateur). Si un numéro de séquence doit être inclus, il DEVRAIT être choisi aléatoirement comme décrit ci-dessus pour l'authentificateur. Une sous-clé PEUT être incluse si le serveur désire négocier une sous-clé différente. Le message KRB_AP_REP est chiffré dans la clé de session extraite du ticket.

Notez que dans le protocole Kerberos Version 4, l'horodatage dans la réponse était l'horodatage du client plus un. Cela n'est pas nécessaire dans la Version 5 car les messages Version 5 sont formatés de telle manière qu'il n'est pas possible de créer la réponse par une chirurgie de message judicieuse (même sous forme chiffrée) sans connaissance des clés de chiffrement appropriées.

3.2.5. Réception du Message KRB_AP_REP

Si un message KRB_AP_REP est renvoyé, le client utilise la clé de session des identifiants obtenus pour le serveur pour déchiffrer le message et vérifie que les champs d'horodatage et de microsecondes correspondent à ceux de l'Authenticator qu'il a envoyé au serveur. S'ils correspondent, alors le client est assuré que le serveur est authentique. Le numéro de séquence et la sous-clé (le cas échéant) sont conservés pour une utilisation ultérieure. (Notez que pour chiffrer le message KRB_AP_REP, la clé de sous-session n'est pas utilisée, même si elle est présente dans l'Authentication.)

3.2.6. Utilisation de la Clé de Chiffrement

Après que l'échange KRB_AP_REQ/KRB_AP_REP ait eu lieu, le client et le serveur partagent une clé de chiffrement qui peut être utilisée par l'application. Dans certains cas, l'utilisation de cette clé de session sera implicite dans le protocole; dans d'autres, la méthode d'utilisation doit être choisie parmi plusieurs alternatives. L'application PEUT choisir la clé de chiffrement réelle à utiliser pour KRB_PRIV, KRB_SAFE ou d'autres utilisations spécifiques à l'application basées sur la clé de session du ticket et les sous-clés dans le message KRB_AP_REP et l'authentificateur. Les implémentations du protocole PEUVENT fournir des routines pour choisir des sous-clés basées sur des clés de session et des nombres aléatoires et pour générer une clé négociée à renvoyer dans le message KRB_AP_REP.

Pour atténuer l'effet des défaillances dans la génération de nombres aléatoires sur le client, il est fortement encouragé que toute clé dérivée par une application pour une utilisation ultérieure inclue l'entropie de clé complète dérivée de la clé de session générée par le KDC transportée dans le ticket. Nous laissons les négociations de protocole sur la façon d'utiliser la clé (par exemple, pour sélectionner un type de chiffrement ou de somme de contrôle) au programmeur d'application. Le protocole Kerberos ne contraint pas les options d'implémentation, mais un exemple de la façon dont cela pourrait être fait suit.

Une façon dont une application peut choisir de négocier une clé à utiliser pour la protection ultérieure de l'intégrité et de la confidentialité est que le client propose une clé dans le champ de sous-clé de l'authentificateur. Le serveur peut alors choisir une clé en utilisant la clé proposée par le client comme entrée, en renvoyant la nouvelle sous-clé dans le champ de sous-clé de la réponse d'application. Cette clé pourrait alors être utilisée pour les communications ultérieures.

Avec les échanges d'authentification unidirectionnelle et mutuelle, les pairs devraient prendre soin de ne pas s'envoyer mutuellement des informations sensibles sans assurances appropriées. En particulier, les applications qui nécessitent une confidentialité ou une intégrité DEVRAIENT utiliser la réponse KRB_AP_REP du serveur au client pour assurer à la fois le client et le serveur de l'identité de leur pair. Si un protocole d'application nécessite la confidentialité de ses messages, il peut utiliser le message KRB_PRIV (section 3.5). Le message KRB_SAFE (Section 3.4) peut être utilisé pour garantir l'intégrité.