Resumen

  • El RFC 5113 separó punto de conexión, identidad, ruta AAA, ruta de carga útil y capacidades del servicio.
  • Las realm hints podían ser incompletas por tamaño o confidencialidad y no constituían un protocolo de enrutamiento dinámico.
  • La selección sucede antes de la autenticación: la publicidad inicial es una pista provisional, y una confirmación posterior solo cubre los parámetros que realmente vincula.

La primera identidad falla porque el realm no tiene ruta. Un proxy AAA central responde con algunas alternativas. El cliente prueba otra identidad y logra autenticarse. Desde fuera, la segunda tentativa parece demostrar que la lista describía la red.

No lo demuestra. La pista ayudó a recuperarse de un error concreto. Podía omitir dominios, llegar tarde y no decir nada sobre la ruta de los paquetes, los servicios o el coste. Convertirla en mapa general habría cambiado una reparación limitada en una autoridad que el mecanismo nunca tuvo.

Una pista nacida del fracaso

RFC 4284 utilizó EAP-Request/Identity para transportar realm hints cuando una solicitud entraba en la zona sin ruta por defecto. RFC 5113 señaló tres límites.

El primero era físico: la lista debía caber en un intercambio sin fragmentación suficiente para transportar una tabla grande. El segundo era institucional: los operadores podían considerar confidencial la tabla de relaciones y no querer entregarla a pares sin autenticar. El tercero era semántico: aunque una lista llegara, no podía asumirse completa.

Un NAS que leyera esos hints no obtenía una tabla de enrutamiento. Obtenía opciones para otro intento. La diferencia determina el diseño del control: un hint puede caducar y fallar; una tabla supuestamente completa se usa para tomar decisiones silenciosas a gran escala.

Fate sharing en el proxy que enruta

Si cada NAS mantiene manualmente los realms que anuncia, su copia puede separarse del estado del núcleo. Puede seguir ofreciendo un dominio cuya relación desapareció o no mostrar una ruta nueva. El cliente descubre la discrepancia después de elegir punto, red e identidad.

El RFC favoreció que el proxy AAA central produzca el hint. Ese mismo proxy deberá encaminar la solicitud siguiente. La entidad que formula la afirmación comparte el destino con la acción basada en ella.

Fate sharing no garantiza que el hint sea completo ni que la segunda identidad sea óptima. Sí reduce una clase de incoherencia: la afirmación no procede de una copia periférica que el decisor real nunca usará.

Elegir identidad era elegir infraestructura

El NAI aporta identidad y realm. La elección de credencial orienta por tanto la conversación AAA hacia una infraestructura. Un usuario con varias identidades puede tener distintas combinaciones de red, proxy y servidor de origen.

Dos rutas pueden aceptar la misma identidad. Una puede ser directa y otra pasar por un consorcio. El resultado de autenticación coincide, pero los servicios, la política comercial y el túnel de datos pueden cambiar.

La conclusión del RFC une credenciales y ruta AAA dentro del mismo problema de selección de identidad. Si la observabilidad los separa, se pierde la explicación. Un error de ruta aparece como contraseña incorrecta; una credencial mal elegida aparece como red caída.

El resto del camino no estaba dentro de EAP

La autenticación no certifica el punto de conexión, todas sus capacidades ni la ruta posterior de la carga útil. El tráfico puede usar un túnel determinado por la relación de roaming. El servicio deseado puede estar bloqueado aunque la identidad sea válida. La tarifa puede depender del mediador.

El sistema debe conservar recibos independientes:

  1. qué puntos se descubrieron;
  2. qué capacidades anunciaron;
  3. qué NAI y credencial se eligieron;
  4. qué ruta AAA respondió;
  5. qué identidad de red se confirmó;
  6. qué ruta siguieron los paquetes;
  7. qué servicio y precio se observaron.

Sin esa cadena, “login correcto” absorbe preguntas que pertenecen a otros planos.

La paradoja temporal de la seguridad

La selección necesita información antes de la autenticación para evitar retrasos. Pero no puede usar las claves dinámicas derivadas de esa autenticación para proteger la información anterior.

La preconfiguración de claves o firmas puede proteger anuncios. A cambio, crea un problema de distribución y actualización de confianza. El channel binding posterior puede confirmar parámetros concretos, pero no debe presumirse que confirma lo que no incluyó.

Algunos valores pueden permanecer sin confirmación. Un atacante podría anunciar una opción más débil y aprovechar esa separación para provocar bidding down. Por eso una publicidad de red debe tratarse como pista. El cliente mantiene una política mínima previa y rechaza lo incompatible, incluso si la opción falsa parece más cómoda.

Privacidad frente a descubrimiento

El cliente podría ayudar al autenticador enviando todos los realms para los que posee credenciales. Antes de autenticarse, esa lista viajaría en claro y revelaría afiliaciones potenciales a un observador.

La divulgación selectiva reduce el riesgo, pero también limita la capacidad del servidor para elegir. No existe una lista gratuita y completa. Cada diseño intercambia privacidad, latencia, tamaño y exactitud.

Una estrategia prudente revela más solo después de que la identidad inicial resulte inutilizable, limita el número de intentos y registra qué información se expuso en cada paso.

No sondear hasta fabricar una ruta

El RFC rechazó usar solicitudes EAP-Response/Identity periódicas para extraer hints y reconstruir una tabla. Las sondas cargan la infraestructura AAA y pueden agravar una sobrecarga. Las retransmisiones multiplican el trabajo. El resultado sigue sin ser completo.

El bucle correcto es corto: fallo de ruta, hint atribuible, identidad alternativa, un nuevo intento y una salida clara. Si el sistema necesita aprendizaje continuo de rutas, debe usar un mecanismo diseñado para ello, no inflar la recuperación de error.

Mandato, preferencia y resultado

El usuario puede preferir menor precio. El operador puede preferir una relación comercial. La aplicación puede necesitar latencia. La política de seguridad puede excluir una red. La primera entrada de una lista no resuelve legítimamente ese conflicto.

Una publicidad no es mandato. Un hint no es consentimiento del usuario. Una ruta AAA exitosa no es prueba de precio. La dirección debe declarar el objetivo de la selección y luego medir si el resultado lo cumplió.

La escalera de evidencia

  • una señal visible no prueba el dominio alcanzable;
  • un realm anunciado no prueba una ruta actual;
  • una pista recibida no prueba una lista completa;
  • otra identidad no prueba que sea la preferida;
  • una ruta AAA no prueba el camino de datos;
  • una autenticación correcta no prueba servicio ni precio;
  • una sesión útil no prueba que no existiera una alternativa mejor.

El RFC 5113 no prometió eliminar la incertidumbre. Exigió mantener visible dónde seguía viva.

Fuentes