Résumé

  • 480 signalait qu’une commande était refusée dans l’état courant de la connexion, et non qu’elle attendait la fin de l’authentification.
  • Après AUTHINFO, le client devait relire les capacités disponibles puis émettre de nouveau sa demande sous la nouvelle identité.
  • Le succès de l’authentification ne décidait pas des droits : une politique locale pouvait encore répondre 502 à la commande répétée.

Ce que le serveur ne faisait pas après 281

Prenons une connexion qui demande GROUP local.research. Le serveur répond 480 Permission denied. Le client consulte les mécanismes disponibles, mène un échange AUTHINFO à son terme et reçoit 281 Authentication accepted. À cet instant précis, le serveur ne sélectionne toujours pas le groupe.

La sélection ne se produit que si le client envoie une seconde fois GROUP local.research. La première occurrence a obtenu une réponse terminale. Elle n’a pas été conservée comme une opération suspendue, associée en coulisses à la prochaine identité valide.

Cette propriété paraît modeste, mais elle distribue clairement les pouvoirs. Le serveur peut exiger une identité. Il ne peut pas conclure que la réussite d’un échange de justificatifs renouvelle automatiquement une intention antérieure. Le client reste responsable de l’action qu’il souhaite encore accomplir.

L’usage historique distinguait déjà les trois étapes

RFC 2980 a consigné les extensions NNTP répandues avant leur normalisation plus stricte. Pour AUTHINFO USER et AUTHINFO PASS, la séquence était explicite : 480 demandait une authentification, 381 pouvait réclamer le mot de passe et 281 annonçait l’acceptation. Ensuite, le client devait réessayer la commande initiale. Le serveur traitait cette nouvelle occurrence normalement.

On trouve donc trois événements, et non un seul parcours de connexion : une demande de ressource refusée, une identité acceptée, puis une nouvelle demande de ressource. Chacun produit sa propre preuve. Un journal fidèle peut dire ce que le client voulait avant de s’identifier, quelle méthode a établi l’identité et quelle décision a été prise ensuite.

Le mécanisme ancien avait toutefois une faiblesse majeure : RFC 2980 précisait que toutes les informations d’authentification circulaient en clair. La bonne séparation entre les opérations ne protégeait pas le secret. Un mot de passe exposé restait compromis même si le client rejouait correctement sa commande.

Authentifier n’était pas attribuer tous les droits

RFC 4643 a formalisé AUTHINFO, conservé USER/PASS pour compatibilité, abandonné les variantes SIMPLE et GENERIC et introduit un profil SASL. Le texte pose d’emblée une limite institutionnelle : l’extension authentifie un utilisateur, tandis que l’autorisation relève de la politique du site.

Ainsi, 480 désigne une indisponibilité susceptible de disparaître après authentification, pas une promesse. Une identité reconnue peut ouvrir l’accès à un groupe local, à la publication ou à une commande particulière. Elle peut aussi ne rien ouvrir du tout. RFC 4643 oppose à ce cas le code 502, qui permet au serveur de maintenir son refus alors même que l’authentification a réussi.

Le code 281 doit donc être lu avec précision. Il atteste l’issue de l’échange d’authentification dans cette session. Il ne prouve ni l’appartenance à chaque groupe, ni le droit de publier, ni l’identité de l’auteur d’un article. Il n’est pas une signature du contenu et ne transmet aucun privilège aux serveurs suivants.

Les capacités changeaient avec l’état de la connexion

Un client qui souhaite employer AUTHINFO est invité à commencer par CAPABILITIES. La liste ne décrit pas abstraitement tout ce que le logiciel serveur saura jamais faire. Elle indique ce qui est utilisable dans l’état présent : avant ou après TLS, avant ou après authentification, en mode lecteur ou en mode transit.

Après une authentification réussie, le serveur doit retirer la capacité AUTHINFO et refuser une nouvelle tentative AUTHINFO avec 502. D’autres capacités peuvent apparaître ou disparaître. Le client a donc une raison opérationnelle de demander une nouvelle liste avant de reprendre son objectif.

