Résumé

  • RFC 3157 imposait confidentialité et intégrité à la mobilité des credentials, sans prétendre qu’un stockage chiffré supprimait la confiance dans le serveur. Celui-ci pouvait ignorer le secret utilisable et garder la main sur sa présence, sa version et sa disponibilité.
  • Le cadre devait accueillir un serveur de credentials et un transfert direct entre terminaux. Le premier concentrait conservation et politique ; le second déplaçait la difficulté vers l’authentification des appareils, leur compatibilité et un accusé de réception vérifiable.
  • Un téléchargement ou un accusé authentifié ne prouve que l’opération nommée. Il ne prouve ni l’effacement des autres copies, ni la sûreté locale, ni l’autorisation d’un acte futur, ni l’acceptation par les correspondants.

L’identité cryptographique avait cessé de tenir dans une seule machine

Le modèle ancien semblait naturel parce que ses frontières se superposaient. Une personne créait une paire de clés sur son ordinateur, transmettait la partie publique à une autorité de certification et gardait la partie privée dans le même boîtier. Machine, stockage et capacité de signer partageaient presque le même destin.

La multiplication des appareils rompait cette simplicité. Une même personne pouvait vouloir signer ses messages depuis son poste au bureau puis depuis un portable en déplacement. Elle pouvait devoir déchiffrer depuis un téléphone ou un pager. Un routeur devenu trop petit pouvait être remplacé sans imposer à tous ses pairs une nouvelle configuration de clé publique.

RFC 3157 appelait ce problème la mobilité des credentials. Le mot recouvrait clés privées, racines de confiance, tickets et parties privées d’un environnement de sécurité personnel. S/MIME, IPsec et TLS apparaissaient comme consommateurs possibles ; le document de 2001 ne réécrivait aucun de ces protocoles.

Dire que « l’identité du routeur » passait dans un nouveau châssis était une commodité de récit. Ce qui voyageait était un matériau cryptographique capable de satisfaire des vérifications déjà configurées. L’ancien appareil, le nouveau, l’administrateur, l’émetteur du credential et les pairs restaient distincts. La continuité d’une preuve cryptographique ne transportait pas automatiquement tous les droits administratifs.

Deux architectures distribuaient le pouvoir de deux façons

La première exigence structurante demandait au cadre SACRED de supporter deux familles : le serveur de credentials et le transfert direct. Les maintenir toutes deux empêchait de cacher un choix d’autorité derrière le mot vague de synchronisation.

Dans le modèle serveur, un dépôt conservait l’objet pour une récupération ultérieure et un serveur participait activement au contrôle de sécurité. Un terminal déposait le credential protégé ; un autre venait le reprendre. L’organisation gagnait un protocole client-serveur familier, une conservation indépendante d’un appareil fragile et, éventuellement, un point d’application uniforme de sa politique.

Le gain concentrait une dépendance. Il fallait exploiter le service, le rendre disponible, le découvrir et le défendre. Le dépôt devenait une cible. Une politique cohérente pouvait coexister avec l’impossibilité de récupérer une clé au moment précis où un appareil neuf en avait besoin.

Le transfert direct évitait le stockage durable chez un intermédiaire. Les routeurs traversés ne devenaient pas des serveurs de credentials parce qu’ils transportaient des paquets. En revanche, les deux terminaux devaient se trouver, parler des transports compatibles, reconnaître leurs méthodes d’authentification et gérer leurs différences de format ou de capacité.

RFC 3157 ne sacrait pas une solution. Il conservait les coûts et les pouvoirs de chacune pour qu’un résultat de l’une ne soit pas imputé à l’autre.

Un secret illisible pouvait encore être retenu

Une exigence générale interdisait que le protocole oblige le credential à apparaître en clair ailleurs que sur les appareils de l’utilisateur final. Cette contrainte permettait au serveur de conserver ou relayer une enveloppe protégée sans devoir ouvrir la clé privée.

Elle ne transformait pas le serveur en tuyau sans autorité. Celui qui contrôlait le dépôt pouvait influer sur l’existence de l’objet, sa visibilité dans une liste, la version rendue au client, son remplacement et sa suppression. Il pouvait être incapable d’en tirer une clé exploitable et néanmoins détruire la copie disponible sur ce serveur.

