Résumé

  • NTS peut identifier le service NTS-KE et authentifier une réponse NTP liée à une demande en attente. Il ne certifie ni la justesse de l’horloge du serveur, ni la symétrie du trajet, ni la source à retenir, ni le droit de faire un saut d’horloge local.
  • Une décision explicable conserve quatre preuves distinctes : identité et établissement des clés, acceptation cryptographique du paquet, aptitude et sélection de la source, puis discipline de l’horloge. Un seul voyant « sécurisé » efface précisément l’autorité qu’il faudrait pouvoir auditer.

Deux réponses valides ne font pas une heure

La scène initiale est une expérience construite, pas le compte rendu d’un incident. Les certificats des sources A et B sont valides. Les deux sessions NTS-KE aboutissent. Chaque serveur fournit ses paramètres et ses cookies. Les réponses NTP s’authentifient avec la bonne clé directionnelle, reprennent l’identifiant de leur demande et ne sont pas des répétitions. Pourtant, l’une suggère une correction presque nulle et l’autre un déplacement de 800 millisecondes.

La contradiction n’accuse pas nécessairement la cryptographie. Une source peut hériter d’une mauvaise référence. Un trajet peut être fortement asymétrique. La distance de synchronisation peut dépasser la limite locale. Les intervalles des deux candidats peuvent ne pas former le groupe majoritaire demandé par l’algorithme de sélection.

Le client peut donc retenir A, retenir B avec d’autres témoins, combiner un ensemble cohérent ou ne rien appliquer. Rester non synchronisé faute de preuve suffisante est une décision correcte, non une panne du protocole.

La proposition exacte de NTS

RFC 8915 sépare l’établissement initial et le transfert du temps. NTS-KE fonctionne sur TLS ; les échanges NTP suivants portent des champs d’extension NTS. La phase coûteuse d’identité et de clés peut ainsi se terminer avant les paquets fréquents et légers de mesure.

NTS-KE utilise le port TCP 4460, TLS 1.3 au minimum et l’identifiant ALPN ntske/1. Le serveur peut désigner le serveur NTP et son port, négocier l’algorithme de chiffrement authentifié et remettre plusieurs cookies opaques. L’exportateur TLS produit deux clés distinctes, client-vers-serveur et serveur-vers-client. Puis la connexion TLS se ferme ; le serveur peut abandonner l’état propre au client.

Le client rapporte cet état dans un cookie. Sa demande contient aussi un identifiant unique et un authentificateur. La réponse acceptable doit être vérifiable avec la clé serveur-vers-client et reprendre un identifiant encore en attente. De nouveaux cookies protégés renouvellent la réserve sans imposer au serveur une mémoire par client.

La conclusion est rigoureuse mais limitée : le paquet accepté provient de la partie liée aux clés NTS, n’a pas été modifié en transit et répond à une demande réelle. Elle ne dit pas que l’oscillateur, la référence amont ou la valeur UTC du serveur est juste.

Le registre IANA attribue les types communs — identifiant unique, cookie, emplacement de cookie, authentificateur et champs chiffrés. Il rend les implémentations compatibles. Il ne note ni la qualité d’une horloge ni le jugement d’un opérateur.

L’identité ne mesure pas l’exactitude

Le certificat répond à la question « quel service NTS-KE ? ». Il n’inspecte pas l’heure servie. Le cookie permet de retrouver les paramètres nécessaires à l’authentification sans état serveur durable ; ce n’est pas un certificat d’heure. L’identifiant unique attache une réponse à une demande ; il ne mesure pas le trajet.

La limite la plus révélatrice est l’attaque par délai. Un intermédiaire peut retarder les deux sens de manière inégale sans toucher au contenu. Tous les contrôles cryptographiques passent alors que l’estimation du décalage devient fausse. RFC 8915 précise que la cryptographie ne peut raisonnablement supprimer ce mécanisme. La limite de distance borne l’erreur possible ; plusieurs sources ou chemins réduisent le risque si l’adversaire n’en contrôle qu’une partie.

La confidentialité est elle aussi circonscrite. L’en-tête NTP de base reste visible. NTS peut protéger des champs d’extension, mais ne chiffre pas indistinctement tout le paquet. Quant à la disponibilité, un acteur en chemin peut toujours jeter des paquets ; certaines réponses Kiss-o’-Death ne sont pas authentifiées.

Une implémentation ne devrait donc pas revenir automatiquement au NTP non protégé si NTS-KE échoue. Un adversaire pourrait provoquer l’échec et obtenir la dégradation. Le repli est une décision locale explicite, pas une conséquence naturelle de l’indisponibilité.

Avant la première mesure, le démarrage a déjà choisi

