Résumé

  • UNAUTHENTICATE permet à un client administratif de quitter une identité IMAP sans fermer la connexion, puis de demander à agir pour un autre utilisateur. Le maintien du canal ne vaut pas maintien des droits.
  • La remise à zéro a des exceptions précises : TLS reste en place, ses éléments d’authentification ne sont pas supprimés et le traitement d’IMAP ID dépend de l’implémentation.
  • Un proxy qui ne contrôle que la première authentification peut laisser la suivante atteindre directement le serveur de stockage. La réutilisation doit être examinée sur l’ensemble du parcours d’autorisation, pas seulement à l’endroit où le second accès réussit.

Ce qu’une connexion fermée faisait à notre place

Fermer une connexion a un coût facile à voir. Il faut en ouvrir une autre, rétablir ses protections et attendre les échanges nécessaires. Ce que la fermeture apportait à l’isolation est moins souvent comptabilisé : elle marquait la fin d’un contexte dont on pouvait supposer qu’il appartenait à un seul utilisateur.

Un service administratif de messagerie peut avoir de bonnes raisons de vouloir supprimer cette répétition. Il agit pour beaucoup de comptes, l’un après l’autre. Reprendre le même canal semble alors relever de la simple efficacité opérationnelle.

Mais l’optimisation transforme le travail à effectuer. La fin du premier utilisateur n’est plus portée par la fin de la connexion. Elle doit devenir une transition explicite, suffisamment complète pour que le suivant n’hérite ni de données de travail ni de privilèges.

Le RFC 8437, publié en août 2018, définit précisément cette possibilité pour IMAP. Son exemple est une passerelle de messagerie vocale : elle dépose les messages dans les boîtes des utilisateurs, puis les marque comme lus lorsque ceux-ci les écoutent par téléphone. Le client administratif peut donc avoir besoin de représenter successivement plusieurs personnes.

Le bénéfice recherché est d’éviter de recréer une connexion pour chacune, notamment lorsqu’une protection du transport a été négociée. Le document ne fournit pas pour autant un gain de performance universel. Il décrit une option dont le prix dépend de la capacité à retirer proprement l’ancien contexte.

Revenir à l’entrée, sans désigner le prochain titulaire

UNAUTHENTICATE ajoute à la machine à états IMAP une transition de l’état authentifié, ou de l’état où une boîte est sélectionnée, vers l’état non authentifié. La commande ne prend pas d’argument. Un résultat OK signifie qu’elle est terminée et que la connexion se trouve désormais dans cet état d’entrée.

Si une boîte était sélectionnée, elle cesse de l’être, sans événement d’expunge. Sortir d’un contexte n’est donc pas une instruction de suppression des messages. Ce n’est pas non plus une réécriture des règles durables d’accès à la boîte.

La commande ne choisit pas davantage le prochain utilisateur. Le client peut ensuite demander une nouvelle authentification, selon les capacités du serveur. Cette demande doit encore être acceptée. Quitter une identité ne crée aucun droit automatique à en prendre une autre.

La norme demande de réinitialiser l’état de la connexion, mais conserve la couche TLS. Elle prévoit aussi un traitement particulier pour IMAP ID, laissé à l’implémentation. Il faut tenir les deux limites ensemble : ni effacement universel, ni maintien de l’autorité applicative au seul motif que le transport reste protégé.

Cette distinction est utile au-delà du vocabulaire. Une interface d’administration qui ne montre qu’un identifiant de connexion peut donner l’impression que la relation de sécurité n’a pas changé. Or ce qui peut rester constant est le canal, pas nécessairement l’identité autorisée à travailler à l’intérieur.

Le refus ordinaire n’est pas une issue prévue

UNAUTHENTICATE n’autorise pas une réponse protocolaire NO. BAD correspond aux cas d’état invalide, de commande non annoncée ou de syntaxe incorrecte. Si le serveur ne parvient pas à remettre l’état à zéro, il peut fermer la connexion avec une réponse BYE non étiquetée.

