Résumé

  • Le projet ACE révisé le 2 novembre propose une chaîne de distribution courte : le serveur d'autorisation peut déposer le jeton auprès du serveur de ressources pour le client et lui annoncer le résultat. C'est encore un Internet-Draft.
  • Une nouvelle section décrit les journaux horodatés des demandes, des dépôts et de la vie des jetons. Les journaux du serveur de ressources dépendent de ses ressources limitées.
  • Les secrets opérationnels ne doivent jamais y figurer. Lors du partage externe, le point de stockage désigné devrait masquer les adresses et identifiants permettant de suivre les appareils, sauf autorisation spécifique.

Le livreur devient témoin

Dans le fonctionnement ACE de base, le client demande un jeton au serveur d'autorisation, puis l'apporte lui-même au serveur de ressources. La chaîne courte donne la deuxième course au serveur d'autorisation. Il dépose le jeton, signale la réussite ou l'échec et, si l'envoi a échoué, remet le jeton au client pour le trajet classique. Certains déploiements peuvent même faire émettre et déposer les jetons automatiquement pour des clients qui ignorent ce mécanisme. La liaison entre les deux serveurs doit être protégée.

En prenant la livraison en charge, le serveur d'autorisation voit davantage d'étapes. La version -09 du projet de travail ACE, datée du 2 novembre, lui ajoute un chapitre opérationnel absent de -08. Elle attend des journaux horodatés pour les demandes de jeton, l'émission, le résultat du dépôt, l'expiration, la révocation et les inscriptions de clients ou de serveurs de ressources. Ce dernier peut aussi noter l'acceptation ou la suppression d'un jeton et les accès refusés, dans la mesure permise par sa mémoire, son calcul et son énergie.

L'opérateur peut alors distinguer un jeton émis d'un jeton réellement reçu.

Cette précision a un prix. Adresses et identifiants d'authentification permettent de relier un appareil à ses échanges avec plusieurs parties. Le projet envisage qu'un point de stockage conserve et transmette les journaux aux gestionnaires externes autorisés, par consultation ou notification. Les serveurs ne doivent jamais y inscrire leurs secrets, clés privées ou matériel de clé dérivé. Le point de stockage devrait retirer les données sensibles avant le partage ; une exception exige une autorisation particulière conforme aux règles de confidentialité appliquées.

Le choix de la durée de conservation et de la granularité revient à l'application et à l'exploitant.

La différence entre obligation et recommandation est nette : l'interdiction des secrets est formulée en MUST NOT ; le masquage en SHOULD. Le document ne fournit ni déploiement mesuré ni cas d'abus. Il place cependant une décision concrète devant l'exploitant : faut-il montrer au gestionnaire externe l'échec d'une livraison, ou aussi l'identité et le parcours de l'appareil concerné ?

Sources originales