Resumen

  • El cookie es estado mutable y limitado a una sesión. Tras aceptar una extensión más larga, la forma corta deja de ser buena y la retransmisión debe usar el valor vigente en ese momento.
  • El cookie frena tráfico ciego, pero no autentica origen. AuthVal puede validar el segmento con una de varias claves durante una transición, mientras distribución, significado de KeyID y retiro son decisiones externas.

La copia fiel puede ser el reintento equivocado

Un transmisor guarda el segmento exacto que acaba de salir. Durante la larga espera, el receptor concatena aleatoriedad al cookie. Si vence un temporizador, volver a poner los bytes guardados en la cola parece prudente: nada de la carga cambió.

Sin embargo, RFC 5327 exige que la retransmisión contenga el cookie correcto en el instante del nuevo envío. Puede no ser el que era correcto en el original. La repetición conserva el objeto lógico, no necesariamente su envoltura de seguridad.

La evidencia debe guardar por separado el hash del contenido y el hash del segmento codificado, la versión de cookie de cada intento, la causa de la repetición y el resultado de los controles. Si solo existe un paquete original y un contador de reintentos, la historia se vuelve irrecuperable.

El receptor puede descartar silenciosamente una copia byte por byte y estar cumpliendo la norma. La forma corta fue válida, pero quedó revocada por la transición de prefijo. “Funcionó antes” no es prueba sobre el estado actual.

La validez depende de prefijo, memoria y reloj

Cualquiera de los motores puede introducir un cookie en cualquier momento. Tras una demora de comunicación aceptable, todos los segmentos de ambos sentidos deben llevar un valor bueno. Mientras la nueva información todavía podría estar viajando, la implementación admite una ventana limitada para segmentos sin cookie.

Ese intervalo no viene decidido por el paquete. Lo calcula la implementación con tiempo de propagación, oportunidad de contacto y política local. La misma ausencia puede ser legítima antes del umbral y motivo de descarte después.

Un motor puede ampliar el cookie concatenando bits. Un valor es bueno cuando comienza con el valor almacenado, o cuando es el primero observado. En cuanto se acepta una extensión, el predecesor corto deja de ser bueno. El sistema no mantiene una bolsa de tokens: mantiene una cadena monotónica.

Un registro defendible conserva predecesor, nueva longitud, actor, recepción, instante de obligatoriedad y primera aceptación. Guardar solo el último valor no permite auditar si la gracia se aplicó bien.

Dos cookies no caben en una sola casilla

Ambos extremos pueden crear un cookie inicial antes de recibir el del otro. Cuando el tráfico alcanza el nuevo estado, los segmentos posteriores incluyen dos extensiones, manejadas por separado, y ambas deben superar su control.

El segundo inicial también debe llegar dentro de una ventana finita. Pasado el punto en que el primer cookie ya debería estar presente en todo el tráfico, no cualquier valor puede presentarse como una segunda raíz legítima.

Esto exige representar dos cadenas, dos direcciones y dos plazos. La normalización a un único cookie_actual pierde la condición que permitió aceptar el segundo campo.

El mismo cuidado se aplica a extensiones repetidas. LTP permite varias ocurrencias de una etiqueta. Conservar solamente la última puede borrar la que verificó o la que causó el rechazo.

El silencio protege recursos y empobrece el diagnóstico

Cuando falta un cookie obligatorio o su prefijo es incorrecto, el receptor descarta sin responder. El atacante no recibe ayuda, pero el transmisor tampoco obtiene una razón.

Un timeout puede corresponder a cookie antiguo, actualización perdida, plazo mal calculado, multiplicidad mal formada, AuthVal inválido, extensión no soportada o contacto ausente. La falta de respuesta no autoriza a escoger uno.

La telemetría local debe separar estas causas, sin convertirlas en acusaciones sobre el par. El receptor sabe qué regla local falló; no sabe por ese hecho si hubo intención maliciosa. El transmisor sabe que no llegó la respuesta; no sabe dónde se perdió la cadena.

La reconstrucción necesita las dos cronologías, los planes de contacto y los hashes de cada envoltura.

El cookie no dice quién lo extendió

Una cadena difícil de adivinar aumenta el coste de una inyección ciega, pero no autentica a quien añadió bits. La advertencia central de RFC 5327 es concreta: sin autenticación de origen, un intermediario puede extender el cookie y bloquear al participante legítimo.

El bloqueo no requiere romper la regla. Después de aceptar el valor del atacante, el receptor considera obsoleto el valor corto del par. El automatismo correcto ejecuta un cambio no autorizado.

Cookie y AuthVal son controles complementarios. Uno compara estado temporal de la sesión; el otro verifica el segmento bajo un contexto criptográfico. Ninguno demuestra aprobación de aplicación, entrega Bundle, identidad institucional ni resultado final.

Además, el cookie no sobrevive a la sesión LTP. No es un registro duradero contra replays entre sesiones ni después de un reinicio.

Un AuthVal válido no resuelve qué clave manda

LTP-auth lleva una suite de ocho bits, un KeyID opcional y un AuthVal en el tráiler. KeyID se trata como octetos y su interpretación queda fuera de la especificación. El RFC tampoco distribuye secretos ni fija activación o retiro.

El primer segmento autenticado debe llevar el encabezado. Los posteriores pueden omitirlo, aunque conviene repetirlo cuando la capacidad lo permita. Si se retransmite el primer segmento, el encabezado debe estar presente otra vez.

Durante una actualización, el emisor puede proteger con clave vieja y nueva. El receptor busca las instancias y puede aceptar si una sola verifica. Es una regla útil de continuidad, pero un resultado agregado oculta si el tráfico depende todavía de la clave que debía desaparecer.

Registrar el AuthVal ganador, suite, KeyID, contexto y política es indispensable. Un candidato fallido junto a otro válido tampoco debe contarse automáticamente como ataque: puede ser el solapamiento previsto.

El registro de IANA no aprueba una postura

El documento asignó HMAC-SHA1-80, RSA-SHA256 y NULL. NULL utiliza una clave fija y proporciona una suma robusta, no autenticación; sigue expuesto a ataques activos. Un cálculo correcto con ese número no prueba identidad.

IANA registra valores. No garantiza adecuación actual, negociación, custodia ni buen ciclo de vida. RFC 5327 es Experimental y dejó la gestión de claves como investigación abierta. Toda implantación contemporánea necesita evidencia adicional.

Fuentes y alcance de evidencia

Las fuentes establecen reglas, asignaciones y estatus. No prueban despliegue, clave configurada, ataque, sesión, conformidad o resultado de aplicación.