Résumé

  • TLS-POK, défini par RFC 9966, fait prouver au serveur qu’il connaît la clé publique BSK d’un appareil et à l’appareil qu’il possède la clé privée correspondante.
  • La norme laisse hors champ l’acquisition de cette clé publique : le résultat ne prouve donc ni propriété légitime, ni garde, ni autorisation de réseau, ni admission effective.

L’amorçage d’un appareil sans interface place souvent l’exploitant dans un cercle : l’accès EAP exige une identité, mais l’appareil a besoin d’accès pour recevoir son identité durable. Dan Harkins et Owen Friel décrivent, dans RFC 9966, une sortie technique de ce cercle pour un réseau filaire. TLS-POK s’appuie sur une Bootstrap Key elliptique, la BSK, puis sur TLS 1.3 pour créer une preuve réciproque avant la délivrance éventuelle d’un identifiant ultérieur.

La répartition est précise. La clé privée reste connue de l’appareil. La clé publique est connue de l’appareil, de son détenteur ou propriétaire, puis provisionnée par l’opérateur du serveur TLS. Le serveur démontre qu’il connaît cette partie publique ; le client démontre qu’il détient le secret correspondant. L’EPSK est dérivée de la clé publique, et le client s’authentifie ensuite par clé publique brute. Ce sont des faits observables dans le protocole, pas un registre de propriété.

RFC 9966 refuse justement de raconter l’étape précédente. Le moyen par lequel le serveur a obtenu la clé publique BSK est déclaré hors périmètre. Une étiquette QR ou un chargement de nomenclature peuvent être utilisés, explique le texte. Si une étiquette est physiquement attachée à l’appareil, le modèle suppose que possession physique et propriété légitime coïncident. Cette supposition peut être nécessaire à l’amorçage ; elle n’est pas vérifiée par la poignée de main.

La section de sécurité montre ce que coûte cette séparation. Le client présume que sa clé publique BSK n’est pas largement diffusée. Si un adversaire obtient cette donnée, attire l’appareil vers son serveur et possède les autres conditions, il peut compléter l’échange TLS-POK et devenir le réseau auprès duquel l’appareil s’amorce. Si, plus tôt encore, une méthode d’amorçage remplace la clé d’un appareil honnête par celle d’un appareil pirate, le serveur peut intégrer ce dernier. Dans les deux scénarios, la cryptographie peut fonctionner exactement comme prévu tout en travaillant sur une association compromise.

Le texte ne masque pas cette dépendance sous une automatisation opaque. Le client ne doit pas livrer sa clé publique BSK avant d’avoir traité ServerHello et vérifié le calendrier de clés TLS ; si cette vérification échoue, il doit arrêter sans divulguer la clé. Les fabricants devraient attribuer une BSK différente à chaque appareil. Une BSK partagée empêche l’opérateur de les distinguer et de s’assurer que seuls certains appareils autorisés se connectent. Ces exigences circonscrivent le problème ; elles n’ajoutent pas un audit de garde.

Après la poignée de main, le serveur peut provisionner une identité destinée aux authentifications EAP suivantes. La BSK n’est employée que pour l’amorçage. Ainsi, réussite de TLS-POK, délivrance d’un identifiant, décision EAP et effet au point d’accès demeurent quatre faits distincts. Les confondre rendrait les refus impossibles à expliquer et les incidents impossibles à attribuer.

Le profil IETF de Harkins atteste son lien public avec RFC 9966, tandis qu’une photographie de reconnaissance IEEE 802.11 sert seulement de référence d’identité au portrait éditorial. Le rôle de la personne n’est pas d’absorber la responsabilité de tous les déploiements. Sa contribution, avec Friel, est de donner à une preuve initiale un format limité sans lui prêter une autorité qu’elle n’a pas.

Sources