Resumen

  • Un EAP Provisioning Identifier de RFC 9965 comunica qué método de aprovisionamiento solicita un par sin credenciales propias. Por ser público y predefinido, no acredita identidad, pertenencia ni derecho de acceso.
  • La red que acepta la solicitud debe mantener al par como no fiable: permitir solo el tráfico previsto, impedir comunicación entre pares y limitar tiempo, datos, servicios, reintentos y capacidad simultánea.
  • Un recibo de cierre del carril de aprovisionamiento debería unir la solicitud, la regla aplicada y la evidencia de retirada o caducidad. Es una propuesta editorial de Daniel Kade, no un requisito del IETF.

La regla que se retira importa más que la pantalla verde

El aprovisionamiento inicial contiene una paradoja. Para autenticarse, el dispositivo necesita una credencial; para obtenerla, quizá necesite conectividad. RFC 9965 acota esa excepción usando identificadores de aprovisionamiento EAP, o EPI, dentro del realm eap.arpa.

El par coloca un identificador predefinido en el formato NAI de RFC 7542. El servidor puede reconocer así la finalidad solicitada antes de conocer una identidad específica. El registro de IANA incluye @noob.eap.arpa para EAP-NOOB y portal@tls.eap.arpa para EAP-TLS.

La sencillez invita a una equivocación peligrosa: leer el EPI como si fuera una credencial. No lo es. Su valor está precisamente en que se conoce de antemano. No contiene una relación verificable con un comprador, una organización, un número de inventario o un propietario actual. Haber enviado correctamente la cadena solo demuestra capacidad para formular la petición.

El RFC exige que las implementaciones traten al par como no confiable. El servidor puede denegar el servicio por su política o capacidad. Si lo acepta, debe colocar al dispositivo en una red limitada, nunca en conectividad irrestricta. Así, el primer «éxito» significa únicamente que se autorizó un procedimiento estrecho.

Después llega el momento menos visible. El portal entrega un certificado o termina un paso de alta. El sistema de aprovisionamiento marca el caso como cerrado. Sin embargo, una ACL antigua puede seguir en el conmutador, una función de acceso puede conservar el rol temporal o un controlador puede haber ampliado el plazo. El dispositivo ya obtuvo lo que necesitaba, pero continúa disponiendo del camino más débil.

Cerrar ese camino no es limpieza posterior. Forma parte de la decisión original.

Un realm reservado no remite la autoridad a Internet

eap.arpa se parece a un dominio, aunque RFC 9965 distingue el realm usado en el NAI del dominio eap.arpa.. El nombre está anotado en el registro de dominios de uso especial de IANA, pero no debe resolverse mediante DNS ni emplearse fuera de EAP. Las consultas deberían producir NXDOMAIN.

La distinción evita convertir una señal local en descubrimiento dinámico de una autoridad. La red receptora decide si conoce el EPI, si admite el método y qué acceso restringido ofrecerá. No existe un tercero remoto que, por poseer el nombre, otorgue confianza al dispositivo.

También hay disciplina en los errores. Un EPI mal formado recibe EAP Failure. Un identificador desconocido o un método no válido para esa solicitud recibe EAP Nak de tipo cero. Con credenciales de aprovisionamiento no se permite negociar libremente otro método. La intención y el mecanismo deben permanecer unidos.

Ese control sintáctico tiene un ámbito concreto. La revisión del registro puede comprobar que el identificador es único y que remite a un método documentado. No puede decidir que el equipo situado hoy en una oficina determinada pertenezca a quien dice pertenecer. El IETF normaliza el carril; IANA mantiene su señalización; el operador administra la exposición; la organización propietaria decide a quién inscribir. Confundir estos mandatos convierte interoperabilidad en autorización ficticia.

Lo limitado se escribe como lista positiva

Una red no queda restringida porque una consola la llame «onboarding». RFC 9965 formula una regla más verificable: se permite únicamente el tráfico esperado y se bloquea todo lo demás. Bloquear solo algunos destinos considerados malos deja canales inesperados, incluido el transporte encubierto por servicios auxiliares.