RFC 4643 impose cependant que la liste des mécanismes SASL reste identique après l’authentification. Ce maintien sert de témoin contre une éventuelle attaque de rétrogradation active. Il ne permet pas de recommencer l’authentification : AUTHINFO n’est plus offert. Le protocole distingue ainsi la trace nécessaire à la vérification de la négociation et l’autorité de refaire la transition d’identité.

Une reprise automatique de l’ancienne commande escamoterait ce changement de contexte. Elle ferait exécuter une intention formulée sous une liste de capacités différente, avant que le client n’ait pu observer le nouvel état.

Même l’échange d’identité avait ses portes

AUTHINFO possédait sa propre discipline. Le client pouvait l’entamer après 480, ou de sa propre initiative lorsque la capacité était annoncée. En revanche, il ne pouvait poursuivre au-delà de la première étape que si une réponse de la famille 38x l’y invitait. Toute autre réponse arrêtait l’échange.

Le serveur ne devait jamais répondre 480 à AUTHINFO lui-même. Sans cette interdiction, la commande destinée à satisfaire une exigence d’authentification pourrait déclencher la même exigence à l’infini. L’ancien 381 gardait une sémantique particulière : il réclamait la commande distincte AUTHINFO PASS, plutôt qu’un simple complément à la ligne précédente.

Une fois l’identité acceptée, le client ne pouvait pas en présenter une autre dans la même session. La mutation était à sens unique. Changer de principal exigeait une nouvelle connexion, ce qui empêchait les droits d’un utilisateur de se mélanger avec les opérations amorcées par un autre.

Le chiffrement répondait à une autre question

Le code 483 indiquait qu’une protection appropriée de la connexion manquait. RFC 4642 a défini STARTTLS pour franchir cette limite. Après la négociation TLS, l’état applicatif antérieur devait être abandonné et les capacités relues. USER/PASS pouvait alors devenir disponible parce que le canal était protégé ; certains mécanismes pouvaient aussi changer.

Quatre décisions demeuraient séparées : protéger le lien, établir une identité, autoriser une ressource et réexprimer l’action souhaitée. TLS ne choisissait pas le groupe. AUTHINFO ne garantissait pas le droit de le lire. La présence d’un droit ne prouvait pas que le client voulait encore exercer la commande initiale.

La protection restait en outre locale à cette liaison. Elle ne signait pas l’article et ne couvrait pas automatiquement sa propagation ultérieure. Un compte NNTP n’était pas transformé en identité universelle d’auteur.

La répétition était la preuve d’une intention actuelle

RFC 3977 illustre l’accès à une installation protégée par une première commande GROUP, un 480, un échange d’authentification, puis la répétition de GROUP. Cet exemple évite toute ambiguïté : la première commande a échoué dans l’ancien état ; elle n’attend pas dans le serveur.

Pour l’exploitation, il faut conserver cette granularité. Les traces devraient relier, sans les fusionner, la commande refusée, le code 480, les capacités annoncées, l’état TLS, la méthode AUTHINFO, son résultat, la nouvelle liste de capacités, la commande répétée et sa décision finale. Un tableau de bord qui réduit l’ensemble à « connexion réussie » devient incapable de distinguer un échec d’identité, un défaut de droit et l’absence de nouvelle demande.

La seconde commande peut avoir exactement les mêmes octets que la première. Elle reste un nouvel acte : son heure, son principal, son environnement fonctionnel et son résultat sont différents. Elle peut réussir, recevoir 502, rencontrer une autre erreur ou ne jamais être envoyée.

Un registre de noms ne distribuait pas les privilèges

Le registre IANA des paramètres NNTP consigne séparément les capacités AUTHINFO, SASL et STARTTLS et renvoie à leurs RFC respectives. Cette distinction permet aux deux extrémités de nommer précisément les transitions possibles.

Elle ne dit pas qu’un serveur particulier les propose, qu’un compte possède un droit ni qu’USER/PASS demeure activé. Les preuves pertinentes restent la réponse CAPABILITIES de cette connexion, l’issue de l’authentification et la réponse à la nouvelle commande.

NNTP a ainsi formulé une règle durable : lorsqu’une identité plus forte peut réparer le contexte d’une opération refusée, cette réparation ne doit pas ressusciter l’opération. Le système peut apprendre qui parle sans décider à sa place ce qu’il demande encore.

Sources