Résumé

  • Chaque requête protégée par NTS contient exactement un identifiant unique produit par un générateur aléatoire cryptographiquement sûr et long d’au moins 32 octets ; le serveur recopie la même valeur.
  • Le client ne traite la réponse que si l’identifiant correspond à une requête encore en attente et si le paquet est authentique avec la clé serveur-vers-client associée.
  • Cette preuve sert à détecter les rejeux et à corréler un échange ; ce n’est ni l’identité stable du client, ni le cookie NTS, ni une garantie d’heure exacte.

Le reçu d’une question encore ouverte

Le mot « identifiant » suggère volontiers un compte, un appareil ou une personne. Le RFC 8915 lui donne un emploi beaucoup plus étroit. Avant d’envoyer une requête de temps protégée, le client produit une chaîne aléatoire d’au moins 32 octets. Il la place dans l’unique champ Unique Identifier de la requête. Le serveur qui accepte la requête reprend exactement cette chaîne dans l’unique champ correspondant de sa réponse.

À l’arrivée, deux contrôles sont indissociables. La valeur doit correspondre à une requête que le client considère encore comme en attente, et le paquet doit être authentique sous la clé S2C liée à cette requête. L’échec de l’un ou de l’autre impose le rejet sans traitement supplémentaire. Un ancien paquet, pourtant authentique au moment de sa création, ne répond donc pas à la nouvelle question.

Le champ n’est pas chiffré. Cette visibilité n’en fait pas un champ librement modifiable : le RFC exige qu’il soit authentifié. Il appartient aux données couvertes par le mécanisme AEAD, même s’il reste hors du contenu chiffré. Un observateur peut lire la valeur ; il ne peut pas la remplacer et fabriquer une réponse valide sans la clé. Confidentialité et intégrité ne sont pas synonymes.

Ainsi comprise, l’unicité est fonctionnelle. La valeur distingue une requête en cours de celles qui l’ont précédée. Elle n’est pas attribuée par le serveur, ne devient pas un numéro de compte et n’affirme rien sur la personne qui utilise la machine. Sa durée utile se termine avec l’acceptation ou l’expiration de la requête.

Pourquoi l’horodatage d’origine ne suffisait pas

NTP savait déjà rattacher une réponse à une émission. Le RFC 5905 définit l’Origin Timestamp sur 64 bits : c’est l’heure, côté client, à laquelle la requête est partie. Le serveur la renvoie, et le client la compare à son état local pour reconnaître les paquets incohérents, dupliqués ou rejoués.

Le RFC 8915 conserve cette histoire mais en marque la limite cryptographique. Soixante-quatre bits offrent un espace plus petit et, selon l’implémentation, une grande partie de la valeur peut être prévisible. Une date de départ est une donnée temporelle utile ; elle n’est pas nécessairement un défi imprévisible face à un adversaire.

L’extension sépare donc les fonctions. Son corps compte au minimum 32 octets et doit provenir d’un générateur aléatoire cryptographiquement sûr. Le RFC 4086 rappelle pourquoi la provenance compte autant que la longueur : une suite peut réussir des tests statistiques tout en étant devinable parce que son état initial est pauvre. Dire « au moins 256 bits de longueur » est exact ; promettre automatiquement 256 bits d’entropie ne le serait pas.

Le RFC 8915 autorise aussi l’usage du champ sans NTS, pour aider à repérer des paquets usurpés par un attaquant hors chemin. Dans l’échange NTS, toutefois, la conclusion solide vient du couple de preuves. L’écho aléatoire désigne la requête ouverte ; l’authentification S2C atteste l’origine cryptographique du paquet. L’un sans l’autre ne forme pas le reçu complet.

Cookie, TLS et identifiant : trois rôles

La première étape, NTS-KE, passe par TLS. Elle authentifie initialement le serveur, négocie les paramètres et extrait les clés. La connexion TLS est ensuite fermée. L’identifiant de la requête ultérieure n’est ni un certificat ni une nouvelle identité TLS.

Le cookie NTS remplit une deuxième fonction. Il transporte un état d’association opaque que le client rend au serveur. Celui-ci peut alors retrouver l’algorithme AEAD et les clés directionnelles sans conserver une fiche par client. Un précédent article de Sofia Ren consacré à Dieter Sibold a suivi ce transfert d’état après la fermeture de TLS. Le présent objet est différent : le cookie restaure le contexte cryptographique ; l’identifiant unique rattache une réponse précise à une requête précise.

Enfin, l’authentificateur protège le paquet. La requête transporte le cookie et l’identifiant sous authentification, sans les chiffrer. Dans la réponse, l’identifiant reste visible tandis que les nouveaux cookies sont placés dans la partie chiffrée et authentifiée. Fusionner ces objets ferait disparaître une décision volontaire du protocole sur la confidentialité.

Cette distinction borne également le risque de suivi. Un identifiant durable permettrait de relier des actions dans le temps. Ici, la valeur est censée être fraîche, imprévisible et limitée à une requête. Une réutilisation, une collision ou une conservation excessive dans les journaux serait un défaut d’exploitation à surveiller, pas la preuve que la norme a défini une identité du client.

Authentique ne veut pas dire exact

Le rejet des rejeux empêche qu’une ancienne réponse protégée soit simplement remise en circulation pour satisfaire une nouvelle requête. Il ne certifie pas pour autant l’heure. Le RFC 7384 distingue le rejeu, la modification, l’usurpation, la manipulation du délai et l’attaque de la source externe d’une horloge maîtresse. Le serveur peut répondre de façon authentique et actuelle tout en dépendant d’une mauvaise source ; le chemin peut aussi introduire un délai malveillant.

Le RFC 8633 traite donc séparément la sélection et la surveillance des sources. Avec une seule source, toute erreur est transmise au client. Des sources suffisamment nombreuses et indépendantes, la détection des désaccords et l’enquête de l’opérateur restent nécessaires. L’identifiant unique prouve « cette réponse protégée correspond à cette demande en attente », jamais « cette heure est vraie ».

Sources