Résumé

  • NTS fait deux choses successives : une négociation TLS établit les clés et remet des cookies ; les paquets NTP ultérieurs présentent l'un de ces cookies sans exiger une session par client sur le serveur.
  • Le cookie transporte un état d'association chiffré. Il n'est ni une identité personnelle, ni une heure, ni une preuve que la source est exacte.
  • Dieter Sibold a contribué, avec quatre coauteurs et la communauté IETF, à cette architecture. Ses fonctions actuelles documentent une responsabilité technique, non un pouvoir sur les déploiements.

Imaginons deux serveurs NTP derrière un répartiteur. Le premier participe à l'établissement sécurisé ; le second reçoit plus tard le paquet horaire. Aucune base centrale ne contient la ligne du client. Pourtant le second serveur doit retrouver l'algorithme et les deux clés convenus, reconnaître une requête valide et construire une réponse que le client acceptera.

La solution de la RFC 8915 n'est pas de rendre la session éternelle. Elle consiste à remettre au client un objet scellé par le service. Le client ne peut ni le lire ni le modifier, mais il peut le restituer. Si le second serveur dispose de la bonne génération de clé de cookie, il récupère l'état et poursuit l'échange.

Cette délégation de stockage est le cœur opérationnel de Network Time Security. Elle permet d'étendre la protection à un grand nombre de clients sans transformer chacun d'eux en entrée permanente. Elle crée aussi une obligation : ne jamais prendre la possession du reçu pour la preuve que l'heure qu'il accompagne est juste.

La première phase s'arrête exprès

NTS Key Establishment, NTS-KE, utilise TLS sur le port TCP 4460 et l'identifiant d'application ntske/1. Le client et le serveur choisissent le protocole suivant, généralement NTPv4, et un algorithme de chiffrement authentifié. La réponse peut aussi orienter le client vers une adresse et un port NTP différents de ceux du service d'établissement.

L'exportateur TLS dérive deux secrets distincts : C2S pour les requêtes allant du client au serveur, S2C pour les réponses. Le serveur fournit plusieurs cookies initiaux. Puis les deux côtés ferment proprement le canal TLS. Le texte précise que le serveur ne conserve pas d'état propre à ce client.

Cette fermeture est une fonction, non une lacune. Les calculs asymétriques et la validation du certificat restent concentrés dans une phase occasionnelle. Le flux courant d'horodatage utilise ensuite des primitives symétriques plus légères. Le service NTS-KE peut même être séparé du serveur NTP, à condition que la gestion des clés de cookies reste cohérente.

Une mesure d'exploitation doit donc aller au-delà du succès TLS. Elle relie l'identité vérifiée, le protocole et l'AEAD négociés, la génération exportée, l'adresse NTP fournie, le nombre de cookies et le premier paquet NTP authentifié. Sans ce dernier, l'établissement est une promesse qui n'a pas encore servi.

Un coffre confié au client

La RFC propose un format de cookie qui permet de comprendre la répartition des responsabilités. Le serveur réunit l'identifiant de l'AEAD et les clés S2C et C2S, chiffre cet ensemble avec une autre clé réservée aux cookies et produit un triplet : identifiant de cette clé, nonce et texte chiffré.

Le client n'obtient pas les champs internes. Pour lui, le cookie reste une suite opaque. Lors d'une requête ultérieure, il renvoie cette suite. Le serveur choisit la clé de déchiffrement grâce à l'identifiant, vérifie le scellement et retrouve les paramètres de l'association.

Le serveur est donc « sans état » dans un sens précis : il n'a pas besoin d'une fiche par client. Il n'est pas sans mémoire. Il possède encore ses clés partagées, leur historique récent, la configuration des algorithmes et les sources de temps. Une grappe dont les membres n'ont pas les mêmes clés brisera la continuité même si chaque cookie est intact.

Cette précision évite un glissement fréquent. Le client porte le registre, mais il n'en devient pas l'auteur. Il ne choisit pas les clés contenues dans l'objet et ne peut pas en fabriquer un autre. La portabilité retire une dépendance à une session centrale ; elle ne transfère pas l'autorité cryptographique.

Le témoin de requête n'est pas le cookie

