Résumé

  • Dans la révision 18 du projet RadSec de RADEXT, le client doit écarter une réponse dont le Response Authenticator échoue, mais garder ouverte la connexion (D)TLS. Il doit également la conserver lorsqu'aucune demande en attente ne correspond à la réponse. Le texte demeure un Internet-Draft examiné par l'IESG, non une norme publiée.
  • L'annexe nouvelle décrit une course possible : après expiration d'une demande, le client réemploie son Identifier sur une autre ; la réponse tardive à la première est alors vérifiée avec le nouvel état. Le rejet du paquet reste impératif. Le maintien de la session n'excuse pas une véritable défaillance du Message-Authenticator.

Le point de départ n'est pas une panne TLS, mais une réponse qui a perdu sa place dans le temps. Un client RADIUS cesse d'attendre une demande, libère son Identifier et l'utilise pour la suivante. Si la réponse à l'ancienne demande parvient alors au client, son contrôle peut échouer face à l'authentificateur de la nouvelle. Le message ne peut pas être remis comme une réponse valide. Faut-il pour autant mettre fin à une connexion qui transporte aussi d'autres échanges ?

La version datée du 30 septembre 2026 répond de manière plus précise que sa devancière. Au paragraphe 3.12, elle classe l'échec du Response Authenticator parmi les cas où le client RadSec doit éliminer la réponse tout en maintenant la connexion. Une réponse sans demande pendante reçoit le même traitement. Dans la version 17, le premier cas appartenait à la liste conduisant à la fermeture ; dans le second, la fermeture relevait du choix de l'implémentation. L'annexe A.1, ajoutée dans la version 18, explicite la course entre réponse tardive et réemploi de l'identifiant. Voilà la nouveauté vérifiable, et non une découverte générale de la sécurité RADIUS.

L'ancien cadre montre l'importance de cette distinction. Le RFC 6613 demandait de fermer TCP si le Response Authenticator d'une réponse échouait ; il laissait deux options pour une réponse sans requête correspondante. Le champ Identifier, long d'un octet, ne distingue que 256 valeurs sur une connexion. Après un délai d'attente, une valeur peut être reprise rapidement, notamment en charge. Le serveur peut expédier sa réponse ancienne juste avant de recevoir la nouvelle demande. Des délais différents de part et d'autre d'un relais RADIUS créent un autre cas de réponse tardive.

Le projet décrit ces possibilités ; il ne documente pas un incident chez un opérateur identifié.

Le nouvel assouplissement ne porte jamais sur la validité de la réponse. Le paquet est abandonné. Une fois que son Response Authenticator a échoué, vérifier ensuite son Message-Authenticator ne change rien au sort de ce paquet. En revanche, si la correspondance avec la demande est valide et que le Message-Authenticator échoue, le motif de fermeture demeure. Le serveur qui juge un client inadmissible doit, lui aussi, terminer immédiatement la connexion (D)TLS, et fermer TCP dans le cas RADIUS/TLS. La règle ne convertit donc pas une erreur d'intégrité avérée en simple bruit opérationnel.

Pour évaluer une implémentation, un compteur unique « échec d'authentification » ne suffit pas. Il faut pouvoir relier le paquet à une demande encore en attente ou non, voir à quelle vérification le traitement s'est arrêté, constater son rejet et observer si la session poursuit des transactions valides. Le projet recommande des journaux indiquant notamment code, identifiant et règle enfreinte ; ces journaux doivent être limités en débit lorsqu'on garde la connexion ouverte. Notre proposition d'une fiche d'essai séparant ces verdicts est une déduction éditoriale, non un nouveau format de télémétrie imposé par l'IETF.

Le document est toujours un projet actif du groupe RADEXT, soumis à l'IESG et dans l'état « Evaluation::AD Followup ». Son statut visé est Proposed Standard. Il n'a pas encore remplacé les RFC 6614 et 7360 : son en-tête conditionne ce remplacement à une approbation future. Le gain conceptuel de cette révision tient dans une phrase stricte : on peut refuser une réponse sans retirer, sur ce seul indice, la confiance accordée à la connexion.

Sources