---

We need Your Support. Make a Donation now! or

---

Mécanismes d'authentification IMAP4

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

1.   Introduction

Le protocole d'accès aux mesages Internet, version 4 (IMAP4, Internet Message Access Protocol, Version 4) [IMAP4] contient la commande AUTHENTICATE, pour identifier et authentifier un usager auprès d'un serveur IMAP4 et facultativement négocier un mécanisme de protection pour les interactions de protocole ultérieures. Le présent document décrit plusieurs mécanismes d'authentification à utiliser avec la commande IMAP4 AUTHENTICATE.

2.   Mécanisme d'authentification Kerberos version 4

Le type d'authentification associé à Kerberos version 4 est "KERBEROS_V4".

Les données codées dans la première réponse ready (prêt) contiennent un nombre aléatoire de 32 bits dans l'ordre des octets du réseau. Le client devrait répondre par un ticket Kerberos et un authentifiant pour le principal "imap.hostname@realm", où "hostname" est le premier composant du nom d'hôte du serveur avec toutes les lettres en minuscules et où "realm" est le domaine Kerberos du serveur. Le champ Somme de contrôle chiffré inclus au sein de l'authentifiant Kerberos devrait contenir le nombre de 32 bits fourni par le serveur dans l'ordre des octets du réseau.

Lors du déchiffrement et la vérification du ticket et de l'authentifiant, le serveur devrait vérifier que le champ de somme de contrôle contenu est égal au nombre aléatoire de 32 bits fourni à l'origine par le serveur. Si la vérification est réussie, le serveur doit ajouter un à la somme de contrôle et construire 8 octets de données, avec les quatre premiers octets contenant la somme de contrôle incrémentée dans l'ordre des octets du réseau, le cinquième octet contenant le gabarit binaire spécifiant les mécanismes de protection pris en charge par le serveur, et les octets six à huit contenant, dans l'ordre des octets du réseau, la taille maximale de mémoire tampon de texte chiffré que le serveur est capable de recevoir. Le serveur doit chiffrer les huit octets de données avec la clé de session et produire ces données chiffrées dans une seconde réponse ready. Le client devrait considérer que le serveur est authentifié si les quatre premiers octets des données non chiffrées sont égaux à la somme de contrôle qu'il a envoyé précédemment plus un.

Le client doit construire les données avec les quatre premiers octets contenant la somme de contrôle produite par le serveur d'origine dans l'ordre des octets du réseau, le cinquième octet contenant le gabarit binaire qui spécifie le mécanisme de protection choisi, les octets six à huit contenant dans l'ordre des octets du réseau la taille maximale de mémoire tampon de texte chiffré que le client est capable de recevoir, et les octets suivants contenant une chaîne de nom d'utilisateur. Le client doit alors ajouter de un à huit octets de sorte que la longueur des données soit un multiple de huit octets. Le client doit alors chiffrer les données en PCBC avec la clé de session et répondre à la seconde réponse ready avec les données chiffrées. Le serveur déchiffre les données et vérifie la somme de contrôle contenue. Le champ Nom d'utilisateur identifie l'usager pour lequel les opérations IMAP ultérieures sont à effectuer ; le serveur doit vérifier que le principal identifié dans le ticket Kerberos est autorisé à se connecter comme utilisateur. Après ces vérifications, le processus d'authentification est achevé.

Les mécanismes de protection et leurs gabarits binaires sont les suivants :

1   Pas de mécanisme de protection

2   Protection de l'intégrité (krb_mk_safe)

4   Protection de la confidentialité (krb_mk_priv)

