Résumé

  • Le groupe LAKE de l’IETF a ouvert le 8 septembre 2026 un dernier appel sur draft-ietf-lake-authz-08; les réponses sont attendues avant le 22 septembre.
  • Dans le parcours normal d’ELA, l’équipement transmet ID_CRED_I dans le message 3 d’EDHOC. L’authentificateur l’envoie au serveur d’enrôlement, puis le voucher revient dans le message 4.
  • Le texte reconnaît que l’équipement révèle ainsi son identité à un authentificateur déjà authentifié avant de savoir si l’autorisation ELA aboutira. Une identité réservée à l’enrôlement est proposée comme précaution possible.
  • Un reçu distinct pour chaque décision permettrait d’expliquer une admission ou un refus sans conserver un identifiant réutilisable. Il s’agit d’une recommandation éditoriale de Daniel Kade, non d’une obligation du projet.

L’annonce du dernier appel demande aux participants de signaler leur soutien ou de motiver leurs objections, avec des pistes de résolution. L’historique Datatracker date du 8 septembre le passage de « WG Document » à « In WG Last Call ». La consultation est donc ouverte; elle ne préjuge pas de son résultat. La fiche actuelle présente toujours la révision 08 comme un Internet-Draft visant le statut de Proposed Standard, et non comme un RFC approuvé.

ELA met en scène trois rôles. U est l’équipement contraint. V est l’authentificateur du domaine qu’il veut rejoindre. W est le serveur d’enrôlement, installé sur la partie moins contrainte du réseau. L’intérêt du montage est de faire avancer l’authentification, l’autorisation et l’enrôlement dans le même échange EDHOC, avec peu de messages sur le lien contraint.

Cette économie de messages repose sur deux relations antérieures. Selon la révision 08, U connaît déjà la clé publique et l’emplacement de W. V et W disposent d’une relation implicite, par exemple via la PKI du Web. U et V, eux, peuvent ne jamais s’être rencontrés. ELA utilise les deux premières relations pour établir la troisième.

Une identité part avant la décision finale

V s’authentifie auprès de U dans le deuxième message EDHOC. U répond par le message 3, qui porte ID_CRED_I, l’identifiant de sa propre référence d’authentification. Les données d’autorisation externes ajoutent l’emplacement de W et du matériel cryptographique frais destiné à protéger le futur voucher.

V forme alors une requête à W. Elle associe ID_CRED_I à la suite cryptographique choisie, à H_12—l’empreinte des deux premiers messages—au matériel éphémère et à une indication demandant éventuellement le justificatif complet de U. W rattache l’empreinte de session à l’identifiant, retrouve la politique applicable et l’exécute. Cette politique peut limiter l’enrôlement à certains équipements, à une période ou à certains authentificateurs; sa définition reste hors du champ du projet.

Le voucher suit le chemin inverse. C’est l’affirmation de W à U que W a autorisé V. Son authentification couvre la session courante, l’identifiant de U et le justificatif de V. Un éventuel périmètre d’autorisation reste lisible par U et W mais opaque pour V. L’authentificateur transporte le résultat dans le message 4. Alors que RFC 9528 rend ce quatrième message facultatif dans EDHOC, le parcours normal d’ELA l’impose: c’est là que l’équipement reçoit ce qu’il attend.

Le texte ne déclare U et V autorisés à interagir qu’après le traitement du message 4. Entre-temps, l’identité de U est déjà connue de V et a été transmise à W. V a prouvé la possession de sa clé, mais l’autorisation de V par W n’est pas encore revenue à U. Ce sont deux états valides, séparés dans le temps.

La protection d’identité ne signifie pas l’absence de destinataire

ELA ne contredit pas la protection d’identité fournie par EDHOC. Les observateurs extérieurs et les interlocuteurs non authentifiés ne reçoivent pas l’identité en clair. Le bénéficiaire de la divulgation est précisément un V authentifié. Le projet note cependant que U ne sait pas encore si l’ensemble du parcours d’autorisation réussira.

La parade offerte par le texte est ciblée: U peut utiliser une identité d’enrôlement, différente de celle employée ensuite pour le trafic opérationnel à l’intérieur du canal sécurisé. Cette possibilité évite de transformer une tentative refusée en indice durable sur l’identité quotidienne du matériel. Elle ne décide pas, à elle seule, de la durée de conservation chez V ou W, du passage entre les deux identités ni de l’accès aux journaux.

Le mot « voucher » a une histoire plus large. RFC 8366 décrit un artefact signé par le fabricant qui assigne un équipement candidat à un propriétaire et épingle un certificat de domaine. ELA reprend une fonction comparable dans une forme plus compacte, sans adopter ce format. RFC 8995 organise le modèle BRSKI entre équipement, registraire et autorité du fabricant, avec des surfaces explicites d’audit et de vie privée. RFC 9031 fournit un autre cadre d’admission pour appareils contraints. Ces références expliquent la famille du problème; seule la séquence ELA détermine l’ordre examiné ici.

Le refus mérite son propre état

Si W reconnaît l’identifiant mais interdit l’enrôlement, il répond par HTTP 403 ou CoAP 4.03. Il peut aussi chiffrer à destination de U une indication exploitable, par exemple la suggestion d’essayer un autre V. L’authentificateur relaie alors une erreur EDHOC « Access denied ».

Ce refus prouve qu’une politique a été appliquée; il ne prouve ni que l’équipement est défectueux ni que le réseau est indisponible. Il intervient après la circulation de l’identifiant. Un tableau de bord qui fusionne refus politique, délai de W, échec de vérification et abandon avant voucher sous une seule étiquette « échec de connexion » supprime donc la donnée la plus utile: où la décision s’est arrêtée.

Le compte rendu LAKE de l’IETF 126 mentionne la conservation de clés éphémères distinctes pour EDHOC et ELA, quelques signes favorables à l’appel et la décision des présidents d’y procéder. Le groupe LAKE doit maintenant apprécier le document. Les responsables de déploiement, eux, doivent préciser la classe d’identité utilisée et la mémoire qu’un refus laissera.

Un reçu qui oublie correctement

Un reçu d’enrôlement utile n’a pas besoin de recopier ID_CRED_I. Il peut employer un identifiant unidirectionnel limité à la tentative, conserver l’empreinte du justificatif de V, la version de l’ancre et du point d’accès W, H_12, la version de politique et un résultat borné: voucher accepté, refus de politique, redirection, échec de justificatif ou expiration.

Le passage d’une identité d’enrôlement à une identité opérationnelle devrait produire la preuve que la transition a eu lieu, sans maintenir une table portable entre les deux. Une échéance de conservation et la confirmation de suppression sont aussi des résultats. Les certificats complets, le contenu du voucher et un identifiant corrélable entre domaines n’ont pas leur place dans ce reçu ordinaire.

Cette architecture de preuve vient de Daniel Kade. La révision 08 ne la prescrit pas et laisse expressément la politique d’autorisation hors de son champ. La norme peut rester légère tout en obligeant chaque exploitation à répondre séparément à trois questions: qui a été authentifié, qui a autorisé quoi, et quelle identité a survécu à la tentative.

Sources