Resumen

  • Las claves maestras de RFC 3079 eran entradas para otra derivación. Sólo las claves transitorias separadas por rol y sentido inicializaban los contextos RC4 de envío y recepción.
  • Un cálculo conforme probaba una relación entre entradas y salidas; no probaba que ambos pares usaran la misma primera autenticación, cruzaran bien envío y recepción, negociaran la misma fuerza MPPE o entregaran datos útiles.

Una clave intermedia con un nombre absoluto

El límite aparece escrito sin rodeos: las claves maestras nunca cifran ni descifran datos. En MS-CHAP-2, el doble hash de la contraseña y el NT-Response producían primero un valor maestro. GetAsymmetricStartKey escogía después una rama según dos preguntas: si la clave era de envío y si el extremo local era el servidor. GetNewKeyFromSHA generaba por último la clave transitoria que entraba en la tabla RC4 correspondiente.

Por eso un registro «master key derivada» terminaba antes de la parte decisiva. No decía qué rama se tomó, en qué dirección se instaló la salida ni si el otro extremo eligió la rama complementaria. Dos implementaciones podían acertar por separado y fracasar juntas.

RFC 3079, publicado en marzo de 2001 como documento informativo, pretendía ofrecer una referencia abierta para interoperar con productos Microsoft. No definía la negociación CCP, los paquetes MPPE ni la evolución de claves durante la sesión: eso pertenecía a RFC 3078. Tampoco era una norma de Internet ni acreditaba adopción.

Tres linajes que no se vuelven equivalentes

MS-CHAP-1 generaba los modos de 40 y 56 bits desde el hash LAN Manager y el de 128 bits desde el hash Windows NT y el desafío. MS-CHAP-2 usaba el linaje Windows NT y el NT-Response para las tres fuerzas. EAP-TLS partía de material exportado por TLS.

El destino común, MPPE, no borraba el origen. La evidencia debía conservar la familia de autenticación, el par que inició la llamada, el primer intercambio seleccionado, los desafíos o la generación TLS y el enlace de destino. Ocho octetos podían representar 40 o 56 bits efectivos; dieciséis octetos podían proceder de sesiones distintas.

RFC 2759 definía Peer-Challenge, Authenticator-Challenge, ChallengeHash, NT-Response y AuthenticatorResponse. RFC 2433 aportaba el procedimiento anterior, y RFC 2716 situaba EAP-TLS dentro de PPP. Cada uno fijaba entradas, no demostraba que CCP llegara después a Opened.

La primera autenticación era estado operativo

Las claves iniciales de ambos sentidos se derivaban de las credenciales del par que inició la llamada. Si intervenía un desafío, debía ser el de la primera autenticación. La regla seguía vigente con autenticación bilateral y en cada enlace de un conjunto multilink.

Esa palabra —primera— obliga a retener historia. Un servicio de identidad puede guardar sólo el último éxito; un coordinador de enlaces puede conservar usuario y sesión sin el desafío original; un chasis de respaldo puede recibir un estado «autenticado» sin la generación exacta. La misma fórmula, alimentada con la historia equivocada, produce de manera determinista la clave equivocada.

RFC 3079 dejó a las implementaciones la responsabilidad de generar las claves correctas en todos los equipos de un multilink multichasis. El algoritmo no replicaba el linaje. La identidad real de la sesión incluía evento de autenticación, rol, miembro del conjunto y generación.

Enviar en A era recibir en B

Las etiquetas fijas de GetAsymmetricStartKey cruzaban los extremos: el envío del servidor correspondía a la recepción del cliente y viceversa. En EAP-TLS, el RFC lo expresó directamente: la clave de envío de un lado es la clave de recepción del otro.

send_key no era, por tanto, un atributo que pudiera copiarse al campo homónimo del par. El nombre era local; la relación era bilateral. El recibo correcto debe unir identidad de los extremos, rol, dirección local, dirección remota, generación de credenciales y huellas de las claves transitorias, sin registrar los secretos.

La fuerza también se transformaba. Los modos de 40 y 56 bits usaban ocho octetos, pero el primero sobrescribía tres octetos con constantes y el segundo uno. El modo de 128 bits usaba dieciséis. EAP-TLS exigía rellenar por la izquierda valores cortos y truncar valores largos. Igual longitud final no implicaba igual procedencia.

Los vectores de prueba demostraban la aritmética. No demostraban la autenticación viva, el transporte seguro desde un servidor EAP separado ni la fuerza acordada. RFC 3079 incluso advertía que la clave inicial MS-CHAP-1 de 40 bits se repetía con las mismas credenciales y recomendaba evitarla. Es una advertencia histórica, no una aprobación moderna de RC4 o MS-CHAP.

Derivar no era prestar el servicio

RFC 3078 exigía fase Network-Layer Protocol y CCP Opened antes de transmitir MPPE. RFC 2548 trataba el transporte RADIUS de claves por dirección y la custodia introducida por proxies. RFC 1661 separaba las fases de PPP.

Así, autenticación no equivalía a entrega del secreto; entrega no equivalía a asociación con el enlace; asociación no equivalía a negociación; CCP Opened no equivalía a sincronía permanente; y descifrar un paquete no equivalía a un resultado de aplicación.

La lectura por capas de realidad de Lu Heng impide que palabras como «maestra», «autenticado» o «128 bits» sustituyan a las transiciones. El código en ejecución debe realizarlas y la evidencia debe conservarlas. La aportación duradera de RFC 3079 fue convertir el linaje en parte explícita de la interoperabilidad.

Fuentes