Ce détail évite une ambiguïté dangereuse. Le client peut avoir modifié le traitement des octets qui suivent la commande, voire avoir envoyé la demande d’authentification suivante dans les conditions permises. Une réponse négative ordinaire, laissant l’ancien état en place, ne constitue pas la sortie définie par cette commande.

Préserver la connexion ne peut donc pas devenir l’objectif supérieur à tous les autres. Quand le retrait de l’ancien contexte ne peut être assuré, la fermeture reste une issue légitime. Elle renonce à l’économie attendue pour ne pas promettre une réutilisation dont la condition essentielle manque.

Il serait toutefois tout aussi inexact de dire que chaque difficulté impose systématiquement la même fermeture. Le RFC autorise cette issue lorsque la réinitialisation est impossible. Une évaluation doit distinguer succès de remise à zéro, erreur de commande et fermeture de protection, sans transformer un cas possible en comportement universel.

Le point économique est déjà visible : le nombre de connexions conservées ne mesure pas, à lui seul, la qualité de l’optimisation. Il faut également savoir à quelles conditions il a été obtenu.

Les couches ne se retirent pas toutes ensemble

La transition traverse aussi les couches négociées dans le flux. Si une couche de sécurité SASL est active, celle qui traite les données émises par le client prend fin immédiatement après le CRLF suivant UNAUTHENTICATE. Dans le sens serveur vers client, elle se termine immédiatement après le CRLF suivant la réponse OK.

Les deux frontières correspondent à deux messages différents. Les confondre reviendrait à mal définir l’endroit où les octets suivants changent de traitement. L’identité visible dans une console n’est donc qu’une petite partie du travail de remise à zéro.

Une couche de compression IMAP active possède les frontières sortantes correspondantes. Lorsque l’ordre importe, elle se termine avant la couche SASL. TLS, en revanche, demeure.

On ne peut résumer l’opération à « couper le chiffrement puis se reconnecter ». Cette formule effacerait la différence entre SASL, compression et TLS. L’extension conserve délibérément une protection tout en retirant d’autres états.

Le raccourci de performance est lui aussi conditionnel. Le client peut enchaîner dans le flux UNAUTHENTICATE et une commande AUTHENTICATE suivante lorsqu’aucune couche de sécurité SASL n’était active. Si SASL-IR est également annoncé, cela peut permettre une réauthentification administrative en un aller-retour. Ce n’est ni une mesure réalisée ici ni une permission générale de regrouper les commandes dans toutes les configurations.

Enfin, le serveur peut n’annoncer UNAUTHENTICATE qu’après une première authentification. Une interrogation CAPABILITY à ce moment peut donc être nécessaire. L’annonce initiale des possibilités du serveur ne décrit pas obligatoirement toutes les possibilités accessibles dans les états suivants.

Les anciens droits se cachent parfois dans les caches

La norme cite explicitement les informations d’identité mises en cache pour évaluer les listes de contrôle d’accès, notamment les appartenances à des groupes. Changer de nom d’utilisateur sans éliminer une telle information ne constitue pas une isolation réussie.

Les fonctionnalités activées sur la connexion doivent également revenir à leur état approprié. CONDSTORE doit se comporter comme si aucune commande ne l’avait activé. Les extensions ouvertes par ENABLE cessent d’être activées. QRESYNC, les extensions de métadonnées et UTF8=ACCEPT figurent parmi les exemples, sans épuiser l’obligation.

Les résultats conservés par SEARCHRES sont abandonnés : la référence au résultat sauvegardé représente ensuite l’ensemble vide. LANGUAGE revient à i-default. Les contextes de recherche font l’objet d’un CANCELUPDATE implicite. L’état associé à NOTIFY est annulé, et les notifications reviennent au comportement de base d’IMAP.

L’objet de ces suppressions est le contexte de travail de la connexion. Elles n’ordonnent pas de détruire les messages persistants ni les définitions permanentes de politique. Ce sont les interprétations accumulées pour le premier utilisateur qui ne doivent pas accompagner le suivant.

