Résumé

  • RFC 4422 sépare l’identité liée aux justificatifs de celle au nom de laquelle le client demande d’agir ; le serveur doit contrôler les justificatifs puis cette délégation.
  • Une négociation SASL réussie établit un état de session et parfois une couche de sécurité, sans décider à elle seule des opérations que l’application autorisera ensuite.

Un « oui » à portée limitée

Les interfaces aiment les résultats binaires. Un voyant vert rassure l’utilisateur, simplifie la télémétrie et permet au développeur de poursuivre le scénario. Or le même voyant peut finir par représenter trois affirmations différentes : les justificatifs sont valides, cette identité peut agir ici, et cette opération lui est permise. SASL conserve les articulations que l’écran efface.

RFC 4422 décrit un cadre placé entre un protocole applicatif et des mécanismes d’authentification interchangeables. Le mécanisme sait éprouver des justificatifs ; le profil applicatif sait transporter l’échange et rattacher son résultat à l’état du protocole. Cette séparation autorise l’évolution de l’un sans réécrire l’autre. Elle interdit surtout d’attribuer au mécanisme une politique métier qu’il ne connaît pas.

Le succès final peut installer une couche de sécurité négociée. Il peut aussi signifier que le serveur accepte d’associer une identité à la session. Il ne constitue pas pour autant une liste de ressources ouvertes. Une commande refusée juste après n’annule pas le succès précédent : elle révèle que deux décisions ont correctement été gardées distinctes.

S’authentifier comme A, demander à agir comme B

Le texte distingue deux identités. L’identité d’authentification est celle que les justificatifs établissent ou impliquent. L’identité d’autorisation est celle au nom de laquelle le client souhaite agir. Dans le cas ordinaire elles ont le même nom, ce qui rend l’écart presque invisible.

Quand le client omet la chaîne d’identité d’autorisation, il demande au serveur de retenir l’identité associée aux justificatifs. Mais le modèle couvre également la délégation : un processus peut prouver qu’il est A et solliciter le droit d’agir comme B. Le serveur doit alors vérifier le secret ou le certificat, puis vérifier séparément la relation entre A et B.

Des justificatifs authentiques ne suffisent donc pas à réussir une délégation. Ce garde-fou évite qu’un compte technique, une passerelle ou un administrateur doté d’un moyen de connexion ne reçoive automatiquement toutes les identités qu’il peut nommer.

L’expression « identité d’autorisation » peut encore induire en erreur. Elle désigne une identité utilisable par l’état d’autorisation du protocole ; elle n’est pas un rôle universel. Les droits sur un dossier, une boîte ou une commande restent l’affaire des contrôles applicatifs.

Le profil applicatif doit terminer la phrase

Le cadre commun laisse volontairement certaines réponses au protocole qui l’adopte. Son profil doit dire comment les mécanismes sont annoncés, comment circulent défis et réponses, quelle syntaxe reçoit l’identité demandée, où commence une couche de sécurité et ce qu’une nouvelle authentification change à un état antérieur.

Ce partage des responsabilités est plus qu’un catalogue d’obligations documentaires. Il précise quel acteur possède le sens. Une chaîne d’identité correcte dans un protocole peut être incorrecte dans un autre. Une nouvelle couche cryptographique peut protéger la suite des octets sans déterminer si la commande qu’ils encodent est autorisée.

Dans un déploiement réel s’ajoutent les correspondances locales : normalisation d’un nom, liaison avec un compte interne, appartenance à des groupes, règles portant sur la ressource. Une trace SASL irréprochable ne certifie pas que ces correspondances étaient exactes, à jour ou suffisamment étroites.

Ce que signifie exactement 235

L’extension SMTP AUTH fournit un repère concret. RFC 4954 réserve 235 2.7.0 Authentication Succeeded au succès de la commande AUTH. Une identité d’autorisation est alors associée à la session SMTP. La réponse décrit ce passage-là ; elle n’atteste ni une transaction de courrier future ni son acheminement.

Lorsqu’une couche de sécurité est négociée, SMTP revient même à son état initial : les connaissances de capacités acquises auparavant sont abandonnées et le client devrait envoyer de nouveau EHLO. Le succès de l’authentification peut donc provoquer un recommencement ordonné du protocole applicatif.

Les politiques de relais, les destinataires, les filtres, les files d’attente et la remise se décident ailleurs. Cet exemple ne transforme pas l’article en histoire de livraison du courrier. Il montre seulement qu’un code de réussite possède un objet grammatical précis : ici, la commande AUTH.

Un mécanisme SASL peut ne prouver personne

La variante ANONYMOUS de RFC 4505 rend impossible toute lecture automatique du mot « réussite ». Elle permet délibérément un accès sans établir ni révéler l’identité de l’utilisateur, généralement sous des privilèges restreints. Sa chaîne de traçage facultative n’est pas authentifiée et peut être falsifiée.

L’analyste doit donc connaître la sémantique du mécanisme avant de qualifier l’événement. Transformer chaque fin de négociation SASL en « utilisateur vérifié » appauvrit le journal et peut attribuer une identité là où la norme exige justement de ne pas en voir une.

Une meilleure cryptographie ne décide pas à qui appartient la salle

RFC 7677 a ensuite enregistré SCRAM-SHA-256 et SCRAM-SHA-256-PLUS. Employer SHA-256 et traiter la liaison de canal améliore la partie remplaçable de l’échange. Cette évolution protège mieux la preuve ; elle n’écrit pas la règle d’accès à la ressource.

Une migration cryptographique ne corrige donc ni un groupe trop large, ni une délégation périmée, ni une application qui confond l’identité de session avec le droit d’exécuter une opération. Tester seulement le nouveau mécanisme peut livrer un système mieux protégé contre certains adversaires et inchangé face à son erreur d’autorisation.

Conserver les preuves de chaque décision

Un journal exploitable devrait distinguer le mécanisme choisi, l’usage éventuel d’une liaison de canal ou d’une couche de sécurité, l’identité issue des justificatifs, l’identité demandée, celle finalement acceptée, la règle qui a permis d’agir en son nom et la décision ultérieure sur la ressource.

Réduire le tout à un champ « utilisateur » rend plusieurs incidents indiscernables : vol de justificatifs, délégation excessive, correspondance obsolète ou permission applicative trop généreuse. Un bit de succès suffit à conduire le protocole ; il ne suffit pas à reconstruire la responsabilité.

Le vocabulaire de l’interface doit suivre la même discipline. « Connecté en tant que » nomme un état de session. « Autorisé à modifier » affirme une décision sur un objet précis. Le produit qui fusionne les deux transforme les refus légitimes en surprises et dissimule l’endroit où la politique agit réellement.

Sources