Resumen

  • RFC 9965 usa eap.arpa para que un par EAP pida una forma definida de aprovisionamiento y conectividad limitada, aún no autenticada.
  • El EPI no sustituye las pruebas del servidor, la contención de red, la decisión de credenciales ni la autorización posterior.

Hay una diferencia decisiva entre pedir una puerta provisional y tener derecho a atravesar el edificio. RFC 9965 conserva esa diferencia en el lenguaje de EAP. El EAP Provisioning Identifier es un NAI bajo eap.arpa. que permite expresar qué clase de aprovisionamiento solicita un par que todavía no dispone de credenciales normales.

El nombre se diseña para no pertenecer a una organización existente. No debe ser encaminado automáticamente por los mecanismos AAA ordinarios ni devolver descubrimiento dinámico. Sin embargo, cada organización puede decidir si encamina ese tráfico y cómo lo trata. Por eso la cadena correcta empieza con una solicitud, no con una identidad: el protocolo hace comprensible la intención; un operador local conserva la decisión sobre ruta, servidor y política.

Un registro de identidad EAP que contiene un EPI sólo demuestra ese mensaje. No demuestra que el par sea un dispositivo conocido, que exista una ruta AAA correcta, que un servidor haya respondido o que la autenticación termine con éxito. RFC 3748 también separa autenticación y acceso: incluso un par autenticado puede ser rechazado por política, por límites de sesión o por otros motivos. Convertir el identificador en un estado de “confiable” borra precisamente esas decisiones posteriores.

RFC 9965 exige que los pares que usan un EPI sean tratados como no confiables hasta que se autentiquen. Si se acepta el método de aprovisionamiento, el par debe quedar en una red limitada —por ejemplo, un portal cautivo— que no permita acceso irrestricto. El control relevante no es un rótulo de portal: una red segura de aprovisionamiento permite sólo el tráfico previsto y bloquea lo demás. Una lista parcial de destinos prohibidos no ofrece el mismo límite ni la misma evidencia.

También hay un límite en la selección de método. El EPI señala el método solicitado; si el servidor EAP lo acepta, debe responder con el método asociado antes de seguir la máquina de estados EAP. Ese emparejamiento no certifica al par ni aprueba servicio. Cada método de aprovisionamiento debe especificar cómo autentica al servidor. RFC 9965 recomienda EAP basado en TLS para dar autenticación del servidor e integridad y confidencialidad durante el intercambio, pero una recomendación de protocolo no prueba la validación de un servidor concreto en una sesión concreta.

Para evitar la compresión de evidencia, conserve por separado el EPI, el encaminamiento local, el método elegido, el resultado de autenticación de servidor, la regla de red limitada aplicada, la decisión de credencial y el resultado de acceso posterior. Esa secuencia permite ofrecer una ruta de recuperación a un par desconocido sin inventar de antemano una autorización que pertenece a otra capa.