Résumé

  • Dans RFC 9820, la réussite de la méthode EAP produit un MSK et un message de succès, mais la preuve bilatérale exige encore un POST protégé à l’étape 7 puis une réponse 2.04 Changed protégée à l’étape 8.
  • La confirmation d’un secret dérivé commun n’autorise pas toutes les ressources. La politique d’amorçage, la décision applicative, la durée de session, le remplacement d’état et l’éviction conservent leurs propres responsables.
  • L’audit doit relier les générations de ressources CoAP, le résultat EAP, la lignée non secrète du contexte, les deux vérifications protégées, la politique effective et le comportement observé, sans jamais journaliser le MSK.

Une suppression locale n’est pas une expulsion constatée

RFC 9820 prévoit qu’un authentificateur puisse retirer un état CoAP-EAP avant son expiration. Il adresse alors une requête DELETE protégée par OSCORE à la dernière ressource d’état connue. Le pair répond par un 2.02 Deleted, lui aussi protégé. Si cette réponse n’arrive pas avant EXCHANGE_LIFETIME, l’authentificateur efface son état local.

La règle est saine pour nettoyer une machine qui ne peut attendre éternellement. Elle ne transforme pas le délai en accusé de réception. Après l’expiration, l’authentificateur sait ce qu’il a supprimé chez lui. Il ne sait pas automatiquement ce que le pair a reçu, ce qu’un intermédiaire a livré, ce qu’un serveur d’application a invalidé ni quels paquets circulent encore.

Un journal sérieux attribue donc chaque verbe : décision de retirer, DELETE émis, DELETE reçu, état effacé par le pair, accusé protégé vérifié, état effacé par l’authentificateur, politique applicative invalidée, trafic ultérieur refusé. Écrire seulement « équipement expulsé » invente une vue globale à partir d’un événement local.

Cette discipline correspond aux couches de réalité de Heng Lu. Un enregistrement administratif, une transition exécutée et un effet réseau peuvent se référer au même identifiant sans devenir le même fait.

Le protocole distribue les rôles avant de distribuer la confiance

Dans CoAP-EAP, l’objet contraint est le pair EAP, mais il héberge le service comme serveur CoAP. Le contrôleur est l’authentificateur EAP, tout en agissant normalement comme client CoAP. En mode pass-through, un serveur AAA placé ailleurs peut encore prendre en charge la méthode EAP et fournir des attributs d’autorisation.

Ces rôles ne sont pas de simples noms. Un message « le client a réussi » ne dit pas si le mot client désigne le rôle CoAP, le rôle EAP, l’équipement commercial ou le mandant juridique. La trace doit conserver le rôle protocolaire, l’instance, l’organisation qui apporte la politique et l’application qui décide l’acte final.

La fiche RFC Editor et la fiche Datatracker classent RFC 9820 sur la voie normative de l’IETF, après les travaux du groupe ACE. Cette autorité porte sur la spécification. Elle ne certifie aucun produit, aucun déploiement et aucune admission réelle.

La découverte de l’authentificateur ou d’un intermédiaire reste hors champ. Un pair peut trouver une adresse offrant le service sans avoir encore prouvé qu’elle correspond à l’autorité attendue. RFC 6677 apporte des mécanismes de liaison de canal EAP ; leur présence dans une norme ne prouve pas leur résultat pour une session donnée.

Les ressources éphémères portent l’ordre

L’échange ne progresse pas derrière une URL permanente. À chaque étape, le pair crée une nouvelle ressource CoAP pour le prochain message et supprime l’ancienne. La réponse indique la nouvelle cible par Location-Path ou Location-Query.

L’ordre devient ainsi visible dans l’espace des ressources. Un ancien POST ne doit pas acquérir l’actualité par simple retransmission. Un déclencheur dupliqué pendant une authentification en cours est écarté. Un vieux déclencheur arrivé après la fin peut faire croire à l’authentificateur qu’une nouvelle procédure commence, alors que le pair ne reconnaît pas la ressource attendue.

RFC 7252 fournit les propriétés de transport de CoAP. RFC 4137 formalise les machines d’état EAP. CoAP-EAP les compose : il ne donne à aucune des deux le droit d’effacer l’autre de l’audit.

Il faut conserver la génération courante, celle qui vient d’être détruite, les identifiants de requête et de réponse, la transition EAP, le résultat CoAP et l’horloge. Une session logique sans génération ne permet pas de distinguer retard, duplication, redémarrage et nouvelle authentification.

Le premier succès reste un résultat local

À l’étape 7, une méthode EAP réussie fournit à l’authentificateur un MSK, un message EAP Success et des informations d’autorisation telles que Session-Lifetime. RFC 5247 définit le cadre de gestion des clés EAP. RFC 9820 exige une méthode capable d’exporter un MSK et un EMSK d’au moins 64 octets.

Le MSK disponible chez l’authentificateur ne prouve pas encore que les deux extrémités ont installé un contexte compatible. RFC 9820 dérive le Master Secret et le Master Salt OSCORE à partir du MSK, de la transcription de négociation cryptographique et de chaînes de contexte définies. Les identifiants de destinataire échangés fixent les contextes d’émission et de réception. RFC 5869 définit HKDF ; RFC 8613 définit OSCORE.

L’authentificateur place ensuite EAP Success dans un POST protégé. Le pair considère sa réception vérifiée comme une indication alternative de réussite, obtient son propre MSK auprès de sa machine EAP et dérive le contexte nécessaire. Cette requête protégée n’est donc pas un emballage ajouté après le verdict. Elle teste si le verdict peut devenir un état partagé.

Le retour protégé ferme une autre frontière

