Resumen

  • RFC 5422 recomienda no habilitar el acceso al final del modo Server-Unauthenticated; el modo Server-Authenticated permite concederlo según la política del servidor.
  • El acuse del Tunnel PAC comunica lo que el par declara sobre su procesamiento y almacenamiento; no prueba una autenticación posterior ni la admisión.

El inicio tiene otro punto de llegada

Un dispositivo puede presentarse sin secreto compartido, raíz de confianza del servidor ni Protected Access Credential. RFC 5422 explica cómo EAP-FAST puede entregar esos datos dentro de la conexión. La pregunta de control es más estrecha: ¿el intercambio preparó al dispositivo o también lo admitió en la red? El texto conserva ambas respuestas en carriles distintos.

EAP-FAST combina una primera fase TLS con una segunda fase de autenticación interna. RFC 5422 define un modo con autenticación del servidor y otro sin ella. En el modo autenticado, el par valida al servidor durante la negociación TLS; para hacerlo ya necesita una raíz o credencial confiable. El modo no autenticado usa un túnel anónimo Diffie–Hellman para iniciar el aprovisionamiento cuando ese material todavía falta. Ese túnel no identifica al servidor.

Por eso la fase anónima no elimina la autenticación. El cliente y el servidor deben completar dentro del túnel un método EAP que los autentique mutuamente y derive claves. El cliente valida entonces el Crypto-Binding TLV para comprobar que la fase interior está vinculada a la integridad del túnel TLS y detectar una posible intermediación activa. La versión de 2009 exigía que las implementaciones de este modo admitieran EAP-FAST-MSCHAPv2 como método de autenticación interna. Si se ignora el vínculo criptográfico entre fases, el éxito de la autenticación interior pierde parte de su valor. (RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

Después de autenticar y validar el vínculo, el servidor puede entregar un Tunnel PAC —con PAC-Key y PAC-Opaque— o raíces de confianza del servidor. El Tunnel PAC permite establecer un futuro túnel EAP-FAST; no concede por sí mismo acceso a los recursos.

El acuse PAC-Acknowledgement tiene un alcance concreto: el par informa del resultado de procesar y guardar un Tunnel PAC recién provisionado. No se usa para los demás tipos de PAC. El servidor recibe una declaración de almacenamiento, no una prueba de que una autenticación posterior vaya a funcionar, que la política autorice el acceso o que el tráfico llegue a la aplicación. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

RFC 5422 lo dice expresamente: al final del aprovisionamiento no autenticado, NO SE DEBERÍA conceder acceso a la red, porque el intercambio solo tiene fines de aprovisionamiento. La política del par puede cerrar esa conexión e iniciar después otro intercambio EAP-FAST con la información recibida. El modo con autenticación del servidor sí permite que el servidor conceda acceso tras un aprovisionamiento satisfactorio. “Aprovisionamiento completado” no significa lo mismo en ambos modos. (RFC 5422 §3.5)

La elección trae costos diferentes. La autenticación del servidor ofrece mayor protección contra un intermediario, pero requiere confianza preinstalada. El modo anónimo reduce la fricción de arranque y puede facilitar el aprovisionamiento sin intervención, pero RFC 5422 describe una mayor exposición a ataques de diccionario fuera de línea. También recomienda limitar intentos en línea y restringir cuándo o dónde se usa este modo. Son límites expuestos en un documento Informativo de 2009, no datos de prevalencia actual. (RFC 5422 §§6.1–6.3)

Un registro operativo debe conservar por separado el modo, el resultado de autenticación interior y Crypto-Binding, el tipo y vencimiento de la credencial, el acuse del Tunnel PAC, la autenticación posterior y la decisión de acceso. Si el equipo de aprovisionamiento no controla la admisión, ambos necesitan un identificador de correlación y un responsable de investigar los casos sin segundo intercambio. Ningún evento inicial completa esa decisión por sí solo.

Un resultado interno satisfactorio aún puede terminar en denegación

La sección 3.5 deja la decisión de acceso en manos de la política del servidor incluso después de completar el aprovisionamiento. En el modo Server-Authenticated, el servidor puede conceder acceso tras autenticar al par y entregarle un Tunnel PAC. En Server-Unauthenticated, NO SE DEBERÍA conceder acceso al terminar: esa conversación solo prepara credenciales. El mecanismo de entrega puede parecer parecido, pero los resultados de autorización son distintos.

Un Result TLV satisfactorio no decide por sí mismo si el par entra en la red. La autenticación interna puede concluir correctamente y, aun así, el servidor considerar que su política no se cumplió y terminar con EAP Failure. Cuando la conversación no tiene por objeto dar acceso, RFC 5422 prohíbe concederlo o entregar claves de sesión al Network Access Server. Por eso un panel que solo cuenta el éxito del método interno puede mostrar verde mientras la red niega legítimamente la entrada. El seguimiento debe llegar al resultado EAP final y a cualquier entrega de claves, no detenerse en el primer indicador positivo.

(RFC 5422 §3.5; RFC 4851 §4.2.2)

El acuse cubre un momento, no toda la vida de la credencial

Un Tunnel PAC contiene componentes distintos. El PAC-Key es un secreto de 32 octetos para establecer el túnel de fase 1. El PAC-Opaque, específico del servidor que lo emite, vuelve a presentarse al servidor. PAC-Info puede identificar al emisor y llevar una vigencia. RFC 4851 exige proteger el PAC-Key; RFC 5422 recuerda que tanto el par como el servidor deben custodiar de forma segura su parte. La entrega crea obligaciones posteriores de almacenamiento, caducidad y renovación.

El PAC-Acknowledgement tiene un alcance mucho más estrecho: el par lo envía para un Tunnel PAC recién provisionado y comunica el resultado de procesarlo y guardarlo. El valor es éxito o fallo. El éxito registra lo que declaró el par en ese momento; no demuestra que un túnel futuro pueda establecerse, que el secreto siga protegido ni que la política vaya a autorizar la red. La autenticación EAP-FAST posterior es la que prueba el material en un nuevo contexto. Ni siquiera ese resultado demuestra por sí solo que una aplicación recibió tráfico. (RFC 5422 §§4.2.2–4.2.5, 6.8; RFC 4851 §3.2.2)

Una denegación también puede interrumpir el servicio

La separación tiene un coste de disponibilidad. RFC 5422 advierte que un EAP Failure tras denegar el acceso puede provocar una desasociación Wi-Fi completa. El par o el servidor puede intentar una renegociación TLS para aprovechar la credencial nueva en otra autenticación sin reiniciar todo el proceso, pero cualquiera de los dos puede rechazarla. La política normal de acceso solo entra después de que funcione esa autenticación posterior. Por ello conviene medir quién vuelve, quién es denegado y si la recuperación usó reinicio o renegociación.

De lo contrario, una denegación prevista parece un fallo de aprovisionamiento o un contador de altas exitosas oculta dispositivos sin acceso. (RFC 5422 §3.5)

Fuentes