Resumen

  • NTS identifica el extremo NTS-KE y autentica una respuesta NTP frente a una solicitud pendiente. No certifica el reloj del servidor, no elimina el retardo asimétrico, no elige entre fuentes que discrepan ni concede permiso para saltar el reloj del sistema.
  • Una decisión defendible enlaza cuatro pruebas sin confundirlas: identidad y claves, aceptación del paquete, aptitud y selección de la fuente, y disciplina local del reloj. El indicador único «seguro» oculta la parte que realmente explica el cambio.

Dos respuestas válidas, ninguna orden

El comienzo es un ensayo imaginado, no un incidente. A y B presentan certificados válidos. Sus intercambios NTS-KE terminan correctamente. Cada servidor entrega cookies y material criptográfico. Después, las respuestas NTP se verifican con su clave de servidor a cliente, reproducen el identificador de una solicitud pendiente y no son repeticiones. Sin embargo, una aconseja una corrección mínima y la otra, 800 milisegundos.

La diferencia puede venir de una referencia superior equivocada, un trayecto asimétrico, una distancia de sincronización excesiva o la ausencia de intersección con las demás fuentes. Nada de ello exige falsificar el autenticador.

El cliente todavía debe clasificar las mediciones. Puede escoger A, usar B si otros testigos la respaldan, combinar un conjunto coherente o no sincronizar. Abstenerse cuando la evidencia no converge es una salida válida y, a menudo, la más segura.

La afirmación limitada de NTS

RFC 8915 divide NTS en dos protocolos. El establecimiento de claves NTS ocurre sobre TLS. La sincronización usa campos de extensión dentro de NTP cliente-servidor. Así se separan la identidad y las claves, relativamente costosas, de los intercambios frecuentes que miden tiempo.

NTS-KE utiliza TCP 4460, TLS 1.3 como mínimo y el identificador ALPN ntske/1. El servicio puede señalar el extremo NTP, negociar el algoritmo de cifrado autenticado y entregar una reserva inicial de cookies opacas. El exportador TLS deriva claves distintas para cliente-servidor y servidor-cliente. Cerrado el canal, el servidor no necesita conservar estado individual.

El cliente devuelve el estado en una cookie. También manda un identificador único y un autenticador. La respuesta aceptable debe verificarse con la clave de servidor a cliente y corresponder a un identificador todavía pendiente. Las cookies nuevas pueden volver protegidas, con lo que se renueva la reserva sin ligar fácilmente las apariciones sucesivas del cliente.

Por tanto, NTS demuestra una proposición concreta: el mensaje procede de la parte asociada a las claves, no fue alterado y contesta a una petición real. No demuestra que la fuente conserve UTC correctamente.

IANA asigna los tipos compartidos para identificador, cookie, marcador de cookie y autenticador con campos cifrados. Esa función permite que dos implementaciones lean la misma gramática; no convierte el registro en árbitro de relojes.

Identidad no significa exactitud

El certificado verifica el servicio NTS-KE, no su oscilador. La cookie recupera parámetros de autenticación, no una garantía de hora. El identificador enlaza solicitud y respuesta, pero no mide la simetría de la red.

RFC 8915 describe el límite mediante el ataque de retardo. Un adversario en ruta puede demorar de modo desigual los dos sentidos sin cambiar el contenido. Los controles criptográficos siguen siendo correctos y el cálculo del desfase puede ser erróneo. La criptografía no puede corregir una variable física que no está dentro del mensaje protegido. La distancia máxima limita el daño, y varias fuentes o caminos reducen la exposición cuando no comparten el mismo punto de control.

Tampoco hay confidencialidad absoluta. La cabecera básica NTP queda a la vista; NTS puede cifrar campos de extensión. La disponibilidad sigue fuera de la promesa: es posible descartar paquetes y algunas respuestas Kiss-o’-Death no están autenticadas.

De ahí la regla contra la degradación automática. Si un fallo de NTS-KE hiciera que el cliente pasase sin intervención a NTP abierto, un atacante podría inducir esa caída. El cambio de nivel es una decisión expresa del operador.

