Resumen

  • El contador de coherencia de doce bits de RFC 3078 permitía detectar una pérdida o ruptura de secuencia. No reconstruía el texto cifrado ausente ni demostraba que la aplicación hubiera recibido todos sus datos.
  • El modo sin estado podía adelantar la clave hasta el valor observado. El modo con estado obligaba a descartar, enviar un CCP Reset-Request y esperar un paquete FLUSHED antes de confiar otra vez en las tablas de cifrado.

La evidencia llegó dentro de un paquete que había que tirar

El receptor esperaba un número y recibió otro. El encabezado de MPPE acababa de revelar una discontinuidad, pero el contenido del mismo paquete podía haber sido cifrado con un estado que el receptor ya no compartía. En el modo con estado, saber que el flujo había avanzado no bastaba para descifrarlo.

RFC 3078 ordenaba abandonar ese paquete, emitir un Reset-Request de CCP sin datos y descartar silenciosamente lo que llegara después hasta ver FLUSHED. Al recibir la petición, el emisor reiniciaba sus tablas RC4 y marcaba el siguiente paquete. No hacía falta un Reset-Ack: el cambio observable del emisor cerraba la transición.

La secuencia separaba tres hechos. El contador probaba que la historia local estaba incompleta. El paquete FLUSHED permitía restablecer un estado común. Ninguno de los dos devolvía el contenido perdido ni acreditaba el resultado de la aplicación.

Antes del primer paquete había una cadena de decisiones

RFC 3078 apareció en marzo de 2001 como documento informativo. Describía Microsoft Point-to-Point Encryption sobre PPP y actualizaba el uso de la opción vinculada a MPPC de RFC 2118. No era un estándar de Internet.

Los pares negociaban MPPE mediante la opción 18 del Compression Control Protocol. El iniciador ofrecía sus alternativas y el receptor debía normalmente escoger una sola: 128, 56 o 40 bits. Un bit separado solicitaba el modo sin estado. Si nadie intentaba negociar MPPE, no había cifrado por defecto. Si lo intentaban y fracasaban, el enlace debía terminarse en vez de continuar como si la protección existiera.

PPP tenía que alcanzar la fase de protocolos de red y CCP el estado Opened antes de transmitir datos MPPE. Esa condición rompe varias equivalencias cómodas. Una autenticación correcta no abría CCP. Recibir una clave no seleccionaba un modo. Anunciar 128 bits no probaba que el otro extremo los aceptara. Una regla administrativa que exigiera cifrado no cifraba el primer paquete.

La documentación repartía expresamente la responsabilidad. RFC 2548 cubría el transporte RADIUS de claves MPPE distintas por dirección. RFC 3079 detallaba derivaciones de claves. RFC 1962 definía la negociación y los resets de CCP. RFC 1661 describía las fases de PPP. RFC 3078 gobernaba el estado de los paquetes cifrados en circulación.

El contador recordaba posición, no contenido

El campo de doce bits aumentaba una unidad por paquete y volvía a cero después de 4095. Compararlo con la expectativa local permitía reconocer huecos, orden incorrecto y la distancia que debía recorrer la evolución de clave.

La cifra no llevaba una copia del paquete ausente. Tampoco autenticaba la causa. Una cola, un filtro, una ruta, un reordenamiento o una modificación activa podían producir observaciones parecidas. Incluso una serie continua solo decía que el monitor había visto una secuencia compatible; no que cada texto claro hubiera llegado a la aplicación.

El RFC decía que MPPE no necesitaba un enlace fiable y que añadir la transmisión fiable de RFC 1663 normalmente aportaba sobrecarga innecesaria para sincronizar. No prometía fiabilidad de servicio. La máquina criptográfica sabía cómo reaccionar a una pérdida; el protocolo superior seguía teniendo que afrontar los bytes ausentes.

Además, solo cierto intervalo de protocolos PPP se cifraba. Otros paquetes evitaban el procesador MPPE. El bit de datos cifrados describía el tratamiento pretendido, pero no estaba autenticado. Por eso un inventario de paquetes con apariencia MPPE no reemplazaba el registro de negociación y descifrado.

El modo sin estado reconstruía el punto de la clave

En el modo sin estado, la clave cambiaba en cada variación del contador. El emisor avanzaba antes de cifrar; el receptor, después de leer el nuevo valor y antes de descifrar. Todos los paquetes cifrados llevaban FLUSHED.

Si el último contador observado era dos y el nuevo era cinco, el receptor ejecutaba tres cambios de clave. Así alcanzaba el estado que el emisor había usado para el paquete cinco sin pedir un reset. Los paquetes tres y cuatro, no obstante, seguían perdidos.

“Sin estado” no quería decir “sin memoria”. Ambos extremos necesitaban la clave inicial, el mismo algoritmo de cambio, la semántica del contador y el modo común. La recuperación era local porque cada paquete aportaba una frontera utilizable, no porque el contrato compartido desapareciera.

El modo con estado necesitaba el camino de vuelta

Con estado, la clave cambiaba en los paquetes cuyo octeto bajo del contador valía 0xFF. Si desaparecía ese paquete de bandera, el emisor avanzaba y el receptor no. La siguiente observación podía denunciar el desfase sin ofrecer un texto descifrable.

El Reset-Request convertía el camino de retorno en parte de la recuperación del tráfico de ida. Una captura unidireccional podía ver el hueco o el posterior FLUSHED, pero no demostrar quién pidió el reinicio. Una captura de la petición tampoco demostraba que regresara un paquete válido. La recepción del primer texto claro posterior era una prueba adicional.

RFC 3078 advirtió que la reinicialización con estado podía reutilizar una clave para dos paquetes y desaconsejó ese modo en redes con pérdidas, como túneles de capa dos sobre Internet. La afirmación tenía un alcance preciso. No era una estadística de despliegue ni un informe de fallos de producto.

La negociación estaba expuesta antes de proteger datos

La negociación MPPE no tenía integridad. Un atacante activo podía cambiar los bits de Supported Bits y alterar la fuerza aparente. Una configuración que rechazara opciones inaceptables limitaba el daño, pero no autenticaba el intercambio.

También era posible modificar el contador para desincronizar a los pares o invertir el bit de datos cifrados para provocar denegación de servicio. El encabezado constituía, por tanto, una entrada a la máquina de estado, no un certificado fiable de lo ocurrido.

La presencia de RC4 exige evitar el anacronismo. RFC 4345 propuso después modos Arcfour mejorados para SSH. Ese texto recuerda que una longitud nominal no agota el análisis de seguridad, pero no transfiere sus propiedades a MPPE ni demuestra una migración.

Un recibo útil sigue todas las fronteras

Hay que conservar la sesión PPP, los pares, el resultado de autenticación, la procedencia y generación de la clave sin registrar el secreto, la secuencia CCP, la fuerza y el modo elegidos y el instante de Opened. Por dirección deben quedar el contador esperado y recibido, el retorno después de 4095, los huecos, FLUSHED, las fronteras 0xFF, los descartes, las peticiones de reset y el primer descifrado correcto.

Después viene la aplicación: su secuencia, retransmisión, acuse y resultado. Restaurar RC4 no recuperaba por sí solo el mensaje que faltaba.

La lectura de Lu Heng sobre capas de realidad evita convertir una señal en autoridad total. Autenticar, derivar una clave, transportarla, negociar, observar un paquete, detectar la pérdida, restablecer el estado, descifrar y entregar son transiciones distintas. El código en ejecución debe demostrar cada unión.

Fuentes