3. Message Exchanges (Échanges de Messages)

3. Échanges de Messages

Les sections suivantes décrivent les interactions entre les clients et serveurs réseau et les messages impliqués dans ces échanges.

3.1. L'Échange du Service d'Authentification

Résumé

Direction du message	Type de message	Section
1. Client vers Kerberos	KRB_AS_REQ	5.4.1
2. Kerberos vers client	KRB_AS_REP ou KRB_ERROR	5.4.2, 5.9.1

L'échange du Service d'Authentification (AS, Authentication Service) entre le client et le serveur d'authentification Kerberos est initié par un client lorsqu'il souhaite obtenir des identifiants d'authentification pour un serveur donné mais ne détient actuellement aucun identifiant. Dans sa forme de base, la clé secrète du client est utilisée pour le chiffrement et le déchiffrement. Cet échange est généralement utilisé au début d'une session de connexion pour obtenir des identifiants pour un serveur d'octroi de tickets (Ticket-Granting Server), qui seront ensuite utilisés pour obtenir des identifiants pour d'autres serveurs (voir Section 3.3) sans nécessiter une nouvelle utilisation de la clé secrète du client. Cet échange est également utilisé pour demander des identifiants pour des services qui ne doivent pas être médiés par le service d'octroi de tickets, mais nécessitent plutôt la connaissance de la clé secrète d'un principal, comme le service de changement de mot de passe (le service de changement de mot de passe refuse les demandes sauf si le demandeur peut démontrer la connaissance de l'ancien mot de passe de l'utilisateur; exiger cette connaissance empêche les changements de mot de passe non autorisés par quelqu'un s'approchant d'une session non surveillée).

Cet échange ne fournit pas par lui-même d'assurance de l'identité de l'utilisateur. Pour authentifier un utilisateur se connectant à un système local, les identifiants obtenus dans l'échange AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des identifiants pour un serveur local; ces identifiants doivent ensuite être vérifiés par un serveur local par l'achèvement réussi de l'échange Client/Serveur.

L'échange AS consiste en deux messages: KRB_AS_REQ du client vers Kerberos, et KRB_AS_REP ou KRB_ERROR en réponse. Les formats de ces messages sont décrits dans les Sections 5.4.1, 5.4.2 et 5.9.1.

Dans la demande, le client envoie (en texte clair) sa propre identité et l'identité du serveur pour lequel il demande des identifiants, d'autres informations sur les identifiants qu'il demande, et un nonce généré aléatoirement, qui peut être utilisé pour détecter les rejeux et pour associer les réponses aux demandes correspondantes. Ce nonce DOIT être généré aléatoirement par le client et mémorisé pour vérification contre le nonce dans la réponse attendue. La réponse, KRB_AS_REP, contient un ticket que le client doit présenter au serveur, et une clé de session qui sera partagée par le client et le serveur. La clé de session et les informations supplémentaires sont chiffrées dans la clé secrète du client. La partie chiffrée du message KRB_AS_REP contient également le nonce qui DOIT être comparé avec le nonce du message KRB_AS_REQ.

Sans pré-authentification, le serveur d'authentification ne sait pas si le client est réellement le principal nommé dans la demande. Il envoie simplement une réponse sans savoir ni se soucier s'ils sont identiques. Cela est acceptable car personne d'autre que le principal dont l'identité a été donnée dans la demande ne pourra utiliser la réponse. Ses informations critiques sont chiffrées dans la clé de ce principal. Cependant, un attaquant peut envoyer un message KRB_AS_REQ pour obtenir du texte en clair connu afin d'attaquer la clé du principal. Surtout si la clé est basée sur un mot de passe, cela peut créer une exposition de sécurité. Ainsi, la demande initiale prend en charge un champ optionnel qui peut être utilisé pour transmettre des informations supplémentaires qui pourraient être nécessaires pour l'échange initial. Ce champ DEVRAIT être utilisé pour la pré-authentification comme décrit dans les sections 3.1.1 et 5.2.7.

Diverses erreurs peuvent se produire; celles-ci sont indiquées par une réponse d'erreur (KRB_ERROR) au lieu de la réponse KRB_AS_REP. Le message d'erreur n'est pas chiffré. Le message KRB_ERROR contient des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Le contenu du message KRB_ERROR n'est pas protégé en intégrité. En tant que tel, le client ne peut pas détecter les rejeux, les fabrications ou les modifications. Une solution à ce problème sera incluse dans une version future du protocole.

3.1.1. Génération du Message KRB_AS_REQ

Le client peut spécifier un certain nombre d'options dans la demande initiale. Parmi ces options figurent si la pré-authentification doit être effectuée; si le ticket demandé doit être renouvelable, proxyable ou transmissible; s'il doit être postdaté ou permettre le postdatage de tickets dérivés; et si un ticket renouvelable sera accepté à la place d'un ticket non renouvelable si la date d'expiration du ticket demandé ne peut pas être satisfaite par un ticket non renouvelable (en raison de contraintes de configuration).

Le client prépare le message KRB_AS_REQ et l'envoie au KDC.

3.1.2. Réception du Message KRB_AS_REQ

Si tout se passe bien, le traitement du message KRB_AS_REQ entraînera la création d'un ticket que le client devra présenter au serveur. Le format du ticket est décrit dans la Section 5.3.

Étant donné que Kerberos peut fonctionner sur des transports non fiables tels que UDP, le KDC DOIT être préparé à retransmettre les réponses en cas de perte. Si un KDC reçoit une demande identique à une qu'il a récemment traitée avec succès, le KDC DOIT répondre avec un message KRB_AS_REP plutôt qu'une erreur de rejeu. Afin de réduire le texte chiffré donné à un attaquant potentiel, les KDC PEUVENT envoyer la même réponse générée lorsque la demande a été traitée pour la première fois. Les KDC DOIVENT obéir à ce comportement de rejeu même si le transport réel en cours d'utilisation est fiable.

3.1.3. Génération du Message KRB_AS_REP

Le serveur d'authentification recherche les principaux client et serveur nommés dans le KRB_AS_REQ dans sa base de données, en extrayant leurs clés respectives. Si le principal client demandé nommé dans la demande est inconnu parce qu'il n'existe pas dans la base de données principale du KDC, alors un message d'erreur avec un code KDC_ERR_C_PRINCIPAL_UNKNOWN est renvoyé.

Si cela est requis, le serveur pré-authentifie la demande, et si la vérification de pré-authentification échoue, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILED est renvoyé. Si la pré-authentification est requise, mais n'était pas présente dans la demande, un message d'erreur avec le code KDC_ERR_PREAUTH_REQUIRED est renvoyé, et un objet METHOD-DATA sera stocké dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Habituellement, cela inclura des éléments PA-ETYPE-INFO et/ou PA-ETYPE-INFO2 comme décrit ci-dessous. Si le serveur ne peut pas accommoder un type de chiffrement demandé par le client, un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP est renvoyé. Sinon, le KDC génère une clé de session 'aléatoire', ce qui signifie que, entre autres choses, il devrait être impossible de deviner la prochaine clé de session sur la base de la connaissance des clés de session passées. Bien que cela puisse être réalisé dans un générateur de nombres pseudo-aléatoires s'il est basé sur des principes cryptographiques, il est plus souhaitable d'utiliser un générateur de nombres vraiment aléatoires, tel qu'un basé sur des mesures de phénomènes physiques aléatoires. Voir [RFC4086] pour une discussion approfondie du caractère aléatoire.

En réponse à une demande AS, s'il existe plusieurs clés de chiffrement enregistrées pour un client dans la base de données Kerberos, alors le champ etype de la demande AS est utilisé par le KDC pour sélectionner la méthode de chiffrement à utiliser pour protéger la partie chiffrée du message KRB_AS_REP qui est envoyé au client. S'il y a plus d'un type de chiffrement fort pris en charge dans la liste etype, le KDC DEVRAIT utiliser le premier etype fort valide pour lequel une clé de chiffrement est disponible.

Lorsque la clé de l'utilisateur est générée à partir d'un mot de passe ou d'une phrase de passe, la fonction chaîne-vers-clé (string-to-key) pour le type de clé de chiffrement particulier est utilisée, comme spécifié dans [RFC3961]. La valeur de sel et les paramètres supplémentaires pour la fonction chaîne-vers-clé ont des valeurs par défaut (spécifiées par la Section 4 et par la spécification du mécanisme de chiffrement, respectivement) qui peuvent être remplacées par des données de pré-authentification (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Étant donné que le KDC est présumé stocker uniquement une copie de la clé résultante, ces valeurs ne devraient pas être modifiées pour les clés basées sur des mots de passe sauf lors du changement de la clé du principal.

Lorsque le serveur AS doit inclure des données de pré-authentification dans un KRB-ERROR ou dans un AS-REP, il DOIT utiliser PA-ETYPE-INFO2, pas PA-ETYPE-INFO, si le champ etype du KRB_AS_REQ du client liste au moins un type de chiffrement "plus récent". Sinon (lorsque le champ etype du KRB_AS_REQ du client ne liste aucun type de chiffrement "plus récent"), il DOIT envoyer à la fois PA-ETYPE-INFO2 et PA-ETYPE-INFO (les deux avec une entrée pour chaque enctype). Un enctype "plus récent" est tout enctype spécifié officiellement pour la première fois simultanément avec ou ultérieurement à l'émission de ce RFC. Les enctypes DES, 3DES ou RC4 et tout défini dans [RFC1510] ne sont pas des enctypes "plus récents".

Il n'est pas possible de générer de manière fiable la clé d'un utilisateur à partir d'une phrase de passe sans contacter le KDC, car il ne sera pas connu si des valeurs de sel ou de paramètres alternatifs sont requises.

Le KDC tentera d'assigner le type de la clé de session aléatoire à partir de la liste des méthodes dans le champ etype. Le KDC sélectionnera le type approprié en utilisant la liste des méthodes fournies et les informations de la base de données Kerberos indiquant les méthodes de chiffrement acceptables pour le serveur d'application. Le KDC n'émettra pas de tickets avec un type de chiffrement de clé de session faible.

Si le starttime demandé est absent, indique une heure dans le passé, ou est dans la fenêtre de décalage d'horloge acceptable pour le KDC et que l'option POSTDATE n'a pas été spécifiée, alors le starttime du ticket est défini sur l'heure actuelle du serveur d'authentification. S'il indique une heure dans le futur au-delà du décalage d'horloge acceptable, mais que l'option POSTDATED n'a pas été spécifiée, alors l'erreur KDC_ERR_CANNOT_POSTDATE est renvoyée. Sinon, le starttime demandé est vérifié par rapport à la politique du domaine local (l'administrateur pourrait décider d'interdire certains types ou plages de tickets postdatés), et si le starttime du ticket est acceptable, il est défini comme demandé, et l'indicateur INVALID est défini dans le nouveau ticket. Le ticket postdaté DOIT être validé avant utilisation en le présentant au KDC après que le starttime soit atteint.

L'heure d'expiration du ticket sera définie sur la plus précoce de l'heure d'expiration (endtime) demandée et d'une heure déterminée par la politique locale, éventuellement en utilisant des facteurs spécifiques au domaine ou au principal. Par exemple, l'heure d'expiration PEUT être définie sur la plus précoce des suivantes:

• L'heure d'expiration (endtime) demandée dans le message KRB_AS_REQ.

• Le starttime du ticket plus la durée de vie maximale autorisée associée au principal client de la base de données du serveur d'authentification.

• Le starttime du ticket plus la durée de vie maximale autorisée associée au principal serveur.

• Le starttime du ticket plus la durée de vie maximale définie par la politique du domaine local.

Si l'heure d'expiration demandée moins le starttime (tel que déterminé ci-dessus) est inférieure à une durée de vie minimale déterminée par le site, un message d'erreur avec le code KDC_ERR_NEVER_VALID est renvoyé. Si l'heure d'expiration demandée pour le ticket dépasse ce qui a été déterminé ci-dessus, et si l'option 'RENEWABLE-OK' a été demandée, alors l'indicateur 'RENEWABLE' est défini dans le nouveau ticket, et la valeur renew-till est définie comme si l'option 'RENEWABLE' avait été demandée (les noms de champ et d'option sont décrits complètement dans la Section 5.4.1).

Si l'option RENEWABLE a été demandée ou si l'option RENEWABLE-OK a été définie et qu'un ticket renouvelable doit être émis, alors le champ renew-till PEUT être défini sur la plus précoce de:

• Sa valeur demandée.

• Le starttime du ticket plus le minimum des deux durées de vie renouvelables maximales associées aux entrées de base de données des principaux.

• Le starttime du ticket plus la durée de vie renouvelable maximale définie par la politique du domaine local.

Le champ des indicateurs du nouveau ticket aura les options suivantes définies si elles ont été demandées et si la politique du domaine local le permet: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. Si le nouveau ticket est postdaté (le starttime est dans le futur), son indicateur INVALID sera également défini.

Si tout ce qui précède réussit, le serveur chiffrera la partie texte chiffré du ticket en utilisant la clé de chiffrement extraite de l'enregistrement du principal serveur dans la base de données Kerberos en utilisant le type de chiffrement associé à la clé du principal serveur. (Ce choix N'est PAS affecté par le champ etype de la demande.) Il formate ensuite un message KRB_AS_REP (voir Section 5.4.2), en copiant les adresses de la demande dans le caddr de la réponse, en plaçant toutes les données de pré-authentification requises dans le padata de la réponse, et chiffre la partie texte chiffré dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande, ou dans une clé spécifiée par les mécanismes de pré-authentification utilisés.

3.1.4. Génération du Message KRB_ERROR

Plusieurs erreurs peuvent se produire, et le serveur d'authentification répond en renvoyant un message d'erreur, KRB_ERROR, au client, avec les champs error-code et e-text définis sur des valeurs appropriées. Le contenu du message d'erreur et les détails sont décrits dans la Section 5.9.1.

3.1.5. Réception du Message KRB_AS_REP

Si le type de message de réponse est KRB_AS_REP, alors le client vérifie que les champs cname et crealm dans la partie en clair de la réponse correspondent à ce qu'il a demandé. Si des champs padata sont présents, ils peuvent être utilisés pour dériver la clé secrète appropriée pour déchiffrer le message. Le client déchiffre la partie chiffrée de la réponse en utilisant sa clé secrète et vérifie que le nonce dans la partie chiffrée correspond au nonce qu'il a fourni dans sa demande (pour détecter les rejeux). Il vérifie également que le sname et le srealm dans la réponse correspondent à ceux de la demande (ou sont autrement des valeurs attendues), et que le champ d'adresse d'hôte est également correct. Il stocke ensuite le ticket, la clé de session, les heures de début et d'expiration, et d'autres informations pour une utilisation ultérieure. Le champ last-req (et le champ obsolète key-expiration) de la partie chiffrée de la réponse PEUT être vérifié pour notifier l'utilisateur de l'expiration imminente de la clé. Cela permet au programme client de suggérer des actions correctives, telles qu'un changement de mot de passe.

Lors de la validation du message KRB_AS_REP (en vérifiant le nonce renvoyé contre celui envoyé dans le message KRB_AS_REQ), le client sait que l'heure actuelle sur le KDC est celle lue depuis le champ authtime de la partie chiffrée de la réponse. Le client peut éventuellement utiliser cette valeur pour la synchronisation d'horloge dans les messages ultérieurs en enregistrant avec le ticket la différence (décalage) entre la valeur authtime et l'horloge locale. Ce décalage peut ensuite être utilisé par le même utilisateur pour ajuster l'heure lue depuis l'horloge système lors de la génération de messages [DGT96].

Cette technique DOIT être utilisée lors de l'ajustement pour le décalage d'horloge au lieu de modifier directement l'horloge système, car la réponse KDC n'est authentifiée qu'auprès de l'utilisateur dont la clé secrète a été utilisée, mais pas auprès du système ou de la station de travail. Si l'horloge était ajustée, un attaquant en collusion avec un utilisateur se connectant à une station de travail pourrait convenir d'un mot de passe, résultant en une réponse KDC qui serait correctement validée même si elle ne provenait pas d'un KDC de confiance par la station de travail.

Le déchiffrement correct du message KRB_AS_REP n'est pas suffisant pour que l'hôte vérifie l'identité de l'utilisateur; l'utilisateur et un attaquant pourraient coopérer pour générer un message au format KRB_AS_REP qui se déchiffre correctement mais ne provient pas du KDC approprié. Si l'hôte souhaite vérifier l'identité de l'utilisateur, il DOIT exiger que l'utilisateur présente des identifiants d'application qui peuvent être vérifiés en utilisant une clé secrète stockée de manière sécurisée pour l'hôte. Si ces identifiants peuvent être vérifiés, alors l'identité de l'utilisateur peut être assurée.

3.1.6. Réception du Message KRB_ERROR

Si le type de message de réponse est KRB_ERROR, alors le client l'interprète comme une erreur et effectue les tâches spécifiques à l'application nécessaires pour la récupération.