Même le verbe « détruire » doit garder son périmètre. La suppression d’un enregistrement ne prouvait pas que les sauvegardes, exports, caches ou appareils avaient perdu leurs copies. Elle ne révoquait pas forcément l’identité connue des pairs. Elle établissait une mutation d’un dépôt, sous une opération donnée.

La disponibilité constituait une autre propriété. Le document décrivait le serveur comme une cible majeure de déni de service. Une enveloppe parfaitement confidentielle mais impossible à obtenir pouvait interrompre une migration de routeur ou empêcher la lecture d’un message. Empêcher la lecture par l’opérateur ne garantissait pas la remise au titulaire.

La leçon dépasse le produit cryptographique : limiter le pouvoir de connaître ne limite pas automatiquement le pouvoir de retenir, restaurer une ancienne version, remplacer ou supprimer.

Le nom de l’opération bornait l’autorisation

Le modèle serveur ne se résumait pas à un bouton de copie. RFC 3157 demandait des opérations permettant d’énumérer les credentials, d’en ajouter, d’en supprimer et de modifier les informations d’authentification. L’auto-inscription devait être supportée ; l’initialisation en masse ne devait pas être empêchée.

Chaque verbe possédait une surface différente. Lister révélait un inventaire sans nécessairement révéler le secret. Télécharger livrait un objet à un terminal. Déposer créait ou modifiait un état. Supprimer retirait un état du serveur. Changer un mot de passe déplaçait la frontière des prochains accès. Réussir l’un n’autorisait pas silencieusement les autres.

L’authentification de l’utilisateur avant téléchargement répondait à une question de compte. L’authentification du serveur protégeait le client contre un interlocuteur imposteur. L’authentification du credential pouvait détecter substitution ou corruption. Trois vérifications, trois sujets.

Un utilisateur valide pouvait encore agir depuis un logiciel compromis. Un serveur authentique pouvait rendre une ancienne enveloppe pourtant intègre. Une clé correcte pouvait ensuite signer une opération non approuvée. Identité de compte, intégrité d’objet, sûreté de l’appareil et autorité d’action ne devenaient pas interchangeables.

RFC 3767 rendrait ensuite visible une autre séparation : le mot de passe du compte authentifiait l’accès au serveur, tandis qu’un mot de passe de credential pouvait protéger le contenu téléchargé. Une seule saisie réussie ne devait pas recevoir le pouvoir conceptuel des deux.

L’opacité du format réduisait la coordination, pas l’incertitude

RFC 3157 exigeait que le protocole ne dépende pas de la structure interne du credential. Le type et le format devaient rester opaques à ses pairs. Le cadre devait aussi accepter plusieurs moyens d’authentifier l’utilisateur et plusieurs transports.

Cette économie de compréhension formait un noyau minimal d’interopérabilité. Un téléphone limité n’avait pas à comprendre tous les objets d’un poste de travail pour participer à leur déplacement.

Mais le succès du transport ne validait pas l’objet opaque. Un serveur capable de ranger une enveloppe ne pouvait pas en déduire que l’application destinataire la lirait, que ses algorithmes étaient encore admis, que la chaîne de certificats restait valide ou qu’elle appartenait au bon compte. L’abstraction qui facilitait la portabilité réduisait aussi la portée du reçu intermédiaire.

Les choix obligatoires à supporter créaient un plancher commun. Ils ne prouvaient ni le support universel, ni une combinaison négociée, ni le comportement du code en cours. Seule une transaction observée pouvait établir l’usage réel.

Le transfert direct avait besoin d’une fin authentifiée

Sans dépôt permanent, la chaîne changeait. Le terminal receveur devait pouvoir authentifier l’appareil émetteur. Après réception, il devait pouvoir renvoyer un accusé que l’émetteur pourrait lui-même authentifier.

Cet accusé réduisait une ambiguïté réelle. Sans lui, le credential pouvait être en route, rejeté, corrompu, reçu ou perdu juste après réception. Avec lui, un pair authentifié déclarait l’avoir reçu sous les règles du protocole.

Le reçu ne prouvait pas que la copie source avait disparu. Il ne garantissait pas un stockage durable ni l’innocuité du terminal. Il ne disait pas que l’application accepterait le format ou que l’humain avait souhaité l’opération. Une preuve de réception n’était pas une preuve d’exclusivité, de conservation ou d’usage.

Une politique « supprimer la source après accusé » aurait ajouté un autre acte, avec sa propre réussite et ses propres pannes. Le mot déplacement pouvait masquer un intervalle où deux copies existaient, ou un échec où aucune bonne copie ne survivait.

