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 (Authentication Service, AS) entre le client et le serveur d'authentification Kerberos est initié par un client lorsqu'il souhaite obtenir des credentials d'authentification pour un serveur donné mais ne détient actuellement aucun credential. Sous 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 credentials pour un serveur d'octroi de tickets (Ticket-Granting Server), qui sera ensuite utilisé pour obtenir des credentials pour d'autres serveurs (voir section 3.3) sans nécessiter l'utilisation ultérieure de la clé secrète du client.

Cet échange est également utilisé pour demander des credentials 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.

Cet échange ne fournit pas en soi d'assurance de l'identité de l'utilisateur. Pour authentifier un utilisateur se connectant à un système local, les credentials obtenus dans l'échange AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des credentials pour un serveur local; ces credentials doivent ensuite être vérifiés par un serveur local via 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 credentials, d'autres informations sur les credentials qu'il demande, et un nonce généré aléatoirement, qui peut être utilisé pour détecter les réutilisations 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 correspondre au 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 les mêmes. Ceci 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 réutilisations, 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, proxiable ou transférable; 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 résultera en la création d'un ticket que le client présentera au serveur. Le format du ticket est décrit dans la section 5.3.

Parce que Kerberos peut fonctionner sur des transports non fiables tels que UDP, le KDC DOIT être prêt à 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 réutilisation. Afin de réduire le texte chiffré donné à un attaquant potentiel, les KDC PEUVENT envoyer la même réponse générée lors du premier traitement de la demande. Les KDC DOIVENT obéir à ce comportement de réutilisation même si le transport réel utilisé 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 car il n'existe pas dans la base de données de principaux du KDC, alors un message d'erreur avec un code KDC_ERR_C_PRINCIPAL_UNKNOWN est retourné.

Si le serveur doit le faire, il 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 retourné. 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 retourné, 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.

Le KDC génère une clé de session 'aléatoire', ce qui signifie qu'entre autres choses, il devrait être impossible de deviner la prochaine clé de session en se basant sur la connaissance des clés de session passées.

Le KDC sélectionne le type de clé de session à partir de la liste des méthodes dans le champ etype. Le KDC n'émettra pas de tickets avec un type de chiffrement de clé de session faible.

Le temps d'expiration du ticket sera fixé au plus tôt du endtime demandé et d'un temps déterminé par la politique locale, éventuellement en utilisant des facteurs spécifiques au domaine ou au principal.

Le champ flags 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 drapeau INVALID sera également défini.

Le serveur formate ensuite un message KRB_AS_REP (voir section 5.4.2), copiant les adresses dans la demande dans le caddr de la réponse, plaçant toutes les données de pré-authentification requises dans le padata de la réponse, et chiffre la partie ciphertext dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande.

3.1.4. Génération du message KRB_ERROR

Plusieurs erreurs peuvent se produire, et le serveur d'authentification répond en retournant 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 et les détails du message d'erreur 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 texte 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 réutilisations). Il vérifie également que le sname et srealm dans la réponse correspondent à ceux de la demande (ou sont des valeurs autrement attendues), et que le champ d'adresse hôte est également correct. Il stocke ensuite le ticket, la clé de session, les temps de début et d'expiration, et d'autres informations pour une utilisation ultérieure.

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 toutes les tâches spécifiques à l'application nécessaires pour la récupération.