Résumé

  • Avec RFC 9813, l’identité PSK remplace l’adresse IP comme clé de recherche du client RADIUS sur TLS, mais elle voyage en clair et arrive avant l’authentification : elle désigne une relation candidate, elle ne la prouve pas.
  • Une exploitation solide conserve des reçus distincts pour l’admission par plage réseau, la validation de l’identité, la version de la table client, la preuve du PSK, l’intégrité RADIUS, la politique locale, la reprise TLS et le service finalement rendu.

Le modèle RADIUS historique faisait de l’adresse source une clé commode. Le serveur trouvait une ligne de configuration, récupérait un secret partagé et vérifiait le message. Cette ligne ne décrivait pas seulement un mot de passe : elle liait un pair, une localisation autorisée et une politique applicative.

Le NAT brise cette commodité. Plusieurs équipements se présentent sous une seule adresse, tandis qu’un équipement mobile ou renuméroté peut en utiliser plusieurs. Élargir les préfixes restaure la connectivité, mais réduit la précision. Dupliquer la configuration pour chaque adresse probable crée une dette qui finit par masquer les relations réelles.

Publié en juillet 2025 comme BCP 243, RFC 9813 précise l’usage des PSK avec RADIUS sur TLS ou DTLS. Son changement essentiel consiste à rechercher le client par son identité PSK plutôt que par son adresse source. Cette phrase ne supprime toutefois aucun des autres contrôles. L’adresse garde un rôle de filtre, l’identité reste hostile avant la preuve du secret, et la réussite de TLS ne vaut ni autorisation RADIUS ni exécution par le serveur d’accès.

Un sélecteur visible n’est pas une identité prouvée

Le client transmet d’abord un identifiant afin que le serveur sache quel PSK essayer. Cet ordre est nécessaire, mais il crée une frontière de sécurité. La chaîne est visible en clair et peut être fabriquée par tout pair capable d’atteindre le service. Un nom parlant peut en outre révéler une organisation, un site ou une fonction. Un identifiant opaque, éventuellement structuré comme un Network Access Identifier, limite cette fuite sans transformer le sélecteur en secret.

Trouver une ligne dans la table signifie seulement que le texte reçu correspond à un état administratif. La possession du PSK apporte une preuve différente. La plage source autorisée en apporte une autre. Les tableaux de bord doivent donc éviter l’étiquette « client authentifié » au moment de la seule correspondance. Sinon, l’ancienne confiance excessive dans l’adresse IP réapparaît sous un nouveau nom.

La chaîne brute doit s’arrêter à la frontière

RFC 9813 demande de traiter l’identité comme une entrée hostile. Elle peut contenir un UTF-8 invalide, un octet NUL, des métacaractères significatifs pour SQL, LDAP, REST ou un outil shell, et atteindre la limite TLS de 65 535 octets. L’envoyer directement dans un système de recherche transforme une fonctionnalité de protocole en canal d’injection.

Le traitement défendable borne d’abord la longueur, classe l’espace de noms, valide l’encodage prévu, applique une règle de comparaison versionnée, puis échappe la valeur pour l’interface réellement utilisée. Un échec ferme la connexion. La normalisation ne doit jamais fusionner silencieusement deux identités administratives après une mise à niveau logicielle.

Le reçu conserve le condensat de l’entrée brute, le résultat de validation, la valeur canonique de recherche, la version des règles et l’identifiant de la ligne choisie. Les journaux n’ont pas besoin de recopier une chaîne malveillante ou révélatrice. Un motif de rejet, un condensat borné, la plage observée et la génération du parseur suffisent à l’enquête.

La table décrit une relation, pas un appareil universel

La table logique TLS-PSK peut relier des plages autorisées, une identité, un PSK, d’autres justificatifs TLS et l’obligation éventuelle d’un certificat client. Après le canal TLS, la configuration RADIUS continue de déterminer les types de requêtes et les droits du pair. La bonne unité d’inventaire est donc la relation client-serveur.

Un même boîtier peut entretenir deux relations distinctes avec deux serveurs. Une paire de secours peut partager une politique mais garder des secrets séparés. RFC 9813 exige que les implémentations sachent attribuer un PSK et une identité uniques à chaque relation possible, même si un opérateur choisit parfois de les réutiliser. Cette capacité réduit le rayon d’explosion : une compromission peut être révoquée sans reconfigurer tout le parc.