Por eso la prueba debe bajar hasta el mecanismo real. Hace falta identificar la versión del filtro, VLAN, rol o ACL, el punto donde se aplicó y las combinaciones de destino, puerto y protocolo permitidas. Los servicios necesarios para validar certificados, resolver nombres o mantener la hora deben quedar explícitos. La regla por defecto tiene que ser denegar.

El RFC distribuye la restricción en varios presupuestos:

  • El tiempo normal de aprovisionamiento se mide en segundos o decenas de segundos; una duración larga puede indicar un problema.
  • El volumen de datos debe ser pequeño y tener un techo.
  • Los servicios accesibles deben limitarse a los necesarios.
  • Los intentos necesitan limitación de frecuencia, con posibilidad de bloquear a quien se comporte mal.
  • La cantidad total de pares aprovisionándose al mismo tiempo debe tener un máximo.
  • Los pares del segmento limitado no pueden comunicarse entre sí.

Cada presupuesto gobierna un recurso distinto. La caducidad impide residencia indefinida. El límite de bytes reduce el uso como canal de transporte. La lista positiva impide movimiento lateral. La cadencia y la concurrencia protegen RADIUS, DHCP, portales, servicios de certificados y capacidad humana. El aislamiento evita que el propio segmento se convierta en un mercado de objetivos vulnerables.

Aplicar uno no compensa la ausencia de otro. Un límite de veinte segundos con salida general sigue siendo peligroso. Una ACL exacta que nunca expira se transforma en infraestructura permanente. Una cola pequeña no protege a un par frente a sus vecinos.

RFC 9965 cita Filter-Id de RADIUS como herramienta para asociar el par a una política. Es un ejemplo, no una arquitectura obligatoria. La condición de auditabilidad es que el nombre pueda resolverse a contenido y versión. «Filtro de alta» no sirve como evidencia si ayer permitía dos destinos y hoy quince.

El desconocido debe conocer a su proveedor

Que el par no esté autenticado no significa que ambas partes puedan ser anónimas. Todo método situado bajo eap.arpa debe definir cómo autenticar al servidor, sea en EAP o posteriormente mediante un protocolo como HTTPS. El par mantiene la presunción de que la red local no es fiable.

En el caso portal@tls.eap.arpa, el acceso EAP-TLS sin autenticación del par aún exige autenticar al servidor, por ejemplo con un certificado. Un PSK conocido por todos no resolvería esa necesidad. La red permite que un dispositivo desconocido alcance una superficie mínima; el dispositivo no debería aceptar su futura identidad de una fuente desconocida.

RFC 8952 diferencia el servicio que proporciona la URI, la API que informa del estado cautivo, el portal y el dispositivo que hace cumplir las reglas. El sistema de negocio puede declarar completado el trámite mientras el equipo de acceso conserva la antigua política. La API puede mostrar un estado que la terminal almacenó y que ya no coincide con los contadores actuales.

La evidencia de cierre debe proceder del punto que controla paquetes. Una orden enviada por el orquestador es intención. Una respuesta de aceptación es progreso. La ausencia observada de la regla, con la generación correcta, es el hecho operacional buscado.

Aprovisionar no es admitir

El resultado puede ser un certificado, una clave, parámetros de red o un paso fuera de banda de RFC 9140. También puede ser un fallo de autenticación del servidor, método incompatible, agotamiento de cuota, tiempo vencido o rechazo por capacidad.

Un único estado «finalizado» borra diferencias esenciales. Crear una credencial no dice si corresponde al registro local correcto, si sigue vigente o si autoriza un servicio concreto. Tampoco garantiza que el siguiente intercambio la presente con éxito.

La transición más comprensible termina primero la sesión EPI. Después el dispositivo inicia una autenticación normal con la nueva credencial. La autorización actual decide entonces qué acceso, si alguno, se concede a la identidad autenticada. Puede no haber interrupción perceptible, pero deben existir dos decisiones separadas.