Le pair ne renvoie 2.04 Changed sous OSCORE qu’après réussite EAP et vérification du POST de l’étape 7. L’authentificateur qui vérifie cette réponse reçoit le second témoin : les deux côtés ont pu employer le même secret dérivé.

Il reste utile de distinguer cinq événements : verdict de la méthode, export du MSK, dérivation locale, vérification par le pair, vérification du retour par l’authentificateur. Un panneau vert peut résumer leur ensemble pour un opérateur pressé ; la preuve sous-jacente ne doit jamais les fusionner.

La transcription des algorithmes négociés entre dans la dérivation. Une modification produit des contextes incompatibles, qui échouent lors des messages protégés. Les registres CoRE de l’IANA et EAP de l’IANA attribuent les codes ; ils ne témoignent pas du choix exécuté sur une machine.

Le reçu peut garder l’empreinte de la transcription, les identifiants de destinataire, la méthode, les versions exécutées, la génération de dérivation et les résultats des deux vérifications. Il ne doit pas garder le MSK. Une exigence d’audit qui transforme un secret de session en donnée de journalisation détruit sa propre finalité.

Une clé commune n’est pas un passe-partout

Après l’étape 8, la dernière ressource CoAP-EAP doit être protégée par OSCORE. Le même contexte peut servir pour d’autres ressources seulement si la politique applicative l’autorise.

Cette condition est la frontière de mandat. L’authentification conclut sur le pair selon une méthode. La confirmation conclut que deux extrémités partagent une protection dérivée. L’autorisation décide si ce pair peut lire, modifier ou invoquer une ressource maintenant.

En présence d’une infrastructure AAA, l’organisation responsable du pair fournit des données d’autorisation. En mode autonome, elles résident chez l’authentificateur. Après l’amorçage, une autorisation plus fine peut rester nécessaire ; RFC 9200 décrit l’usage d’OAuth dans ACE.

Un contrôleur possédant le MSK ne devient pas propriétaire de la politique de l’organisation. Un serveur AAA qui émet un attribut ne prouve pas son application. Un message OSCORE valide n’établit pas que la ressource demandée se trouvait dans le périmètre permis.

Pendant l’authentification, le trafic IP non protégé doit rester limité au service CoAP-EAP entre le pair et l’authentificateur ou l’intermédiaire. Ouvrir tout un segment dès le premier succès EAP reviendrait à supprimer la séparation que le protocole vient de construire.

Le renouvellement fait coexister deux états

Si aucune durée n’est fournie, le pair adopte par défaut huit heures, selon la recommandation de RFC 5247. Ce nombre n’est ni une mesure de sécurité universelle ni la preuve d’un réglage réel.

Lors d’une réauthentification, l’état courant continue d’exister tandis qu’un nouvel état se construit. L’ancien n’est remplacé qu’après la réussite complète du nouveau. Si la tentative échoue, il peut rester utilisable jusqu’à son expiration ou une tentative ultérieure.

La continuité crée donc deux présents légitimes mais différents : un contexte actif et un candidat. L’outil de contrôle ne doit pas annoncer la nouvelle génération au démarrage du renouvellement. Il doit enregistrer début, verdict EAP, confirmations protégées, activation, dernière utilisation de l’ancien contexte et retrait.

Une ressource mise en cache peut encore accepter l’ancienne génération après que le contrôleur croit la transition terminée. Le suivi doit rapprocher la politique effective du message observé, pas seulement comparer deux lignes de configuration.

Un essai utile fabrique des désaccords

Le test minimal emploie un pair, un authentificateur, un serveur AAA, deux ressources aux politiques différentes et un observateur réseau indépendant. Il couvre le chemin heureux, puis modifie la transcription cryptographique, perd l’étape 7, perd l’étape 8, rejoue une ancienne génération, lance une réauthentification qui échoue et supprime une session pendant une partition.

Il faut aussi vérifier qu’une ressource autorisée répond tandis qu’une autre reste interdite avec le même contexte, qu’un ancien contexte cesse réellement d’être accepté après remplacement et qu’un DELETE sans accusé n’est rapporté que comme nettoyage local.

Chaque cas compare quatre surfaces : état EAP, génération CoAP, vérification OSCORE et décision/effet applicatif. Le test échoue s’il ne produit qu’un booléen final.

Ce que les sources ne disent pas

La norme ne nomme aucun parc d’objets déployé. Elle ne mesure ni autonomie énergétique, ni latence, ni taux de perte, ni adoption. Ses scénarios illustrent le protocole ; ils ne constituent pas des observations commerciales.

L’historique Datatracker, les références et les documents qui citent RFC 9820 établissent une lignée documentaire. La recherche d’errata renseigne l’état éditorial. Aucune de ces pages ne prouve une session réelle.

RFC 3748 définit EAP dans un cadre plus large. L’existence de ce cadre et de RFC 9820 ne permet pas d’inférer l’identité, le mandat ou l’état d’un équipement particulier.

Sources

  1. Datatracker : RFC 9820
  2. Historique RFC 9820
  3. Documents citant RFC 9820
  4. Références de RFC 9820
  5. IANA CoRE Parameters
  6. IANA EAP Parameters
  7. Errata RFC 9820
  8. Fiche RFC Editor
  9. RFC 3748
  10. RFC 4137
  11. RFC 5247
  12. RFC 5869
  13. RFC 6677
  14. RFC 7252
  15. RFC 8613
  16. RFC 9200
  17. RFC 9820
  18. Heng Lu : spécification initiale minimale
  19. Heng Lu : couches de réalité
  20. Heng Lu : primauté du code exécuté