Le standard fixe une mécanique commune stricte et laisse à l’exploitation le coût de rotation, les fenêtres de maintenance et la topologie. C’est exactement la séparation défendue par Minimum Initial Specification : le socle partagé ne doit pas prétendre décider de toutes les circonstances locales.

Deux contrôles réseau, deux questions

Avant même d’examiner l’identité, le serveur vérifie que la connexion provient d’une plage globalement admise. Après la sélection de la relation, il peut appliquer une seconde règle de provenance propre à ce client. Le premier contrôle protège l’exposition du service ; le second demande si cette relation authentifiée est autorisée depuis l’endroit observé.

Dans ce cadre, plusieurs identités doivent pouvoir apparaître sous une adresse NAT et une identité depuis plusieurs adresses. L’adresse n’a pas disparu : elle est devenue une coordonnée indépendante. En enquête, la plage réussie prouve seulement une origine réseau observée. La preuve PSK établit la possession d’un secret symétrique. Leur combinaison resserre l’affirmation sans prétendre identifier une personne ou un matériel physique.

Ne jamais confondre les deux secrets

Le PSK TLS protège et authentifie la relation TLS. Le secret partagé RADIUS sert aux contrôles du protocole encapsulé. RFC 9813 interdit de réutiliser la même valeur et demande aux implémentations de rejeter une configuration identique dans les deux champs. Le même PSK ne doit pas non plus franchir la frontière entre TLS 1.3 et les versions antérieures ; RFC 9258 fournit un mécanisme d’import qui lie les clés à la version, au KDF et au contexte.

Une interface qui affiche un seul champ « secret du site » invite précisément à effacer ces limites. Elle devrait nommer les rôles séparément, exposer leurs générations non secrètes et empêcher l’égalité sans journaliser la matière cryptographique. Un handshake vert prouve le canal ; il ne remplace ni les vérifications du paquet RADIUS ni la décision d’autorisation.

La rotation crée une nouvelle génération de relation

Puisque l’identité sert à trouver le PSK, elle doit changer en même temps que lui. Modifier la clé sous un nom inchangé rend les échecs ambigus : client en retard, erreur de distribution et tentative hostile deviennent indiscernables. Une rotation contrôlée crée une nouvelle identité, observe sa première utilisation, encadre le chevauchement, enregistre la dernière réussite de l’ancienne et traite les tentatives tardives après retrait.

Le suivi « dernière vue » aide à invalider les clients dormants, mais le silence n’explique pas sa cause. Il peut signaler un retrait, une panne, un équipement saisonnier ou un vol. Le seuil, le propriétaire, les exceptions et la reprise doivent être connus avant toute invalidation automatique.

La reprise ouvre un deuxième espace de noms

TLS 1.3 emploie aussi des PSK et des identités de reprise créés par la pile TLS. Ils ne sont pas les noms statiques de l’administrateur. RFC 9813 déconseille la reprise dans ce contexte. Lorsqu’elle reste nécessaire, le serveur sépare clairement les tickets opaques des identités statiques, rejette les valeurs inconnues et interdit toute collision entre les deux tables.

Une reprise réussie ne rend pas la politique éternelle. Le serveur doit récupérer l’identité et le contexte de la poignée de main initiale, réévaluer les règles affectées par une nouvelle adresse et revenir à une négociation complète si le cache n’est pas fiable. Le ticket et son cache ne doivent pas vivre au-delà de sept jours. Le reçu associe la génération d’authentification initiale, l’espace de noms, l’âge du cache, la source actuelle et la décision réévaluée.

Reconstituer la chaîne complète

Pour chaque connexion acceptée, l’opérateur devrait pouvoir retrouver : l’admission réseau générale ; la validation et la normalisation de l’identité ; la génération exacte de la table client ; la plage propre à la relation ; la version TLS et le KDF ; la preuve du PSK ; le contexte de reprise ; les contrôles RADIUS ; la décision locale ; l’action du NAS ; et le service observé. Chaque étape peut réussir alors que la suivante échoue.

Running-Code Primacy rappelle qu’un champ conforme et une table configurée ne prouvent pas quelle génération a réellement servi. Seuls le parseur, la recherche, le handshake et le moteur de politique en production fournissent ce reçu. On Reality Layers explique pourquoi le symbole « identité connue » ne doit jamais parler à la place de toutes ces réalités.

RFC 9813 ne remplace donc pas l’adresse par un nouveau monarque. Il sépare enfin le sélecteur, la provenance, la preuve et l’effet. Sa valeur opérationnelle apparaît lorsque cette séparation reste visible dans l’inventaire, les journaux et les décisions.

Sources