Résumé

  • Le RFC 10020 distingue le groupe CoAP, le groupe applicatif et le groupe de sécurité. Leurs relations peuvent être plusieurs-à-plusieurs, un-à-plusieurs, plusieurs-à-un ou un-à-un : le déploiement organise leur correspondance, pas le protocole.
  • Group OSCORE authentifie l’émetteur identifié comme membre du groupe de sécurité. Cette preuve ne remplace pas l’autorisation d’utiliser une ressource applicative, que le RFC situe expressément dans un domaine de sécurité séparé.

Dans la console, tous les voyants étaient au vert. L’équipement écoutait bien l’adresse multicast. Il hébergeait encore le chemin demandé. La signature Group OSCORE désignait un émetteur admis. Pourtant, cet équipement avait quitté le périmètre métier auquel l’ordre était destiné.

L’ordre n’était ni forgé ni mal routé. Il était devenu légitime dans deux registres et illégitime dans le troisième.

Cette situation n’exige aucun défaut hypothétique du protocole. Elle découle de l’architecture que décrit le RFC 10020, norme IETF de juillet 2026 consacrée aux communications de groupe dans CoAP. Le texte remplace le RFC 7390, actualise le RFC 7252 et le RFC 7641, et retient le multicast UDP/IP comme transport par défaut. Surtout, il ne confond pas les différents pouvoirs que recouvre le mot « membre ».

Un mot, trois périmètres

Un groupe CoAP rassemble les points d’extrémité configurés pour recevoir les messages envoyés à une adresse IP multicast et à un port UDP associés. Il décrit une surface de réseau et d’écoute. L’URI de groupe peut porter l’adresse ou un nom d’hôte de groupe ; en l’absence d’indication contraire, le port UDP CoAP est 5683.

Un groupe applicatif rassemble des serveurs qui partagent une fonction au moyen de ressources CoAP. Il décrit ce que les destinataires sont censés faire. Le nom du groupe peut se trouver dans le chemin de l’URI ou être déduit du message et du contexte du déploiement.

Un groupe de sécurité rassemble les points d’extrémité qui détiennent le matériel nécessaire pour protéger et vérifier les échanges. Il décrit une communauté cryptographique. Un même équipement peut appartenir à plusieurs groupes de sécurité.

Le RFC autorise toutes les formes de correspondance entre ces ensembles. Plusieurs groupes applicatifs peuvent réutiliser un groupe de sécurité afin d’alléger stockage et mises à jour. Un groupe applicatif peut aussi accepter plusieurs groupes de sécurité lorsque les clients prennent en charge des algorithmes incompatibles. L’entité chargée de la configuration choisit ces liens pour son installation.

Même l’émetteur ne se déduit pas de la liste d’écoute. Le transport retenu relève de l’Any-Source Multicast : la source peut appartenir ou non au groupe IP de destination et le nombre de sources n’est pas limité par ce modèle. Afficher les auditeurs comme s’ils constituaient la liste des émetteurs autorisés mélange donc deux propriétés avant même que la cryptographie n’intervienne.

L’identité cryptographique ne porte pas tout le mandat

La communication sécurisée s’appuie sur Group OSCORE, défini dans le RFC 10021. Le protocole prolonge OSCORE du RFC 8613 et emploie les structures COSE, notamment celles du RFC 9052, pour protéger les messages au niveau applicatif. Le mode de groupe utilise la signature propre de l’émetteur ; le mode pairwise fournit des clés dérivées aux échanges individuels.

La preuve obtenue est forte et bornée. Un destinataire peut établir que le message a été produit par un point d’extrémité précis, identifiable et membre du groupe OSCORE. Les éléments symétriques communs donneraient seuls une authentification au niveau du groupe ; Group OSCORE ajoute l’authentification de la source. Il n’authentifie cependant ni l’adresse IP ni le port source du paquet.

Il n’accorde surtout pas un droit général sur les ressources. Le RFC 10020 déconseille explicitement d’utiliser l’appartenance à différents groupes de sécurité pour appliquer des politiques d’accès au sein d’un groupe applicatif. Cette appartenance donne accès à l’échange protégé et à l’authentification des membres. L’autorisation d’employer une ressource appartient à un domaine séparé et doit s’appuyer sur les propriétés de cette ressource ou sur des titres d’accès dédiés.

Il faut donc poser deux questions successives. « Qui a émis ce message pendant cette époque de clés ? » relève de Group OSCORE. « Cette identité peut-elle appliquer cette méthode à ce chemin, dans ce périmètre et à cet instant ? » relève de l’autorisation applicative. Transformer la première réponse en réponse universelle fabrique une habilitation là où le standard n’en promet pas.

Le cadre ACE du RFC 9200 peut participer à l’autorisation nécessaire pour rejoindre un groupe auprès d’un Group Manager. Mais le droit d’obtenir le matériel du groupe ne vaut pas mécaniquement droit d’utiliser chacune des ressources que ce matériel protège. Admission, authenticité et autorisation demeurent trois actes distincts.

Le décalage se fabrique tout au long de la chaîne

Le RFC 10020 parle d’« entité de configuration » parce qu’aucun administrateur unique ne détient nécessairement les trois listes. Une application, un utilisateur, un développeur, un service en nuage ou un outil de mise en service peuvent créer un groupe. La décision peut intervenir lors de la conception du logiciel, en usine, chez un revendeur, pendant l’installation initiale ou lors d’une reconfiguration ultérieure.

Ces opérations, relève le texte, peuvent être accomplies par des entités différentes avec peu ou pas de coordination. L’usine peut installer une identité, l’intégrateur affecter l’adresse multicast, le service applicatif construire le groupe de ressources et l’équipe de maintenance ne modifier ensuite qu’une seule de ces couches.