Les certificats X.509 ont des périodes de validité. Or la machine demande souvent le temps au réseau parce que son propre temps est douteux. Elle doit néanmoins disposer d’une approximation suffisante pour vérifier le service qui l’aidera à se corriger.

RFC 8915 énumère des ancrages imparfaits : horloge sauvegardée par batterie, estimation manuelle, dernière heure persistée, comparaison de plusieurs sources. Une réponse immédiatement postérieure à NTS-KE devrait aussi rester dans la période du certificat. Cette cohérence établit une fenêtre plausible ; elle ne fournit pas l’heure exacte.

Le choix d’autorité commence donc avant le premier paquet authentifié. Quel magasin de confiance est accepté ? Quelle ancienneté de l’état persistant est tolérable ? Peut-on relâcher le contrôle temporel du certificat, pour combien de temps et sous quelle alerte ? Combien de sources doivent s’accorder avant une modification ? Les valeurs par défaut répondent à ces questions même lorsque l’organisation ne le fait pas.

Après l’authentification vient la sélection

RFC 5905 décrit une chaîne locale. Le traitement des paquets fournit des mesures. Le filtre réduit le bruit de chaque association. La sélection recherche une intersection soutenue par un groupe majoritaire de candidats crédibles. Le regroupement écarte les valeurs aberrantes. La combinaison calcule le décalage final. La discipline pilote ensuite l’heure et la fréquence de l’horloge système.

NTS renforce l’entrée de cette chaîne : une falsification ou une répétition peut être rejetée avant de devenir une mesure. Il ne remplace aucune étape ultérieure. Une source authentifiée peut être classée falseticker. Une mesure valide peut dépasser la distance ou le délai admis. Si trop peu de sources survivent, aucune correction n’est autorisée.

La documentation actuelle de chrony sépare justement ces vues. authdata montre le mécanisme d’authentification, les établissements de clés, les tentatives, les acquittements négatifs et la réserve de cookies. D’autres rapports montrent la joignabilité, l’accord et la sélection. maxdelay et ses variantes rejettent certains délais ; minsources peut empêcher toute mise à jour tant qu’un nombre minimal de sources n’est pas sélectionnable. Les options de confiance et d’exigence organisent la relation entre sources authentifiées et non authentifiées.

NTPsec offre ses propres commandes pour les certificats, le service NTS et la conservation des clés de cookies. Cette variation ne contredit pas l’interopérabilité. Elle marque l’endroit où la règle commune cède la place au choix d’exploitation.

Quatre preuves au lieu d’un badge

La preuve d’identité conserve le nom NTS-KE configuré, la chaîne et l’identité de service acceptées, le magasin de confiance et l’instant d’établissement des clés.

La preuve de paquet conserve la génération de clés, l’identifiant unique, l’état des cookies, l’authentificateur, l’appariement avec une demande et les changements provoqués par une répétition ou un acquittement négatif.

La preuve de mesure conserve décalage, délai, dispersion, distance racine, joignabilité, historique, intersection et statut d’aberration. C’est ici qu’une réponse authentique peut devenir inutilisable.

La preuve d’action conserve la source ou la combinaison retenue, le seuil qui a autorisé une correction progressive ou un saut, le processus responsable et l’état antérieur. C’est l’autorité sur la machine rendue visible.

Un tableau de bord qui ne garde que « NTS activé » ne peut donc expliquer pourquoi l’horloge a bougé.

Règle commune minimale, décision locale

Le principe de spécification initiale minimale de Heng Lu éclaire cette séparation. Le socle commun porte les règles déterministes nécessaires à l’interopérabilité, à la sécurité et à la validation locale. Les choix futurs qui ne sont pas des invariants restent chez les participants qui exécutent le code. La publication d’une règle n’équivaut pas à son adoption et la syntaxe partagée ne crée pas une souveraineté permanente.

Lu ainsi, NTS respecte la frontière. L’IETF décrit les échanges, les clés, les cookies et les validations. IANA tient les nombres communs. Une autorité de certification contribue à l’identité du service. Aucun de ces acteurs ne choisit les sources du client, sa distance maximale, son estimation de démarrage ou l’autorisation de modifier l’horloge du système.

La primauté du code en fonctionnement apporte le test final : le document vaut parce que des systèmes indépendants peuvent l’implémenter et vérifier les mêmes propriétés. Le client peut authentifier le paquet puis refuser la mesure. Il peut reconnaître le service puis interdire le saut. Cette possibilité est la sécurité, pas une exception à celle-ci.

Sources et périmètre

L’écart de 800 millisecondes est illustratif et ne décrit aucun fournisseur, défaut, incident ou attaquant. Sources gelées :