Si una plataforma cambia el rol dentro de la misma sesión, necesita conservar la frontera lógica: referencia protegida de la nueva credencial, identidad resultante, política consultada, nueva regla aplicada y retirada de la limitada. Un error parcial debe dejar al dispositivo en el estado más estrecho, no en una mezcla indefinida de ambos.

Aquí está la diferencia con la cobertura anterior de RFC 9966. TLS-POK prueba una relación concreta de conocimiento de clave; no explica la custodia legítima. Este artículo no vuelve a evaluar esa prueba. Pregunta qué red temporal se abrió alrededor del proceso y qué demuestra su desaparición. La cadena de clave y la cadena de enforcement son adyacentes, pero no idénticas.

El recibo de cierre

El recibo propuesto puede ser compacto y mantenerse bajo acceso restringido. Debe enlazar:

  1. Solicitud: EPI, método EAP, hora, autenticador/NAS, interfaz e identificador efímero de sesión.
  2. Decisión local: aceptación o rechazo, revisión de política, disponibilidad de capacidad y servicio responsable.
  3. Estado aplicado: filtro, segmento, rol o ACL con versión, puntos de enforcement, lista positiva y control de aislamiento.
  4. Presupuestos: inicio, vencimiento duro, bytes, servicios, número de intento, límite de frecuencia y ocupación de la cola simultánea.
  5. Autenticación del servidor: mecanismo, referencia del certificado o ancla, resultado de validación y excepción acotada si procede.
  6. Resultado: alta lograda o clase precisa de fallo; referencia de la credencial y vida prevista sin almacenar material secreto.
  7. Cierre: hora y causa de retirada, observación del punto de aplicación, tratamiento de flujos residuales, nueva sesión autenticada y reconciliación de estados huérfanos.

Una vista pública no necesita exponer equipos, certificados ni topología. Puede publicar agregados de duración, revisiones de política, tasas de excepción y retrasos de cierre. Los hashes ayudan a detectar sustituciones entre la vista pública y el registro privado, pero no demuestran que la política original fuese legítima.

El nombre «recibo de cierre del carril de aprovisionamiento» pertenece a la propuesta editorial de Daniel Kade. No es un campo de RFC 9965 ni una certificación del IETF. El estándar deja a cada despliegue la aplicación concreta; precisamente por ello, cada operador necesita una forma local de comprobar el final de la excepción.

La caducidad también puede mentir

Un TTL agotado en el controlador no demuestra por sí solo que el switch eliminó la ACL. Una tarea de limpieza puede fallar, perder comunicación o actuar sobre una generación ya sustituida. Del mismo modo, el equipo puede retirar la regla antes de que la aplicación registre el cierre. El recibo debe conservar ambas observaciones y su desfase.

El fallo seguro exige terminar estrechamente. Un portal caído no justifica abrir Internet. Un servicio de certificados lento no justifica extender sin registro la ventana. Reintentar tras cada vencimiento tampoco debería eludir el presupuesto: la cadencia debe considerar la secuencia, no solo la sesión aislada.

La comparación útil contiene tres columnas: política prevista, estado aplicado durante el proceso y estado residual. Una alerta no se resuelve promediando las discrepancias. La diferencia es el objeto de investigación.

En términos del Policy Mirror de Heng Lu, el documento formal revela la autoridad declarada y la configuración ejecutada revela quién tiene poder efectivo. La gobernanza aparece cuando ambos pueden confrontarse y cuando la excepción deja una prueba de su propia desaparición.

Límites

Las fuentes fijan requisitos y riesgos de los protocolos, no su adopción comercial. No identifican despliegues, incidentes ni ventajas medidas. Cada operador elegirá controles, plazos y fronteras de privacidad distintos.

El recibo no es una credencial, un perfil de directorio ni una declaración legal sobre el dispositivo. Tampoco convierte una EPI en identidad. Conserva una afirmación más limitada y comprobable: durante un intervalo existió una vía de acceso provisional; se aplicaron ciertos límites; y la vía se cerró antes de que una autenticación nueva decidiera el siguiente estado.

Sources