El problema de arrancar con una hora dudosa

Los certificados X.509 tienen fechas de validez. La máquina que busca hora porque desconfía de su reloj necesita, sin embargo, una aproximación para validar el certificado del servicio. No existe una solución universal que borre el círculo.

RFC 8915 contempla reloj con batería, hora introducida a mano, último valor persistido y comparación entre fuentes. También recomienda comprobar que una respuesta inmediata a NTS-KE sea compatible con el intervalo del certificado. Son límites de plausibilidad, no una fuente exacta de UTC.

El operador ya está asignando autoridad: qué raíces acepta, cuánto puede envejecer la hora guardada, en qué condiciones se relaja la fecha del certificado y cuántos testigos exige antes de actuar. Si no lo documenta, la respuesta queda alojada en la configuración predeterminada.

Autenticar es el principio de la selección

RFC 5905 mantiene una cadena local. El procesamiento produce mediciones; el filtro reduce ruido por asociación; la selección busca una intersección con respaldo mayoritario; el agrupamiento aparta valores extremos; la combinación calcula un desfase final; y la disciplina dirige fase y frecuencia del reloj.

NTS mejora la entrada. Descarta falsificaciones y repeticiones antes de que se conviertan en observaciones. No sustituye los pasos siguientes. Una fuente autenticada puede ser falsa en términos temporales. Una medición puede superar límites de retardo o distancia. Sin supervivientes suficientes, el sistema debe conservar el estado de no sincronizado.

La documentación actual de chrony conserva esa separación. authdata informa del modo de autenticación, establecimientos de claves, intentos, respuestas negativas y cookies disponibles. Otros informes explican alcance, desacuerdo y selección. maxdelay y pruebas relacionadas rechazan retardos; minsources puede impedir la actualización hasta que haya varias fuentes seleccionables. Las opciones de confianza y requisito deciden el peso de fuentes autenticadas y abiertas.

NTPsec presenta controles distintos para certificados, servidor, cliente y claves de cookies. Las decisiones de producto difieren porque el estándar fija interoperabilidad, no una única política operativa.

El expediente de las cuatro pruebas

La prueba de identidad registra el nombre NTS-KE configurado, cadena, identidad de servicio, conjunto de confianza y momento del intercambio.

La prueba de paquete registra generación de claves, identificador, cookies, autenticador, solicitud asociada y tratamiento de repeticiones o respuestas negativas.

La prueba de medición registra desfase, retardo, dispersión, distancia raíz, alcance, historia, intersección y condición de valor discordante. Aquí una respuesta auténtica puede dejar de ser útil.

La prueba de actuación registra fuente o combinación elegida, umbral que permitió corregir gradualmente o saltar, proceso responsable y estado anterior. Aquí reside la autoridad sobre la máquina.

Conservar sólo «NTS sí» prueba que se empleó un mecanismo. No prueba por qué cambió el reloj.

Regla común mínima y decisión propia

La Especificación Inicial Mínima de Heng Lu propone que la capa compartida contenga únicamente reglas deterministas necesarias para interoperabilidad, seguridad y validación local. Las decisiones posteriores pertenecen a quienes ejecutan el sistema. Publicar una regla no la vuelve realidad operativa, y una sintaxis común no da poder permanente sobre participantes independientes.

NTS respeta ese diseño si se lee con precisión. IETF define intercambio, derivación de claves, cookies y comprobaciones. IANA registra números. La autoridad certificadora interviene en la identidad del extremo. Ninguna selecciona las fuentes del cliente, decide su distancia máxima, valida su hora aproximada de arranque ni ordena una llamada del sistema para cambiar el reloj.

La Primacía del Código en Ejecución añade la prueba práctica: la norma importa porque cada participante puede implementar y verificar por sí mismo. El cliente puede aceptar el paquete y rechazar la medición. Puede confiar en la identidad y negar el salto. Esa separación es una propiedad de seguridad.

Fuentes y alcance

Los 800 milisegundos son un ejemplo. No describen proveedor, fallo, incidente ni ataque. Fuentes congeladas: