Résumé

  • Dans RFC 5193, un canal déjà sûr avant PANA doit protéger contre l’usurpation et l’écoute. Ce fait peut supprimer le besoin d’exécuter ensuite un protocole d’association sécurisée et influe sur le choix de la méthode EAP.
  • Un état « chiffrement actif » sans pair, interface, EP, portée et fraîcheur ne prouve pas ce fait. La capacité, la configuration, la négociation et la protection effectivement liée au chemin sont quatre reçus différents.

Le mot « chiffré » paraît précis. Il ne l’est que lorsqu’il répond à des questions simples : quel lien, entre quels pairs, pour quel trafic, depuis quand et jusqu’où ? Sans ces réponses, il décrit au mieux une fonction disponible, pas la propriété dont dépend l’architecture PANA.

RFC 5193 ne présente pas un déploiement unique. Il distingue les réseaux où un canal sûr relie déjà le client au point d’application avant l’échange PANA et ceux où ce canal doit être créé après une authentification réussie. Dans le premier cas, le protocole d’association sécurisée ultérieur peut être inutile. Dans le second, la méthode EAP doit résister à un environnement exposé à l’écoute et à l’usurpation, puis produire les clés nécessaires à l’association.

La preuve du canal décide donc non seulement ce que le tableau de bord affiche, mais aussi ce que le système choisit de ne pas exécuter.

Une propriété relationnelle, pas un badge d’équipement

Le chiffrement n’existe pas « sur » un produit de manière absolue. Il protège une relation donnée. Un contrôleur peut gérer plusieurs radios, plusieurs interfaces virtuelles, plusieurs associations et plusieurs états de clé au même instant. Un client peut voir un SSID attendu tout en étant attaché à un pair différent de celui que l’inventaire associe à l’EP.

Le reçu minimal doit relier l’identité du PaC, l’interface, le pair de couche inférieure, le mécanisme, le résultat d’authentification du pair, l’état d’intégrité ou de confidentialité, l’EP visé, la portée et l’horodatage. Une chaîne de caractères encrypted ne peut pas remplacer cette relation.

Cette exigence n’est pas un schéma imposé par RFC 5193. C’est l’inférence opérationnelle nécessaire pour ne pas étendre le sens de la norme. Le RFC définit la dépendance : la présence d'un canal sûr change le choix EAP et l’association sécurisée. L’exploitant doit pouvoir prouver l’entrée de cette dépendance.

Le pair manquant crée une fausse continuité

Une interface peut rester active pendant que son pair change. Une nouvelle association radio peut reprendre le même nom logique. Un tunnel peut être recréé vers un autre terminal. Un chemin de secours peut aboutir sur un autre EP. Si le reçu ne porte que sur l’interface, le système hérite une protection dont le sujet a disparu.

Il faut donc distinguer la continuité administrative de la continuité cryptographique. Le fait que wlan0 existe encore ne prouve pas que la même association la protège. Le fait qu’une clé soit présente dans un magasin ne prouve pas qu’elle a été négociée avec le pair qui reçoit les paquets. Le fait qu’un EP figure dans une politique ne prouve pas que le chemin courant passe par lui.

À chaque changement de pair, d’attachement ou d’EP, l’ancienne preuve devient historique. Elle peut expliquer une décision passée ; elle ne doit pas autoriser la suivante.

Les quatre niveaux qu’un seul voyant efface

La capacité répond : le produit sait-il mettre en œuvre ce mécanisme ? La configuration répond : l’opérateur l’a-t-il demandé ? La négociation répond : les deux extrémités ont-elles établi les paramètres ? L’observation répond : l’attachement actuel possède-t-il la propriété attendue ?

Ces niveaux échouent indépendamment. Un logiciel peut supporter IPsec sans aucune SA active. Une politique peut exiger le chiffrement tandis que la négociation échoue. Une négociation peut réussir pour un pair qui n’est plus sur le chemin. Une télémétrie peut observer une association sans connaître l’EP auquel l’architecture l’associe.

Le voyant unique récompense la déclaration la plus facile à produire. C’est ainsi qu’une fiche technique finit par gouverner le choix d’une méthode EAP et par supprimer une association ultérieure. Dans la discipline de Lu Heng, le symbole a pris le pouvoir sur la réalité qu’il devait seulement décrire.

RFC 5193 admet aussi la protection physique

Le cadre cite un réseau DSL où le câblage protège pratiquement le lien en ne laissant qu’un client envoyer et recevoir des paquets. Il cite aussi un environnement radio déjà authentifié, autorisé et chiffré. Ces exemples empêchent une simplification courante : exiger un identifiant cryptographique pour toute preuve de canal sûr.

Une preuve physique peut être légitime, mais elle a sa propre portée. Elle doit identifier le segment isolé, le dispositif d’accès et les changements qui pourraient le rendre partagé. Une documentation ancienne du câblage n’est pas une observation permanente. Si un équipement intermédiaire ou une dérivation modifie la topologie, la justification doit être réévaluée.

La bonne normalisation ne transforme donc pas tous les mécanismes en « chiffrement ». Elle conserve leur nature tout en vérifiant qu’ils satisfont les propriétés nécessaires contre l’usurpation et l’écoute dans leur domaine annoncé.

La méthode EAP révèle le coût de l’erreur

Dans un canal non protégé avant PANA, RFC 5193 demande une méthode EAP résistante aux attaques possibles et capable de créer des clés pour l’association sécurisée ultérieure. Une classification erronée peut faire choisir une méthode sur des hypothèses qui ne sont plus vraies.

Le journal de décision doit garder la méthode choisie, son profil, les propriétés de l’environnement invoquées et l’attente de génération de clé. S’il n’existe aucune preuve liée au pair, l’outil ne doit pas écrire rétrospectivement que la méthode était sûre parce que l’échange PANA a abouti. Le succès du protocole ne remonte pas le temps pour authentifier le canal initial.

De même, la production de clés n’est pas l’association elle-même. Elle rend l’étape suivante possible. Le protocole choisi, les pairs et les SA produites ont leurs propres reçus. La frontière avec l’Article RFC 5191 est claire : ici, nous auditons pourquoi l’architecture a exigé ou omis cette étape ; là-bas, l’enjeu est ce que l’authentification et l’exécution ultérieure prouvent réellement.

Un reçu qui résiste à l’audit

Pour chaque décision secure-before, conserver : l’attachement, l’interface, le pair ou segment, l’EP, le mécanisme, la portée anti-usurpation et anti-écoute, le résultat d’authentification inférieur s’il existe, l’état de protection, le temps d’observation, la source et la version de politique.

Conserver séparément le choix EAP, l’exigence de clé, la nécessité d’une association post-PANA et l’identifiant de la tâche correspondante. Un changement de chemin invalide les liens, il ne les met pas simplement à jour en place.

Le résultat peut être « non prouvé ». RFC 5193 ne dicte pas si l’exploitant doit alors fermer le lien, forcer le profil secure-after ou demander une intervention. Il impose en revanche de ne pas confondre les deux environnements. Une politique locale honnête commence par préserver ce doute au lieu de le convertir en vert.

Sources

  1. RFC 5193 HTML
  2. RFC 5193 texte
  3. Fiche RFC 5193
  4. Datatracker RFC 5193
  5. Historique RFC 5193
  6. Références RFC 5193
  7. Errata RFC 5193
  8. RFC 5191
  9. Fiche RFC 5191
  10. RFC 4058
  11. Fiche RFC 4058
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code exécuté