Resumen

  • RFC 8915 exige que cada solicitud protegida por NTS incluya un único identificador generado por un CSPRNG, con un cuerpo de al menos 32 octetos; la respuesta copia exactamente ese valor.
  • El cliente solo procesa el paquete si el valor coincide con una solicitud aún pendiente y la autenticación con su clave servidor-a-cliente también es válida.
  • La prueba detecta repeticiones y correlaciona un intercambio; no identifica de forma duradera a una cuenta, persona o equipo, no es la cookie NTS y no certifica que la hora sea correcta.

Una ficha que caduca con la pregunta

Supongamos que llegan dos respuestas NTP bien formadas. Una acaba de ser producida para la consulta abierta; la otra fue capturada cuando era válida y reaparece después. Verificar una firma o etiqueta de autenticación demuestra una propiedad importante del paquete, pero no basta para decidir a qué pregunta pendiente responde.

RFC 8915 añade una ficha creada por el cliente. Cada solicitud protegida lleva exactamente un campo Unique Identifier. Su cuerpo debe salir de un generador aleatorio criptográficamente seguro y medir al menos 32 octetos. El servidor que valida la solicitud incluye exactamente un campo equivalente en su respuesta y repite la misma secuencia de octetos.

El cliente no elige entre dos pruebas: exige ambas. El identificador debe coincidir con una solicitud que siga pendiente y el paquete debe autenticarse con la clave S2C asociada a ella. Si falla cualquiera de las comprobaciones, se descarta sin más procesamiento. Una respuesta auténtica del pasado no puede ocupar el lugar de la respuesta esperada ahora.

El identificador viaja sin cifrar, pero no viaja sin protección. La norma obliga a autenticarlo. Forma parte de los datos cuya integridad cubre AEAD aunque no esté dentro del texto cifrado. Quien observa el tráfico puede verlo, pero no sustituirlo y recomponer una respuesta aceptable sin la clave correspondiente. Visibilidad no equivale a capacidad de modificación.

El nombre cobra así su medida exacta: identifica la operación abierta ante el propio cliente. No lo entrega el servidor como número de sesión, no se convierte en credencial ni dice qué ser humano o dispositivo inició el paquete. Su vida probatoria acaba cuando la solicitud se resuelve o expira.

El límite criptográfico del reloj

NTP ya devolvía un dato de la solicitud. RFC 5905 define el Origin Timestamp de 64 bits como el instante, según el cliente, en que partió el mensaje. La comparación con el estado de transmisión ayuda a detectar paquetes falsos, duplicados o repetidos.

RFC 8915 explica por qué no conviene tratar ese reloj como reto criptográfico. Sesenta y cuatro bits constituyen un espacio menor y, según cómo se construya la marca temporal, gran parte puede ser predecible. El tiempo aporta orden y cálculo de demora; no garantiza sorpresa frente a un adversario.

El nuevo campo desacopla las dos tareas. Tiene un cuerpo de 32 octetos como mínimo y exige una fuente aleatoria segura. Eso proporciona longitud, imprevisibilidad y resistencia a colisiones más apropiadas para detectar repeticiones. Pero RFC 4086 impide convertir la longitud en una afirmación automática sobre entropía: una salida estadísticamente convincente puede nacer de un estado pequeño y adivinable. Hay que observar también la siembra y la salud del generador.

La norma permite usar este campo sin NTS para ayudar contra paquetes falsificados por atacantes fuera del camino. Dentro de NTS, la conclusión más fuerte depende del par completo. El eco aleatorio enlaza la respuesta con la consulta; la autenticación S2C enlaza el paquete con el contexto criptográfico. Cada comprobación tiene un objeto distinto.

No confundir certificado, cookie y eco

NTS-KE ocurre primero sobre TLS. Allí se realiza la autenticación inicial del servidor, se negocian opciones y se extraen claves. La conexión TLS se cierra después. El identificador de una solicitud NTP posterior no repite esa identidad ni sustituye al certificado.

La cookie NTS lleva otro recibo. Contiene estado de asociación opaco que el cliente devuelve para que el servidor recupere el algoritmo AEAD y las claves de ambos sentidos sin mantener estado por cliente. Un artículo anterior de Sofia Ren sobre Dieter Sibold se ocupó precisamente de esa frontera tras el cierre de TLS. La cookie permite reconstruir contexto; el Unique Identifier permite saber qué respuesta corresponde a qué solicitud pendiente.

El autenticador completa el tercer papel. En la solicitud, cookie e identificador son autenticados y no cifrados. En la respuesta, el identificador continúa visible mientras que las cookies nuevas van cifradas y autenticadas. La diferencia no es decorativa: evita atribuir confidencialidad, persistencia o identidad al objeto equivocado.

También delimita la lectura de privacidad. Un identificador estable serviría para unir actividades a lo largo del tiempo. Este valor debe ser fresco e impredecible por solicitud. Reutilizarlo, generar colisiones o guardarlo sin límite podría crear riesgos, pero serían fallos de generación o de operación, no el propósito que define RFC 8915.

Un paquete actual no hace verdadero al reloj

La protección contra repetición impide que una vieja respuesta protegida satisfaga una consulta nueva. No prueba todos los componentes de la hora. RFC 7384 separa repetición, manipulación, suplantación, alteración de la demora y ataque a la fuente externa del reloj maestro. Un servidor puede emitir un paquete auténtico y reciente mientras su referencia está equivocada; una ruta también puede introducir una demora maliciosa.

Por eso RFC 8633 recomienda suficientes fuentes, diversidad y vigilancia de desacuerdos. Con una única fuente, su error pasa directamente al cliente. El resguardo de NTS afirma «esta respuesta protegida corresponde a esta solicitud abierta». La exactitud requiere otros recibos.

Fuentes