Résumé

  • La RFC 5422 déconseille l’accès à l’issue du mode sans authentification du serveur ; après le mode authentifié, le serveur peut l’accorder selon sa politique.
  • L’accusé du Tunnel PAC rapporte le traitement et le stockage déclarés par le pair ; il ne prouve ni une authentification ultérieure ni l’autorisation d’accès.

L’amorçage ne franchit pas le seuil d’admission

Un équipement peut arriver sans secret prépartagé, racine de confiance du serveur ni Protected Access Credential. RFC 5422 décrit comment lui fournir ces éléments dans EAP-FAST. Le sujet de décision est alors très précis : l’échange a peut-être préparé l’équipement ; a-t-il aussi le droit d’ouvrir une session réseau ? Le document répond en séparant les deux étapes.

EAP-FAST comporte une première phase TLS puis une méthode EAP interne. RFC 5422 distingue le provisionnement avec authentification du serveur et celui sans cette authentification. Dans le premier, le pair valide le serveur durant la négociation TLS. Il lui faut donc déjà les éléments de confiance que l’on souhaite parfois lui donner. Dans le second, le tunnel anonyme Diffie–Hellman permet l’amorçage malgré cette absence. Il ne dit pas au pair à qui appartient le serveur rencontré.

Cette absence d’identité au début ne dispense pas d’authentifier les deux parties. L’échange intérieur doit employer une méthode EAP qui établit leur authentification mutuelle et dérive des clés. Le pair vérifie ensuite le Crypto-Binding TLV pour relier l’échange intérieur à l’intégrité du tunnel TLS et réduire le risque d’intermédiaire actif. La version de 2009 exigeait que les implémentations de ce mode prennent en charge EAP-FAST-MSCHAPv2 comme méthode d’authentification intérieure. Une phase 1 anonyme suivie d’une phase intérieure aboutie n’est pas une simple remise de mot de passe ; l’attachement cryptographique entre les phases compte.

(RFC 5422 §§2, 3.2–3.2.3, 6.1.2 ; RFC 4851)

Après authentification intérieure et validation du Crypto-Binding, le serveur peut remettre un Tunnel PAC — avec PAC-Key et PAC-Opaque — ou des racines de serveur approuvées. Le Tunnel PAC sert à établir un futur tunnel EAP-FAST ; il ne vaut pas à lui seul autorisation d’utiliser les ressources du réseau.

Pour le Tunnel PAC, le pair envoie un PAC-Acknowledgement qui rapporte le résultat du traitement et du stockage. C’est une preuve limitée à la déclaration du pair sur ce credential. Ce message ne montre pas qu’une nouvelle authentification a ensuite réussi, que la politique d’accès a autorisé la session ou qu’un service a effectivement été atteint. RFC 5422 ne fusionne pas ces résultats. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

La règle est explicite : à la fin du mode Server-Unauthenticated, l’accès réseau NE DEVRAIT PAS être accordé, puisque l’échange ne sert qu’au provisionnement. La politique du pair peut couper cette connexion puis lancer un nouvel échange EAP-FAST avec les données reçues. Pour le mode Server-Authenticated, le serveur PEUT accorder l’accès après un provisionnement réussi. Les deux variantes ne constituent donc pas une même décision d’autorisation. (RFC 5422 §3.5)

Le compromis est assumé dans le texte. L’authentification du serveur protège mieux contre l’homme du milieu, mais suppose que l’équipement possède déjà les éléments de validation. Le mode anonyme facilite parfois un déploiement sans intervention ; il expose davantage les échanges de mot de passe à des attaques hors ligne. RFC 5422 recommande de limiter les essais en ligne et encourage les restrictions d’interface ou de contexte. Ce sont les précautions d’un document informatif de 2009, pas une statistique sur les déploiements actuels. (RFC 5422 §§6.1–6.3)

Un journal exploitable sépare donc le mode d’amorçage, l’authentification intérieure et le Crypto-Binding, l’émission du credential, l’accusé du pair, l’authentification ultérieure et la décision d’accès. Quand l’équipe qui distribue les credentials n’est pas celle qui contrôle l’admission, il faut relier ces événements par un identifiant de session et désigner qui traite l’absence du second échange. Le premier succès ne remplit pas cette lacune.

Un succès interne peut encore se terminer par un refus

La section 3.5 laisse la politique du serveur décider de l’accès après le provisionnement. En mode Server-Authenticated, le serveur peut autoriser l’accès après avoir authentifié le pair et fourni un Tunnel PAC. En mode Server-Unauthenticated, il NE DEVRAIT PAS accorder l’accès à la fin de l’échange : celui-ci sert uniquement à provisionner. Les deux parcours peuvent distribuer le même type d’identifiant sans produire le même résultat d’autorisation.

Un Result TLV positif ne tranche pas cette question. Le pair et le serveur peuvent avoir terminé avec succès la méthode intérieure alors que la politique du serveur n’est pas satisfaite ; le serveur peut alors conclure par EAP Failure. Si l’échange ne doit pas ouvrir l’accès, la RFC 5422 interdit au serveur d’accorder cet accès ou de transmettre des clés de session au Network Access Server. Un tableau de bord qui ne compte que le succès de la méthode intérieure peut donc afficher un état vert alors que le réseau a correctement refusé l’admission.

Il faut suivre le résultat EAP final et la remise des clés, pas seulement le premier indicateur positif. (RFC 5422 §3.5 ; RFC 4851 §4.2.2)

L’accusé ne couvre qu’un moment de la vie du credential

Un Tunnel PAC réunit plusieurs éléments. Le PAC-Key est un secret de 32 octets qui sert à établir le tunnel de phase 1. Le PAC-Opaque, propre au serveur émetteur, lui est présenté lors de l’échange ultérieur. Le PAC-Info peut identifier l’autorité et contenir une durée de vie. La RFC 4851 exige de protéger le PAC-Key ; la RFC 5422 rappelle que le pair et le serveur doivent sécuriser leur stockage. La remise crée donc des obligations de garde, d’expiration et de renouvellement qui ne disparaissent pas avec le succès de l’amorçage.

Le PAC-Acknowledgement a une portée précise : le pair le renvoie pour un nouveau Tunnel PAC afin d’indiquer le résultat du traitement et du stockage. Il indique succès ou échec. Le succès rapporte ce que le pair a déclaré à cet instant ; il ne prouve ni qu’un tunnel pourra être établi plus tard, ni que le secret restera protégé, ni que l’accès réseau sera autorisé. Seul l’échange EAP-FAST suivant éprouve le credential dans son nouveau contexte d’authentification. Même ce résultat ne démontre pas à lui seul qu’une application est joignable. (RFC 5422 §§4.2.2–4.2.5, 6.8 ; RFC 4851 §3.2.2)

Le refus peut aussi interrompre le service

La séparation a un coût de disponibilité. La RFC 5422 signale qu’un EAP Failure après un refus peut provoquer une désassociation Wi-Fi complète. Le pair ou le serveur peut tenter une renégociation TLS afin d’utiliser les nouveaux identifiants dans une authentification ultérieure sans repartir entièrement de zéro ; l’un ou l’autre peut toutefois refuser cette demande. La politique normale d’accès ne s’applique qu’après le succès de cette authentification suivante. Un déploiement doit donc mesurer le retour des pairs, les refus et la reprise par redémarrage ou renégociation.

Sinon, un refus légitime peut ressembler à un incident d’amorçage, tandis qu’un comptage de provisionnements réussis masque les appareils jamais admis. (RFC 5422 §3.5)

Sources