Chaque requête protégée contient un Unique Identifier aléatoire, exactement un cookie et un champ d'authentification créé avec C2S. Le serveur reprend l'identifiant dans sa réponse et la protège avec S2C. Le client peut alors vérifier que la réponse correspond à la requête qu'il vient d'émettre.

Ce témoin aléatoire protège le client contre la réinjection d'une ancienne réponse. Il n'est pas un identifiant durable de machine et ne sert pas à ouvrir le cookie. De même, les deux clés directionnelles ne doivent pas être fondues dans une notion vague de « clé NTS » : chacune atteste un sens de circulation différent.

Dans ce profil, le serveur reste volontairement sans protection de rejeu équivalente. Traiter de nouveau une requête ne lui nuit pas si la réponse ne peut pas amplifier fortement le trafic. C'est l'une des raisons pour lesquelles la RFC 8915 se limite aux modes client 3 et serveur 4 de NTP. Les autres modes ont d'autres exigences de symétrie et d'état.

Pour diagnostiquer, il faut distinguer un cookie inconnu, un déchiffrement impossible, une balise de paquet invalide, un identifiant de réponse inattendu et une mesure horaire rejetée. Le mot « échec d'authentification » est trop large pour désigner le responsable.

Les espaces réservés financent la réponse

Un client doit renouveler son stock parce que la réutilisation répétée d'un cookie peut devenir un marqueur reconnaissable. Le serveur renvoie donc de nouveaux cookies dans ses réponses. Mais un protocole UDP public ne peut pas laisser une petite requête commander une grande réponse à une adresse usurpée.

Les Cookie Placeholders occupent à l'avance la place nécessaire. Le client les ajoute ; le serveur remplace cet espace par les cookies demandés. La recommandation vise un stock de huit cookies inutilisés et limite normalement à sept le nombre d'espaces dans une requête. En cas de risque de fragmentation, il faut réduire ce nombre.

L'idée économique est simple : la requête paie en octets la capacité de réponse qu'elle sollicite. Le renouvellement n'ouvre pas un multiplicateur gratuit. Un contrôle doit suivre la taille des paquets, les espaces envoyés, les cookies reçus et le stock restant, sans traiter le nombre huit comme une obligation absolue de toutes les implémentations.

La rotation produit une date de péremption implicite

Le format suggéré n'inscrit pas une échéance universelle dans le cookie. Sa validité pratique dépend de la présence de la clé de déchiffrement correspondante. Les serveurs sont invités à faire tourner ces clés, à effacer les anciennes pour limiter l'effet d'une compromission et à garder quelques générations afin que les clients traversent la transition.

Si l'identifiant renvoie à une clé effacée ou inconnue, le serveur répond par NTS NAK. Le client doit retourner à NTS-KE et recevoir une nouvelle association. Une rotation trop brutale, un redémarrage sans persistance ou une mauvaise synchronisation de grappe peut ainsi provoquer une foule de nouvelles connexions TLS.

Le découpage apporte néanmoins une résilience utile. Une attaque qui sature seulement NTS-KE ne coupe pas forcément les clients qui possèdent déjà des cookies encore déchiffrables. À l'inverse, elle bloque les nouveaux clients et ceux dont le stock est devenu inutilisable. La continuité a donc une fenêtre mesurable, définie par l'inventaire du client et les générations conservées par le serveur.

La documentation actuelle de chrony montre une réalisation de ce modèle. La commande authdata sépare le numéro d'établissement, le type d'AEAD, la longueur de clé, l'ancienneté, les tentatives, les NAK et l'inventaire de cookies. La configuration permet de conserver des clés lors d'un redémarrage et d'organiser leur rotation. Ce sont des décisions d'une implémentation, pas la loi commune de tous les produits.

Réutiliser ou ne pas être suivi

Un cookie renvoyé plusieurs fois peut permettre à un observateur de rapprocher des paquets provenant de deux réseaux. La RFC recommande donc l'usage unique tant qu'un stock frais existe. L'objectif n'est pas de cacher le trafic horaire, mais de ne pas ajouter un marqueur stable à ce que NTP révèle déjà.

Lorsque NTS-KE est indisponible, l'usage unique peut cependant épuiser le stock et interrompre le service. La RFC autorise alors la réutilisation si la résilience prime sur la non-corrélation. Ce choix doit appartenir à une politique explicite, car aucun réglage ne maximise les deux valeurs.

