Résumé

  • La liste TRL de RFC 9770 indique qu’un serveur d’autorisation a marqué des jetons non expirés comme révoqués; elle ne rend pas instantanément tous les serveurs de ressources conscients de cette décision.
  • Il faut distinguer la décision, la mise à jour de la liste, la notification ou l’interrogation, la réception, l’effacement local et le résultat d’une requête protégée.

Le mot « révoqué » donne facilement l’illusion d’un état unique. Dans une installation ACE, c’est au moins une chaîne d’états. Le serveur d’autorisation peut avoir changé son enregistrement tandis qu’un serveur de ressources, parfois intermittent et contraint, conserve encore le jeton qui lui avait été présenté. Cette différence n’est pas un détail administratif : elle détermine si une ressource peut encore être servie.

RFC 9770, publiée en 2025 sur le Standards Track par Marco Tiloca, Francesca Palombini, Samuel Echeverria et Grace Lewis, rend la chaîne observable sans prétendre l’abolir. Les clients et serveurs de ressources enregistrés peuvent lire une Token Revocation List auprès du serveur d’autorisation via CoAP. Ils peuvent demander une vue complète, demander des différences ou observer la ressource. La TRL est une collection de hachages de jetons révoqués mais pas encore expirés; elle n’est ni le jeton, ni une identité, ni le compte rendu d’une décision d’accès ultérieure.

La RFC limite d’abord l’autorité de cette liste. La manière dont un jeton est déclaré révoqué, et celle dont le serveur d’autorisation découvre cette nécessité, restent hors de son champ. Une entrée dans la TRL ne permet donc pas de conclure seule à une fraude, à une compromission, à l’exactitude d’une politique ou à la faute d’un utilisateur. Elle prouve un changement dans la représentation du serveur qui gère la liste.

Vient ensuite la frontière de livraison. Quand la TRL est modifiée, le serveur envoie des notifications Observe aux abonnés concernés. Mais un envoi ne vaut pas réception. RFC 9770 explique qu’un attaquant capable de supprimer ces notifications peut empêcher durablement un demandeur de savoir qu’un de ses jetons est révoqué. Le texte recommande donc de ne pas dépendre des seules notifications et d’interroger régulièrement la liste selon une politique applicative, les contraintes d’énergie et la disponibilité réelle.

Le silence n’a pas non plus le droit de devenir un verdict. Sans réponse ou face à une erreur du point d’accès TRL, le demandeur ne doit tirer aucune conclusion sur la révocation ou l’expiration. Les listes de différences sont bornées : une ancienne mise à jour peut ne plus être récupérable. Une interrogation complète peut, elle, dépasser la capacité qu’un équipement avait prévue. Une supervision sérieuse montre ces limites au lieu de les recouvrir d’un simple état « synchro ».

Il existe néanmoins un acte local net. Quand un équipement enregistré reçoit une réponse TRL qui contient le hachage pertinent, il doit expurger le jeton stocké correspondant. Un serveur de ressources doit conserver le hachage après l’expurgation. C’est la preuve d’un changement local exigé par le protocole. Ce n’est pas la preuve rétroactive que tous les avis précédents ont été reçus, ni la preuve prospective que tout client sera rejeté par toute ressource.

La RFC décrit explicitement l’intervalle dangereux : un client peut tenter l’accès après la révocation mais avant que le serveur de ressources en ait connaissance. Si celui-ci conserve encore le jeton, l’accès peut réussir alors qu’il ne devrait pas; le document qualifie cela de violation de sécurité. La qualité d’une enquête dépend donc de reçus distribués, pas d’un statut au centre.

La lecture de Heng Lu aide à conserver une règle mince à sa place. La TRL rend une information partageable entre participants indépendants. L’heure de réveil de l’appareil, le chemin de notification, la relève par sondage, la mutation du stockage et la décision finale restent des faits du code en fonctionnement. C’est là que l’on doit chercher la preuve de retrait.

Sources