Résumé

  • Le RFC 5113 distingue la découverte du point d’attachement, le choix de l’identité, le routage AAA, le chemin des paquets et la découverte des services ou du tarif.
  • Une même identité peut être authentifiée par plusieurs relations d’itinérance, avec des coûts, des capacités et des routes de trafic différents.
  • La sélection a généralement lieu avant l’authentification : l’annonce initiale reste donc un indice à confirmer, pas une instruction qui s’impose au terminal.

Deux routes mènent au serveur AAA du domaine d’origine. La première passe directement par une relation bilatérale. La seconde traverse un consortium. Les deux reconnaissent les mêmes identifiants et acceptent le même secret. Sur un écran d’exploitation centré sur l’authentification, elles sont équivalentes : succès.

Pour l’utilisateur, elles peuvent être très différentes. Le prix, les services accessibles et le tunnel emprunté par les paquets peuvent dépendre de la relation choisie. Le RFC 5113 fait de cette divergence un problème de sélection et non un défaut secondaire de facturation.

L’identité choisissait aussi une route

Le NAI identifie l’utilisateur, mais son domaine sert également au routage de la requête AAA. Choisir un identifiant et les justificatifs associés revient donc à sélectionner une partie de l’infrastructure qui tentera de joindre le serveur d’origine.

Ce couplage explique une conclusion essentielle du RFC : le choix des justificatifs et le routage AAA sont deux aspects du même problème de sélection d’identité. Les traiter comme des équipes ou des journaux indépendants détruit la causalité. Une anomalie de route peut apparaître comme un échec de compte ; un mauvais identifiant peut apparaître comme une indisponibilité de réseau.

Le succès ne referme pas tout. Il prouve qu’un échange a atteint une autorité disposée à accepter le justificatif. Il ne prouve pas que le chemin était préféré, que la relation commerciale était celle attendue ou que les données suivront la même topologie.

Cinq décisions, pas un seul bouton

La première décision concerne le point d’attachement visible. Plusieurs points peuvent annoncer des capacités radio ou de liaison proches tout en donnant accès à des ensembles de services différents.

La deuxième concerne le réseau et le domaine utilisables. Une annonce peut dire qu’un domaine est accessible sans fournir une vue complète des relations d’itinérance.

La troisième concerne l’identité et les justificatifs. Un terminal possédant plusieurs identités doit savoir laquelle a une chance raisonnable d’aboutir.

La quatrième est la route AAA. Proxies, domaine d’origine et politiques intermédiaires déterminent le chemin de l’échange d’accès.

La cinquième est la route utile : tunnel, accès Internet, service demandé, qualité, sécurité et politique tarifaire.

Une plate-forme qui stocke uniquement « connecté » efface les quatre transitions précédentes et rend impossible l’explication d’un résultat coûteux mais techniquement valide.

L’information arrive trop tôt ou trop tard

Pour réduire le délai, le terminal aurait besoin des caractéristiques du réseau avant de s’authentifier. Mais c’est précisément avant l’authentification que cette information est la moins facile à protéger et à vérifier.

Lorsque l’authentification révèle une capacité insuffisante, le terminal a déjà choisi le réseau, le point et le NAI. Il doit recommencer. Le coût comprend une nouvelle association, un nouvel échange EAP, un possible changement de justificatif et l’interruption visible par l’application.

Une clé dynamique issue de l’authentification ne peut pas protéger l’annonce qui l’a précédée. Une signature ou une clé préconfigurée peut déplacer la confiance en amont, mais exige sa propre distribution. Le problème ne disparaît pas ; il devient un problème de provisionnement.

Les realm hints étaient une réparation

Le RFC 4284 permet de renvoyer des indications de domaines lorsqu’une requête rencontre une zone sans route par défaut. Le RFC 5113 refuse d’en faire une carte complète. La taille du paquet est limitée, la table peut être confidentielle et la liste peut omettre des domaines valides. Le mécanisme n’est pas un protocole de routage dynamique.

Il est plus sûr de le lire comme une réparation : une première tentative échoue, le proxy AAA central propose quelques identités alternatives et le terminal peut recommencer dans une limite définie.

Le proxy central est mieux placé qu’un NAS pour produire cette indication. Il dispose de l’état dont il se servira ensuite pour router la requête. Si chaque NAS maintient une copie manuelle, une annonce peut survivre au retrait de la route ou ignorer une nouvelle relation. Faire produire l’indice par l’acteur qui devra l’exécuter crée un partage du destin.

L’annonce n’était pas un mandat

Avant l’authentification, la divulgation de tous les domaines pris en charge par le terminal exposerait en clair les organisations auprès desquelles l’utilisateur possède des justificatifs. Réduire la divulgation protège la vie privée mais diminue l’information disponible pour choisir.

Après l’authentification, un channel binding ou une association sécurisée peut confirmer certains paramètres. D’autres peuvent rester sans preuve. Une annonce d’un nom de réseau, d’une méthode forte ou d’un service n’acquiert donc pas d’autorité par ordre d’arrivée.

Le client doit conserver une politique minimale préconfigurée. Une annonce incompatible avec cette politique peut être ignorée. Le RFC 5113 formule ici une règle d’architecture plus générale : l’information découverte aide à décider ; elle ne doit pas pouvoir abaisser seule les conditions de sécurité de la décision.

Prix, service et chemin de données

Le chemin AAA n’est pas nécessairement le chemin des paquets. Une relation d’itinérance peut faire accepter l’identité par une route et transporter les données par un autre tunnel. La disponibilité d’un service ou son prix peuvent dépendre de cette séparation.

Une direction qui mesure uniquement le taux d’authentification encourage une optimisation étroite. Les équipes peuvent améliorer le chiffre en choisissant le premier chemin qui accepte le compte, même si les utilisateurs doivent ensuite changer de réseau, ne trouvent pas le service ou contestent la facture.

Il faut rapprocher trois reçus : l’objectif déclaré au moment du choix, le chemin réellement utilisé et le résultat observable. Sans objectif, on ne sait pas si le système voulait minimiser le prix, respecter une politique de sécurité, préserver la latence ou suivre une préférence commerciale.

Les limites de l’échelle

Un NAS ne devrait pas sonder périodiquement l’infrastructure AAA avec de faux échanges d’identité pour reconstituer une table. Cette charge peut aggraver la panne d’un serveur déjà saturé, déclencher des retransmissions et ne produire qu’une liste partielle.

La diffusion d’une table complète pose aussi un problème commercial et de confidentialité. Sa réplication manuelle crée de l’état périmé. Les itinéraires décorés bâtis sur une vue incomplète peuvent être refusés par un proxy qui n’entretient pas la relation supposée.

La bonne unité de contrôle est donc une reprise bornée : source de l’indice, âge, cause de l’échec initial, identité alternative, résultat et nombre maximal d’essais.

L’échelle des preuves

  • voir un point d’attachement ne prouve pas le service ;
  • recevoir un domaine ne prouve pas sa route actuelle ;
  • choisir un NAI ne prouve pas la relation d’itinérance préférée ;
  • atteindre un proxy ne prouve pas l’authentification ;
  • réussir l’authentification ne prouve ni le chemin des données ni le prix ;
  • confirmer le nom du réseau ne confirme pas chaque capacité annoncée ;
  • établir une session ne prouve pas que le meilleur réseau disponible a été choisi.

Le RFC 5113 demeure utile parce qu’il interdit à une solution partielle de se présenter comme la décision entière.

Sources