Résumé

  • La RFC 3652 séparait une enveloppe de 20 octets, consacrée à l’acheminement et au réassemblage, d’un en-tête de 24 octets et d’un corps propre à l’opération. La signature numérique du Message Credential ne couvrait pas l’enveloppe, mais couvrait l’en-tête et le corps.
  • Le Credential pouvait porter une signature de l’émetteur ou un code d’authentification de message fondé sur une clé de session préétablie. Cette frontière décrit le périmètre d’intégrité du protocole, pas une attaque documentée, une défaillance d’implémentation ni l’impossibilité de protections à une couche inférieure.

Une enveloppe, plusieurs surfaces de confiance

En 2003, le protocole Handle devait préciser davantage qu’une recherche. Le client devait trouver le serveur compétent, lui demander de résoudre ou d’administrer un Handle, puis comprendre la réponse. Il fallait aussi transporter des messages sur des réseaux qui ne présentent pas les données de la même manière. La version 2.1 de la RFC 3652 répartissait ces fonctions en quatre éléments contigus : Message Envelope, Header, Body et Credential. RFC 3652

L’enveloppe, toujours présente, mesure exactement 20 octets. Le texte la décrit comme un emballage utile à la livraison, sans information applicative. Elle contient notamment la version du protocole, les indicateurs du message, un identifiant de session, un identifiant de requête, un numéro de séquence et la longueur du message. L’en-tête obligatoire mesure 24 octets et porte les champs communs, dont les codes d’opération et de réponse. Le corps contient les données propres à l’opération et peut être vide. RFC 3652

La frontière de confiance ne suivait donc pas celle du paquet. La RFC précise que la signature numérique du Message Credential ne protégeait pas le contenu de l’enveloppe. Elle protégeait l’en-tête et le corps. Un Credential non vide pouvait contenir une signature numérique de l’émetteur ou un MAC unidirectionnel fondé sur une clé de session déjà établie. Le texte présente ce mécanisme comme un moyen d’authentifier un message et d’en contrôler l’intégrité en transit. Un MAC dépend d’un secret partagé ; une signature numérique repose sur un autre modèle de clés. RFC 3652 RFC 2104

Cette séparation correspondait au rôle de l’enveloppe. Le client Handle pouvait utiliser des datagrammes UDP ou un flux TCP. La RFC limitait à 512 octets le message transporté en UDP, sans compter les en-têtes IP et UDP. Au-delà, il fallait fragmenter : chaque fragment transportait son numéro de séquence dans l’enveloppe pour permettre le réassemblage. TCP fournissait un flux d’octets, pas les frontières Handle ; le protocole pouvait donc encore fragmenter les messages longs avant leur réassemblage. RFC 3652 RFC 768 RFC 793

L’en-tête et le corps, eux, décrivaient l’action demandée. Le code d’opération indiquait quel type de traitement Handle était sollicité ; le code de réponse en indiquait l’issue : succès, valeur absente, renvoi vers un autre service, refus d’autorisation ou authentification requise. La définition du protocole s’appuyait sur un modèle de noms et de données distinct, tandis que la RFC 3650 décrivait l’architecture du service. Le contenu sémantique protégé commençait donc après l’emballage de livraison : réassembler un fragment ne signifiait pas encore autoriser l’opération qu’il transportait. RFC 3652 RFC 3650 RFC 3651

Authentifier n’était pas autoriser

La RFC distinguait aussi la preuve du client de la décision du serveur. Pour une action administrative, le serveur pouvait envoyer un défi ; le client répondait en prouvant qu’il détenait la clé privée ou le secret partagé pertinent. Après validation, le serveur devait encore vérifier les privilèges du compte pour l’opération demandée. Une réponse correcte au défi n’était pas une permission de modifier un Handle. Une session pouvait en outre partager état et clés entre plusieurs opérations. RFC 3652

La RFC 3552 distingue l’intégrité, l’authentification de l’interlocuteur, la confidentialité et la sécurité du système : une signature ou un MAC ne garantit pas automatiquement chacune de ces propriétés. La section de sécurité de RFC 3652 parle des signatures du serveur et de l’authentification du client, mais la définition du format reste précise : le Credential couvre l’en-tête et le corps, pas l’enveloppe de livraison. Cette phrase ne prouve pas qu’un message ait été modifié dans un déploiement. Un canal de couche inférieure peut offrir d’autres protections ; la RFC est une spécification, non un rapport d’incident. RFC 3552 RFC 3652

Enfin, le Credential Handle ne doit pas être confondu avec le profil de signature X.509. La RFC 3279 définit des identifiants d’algorithmes et encodages pour les certificats et listes de révocation ; elle n’élargit pas les octets signés par RFC 3652 et ne rend pas l’enveloppe authentifiée. Le vocabulaire cryptographique ne suffit pas : il faut préciser quel objet est couvert. RFC 3279 RFC 3652

La RFC 3652 est Informational et sa note de l’IESG indique qu’aucun consensus de l’IETF n’avait été atteint sur le système Handle ni sur son intégration à l’architecture des identifiants de l’IETF. Le document décrit un protocole proposé, pas une adoption universelle. Sa leçon est plus restreinte : cadrage, réassemblage et authentification peuvent suivre des règles différentes ; toute affirmation d’intégrité doit donc nommer les octets réellement couverts par le Credential. RFC 3652

Sources