Surtout, le RFC étend cette exigence aux extensions actuelles et futures, avec les exceptions STARTTLS et ID. La prise en charge de la réutilisation n’est donc pas une tâche que l’on termine une fois pour toutes. Une nouvelle fonctionnalité conservant un état par utilisateur peut ajouter une obligation de nettoyage sans changer la syntaxe d’UNAUTHENTICATE.

Un test limité au succès de la deuxième authentification risque de passer à côté du problème. Le serveur peut accepter le bon nom et conserver une mauvaise appartenance de groupe, une sélection sauvegardée ou une notification liée au compte précédent. Ce qui manque alors n’est pas nécessairement l’authentification ; c’est la preuve que l’ancienne relation a pris fin.

Le certificat reste, son lien applicatif change

Le cadre SASL du RFC 4422 distingue l’identité associée aux éléments d’authentification de celle sous laquelle le client demande à agir. Le serveur doit vérifier les éléments présentés et le droit de cette identité à représenter l’identité d’autorisation demandée.

EXTERNAL utilise des éléments établis en dehors du mécanisme. Il peut transporter une identité d’autorisation, mais ne fournit pas lui-même de couche de sécurité. Sans accord préalable, le client ne peut présumer de la source externe choisie par le serveur, pas même supposer qu’il s’agit nécessairement de TLS. La protection externe et les règles de correspondance restent déterminantes.

RFC 8437 décrit un usage particulier des éléments d’authentification du client TLS. UNAUTHENTICATE rompt leur lien au niveau applicatif sans les supprimer. Un certificat administratif peut ainsi participer à plusieurs demandes EXTERNAL sur la même connexion, pour différents utilisateurs, dans les limites des autorisations applicables.

Un certificat quelconque ne devient pas pour autant un droit de choisir n’importe quel compte. La persistance du certificat n’est pas la persistance de la dernière identité IMAP. Inversement, quitter cette identité n’est pas révoquer le certificat.

Le document traite aussi le cas de certaines configurations imaps qui associent immédiatement le certificat client TLS à son identité IMAP par défaut, avec une annonce PREAUTH. Si UNAUTHENTICATE est annoncé, un client administratif peut quitter cette association initiale puis demander AUTHENTICATE EXTERNAL pour l’identité utile à son travail.

Il ne faut pas en conclure que PREAUTH est toujours un défaut. Le cas montre simplement qu’une association initiale automatique peut être différente de celle requise pour représenter un autre utilisateur. Le protocole fournit un passage explicite pour refaire cette association, pas une autorisation implicite de l’ignorer.

ID décrit un logiciel, pas son mandant

Le nom IMAP ID peut prêter à confusion. Le RFC 2971 définit l’échange d’informations sur les implémentations pour le diagnostic et les statistiques : nom du programme, version et autres propriétés utiles à l’analyse des problèmes.

La norme interdit les changements opérationnels fondés sur ces données. Elles ne doivent pas servir à accorder des fonctionnalités, à appliquer des optimisations particulières ou à refuser un service. Une identité logicielle déclarée ne remplace pas la négociation des capacités, encore moins une identité autorisée.

Les implémentations peuvent fournir moins d’informations ou envoyer NIL, mais pas des informations fausses. La possibilité de réduire la divulgation ne transforme pas ce canal descriptif en mécanisme de preuve.

C’est pourquoi RFC 8437 laisse à l’implémentation l’interaction entre ID et UNAUTHENTICATE. Conserver la version du logiciel administratif sur la durée du canal peut être utile, alors même que ce logiciel change d’utilisateur représenté. Cette conservation ne prolonge aucun droit de l’ancien utilisateur.

Elle peut cependant avoir des conséquences de confidentialité. RFC 2971 avertit que des identifiants uniques ou presque uniques peuvent faciliter le suivi, que certaines informations d’implémentation peuvent aider un attaquant et qu’une journalisation naïve des données non authentifiées peut épuiser les ressources de journal.