Le journal pouvait devenir une fuite parallèle

Le document recommandait d’auditer les événements importants, particulièrement sur le serveur. Heure, compte, opération et résultat pouvaient aider à distinguer suppression volontaire, échec du dépôt, tentative de téléchargement et indisponibilité.

Il avertissait aussi contre l’enregistrement des secrets. Un utilisateur pouvait saisir son mot de passe dans le champ du nom. Recopier aveuglément l’entrée dans les logs aurait placé le secret dans une surface plus largement répliquée et souvent moins protégée que le dépôt.

Une piste durable n’est donc pas une copie exhaustive. Elle garde l’identité et le contexte nécessaires à l’enquête tout en excluant les valeurs réutilisables. Ses horloges, accès, rétention et intégrité demandent leur propre contrôle.

La ligne « téléchargement réussi » ne prouve pas seule quelle version est arrivée dans quel magasin local. L’enquête doit la joindre à l’empreinte de l’objet, au transcript, à l’import local, à l’usage par le protocole dépendant et au résultat.

Le matériel fixait une autre frontière physique

L’annexe comparait la mobilité logicielle aux cartes à puce et autres jetons matériels. Une clé restant dans un support transportable pouvait être utilisée depuis plusieurs hôtes compatibles sans être copiée dans leur stockage général.

Ce modèle n’était pas universel. Les interfaces différaient, le coût et la disponibilité aussi, et le matériel connaissait ses propres défaillances. Certaines organisations pouvaient refuser cette solution. Les protocoles SACRED pouvaient même compléter le matériel en mettant à jour un credential sans retour physique au service administratif.

RFC 3157 reconnaissait qu’un credential logiciel mobile n’offrait pas le même confinement qu’une clé qui ne quitte jamais un composant contrôlé. Il ne concluait pas que tout jeton était sûr ni que tout transfert logiciel échouait. La question était : quelle matière franchit quelle frontière, qui peut interrompre le parcours et comment le système récupère-t-il ?

Le protocole ultérieur n’a réalisé qu’un chemin possible

RFC 3760 a ensuite décrit le cadre abstrait, puis RFC 3767 a défini un protocole serveur en XML avec un profil BEEP et le support de TLS et/ou DIGEST-MD5. Il séparait récupération en exploitation et gestion facultative du compte.

Cette suite prouve l’évolution d’un travail de spécification : exigences, cadre, réalisation. Elle ne prouve pas une adoption générale, le déploiement du transfert direct ni la conformité d’un produit particulier.

La résistance recherchée aux attaques par dictionnaire hors ligne illustre encore la limite. Un échange peut éviter de livrer à l’observateur le matériau utile à la vérification d’un mot de passe tout en dépendant de la qualité du mot de passe, du logiciel terminal, de la disponibilité du serveur et du chiffrement correct du credential.

Le mérite historique de RFC 3157 tient dans ce refus des raccourcis. Confidentialité du transit, pouvoir du dépôt, disponibilité, authentification des terminaux, reçu, stockage local, continuité de l’identité et résultat ultérieur restaient liés sans devenir synonymes.

La mobilité élargissait la surface de preuve

Le modèle à une machine concentrait le risque. La mobilité améliorait récupération et commodité en ajoutant des transitions. Dépôt, mutation, téléchargement, remise directe, import et usage devenaient autant de lieux où l’identité pouvait être copiée, retenue, substituée ou mal interprétée.

Un audit solide part de l’émetteur du credential et de l’empreinte de l’objet protégé. Il nomme l’architecture ; conserve séparément authentification utilisateur et serveur ; identifie l’opération ; garde version et intégrité ; mesure l’état et la disponibilité du dépôt ; identifie le terminal et ses hypothèses de confiance ; puis suit l’objet jusque dans le protocole dépendant et le résultat métier.

Si les pairs d’un routeur acceptaient l’ancienne clé et le trafic revenait, la preuve dépassait le téléchargement. Si la clé était stockée mais refusée, la continuité avait échoué. Si elle était acceptée après une migration déclenchée par un opérateur non autorisé, la continuité cryptographique n’avait pas fourni l’autorité administrative.

Le serveur n’avait pas besoin du texte clair pour rester puissant. Cette distinction, plus que la simple promesse de transporter une clé, est ce que RFC 3157 a laissé à l’histoire d’Internet.

Sources