Il faut aussi limiter la promesse. Le serveur horaire voit les clients qui lui parlent. Le trafic d'établissement TLS n'est pas couvert par l'objectif de non-corrélation, et l'en-tête NTP ordinaire n'est pas chiffré. NTS offre une protection ciblée, pas un anonymat général.

La cryptographie ne choisit pas la bonne horloge

Une réponse valide établit que son émetteur possède S2C et que les octets protégés n'ont pas changé. Elle ne garantit pas que la source de référence fonctionne, que l'opérateur est honnête ou que le client devrait discipliner son oscillateur avec cette mesure.

La RFC 8633 recommande au moins quatre sources indépendantes et diverses lorsqu'une bonne exactitude est nécessaire. Les mécanismes de sélection de NTPv4 restent responsables de l'intersection, du filtrage des valeurs aberrantes et de la combinaison. L'authentification élimine certaines attaques ; elle ne transforme pas une source unique en vérité.

Une attaque par retard le démontre. L'adversaire ne modifie rien : il retient un paquet valide plus longtemps dans un sens que dans l'autre. Le calcul d'offset, fondé sur une approximation de symétrie, est déplacé. La balise reste correcte. La mesure peut devenir mauvaise.

Le démarrage présente une autre circularité. Le certificat TLS possède des dates de validité, alors que l'horloge locale peut précisément être fausse. La RFC propose plusieurs atténuations — dernière heure persistée, horloge secourue, sources multiples, comparaison après la première réponse — sans annoncer de solution parfaite.

Ainsi, le reçu final doit contenir l'offset, le délai, la distance, les sources candidates, le résultat de sélection et l'ajustement de l'horloge. La cryptographie est une ligne du dossier, pas sa conclusion.

Dieter Sibold dans une œuvre collective

La RFC 8915 a été publiée en septembre 2020 avec Daniel Fox Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie et Ragnar Sundblad comme auteurs. Son statut Standards Track signifie revue publique et consensus de l'IETF. Il serait inexact de transformer cette attribution en récit d'inventeur solitaire.

La fiche actuelle de l'IETF présente Sibold comme président du groupe Network Time Protocols et relecteur de l'Internet Area Directorate. Elle lui attribue également la RFC 8633. La page du groupe le nomme avec Karen O'Donoghue et décrit les travaux qui continuent sur NTP, NTS, la résistance aux retards et la prochaine génération du protocole.

La PTB, institut national allemand de métrologie, désigne aujourd'hui le Dr Dieter Sibold comme responsable de la sécurité de l'information. Une note officielle de la PTB sur la synchronisation sécurisée le cite comme contact pour les travaux NTS.

Ces éléments relient une carrière institutionnelle, l'exploitation du temps et la normalisation. Ils ne prouvent ni contrôle sur le consensus, ni autorité sur chrony, ni responsabilité personnelle pour les choix d'un opérateur. Une norme collective reste collective, comme un cookie transporté par le client reste une déclaration scellée du serveur.

Un reçu continu, sans journaliser les secrets

Le dossier de contrôle commence par le pair NTS-KE, la chaîne de certificat, la politique appliquée, le résultat ALPN, le protocole et l'AEAD, l'identifiant de génération et l'adresse NTP. Il conserve des références aux clés, jamais leur matière secrète.

Il suit ensuite le cookie : génération de la clé de scellement, inventaire, première utilisation ou réemploi, espaces réservés, NAK, rotation et nouvel établissement. Dans une grappe, il doit montrer quel membre a su déchiffrer quelle génération.

Pour chaque échange NTP viennent une empreinte sûre de l'identifiant aléatoire, la corrélation de réponse, le résultat cryptographique, l'offset et le délai. Le dernier bloc note les sources retenues ou rejetées et la correction réellement appliquée à l'horloge.

Cette chaîne évite de prendre une étape pour le tout. TLS peut réussir et le premier paquet échouer. Un paquet peut être authentique et sa mesure refusée. L'heure peut être bonne et l'inventaire de cookies prêt à disparaître au prochain redémarrage. La priorité au code en fonctionnement consiste à prouver chacun de ces passages.

Sources