Résumé

  • Une requête RADIUS CoA ou Disconnect authentifiée établit l’origine acceptée du saut protocolaire. Elle ne démontre ni le mandat du demandeur pour ce client, ni l’unicité de la session ciblée, ni la capacité du NAS à exécuter l’attribut demandé.
  • La preuve exploitable relie l’accès initial, la comptabilité, le chemin des mandataires, le NAS, la clé de session, la requête exacte, son identité de rejeu, la réponse, l’état installé et le trafic. RADIUS/1.1 renforce le transport sans fusionner ces décisions.

Une identité de compte n’est pas une session

Le cas d’ouverture est un exercice d’exploitation, pas le récit d’un incident. Un même abonné utilise un ordinateur au bureau et un téléphone sur un réseau visité. Les deux accès exposent le même nom d’utilisateur, mais pas le même identifiant comptable, le même NAS, le même point d’attachement ni la même règle en cours.

Un moteur de risque veut limiter l’ordinateur. Il envoie une CoA-Request valide avec le nom d’utilisateur et un filtre. Le récepteur trouve deux lignes actives. Choisir la plus récente serait commode, mais cette préférence n’existe pas dans la demande. Appliquer le filtre aux deux transformerait un critère imprécis en pouvoir transversal. Refuser la sélection multiple préserve la seule conclusion justifiée : un acteur reconnu a demandé une action dont la cible reste ambiguë.

RFC 5176 distingue le client d’autorisation dynamique qui émet, le serveur d’autorisation dynamique qui reçoit, le NAS qui fournit le service et la session qui représente une instance de ce service. Un utilisateur peut avoir plusieurs sessions successives ou simultanées. Cette définition interdit de réduire toute la chaîne à un seul champ familier.

L’adresse du client RADIUS n’est pas l’abonné. Le NAS n’est pas la session. Le nom de compte n’est pas une attache actuelle unique. Le secret partagé ou le certificat du pair établit une relation technique ; il ne contient pas tout le mandat commercial et opérationnel nécessaire à chaque action.

Disconnect n’est pas un repli anodin

La CoA-Request modifie l’autorisation d’une session. La Disconnect-Request détruit le contexte sélectionné et met fin au service. Employer Disconnect quand un changement ciblé échoue élargit donc la décision : un filtre réversible devient une interruption.

Cette différence doit apparaître dans les rôles, les validations et le journal. Un système autorisé à ajuster un débit n’a pas besoin, par défaut, du droit de supprimer une session. Le raccourci « si CoA échoue, déconnecter » reporte le coût d’une intégration incomplète sur l’utilisateur et efface une partie de l’état utile au diagnostic.

La cardinalité appartient à l’autorisation

Les attributs de sélection peuvent inclure Acct-Session-Id, des informations de port NAS, d’adresse attribuée ou de station appelée et appelante. User-Name ou Chargeable-User-Identity aide à rattacher l’acte à la bonne personne ou au bon domaine, sans devenir une clé universelle.

Le récepteur doit calculer la cardinalité réelle du jeu complet : zéro, une ou plusieurs sessions vivantes. Ces résultats ne sont pas trois variantes d’un succès de recherche. Ils portent trois décisions. Les causes d’erreur Session Context Not Found et Multiple Session Selection Unsupported donnent justement une forme explicite aux deux cas où l’exécution ne doit pas être devinée.

Acct-Session-Id est utile seulement avec sa provenance. Il faut conserver le NAS qui l’a émis, le domaine ou locataire, l’époque de démarrage et les attributs d’affectation. Après un redémarrage, une réutilisation ou un déplacement, une valeur isolée peut pointer vers un autre contexte. La jointure entre comptabilité et inventaire actif est une vérification d’autorité, pas une préparation administrative.

L’authenticité du saut ne donne pas un mandat général

Dans le fonctionnement historique, l’adresse source UDP permet de choisir le secret partagé. Un authentificateur valide montre donc la cohérence du paquet avec un client configuré sur ce saut. Il ne signe pas l’approbation humaine, ne prouve pas la portée locataire et ne garantit pas qu’un mandataire antérieur n’a pas modifié les attributs avant de protéger le saut suivant.

RFC 5176 reconnaît le risque des NAS partagés : sans contrôle supplémentaire, un fournisseur peut agir sur les utilisateurs d’un autre. Des secrets distincts, le filtrage réseau et une vérification du chemin inverse réduisent ce pouvoir. La question locale reste pourtant entière : ce client peut-il demander cette opération pour ce domaine, ce NAS et cette session ?

RFC 8559 organise le retour d’une CoA dans l’itinérance. Le réseau d’origine conserve Operator-Name et, s’il est fourni, un Operator-NAS-Identifier opaque créé par le réseau visité. La demande ultérieure suit le domaine de l’opérateur vers le réseau où vit la session. Elle ne suit pas le domaine du nom d’utilisateur comme si le chemin d’authentification pouvait simplement être inversé.

Le réseau visité traduit ensuite son jeton opaque vers le NAS interne, retire les signaux réservés aux mandataires et produit une requête locale. Cette délégation est traçable, mais elle n’est pas de bout en bout. Chaque mandataire voit les données qu’il traite, peut les modifier et protège un nouveau saut. Le dossier d’autorisation doit donc nommer cette chaîne au lieu d’attribuer le paquet final directement à une décision lointaine.

