Résumé

  • La RFC 2444 a remplacé les parseurs locaux et improvisés par un mécanisme OTP nommé dans SASL, assorti de formats d’échange définis.
  • Ce mécanisme authentifiait au moyen d’une réponse OTP, mais ne fournissait ni couche de sécurité, ni confidentialité de session, ni authentification du serveur, ni protection contre les attaques actives.

À la fin des années 1990, un client de messagerie pouvait intégrer l’authentification selon les habitudes propres à son protocole. La RFC 2444 s’attaque précisément à cette couture : l’OTP était ajouté de façon ad hoc, par analyse heuristique. Elle lui donne un nom de mécanisme dans la Simple Authentication and Security Layer, ou SASL. Un protocole applicatif peut ainsi appeler un échange défini au lieu d’inventer son propre analyseur de mots de passe OTP.

C’est une avancée d’interopérabilité, pas une promesse de sécurisation de toute la connexion. La RFC 2222 séparait déjà l’authentification de la négociation facultative d’une couche de sécurité. La RFC 2444 le dit sans détour : le mécanisme OTP ne fournit aucune couche de sécurité. Sa section consacrée à la sécurité exclut la confidentialité de session, l’authentification du serveur et la protection contre les attaques actives. Un échange peut donc aboutir à une réponse « authentification réussie » alors que le canal des commandes suivantes demeure un objet distinct, soumis à d’autres protections.

La RFC 2444 définit son profil à partir du système OTP de la RFC 2289 et des réponses étendues de la RFC 2243. Le serveur doit reconnaître quatre formes : hex, word, init-hex et init-word. Les deux premières portent une réponse ; les formes init- réinitialisent aussi le compteur. MD5 est obligatoire et SHA-1 recommandé. Le client signale un compteur trop bas et devrait proposer une procédure de réinitialisation. Chaque usage met à jour l’entrée correspondante dans la base d’authentification. La standardisation précise ainsi le comportement attendu des deux côtés, mais fait aussi de la compatibilité et de la gestion d’état des conditions opérationnelles.

La RFC cite le client non fiable — par exemple une borne en libre-service — comme cas d’usage. Un OTP intercepté ne devrait donner à ce client qu’une seule possibilité d’agir au nom de l’utilisateur. Cette garantie est plus étroite que la protection de la session qui suit. Le texte reconnaît aussi qu’une base d’authentification compromise reste exposée aux attaques par dictionnaire, tout en précisant qu’elle n’a pas besoin d’équivaloir à une base de mots de passe en clair.

Rien de cela ne rend le mécanisme invulnérable : la RFC évoque également l’attaque passive par dictionnaire et exige que les implémentations se prémunissent contre l’attaque par concurrence décrite dans la spécification OTP sous-jacente.

SASL distingue en outre l’identité d’authentification de l’identité d’autorisation. La première fournit les justificatifs ; la seconde désigne les privilèges demandés. Un agent peut s’authentifier avec ses propres justificatifs tout en sollicitant ceux d’un autre utilisateur ; une identité d’autorisation vide laisse le serveur en déduire une à partir des justificatifs. Une réponse OTP correcte règle donc une question de l’échange, pas toute la politique d’accès.

Le nom du mécanisme, la syntaxe des défis, l’encodage propre au protocole hôte, la protection du transport, l’identité du serveur et la décision d’autorisation ne doivent pas se fondre dans un unique état « authentifié ».

La RFC 2444 met à jour la spécification SASL de 1997 et rend obsolète l’usage prévu du mécanisme SASL S/Key. La RFC 4422 remplacera ensuite le cadre SASL initial ; la RFC 5034 décrit un profil POP3, tandis que la RFC 5802 définit un mécanisme distinct, SCRAM. Ces textes balisent l’évolution du cadre : ils ne prouvent ni un déploiement universel de la RFC 2444 ni la pertinence actuelle de ses recommandations cryptographiques de 1998. Une RFC décrit une interface normalisée et un comportement normatif, pas un recensement des implémentations.

La contribution historique est circonscrite : un protocole applicatif pouvait désormais demander un mécanisme OTP nommé plutôt que parser localement une convention de mot de passe. Le texte laisse le travail restant bien visible. Le concepteur devait préciser le transport des jetons SASL ; l’implémentateur, maintenir la cohérence du compteur ; l’exploitant, protéger les commandes après l’authentification ; l’application, déterminer les actes permis à l’identité authentifiée. « À usage unique » décrivait la limite de réutilisation de la réponse, non la sécurité de la session.

Sources