Résumé

  • RFC 1457 décrivait le label de sécurité comme un attribut des données : son format, son attachement au contenu et sa sémantique devaient survivre au transport avant toute décision d’accès.
  • Le choix de la couche décidait de son pouvoir réel. Un routeur n’avait besoin que de ce qui orientait ou rejetait un paquet ; un système terminal devait recevoir assez d’information, assez tôt, pour contrôler la remise au bon processus.
  • Un label reconnu n’était ni un chiffrement ni une autorisation. La traduction, la politique locale, l’exécution et l’observation formaient des preuves ultérieures et indépendantes.

La traduction avant l’autorisation

RFC 1457 n’était pas la spécification d’une étiquette universelle. Publié comme document informatif en mai 1993, le texte de Russell Housley proposait une méthode de raisonnement aux concepteurs de protocoles. Devait-on porter un label ? Sous quelle forme ? À quelle couche ? Quel équipement devait le lire ? La réponse dépendait de la décision attendue, pas du prestige du mot « sécurité ».

Le document commençait par détacher l’étiquette du contenu ordinaire. Le label était un attribut des données qui exprimait des exigences de traitement : conditions de collecte, transfert, stockage, diffusion ou destruction. Cette distinction obligeait à préserver une relation. Copier les données sans leur attribut faisait perdre la règle ; copier l’attribut vers d’autres données fabriquait une règle fausse.

RFC 1457 demandait donc que le label demeure lié aux données. Un service d’intégrité pouvait établir ce lien. Si l’environnement ne fournissait pas ce service, il fallait un autre mécanisme. La présence simultanée de deux objets ne suffisait pas : le système devait avoir une raison vérifiable de croire qu’ils appartenaient toujours l’un à l’autre.

À l’arrivée, le problème changeait de nature. Un système d’exploitation ou une base de données pouvait représenter ses labels dans une syntaxe locale différente de celle du protocole. La machine devait traduire la représentation réseau sans perte de sens, puis seulement remettre l’information à la base de calcul de confiance chargée du contrôle d’accès. Cette base devait encore vérifier que le processus destinataire disposait de l’autorisation suffisante.

On obtient ainsi quatre faits souvent confondus. Le parseur reconnaît une forme. Le traducteur trouve une expression locale. La politique décide si une relation sujet-objet est admise. Le système de confiance remet ou refuse effectivement les données. Un test réussi au premier niveau ne dit rien de définitif sur le quatrième.

Deux politiques peuvent partager le même signe

La difficulté n’était pas seulement lexicale. Deux administrations pouvaient employer le même niveau pour des obligations différentes. Une catégorie précise dans le domaine d’origine pouvait ne pas exister dans le domaine d’arrivée. Une traduction pouvait conserver un niveau et perdre un compartiment, ou remplacer plusieurs restrictions par une catégorie plus large. Son résultat resterait bien formé tout en élargissant silencieusement les destinataires.

Le cadre privilégiait donc un format explicite commun associé à des sémantiques enregistrées. Cette séparation avait un mérite technique : un analyseur pouvait comprendre une structure stable, tandis que plusieurs politiques conservaient leurs espaces de sens. Mais l’enregistrement ne transformait pas le registre en pouvoir universel. Il indiquait où chercher la définition. L’accord entre autorités et la règle d’accès restaient locaux.

Lorsque les formats différaient, une passerelle applicative pouvait accomplir la transformation. Elle devenait alors beaucoup plus qu’un relais. Elle interprétait une obligation, décidait d’une correspondance et produisait un nouvel attribut capable d’ouvrir ou de fermer l’accès. RFC 1457 recommandait d’éviter cette concentration quand un format partagé pouvait la rendre inutile, notamment parce que la passerelle compliquait l’exploitation de protocoles autrement compatibles.

Le point est toujours actuel : une table de correspondance n’est pas une opération neutre. Elle peut être incomplète, asymétrique, périmée ou impossible à inverser. Elle possède une version, un auteur et une date d’effet. Sans ces éléments, la preuve s’arrête à « un label est sorti », pas à « la même obligation est sortie ».

Intégrité et sensibilité n’étaient pas le même axe

Le mot sécurité recouvrait aussi deux sortes de labels. Un label d’intégrité indiquait la confiance que l’on pouvait accorder aux données et les protections requises contre leur modification ou leur destruction. Un label de sensibilité indiquait le dommage possible d’une divulgation et les précautions nécessaires contre celle-ci.

Le chemin pouvait diminuer la confiance accordée à l’information. Il ne rendait pas automatiquement une information sensible moins dommageable à révéler. L’association avec d’autres données pouvait même augmenter le dommage. Ainsi, une politique ne pouvait pas réduire les deux axes à une seule hiérarchie commode. Une donnée très fiable n’était pas pour autant publique ; une donnée peu fiable pouvait encore être très sensible.

Cette séparation empêchait aussi une confusion avec le chiffrement. Une protection cryptographique pouvait contribuer à l’intégrité du lien entre label et données ou à la confidentialité du transport. Elle ne définissait pas à elle seule le sens du label, le destinataire autorisé ni l’usage permis après déchiffrement.