Une cible unique peut encore recevoir une action invalide

Une fois la session sélectionnée, chaque changement doit être admis séparément. Un filtre, un VLAN, une limite de débit ou un attribut fournisseur peut être inconnu, impossible sur cette méthode d’accès ou interdit pour ce locataire. RFC 5176 demande au destinataire final de traiter les attributs comme obligatoires : si l’ensemble ne peut pas être appliqué, la réponse doit être négative, non un succès partiel dissimulé.

Il faut aussi séparer les champs qui identifient de ceux qui agissent. Un même attribut fournisseur ne doit pas sélectionner la session et définir simultanément la modification. Sinon, la valeur qui répond à « qui ? » commande déjà « quoi ? », sans point de contrôle intermédiaire.

Certaines mutations impliquent une renégociation dans une couche inférieure. La présence d’un attribut n’ajoute pas une capacité au logiciel du NAS. Les catalogues centraux doivent décrire le comportement effectivement déployé. Ils ne peuvent pas déclarer une fonction opérationnelle à la place du code qui tourne.

Un nouvel envoi n’est pas une nouvelle intention

Sur UDP, une retransmission inchangée vers le même serveur conserve port source, Identifier et Request Authenticator. Une modification d’attributs impose une nouvelle identité. Le serveur doit reconnaître les doublons pendant la période pertinente afin qu’une perte de réponse ne transforme pas une seule décision en plusieurs exécutions.

Sans protection IPsec contre le rejeu, Event-Timestamp apporte une borne de fraîcheur. Le timestamp initial reste inchangé lors d’une retransmission. La fenêtre temporelle et la mémoire des doublons doivent donc couvrir la même période. Si la mémoire expire plus tôt, un ancien paquet encore jugé frais peut être exécuté une seconde fois.

Ce timestamp n’est ni l’heure d’un ticket approuvé ni la preuve que la session est toujours la même. Il décrit l’émission de la requête protocolaire dans la tolérance des horloges participantes. De même, une réponse remise depuis un cache ne représente pas une deuxième application. La télémétrie doit séparer décision initiale, retransmission, doublon supprimé, réponse mémorisée et nouvelle action indépendante.

RADIUS/1.1 déplace la frontière cryptographique

RFC 9765 définit le nom ALPN radius/1.1 et exige TLS 1.3 ou une version ultérieure. Si les deux pairs le négocient, TLS porte l’authentification de connexion, l’intégrité et la confidentialité. Les anciens calculs Request et Response Authenticator ne servent plus dans ce mode ; Message-Authenticator n’y authentifie plus le paquet.

Un Token de quatre octets associe requête et réponse. Chaque nouveau paquet de la connexion reçoit une nouvelle valeur. Une retransmission DTLS inchangée conserve la sienne. La détection des doublons est liée à la connexion : le même Token ailleurs désigne un autre événement.

Cette modernisation est importante. Elle ne choisit cependant aucun abonné, ne donne aucun droit inter-locataire et ne démontre aucun filtre installé. Les codes CoA et Disconnect et la majorité des attributs gardent leur sens. Il faut donc deux registres : l’un pour certificat, ALPN, version TLS, connexion et Token ; l’autre pour domaine, NAS, cible, action, décision locale et résultat.

Une ACK est un témoignage à vérifier

Une CoA-ACK indique que le NAS affirme avoir effectué la modification. Une NAK et son Error-Cause classent le refus. Le contrôle final compare pourtant l’état avant et après : filtre installé, VLAN, débit, continuité comptable et trafic représentatif.

Une ACK sans changement observable révèle un défaut d’application. Un changement dont la réponse s’est perdue révèle un défaut d’observation du transport. Une NAK après mutation partielle révèle une rupture d’atomicité. Un compteur unique « échec CoA » masquerait le composant responsable.

La chaîne minimale relie l’accès initial, le relevé comptable, l’inventaire actuel, le demandeur autorisé, les mandataires, l’empreinte exacte de la requête, son Token ou son identité historique, le timestamp, la cardinalité, la capacité locale, la réponse, l’état installé, les paquets et l’inversion ciblée.

Éprouver les refus proches du succès

Créer deux sessions d’essai simultanées avec le même identifiant tentant, mais des Acct-Session-Id et contextes NAS différents. Une demande étroite doit en changer exactement une. Le trafic de l’autre doit rester identique.

Retirer ensuite le champ distinctif. Le système doit refuser l’ambiguïté sans préférer la session la plus récente ni l’ordre accidentel d’une base. Répéter le paquet doit produire au plus la même réponse, pas un nouvel effet. Tester encore un timestamp périmé, un domaine non autorisé, le mauvais NAS et un attribut non pris en charge.

Le retour arrière restaure l’état précédent par une action de portée équivalente. Une déconnexion n’est correcte que si la décision initiale était de terminer la session. Le test probant montre à la fois le chemin admis et les pouvoirs voisins que le NAS refuse sans toucher à l’utilisateur protégé.

Sources