Résumé

  • RFC 5343 réserve localEngineID pour atteindre le contexte local par défaut et lire snmpEngineID.0. Cette valeur spéciale conduit au nom réel du moteur ; elle n’est pas elle-même ce nom.
  • Le contextEngineID répond à « où se trouve l’information ? ». Le triplet securityModel, securityName, securityLevel et VACM répondent à « qui demande quoi, avec quelles protections et quelle vue ? ».
  • Une découverte réussie ne prouve ni l’identité du demandeur, ni une autorisation, ni le succès d’une opération suivante. Elle peut en outre divulguer une adresse ou un texte administratif incorporé dans l’EngineID.

Une adresse de transport ne suffisait pas à nommer le contexte

Une entité SNMP peut donner accès à plusieurs contextes. Pour viser un objet sans ambiguïté dans un domaine administratif, l’architecture assemble quatre éléments : contextEngineID, contextName, type d’objet et instance. Le PDU porte les deux derniers sous forme d’OID ; le ScopedPDU transporte aussi les deux coordonnées de contexte.

Le paradoxe opérationnel est immédiat. Le gestionnaire doit connaître l’identifiant du moteur pour adresser son contexte, mais il contacte parfois précisément ce moteur afin d’apprendre l’identifiant absent de sa configuration. RFC 5343 crée une porte d’entrée étroite : la valeur hexadécimale 8000000006, format 6 sous le numéro d’entreprise zéro, signifie toujours « contexte local par défaut du moteur qui reçoit ».

Le répondant enregistre ses types de PDU sous cette valeur en plus de son EngineID ordinaire. Le gestionnaire réutilise d’abord un identifiant déjà connu. Si son modèle de sécurité sait découvrir le moteur — comme USM pour ses propres besoins — il privilégie ce chemin. Sinon, il adresse une opération de lecture à localEngineID et demande snmpEngineID.0. Une réponse livre l’identifiant candidat ; un échec demeure un échec.

La frontière est inscrite dans la norme. localEngineID ne doit jamais devenir la valeur de snmpEngineID.0 ni celle de msgAuthoritativeEngineID dans USM. Il s’agit d’un sélecteur bien connu, pas d’une identité réutilisable.

Le contexte nomme le lieu, pas le principal

RFC 3411 réserve securityName au principal. Un modèle de sécurité transforme son identifiant propre en ce nom lisible. L’EngineID, lui, nomme un moteur dans un domaine administratif. Mélanger les deux revient à transformer la connaissance d'une adresse logique en preuve d’identité.

RFC 5343 ferme explicitement ce raccourci : le primitive isAccessAllowed() ne reçoit pas contextEngineID. VACM ne peut pas créer une vue spéciale simplement parce que la requête a emprunté localEngineID. L’accès dépend du modèle de sécurité, du securityName, du niveau de sécurité, du groupe, du contextName, du type de vue et de la variable demandée.

La découverte rend donc une requête future adressable, pas admissible. Le même EngineID peut être connu par un opérateur légitime, un outil d’inventaire, un observateur non authentifié ou un relais. Seuls les reçus du modèle de sécurité et de VACM permettent de distinguer leurs pouvoirs.

À noAuthNoPriv, la nuance est décisive. RFC 5343 rappelle que des configurations VACM courantes rendent l’EngineID lisible sans authentification, afin d’aider les outils. Le champ securityName présent dans le traitement n’a alors pas été authentifié cryptographiquement. Une interface qui affiche « identité vérifiée » après cette découverte fabrique une autorité absente du protocole.

L’identifiant peut révéler sans authentifier

Les formats EngineID peuvent intégrer IPv4, IPv6, une adresse MAC, un texte ou des octets administratifs. Un outil d’inventaire y voit une clé de corrélation ; un attaquant peut y chercher une information que NAT, pare-feu ou routeur masquait autrement. RFC 5343 recommande donc de protéger l’échange de découverte.

Mais l’adresse incorporée n’est pas un certificat. Elle peut être ancienne, choisie administrativement, transportée par un proxy ou dissociée de l’adresse qui a porté la réponse. L’architecture permet justement au contextEngineID de rester stable lorsque le transport change. Exiger leur égalité ferait perdre cette propriété et transformerait la mobilité ou le proxy en faux signal d’usurpation.

La portée d’unicité est elle aussi limitée : RFC 3411 parle d’un domaine administratif et signale que la fédération peut nécessiter une coordination. Une base globale ne doit pas traiter la seule forme de l’EngineID comme une garantie universelle de propriété ou de continuité.

Le reçu de découverte ne traverse pas l’opération suivante

RFC 5343 autorise la lecture simultanée d’autres objets, comme sysObjectID.0 ou snmpSetSerialNo.0. Le gain de trajet n’élargit pas leur force probante. Le reçu montre qu’un message, sous un contexte de sécurité donné, a rapporté ces valeurs. Il ne prouve pas qu’une autre variable appartient à la vue autorisée ni qu’un futur SET sera accepté.

Une chaîne d’audit honnête conserve séparément : destination de transport, réponse reçue, modèle et niveau de sécurité, principal éventuellement authentifié, emploi du sélecteur local, EngineID retourné, contextName visé, décision VACM, statut du PDU, relecture de l’objet et effet opérationnel. Chaque étape peut réussir alors que la suivante échoue.

Cette séparation protège aussi contre les conclusions excessives. Une réponse à la découverte ne démontre pas qu’un équipement physique précis se trouvait derrière le proxy, qu’un opérateur particulier a autorisé l’action, qu’une configuration a été engagée, ni qu’un service a changé d’état.

Le registre vivant doit rester daté

RFC 5343 complète le registre que RFC 3411 avait demandé sans en détailler toutes les règles. Il consigne les formats 1 à 5, attribue 6 au moteur local, laisse 128 à 255 aux usages d’entreprise et exige une spécification pour les nouvelles valeurs de l’espace contrôlé.

Le registre IANA actuel documente l’administration présente du vocabulaire. Il ne prouve pas qu’un agent ancien connaissait le format 6, qu’un produit précis l’implémente aujourd’hui ni qu’un EngineID concret est exact. L’observation doit conserver la date du registre et la capacité réellement mesurée du pair.

Une ligne enregistrée coordonne la syntaxe. Elle ne garantit ni la fraîcheur d’une valeur, ni sa confidentialité, ni sa bonne administration, ni le résultat d’une requête.

Sources et limite de preuve

Le dossier associe les surfaces canoniques de RFC 5343, les RFC d’architecture, de dispatch, USM, VACM, opérations et MIB, le Transport Security Model ultérieur, le registre IANA vivant et les sources doctrinales déclarées. Il ne documente aucun produit, déploiement, endpoint exposé, lecture illicite, écriture réussie, incident ou taux d’adoption actuel.