Montrer juste assez au routeur

Un système terminal et un système intermédiaire ne prenaient pas la même décision. Le premier pouvait avoir besoin de l’étiquette complète pour sélectionner un processus autorisé. Le second pouvait n’avoir besoin que d’un sous-ensemble permettant de choisir une route ou de rejeter le paquet. Exposer chaque compartiment applicatif à chaque routeur imposait un coût de traitement et révélait des informations sans nécessité.

RFC 1457 appliquait donc la dissimulation d’information aux métadonnées de sécurité. Les parties utiles à la décision de routage pouvaient se trouver à la couche liaison ou réseau. Les parties uniquement destinées au système terminal devaient rester au-dessus des équipements qui n’en faisaient rien. Un appareil qui ne pratiquait aucun contrôle fondé sur le label ne devait pas devenir analyseur par simple proximité.

Cette économie créait toutefois une contrainte temporelle. Si la décision visée était le démultiplexage de confiance — remettre des données d’un traitement système vers un processus utilisateur — le label devait être disponible avant cette remise. Une étiquette découverte seulement par l’application arrivait trop tard pour contrôler la frontière déjà franchie.

Le parcours des sept couches dans RFC 1457 était donc une carte de compétence. Le physique pouvait fournir un label implicite par le port, mais ne disposait pas de champ de protocole pour un label explicite. La liaison pouvait guider un pont. Le réseau pouvait guider un routeur et certains démultiplexages. Le transport pouvait associer un label plus riche à une connexion, sans aider les routeurs qui ne le lisaient pas. L’application pouvait exprimer des exigences propres à son objet, mais pas décider rétroactivement d’un transfert de couche inférieure.

Explicite ou implicite, par paquet ou par connexion

Le cadre croisait deux choix. Dans le premier, le label était explicite ou implicite. Explicite, il apparaissait dans l’information de contrôle du protocole. Implicite, il était déduit d’un port, d’une interface, d’une connexion ou du choix d’une clé cryptographique.

Le label implicite économisait des octets, particulièrement dans un environnement à niveau unique. Mais il déplaçait la preuve hors du paquet. Une capture ne permettait plus de reconstituer la décision sans connaître l’association locale en vigueur au même instant. Changer le câble, réutiliser une connexion ou remplacer une clé pouvait changer le sens sans toucher aux données.

Dans le second choix, l’étiquette était sans connexion ou orientée connexion. Une étiquette sans connexion accompagnait chaque unité et permettait un traitement paquet par paquet, au prix d’un espace de contrôle répété. Une étiquette de connexion était établie une fois ; tous les transferts suivants en héritaient. Le gain d’efficacité se payait en dépendance à l’état.

L’erreur caractéristique n’était alors plus un champ mal formé. C’était une connexion réutilisée pour deux sensibilités, un état ancien conservé après un changement de politique, ou un enregistrement d’établissement devenu introuvable. Des paquets parfaitement ordinaires héritaient d’une attribution erronée.

RFC 1108 comme expérience concrète

RFC 1108 avait défini des options de sécurité du Département de la défense des États-Unis pour IPv4. L’option de base transportait un niveau de classification et des indicateurs d’autorités de protection. Elle montrait la forme explicite, sans connexion et placée à la couche réseau que RFC 1457 allait utiliser comme exemple.

Même là, les bits ne décidaient pas seuls. Des paramètres locaux, notamment par port, déterminaient si l’option était obligatoire à l’émission ou à la réception, si un datagramme non marqué pouvait être accepté et quel label implicite lui serait associé. La politique du récepteur complétait le format du paquet.

RFC 1457 élargissait ce cas sans l’effacer. Il ne déclarait pas universelle la taxonomie d’une autorité. Il demandait quelle syntaxe, quelle sémantique et quelle couche convenaient au contrôle recherché. Cette question le sépare aussi de RFC 1455 : une préférence de route moins observable ne devient pas une classification, et une classification ne prouve pas le chemin physique, le chiffrement ou la confidentialité.

Ce que les textes ultérieurs précisent

En 2009, RFC 5570 a rendu explicite le contexte avec le Domain of Interpretation de CALIPSO. Un niveau tel que « SECRET » n’avait pas de sens isolé ; il fallait connaître l’organisation et la politique qui définissaient ses niveaux et compartiments. L’identifiant de domaine pointait vers cette sémantique, sans contenir toute la politique ni exécuter la décision.

CALIPSO imposait aussi une limite nette : son option IPv6 informative visait des réseaux fermés, fiables et multi-niveaux, non l’Internet public mondial. Le rapprochement historique ne doit donc pas devenir un conseil de déploiement général.

RFC 4301 fournit un autre contraste. Dans l’architecture IPsec, des sélecteurs rencontrent une politique locale qui choisit de protéger, laisser passer ou rejeter ; une association de sécurité porte ensuite l’état de traitement cryptographique. Un label peut alimenter une décision. Il n’est ni cette politique, ni l’association installée, ni la preuve du traitement accompli.