Resumen

  • RFC 5421 documenta EAP-FAST-GTC con el tipo 6, ya asignado a EAP-GTC, para un intercambio interno diferente que viaja por el túnel.
  • Las prohibiciones dentro/fuera del túnel y la advertencia de compatibilidad del IESG hacen del contexto EAP-FAST parte de la identidad del método; es una implicación de implementación, no evidencia de una interrupción medida.

El número no cuenta toda la historia

El campo Type de EAP ocupa un solo octeto, pero determina cómo se procesa un paquete. RFC 3748 explica que identifica el método y que las capas EAP distribuyen los paquetes según ese valor, de forma parecida a un puerto de transporte. Si un componente ve el tipo 6, la lectura inmediata es Generic Token Card.

RFC 5421 añade un contexto que esa lectura aislada no contiene. El memorando Informational de 2009 describe EAP-FAST-GTC, un método interno para un intercambio básico de contraseña. Entre sus usos previstos están las bases de contraseñas heredadas, el cambio de contraseña y los códigos de un solo uso. Por razones históricas, el método reutiliza el código asignado originalmente a EAP-GTC. El registro de IANA todavía llama «Generic Token Card» al tipo 6: RFC 5421 no creó una segunda asignación global.

La diferencia está en el marco y en el formato. EAP-FAST establece un túnel TLS; durante la fase interna, los paquetes EAP se encapsulan en TLV EAP Payload. RFC 5421 advierte que el formato EAP-FAST-GTC es específico del túnel y puede no ser compatible con los mecanismos EAP-GTC que se usan fuera de él. Por eso establece dos reglas complementarias: EAP-FAST-GTC NO DEBE usarse fuera de un túnel EAP-FAST y EAP-GTC NO DEBE usarse dentro.

Las reglas también indican qué significa Type 6 en cada contexto. Si el distribuidor conserva el octeto Type pero pierde si el paquete procede del intercambio exterior o de la fase interna EAP-FAST, descarta información que el protocolo necesita para diferenciar los métodos. Esa es una implicación para quien implementa el sistema, no la afirmación de que los sistemas actuales hayan cometido el error.

La nota de compatibilidad no fue implícita

La nota del IESG en RFC 5421 declara que reutilizar códigos EAP ya asignados es incompatible con la negociación de métodos de RFC 3748. Como EAP-GTC no admite negociación de versiones propia del método, dentro del túnel se presupone que Type 6 significa EAP-FAST-GTC. La nota advierte que esto puede crear problemas cuando una implementación también necesita admitir el EAP-GTC de otro proveedor; mantener el mismo código dentro y fuera del túnel añade casos especiales.

El texto afirma que un código Type único habría evitado la dificultad y pide que los tipos asignados no vuelvan a reutilizarse con significados distintos en métodos futuros dentro de túneles.

El alcance importa: el RFC no concluye que todas las negociaciones fallen, que el tipo 6 haya sido revocado ni que un producto concreto presente un defecto. Registra un coste de compatibilidad derivado de dar al código un significado que depende del contexto. El registro publica la denominación global; las reglas del túnel delimitan el uso interno; la nota del IESG expone la fricción entre ambos.

La primacía del código en ejecución ofrece un marco editorial útil: una entrada de registro no constituye por sí sola el sistema. El resultado depende también del código que recibe el paquete, identifica su capa y selecciona el método. La Nota 65 de Heng Lu inspira esta lectura; no prueba requisitos de EAP ni conductas de proveedores.

La protección de credenciales es otro límite

RFC 5421 también señala que EAP-FAST-GTC transporta contraseñas como cadenas en claro dentro del túnel TLS cifrado. El interlocutor debe autenticar al servidor antes de entregar las credenciales. EAP-FAST-GTC NO DEBE usarse en Server-Unauthenticated Provisioning Mode, porque ese modo no autentica el servidor. Es un requisito de seguridad importante, pero separado del problema del Type: cifrar el canal no resuelve la selección de método, y elegir bien el método no demuestra por sí mismo que se autenticó al servidor.

Para los operadores, la revisión debe centrarse en la frontera: ¿dónde decide el sistema si el tipo 6 corresponde a EAP-GTC o a EAP-FAST-GTC? La fase del túnel debería acompañar al Type, y las prohibiciones recíprocas deberían hacerse cumplir. Las pruebas pueden comprobar GTC fuera y FAST-GTC dentro, además de rechazar cada uno en el contexto contrario. Son prácticas de verificación propuestas, no requisitos nuevos.

RFC 5421 es Informational. Las fuentes públicas consultadas no permiten determinar prevalencia actual, comportamiento de proveedores o incidentes. Su enseñanza es más acotada: cuando un código se reutiliza dentro de un túnel, el marco del paquete se convierte en contexto operativo que el distribuidor no debería descartar.

Fuentes