La maintenance ne signifie donc pas simplement « ajouter » ou « retirer » un appareil. Elle comprend aussi la rotation du matériel de sécurité, le changement d’adresse ou de port, la modification de l’URI, le renommage d’un groupe applicatif, ainsi que la division ou la fusion de groupes. Un ticket qui ne précise pas le registre modifié et la réconciliation attendue avec les deux autres ne décrit qu’un tiers du changement.

Le temps intervient aussi dans l’état de sécurité. Un groupe OSCORE doit adopter un mécanisme de renouvellement des clés pour la révocation et la rotation. Si les membres changent souvent et que l’opération est lente, il peut être prudent de grouper plusieurs changements. Le coût est connu : jusqu’au renouvellement, un membre parti peut encore accéder aux communications protégées par l’ancien matériel ; selon la politique retenue, un nouvel arrivant peut voir des échanges antérieurs.

Une liste de sécurité dépourvue de numéro d’époque et d’état d’achèvement de la rotation n’est donc pas une photographie actuelle des pouvoirs. Elle peut juxtaposer un membre en règle et un ancien membre dont la révocation reste inachevée.

Une absence de réponse n’est pas une preuve d’absence

Le modèle de réponse complique encore l’audit. Une requête unique part en multicast ; les serveurs répondent individuellement en unicast. Pour éviter l’implosion des réponses sur des réseaux contraints, les requêtes de groupe sont Non-confirmable et les serveurs étalent leurs réponses sur un délai aléatoire appelé Leisure. Les contraintes NSTART et PROBING_RATE continuent de s’appliquer.

Un serveur peut aussi supprimer sa réponse. Le RFC 10020 lui recommande de le faire en cas d’erreur ou lorsqu’il n’a rien d’utile à retourner, sauf si la politique de la ressource exige une réponse. L’option No-Response ne doit infléchir ce comportement que lorsque l’application a décidé à l’avance que cela convenait à cette ressource.

Le silence peut donc correspondre à une perte de requête, à l’absence de ressource, à un refus dont la réponse a été supprimée, au délai Leisure, à une perte de retour ou à une exécution sans réponse. Une répétition munie d’un nouveau Message ID peut conduire des serveurs ayant déjà traité la première requête à traiter aussi la seconde. Compter les réponses ne suffit pas à compter les effets.

C’est la portée concrète de la priorité donnée par Heng Lu au running code. Les listes de configuration établissent ce qui devait être joignable, fonctionnel et authentifié. Les observations disent ce qui s’est passé. Un dispositif gouvernable conserve les deux sans convertir l’un en preuve de l’autre.

Un reçu d’autorisation à trois registres

Un reçu d’autorisation à trois registres peut rétablir la continuité de preuve. Son premier volet décrit le groupe CoAP : adresse ou nom multicast, port UDP, portée de l’adresse, points d’écoute, source de découverte et époque de configuration. L’émetteur y figure séparément, puisque l’Any-Source Multicast ne lui impose pas d’écouter le groupe de destination.

Le deuxième volet décrit le groupe applicatif et la décision de ressource : chemin URI, méthode, type de charge utile, serveurs censés assurer la fonction, version de politique, titre d’accès examiné, résultat et expiration. Une signature correcte ne remplit jamais la case d’autorisation.

Le troisième volet identifie le groupe de sécurité : Group Manager, identifiant de groupe, suite cryptographique, identité de l’émetteur, époque OSCORE, preuve d’admission, état de départ, dernière rotation et achèvement chez les membres requis. L’authentification de l’émetteur reste distincte de la validation de son adresse réseau. Lorsque cette validation compte, l’option Echo du RFC 9175 peut vérifier que le demandeur est joignable à l’adresse annoncée.

Le volet résultat consigne les destinataires attendus, les traitements observés, la politique de suppression, la fenêtre Leisure, les réponses, les pertes et les répétitions. Le silence devient une observation non résolue, pas un « non exécuté » automatique. Chaque mutation d’une liste doit enfin désigner son auteur et la vérification de cohérence menée sur les deux autres.

Ce reçu est une proposition de gouvernance éditoriale de Daniel Kade, non une obligation du RFC 10020. Son but est d’empêcher qu’une adresse valide, un chemin présent et une clé valable soient condensés dans un même voyant trompeur.

La sécurité ne supprime pas le risque d’amplification

Le mode NoSec est fortement déconseillé et réservé à des étapes exceptionnelles, étroites et bien comprises, par exemple certaines découvertes initiales. Un serveur de groupe accessible en NoSec ne doit pas être exposé à l’Internet public. La raison tient au multiplicateur : une adresse source usurpée dans une requête multicast peut orienter plusieurs réponses vers la victime.

Group OSCORE réduit cette surface en authentifiant l’émetteur et en protégeant le chemin et la requête. La limitation des réponses et l’option Echo ajoutent des défenses. Elles n’effacent pas l’adversaire interne, la présence sur le chemin, ni l’effet du nombre de serveurs autorisés à répondre.

Le miroir des politiques de Heng Lu fournit ici le bon critère d’interface : montrer la distribution réelle du contrôle. L’adresse, la ressource, la clé, l’autorisation, la suppression et l’observation ont des propriétaires différents. Le badge « groupe sain » ne dit pas lequel a échoué.

La démarche de BTW Media fondée sur le réel conduit à une conclusion sobre. L’adresse prouve une destination configurée. Group OSCORE prouve une identité dans une époque de sécurité. L’autorisation prouve un droit sur une ressource. L’exécution se prouve encore autrement. Aucune de ces vérités ne gagne à emprunter le nom de l’autre.

Sources