Dire que l’identité applicative a été retirée ne prouve donc pas que toute information permettant un rapprochement a disparu. Le contrôle doit demander quelle donnée reste, pour quelle finalité et avec quel droit d’usage. Une exception de diagnostic ne doit pas devenir une autorité cachée ou un dispositif de corrélation sans limite.

Le modèle de privilèges doit accepter le retour

L’avertissement architectural du RFC 8437 va plus loin qu’un inventaire de variables. L’extension n’est pas compatible avec une approche où chaque identité IMAP correspond à une identité du système d’exploitation et où le serveur abandonne tous ses privilèges administratifs après l’authentification.

Une telle approche n’offre pas nécessairement le retour à la capacité administrative permettant de servir un autre utilisateur. La réutilisation suppose donc un autre cycle de vie des privilèges, pas seulement un transport gardé en réserve.

Le document souligne les coûts de performance de l’approche antérieure sur Unix et présente l’efficacité comme une priorité des environnements visés. Il précise aussi que l’extension peut ne pas convenir aux environnements les plus sensibles. Ce sont des considérations de conception du RFC, non un classement actuel des produits ou un résultat de mesure.

Le cas du proxy pose la même question à l’échelle de plusieurs composants. Certaines architectures font contrôler la première authentification par un intermédiaire, puis laissent passer le flux vers le serveur de stockage. Si des restrictions existent uniquement dans l’intermédiaire, une authentification ultérieure peut les contourner lorsqu’il ne traite plus cette transition.

La norme impose aux implémentations de fournir un moyen de désactiver l’extension lorsqu’elle est inutile. Un proxy qui traite UNAUTHENTICATE à son propre niveau élimine le problème de passage direct ainsi décrit. N’activer l’extension que pour des éléments d’authentification associés à une identité administrative est une autre atténuation proposée.

L’analyse reste conditionnelle. Aucun compte de messagerie n’a été manipulé, aucun changement d’utilisateur n’a été exécuté et aucun contournement de proxy n’a été testé pour cet article. Une commande prise en charge ne prouve ni qu’une architecture est vulnérable ni qu’elle est correctement isolée.

La responsabilité doit suivre l’économie réalisée

Au moment de la recherche, les pages d’errata du RFC 8437, d’errata du RFC 4422 et d’errata du RFC 2971 ne renvoyaient aucun enregistrement correspondant. Cette observation ne garantit pas l’absence de défaut dans les implémentations.

RFC 8437 évoque également un bénéfice possible de confidentialité entre centres de données : la réutilisation pourrait rendre l’analyse de trafic plus difficile. Le conditionnel est essentiel. Ce n’est pas une garantie d’anonymat, et cela n’annule pas les questions soulevées par les données ID conservées.

La réflexion de Lu Heng sur le problème d’agence au cœur de la gouvernance d’internet aide à poser la question organisationnelle : qui décide de l’économie de connexions, et qui assume le coût de l’isolation lorsque le canal sert plusieurs utilisateurs ? Son texte sur la réalité plutôt que le plaidoyer comme produit de BTW Media invite à ne pas dépasser ce que les sources montrent.

Ces textes fournissent une grille de lecture, pas une preuve des intentions des développeurs. Les gains de capacité, les fuites entre utilisateurs et les coûts de support restent ici des conséquences possibles à mesurer, non des résultats observés.

L’annexe du RFC explique une raison précise de séparer UNAUTHENTICATE de l’authentification : le code qui reçoit une demande potentiellement hostile est plus simple à examiner s’il entre toujours par l’état non authentifié. Une commande distincte facilite aussi l’activation ou la désactivation de la fonction.

La frontière n’est donc pas censée disparaître. Elle doit pouvoir être rétablie plusieurs fois dans un même canal. C’est cette obligation répétée, et non la seule longévité de la connexion, qui définit la qualité de la réutilisation.