EXEMPLE : Voici deux scénarios de connexion de Kerberos version 4 (noter que les coupures de ligne dans l'exemple d'authentifiant sont pour faciliter la lecture et ne sont pas dans l'authentiant réel)

S: * OK IMAP4 Server

C: A001 AUTHENTICATE KERBEROS_V4

S: + AmFYig==

C:BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh

S: + or//EoAADZI=

C: DiAF5A4gA+oOIALuBkAAmw==

S: A001 OK Kerberos V4 authentification réussie

S: * OK IMAP4 Server

C: A001 AUTHENTICATE KERBEROS_V4

S: + gcfgCA==

C:BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh

S: A001 NO Kerberos V4 échec d'authentification

3.   Mécanisme d'authentification GSSAPI

Le type d'authentification associé à tous les mécanismes employant le mécanisme GSSAPI [RFC1508] est "GSSAPI".

La première réponse ready produite par le serveur ne contient pas de données. Le client devrait appeler GSS_Init_sec_context, en passant 0 pour input_context_handle (initialement) et un targ_name égal à output_name provenant de GSS_Import_Name appelé avec unn input_name_type de NULL et un input_name_string de "SERVICE:imap@hostname" où "hostname" est le nom d'hôte pleinement qualifié du serveur avec toutes les lettres en minuscules. Le client doit alors répondre avec le output_token qui en résulte. Si GSS_Init_sec_context retourne GSS_CONTINUE_NEEDED, le client devrait alors s'attendre à ce que le serveur produise un jeton dans une réponse ready suivante. Le client doit passer le jeton à un autre appel à GSS_Init_sec_context.

Si GSS_Init_sec_context retourne GSS_COMPLETE, le client devrait alors répondre avec tout output_token résultant. Si il n'y a pas de output_token, le client devrait répondre sans données. Le client devrait alors s'attendre à ce que le serveur produise un jeton dans une réponse ready ultérieure. Le client devrait passer ce jeton à GSS_Unseal et interpréter le premier octet de texte en clair résultant comme un gabarit binaire qui spécifie les mécanismes de protection pris en charge par le serveur et les octets du second au quatrième comme la taille maximum de output_message à envoyer au serveur. Le client devrait construire les données, avec le premier octet contenant le gabarit binaire qui spécifie le mécanisme de protection choisi, les octets du second au quatrième contenant dans l'ordre des octets du réseau la taille maximum de output_message que le client est capable de recevoir, et les octets restants contenant une chaîne de nom d'utilisateur. Le client doit passer les données à GSS_Seal avec le conf_flag mis à FAUX, et répondre par le output_message généré. Le client peut alors considérer que le serveur est authentifié.

Le serveur doit produire une réponse ready sans données et passer le jeton fourni par le client en résultant à GSS_Accept_sec_context comme input_token, réglant acceptor_cred_handle à NULL (pour "utiliser les accréditifs par défaut"), et 0 pour input_context_handle (initialement). Si GSS_Accept_sec_context retourne GSS_CONTINUE_NEEDED, le serveur devrait retourner le output_token généré au client dans une réponse ready et passer le jeton resultant fourni par le client à un autre appel à GSS_Accept_sec_context.

Si GSS_Accept_sec_context retourne GSS_COMPLETE, et si un output_token est retourné, le serveur devrait le retourner au client dans une réponse ready et s'attendre à une réposne du client sans données. Qu'un output_token ait été retourné ou non, le serveur devrait alors construire 4 octets de données, avec le premier octet contenant un gabarit binaire spécifiant les mécanismes de protection pris en charge par le serveur et les octets du second au quatrième contenant, dans l'ordre des octets du réseau, la taille maximum de output_token que le serveur est capable de recevoir. Le serveur doit alors passer le libellé à GSS_Seal avec conf_flag réglé à FAUX et produire le output_message généré au client dans une réponse ready. Le serveur doit alors passer le jeton résultant produit par le client à GSS_Unseal et interpréter le premier octet du texte en clair résultant comme le gabarit binaire du mécanisme de protection choisi, les octets du second au quatrième comme la taille maximum du output_message à envoyer au client, et les octets restants comme le nom de l'usager. En vérifiant que le src_name est autorisé à s'authentifier comme nom d'usager, le serveur devrait alors considérer que le client est authentifié.

Les mécanismes de protection et les gabarits binaires correspondants sont les suivants :

1   Pas de mécanisme de protection

2   Protection d'intégrité . l'envoyeur appelle GSS_Seal avec le conf_flag réglé à FAUX

4   Protection de confidentialité . l'envoyeur appelle GSS_Seal avec le conf_flag réglé à VRAI

4.   Mécanisme d'authentification S/Key

Le type d'authentification associé à S/Key [SKEY] est "SKEY".

La première réponse ready produite par le serveur ne contient pas de données. Le client répond avec la chaîne de nom d'utilisateur.

Les données codées dans l   a seconda réponse ready contiennent le numéro de séquence décimal suivi par une seule espace et la chaîne de germe pour l'utilisateur indiqué. Le client répond avec le mot de passe à utilisation unique, soit comme une valeur de 64 bits dans l'ordre des octets du réseau, soit codé dans le format "six mots anglais".

Le mot de passe à utilisation unique ayant été bien vérifié, le serveur pourra considérer que le client est authentifié.

L'authentification S/Key ne fournit aucun mécanisme de protection.

EXEMPLE : Voici deux scénarios de connexion S/Key.

S: * OK IMAP4 Server

C: A001 AUTHENTICATE SKEY

S: +

C: bW9yZ2Fu

S: + OTUgUWE1ODMwOA==

C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==

S: A001 OK S/Key authentification réussie

S: * OK IMAP4 Server

C: A001 AUTHENTICATE SKEY

S: +

C: c21pdGg=

S: + OTUgUWE1ODMwOA==

C: BsAY3g4gBNo=

S: A001 NO S/Key échec d'authentification

5.   Références

[IMAP4]   M. Crispin, "Protocole d'accès au message Internet - Version 4", RFC 1730, décembre 1994.

[RFC1508]   J. Linn, "Interface générique de programme de service de sécurité", septembre 1993. (P.S.)

[SKEY]   Haller, Neil M. "The S/Key One-Time Password System", Bellcore, Morristown, New Jersey, octobre 1993, thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps

6.   Considérations pour la sécurité

Les questions de sécurité sont discutées tout au long de ce mémoire.

7.   Adresse de l'auteur

John G. Myers

Carnegie-Mellon University

5000 Forbes Ave.

Pittsburgh PA, 15213-3890

mél : jgm+@cmu.edu