Resumen

  • RFC 5418 descompone la seguridad de CAPWAP en relaciones bilaterales entre la estación inalámbrica, el servicio AAA, el controlador de acceso y el punto de terminación inalámbrico. La confianza no se vuelve integral porque cada enlace contiguo use credenciales.
  • Con claves precompartidas, la autorización puede ser amplia y basarse en una clase: la clave no siempre permite distinguir un controlador de un punto de terminación inalámbrico.
  • Un certificado legítimo, un canal de control protegido y la autorización para incorporarse a una red son hechos distintos. El alta del equipo, sus roles, las claves AAA y la ruta real de los datos requieren comprobaciones separadas.

El puente local cambia dónde se aplica la política

Una WLAN puede conservar el control en el AC y entregar localmente las tramas de usuario desde el WTP. Al revisar una sucursal, por tanto, la sesión CAPWAP y la ruta que aplica la política pueden terminar en lugares distintos. RFC 5418 obliga a preguntar dónde se aplica la confianza y dónde circulan realmente los datos.

Ese es un buen punto de partida para leer RFC 5418. Publicado en marzo de 2009 como documento informativo, analiza la exposición que surge al dividir el punto de acceso autónomo en dos elementos: un Wireless Termination Point (WTP) en el extremo inalámbrico y un Access Controller (AC) en otra ubicación. Interacciones que antes ocurrían dentro de un solo dispositivo pasan ahora por una red de capa 3. Según el documento, la seguridad resultante depende de la red intermedia y de cómo se reparten las funciones entre ambos equipos.

El alcance es concreto: analiza amenazas para CAPWAP con IEEE 802.11; no es un censo de productos, un informe de incidentes ni un estándar de Internet. Su valor está en hacer visible una pregunta que los diagramas pueden ocultar: quién es el otro dispositivo, qué función puede ejercer, qué claves recibe y por dónde circula el tráfico del cliente.

La guía editorial toma una idea metodológica de la Nota 65 de Heng Lu, «Running-Code Primacy»: contrastar las afirmaciones con lo que los sistemas ejecutan y los operadores pueden verificar. Esa nota trata del diseño de sistemas de coordinación de Internet; no es una regla de seguridad inalámbrica. Aplicada aquí, recuerda que un dibujo o una política declarada no reemplazan las pruebas sobre credenciales, roles y rutas de reenvío instalados.

CAPWAP incorpora nuevas relaciones de confianza

En un punto de acceso convencional, un dispositivo gestiona el extremo inalámbrico y su conexión con la red cableada. CAPWAP divide esa función. El WTP transmite y recibe comunicaciones inalámbricas; el AC gestiona el controlador y las funciones del lado cableado. La separación facilita la gestión centralizada y varias arquitecturas de sitio, pero también incorpora más relaciones de confianza.

El ejemplo simplificado de RFC 5418 incluye al menos siete relaciones o transferencias de claves:

Paso Relación o transferencia Qué establece en el ejemplo
1 WTP–AC Una relación entre pares CAPWAP
2 AC–AAA El enlace autenticado del controlador con el servicio de autenticación
3 Estación–AAA La autenticación EAP y la generación de material de claves
4 AAA → AC La entrega de una clave maestra por pares al controlador
5 AC–estación Un intercambio de cuatro pasos que genera claves temporales
6 AC → WTP La entrega de una clave temporal cuando el cifrado está descentralizado
7 WTP–estación La seguridad del enlace inalámbrico del cliente

No es una única negociación de extremo a extremo. RFC 5418 recalca que estas relaciones son bilaterales. Que una estación confíe en un servidor AAA, que AAA confíe en el AC y que el AC confíe en un WTP no significa automáticamente que la estación deba confiar en ese WTP. Un WTP comprometido podría mantener su relación con el AC y, al mismo tiempo, mostrar información engañosa al cliente. Un dispositivo comprometido dentro de la jerarquía puede afectar a los que dependen de él.

Se trata de una propiedad estructural, no de afirmar que todas las redes estén comprometidas. La revisión debe seguir cada identidad y cada clave hasta los permisos que concede y preguntar qué podría hacer un nodo comprometido con esos permisos.

Qué acredita una clave compartida — y qué deja pendiente

RFC 5418 distingue autenticación de autorización. La autenticación pregunta si el interlocutor puede demostrar una identidad o que posee una credencial. La autorización determina a qué recursos puede acceder y qué acciones puede realizar.

Para las claves precompartidas, el documento describe una autorización amplia y poco granular: conocer la clave coloca al dispositivo en una clase de confianza. Se pueden crear clases con claves separadas, pero una clave de clase no demuestra por sí sola si el titular es un AC o un WTP. Si ambos roles usan el mismo secreto, quien lo obtenga podría declarar cualquiera de ellos, salvo que otro control limite el intercambio.

El riesgo aumenta cuando el secreto circula más que el inventario. Una clave copiada en el aprovisionamiento de fábrica, las notas de preparación, la configuración del controlador y los procedimientos de reemplazo deja de pertenecer a un equipo: se convierte en una capacidad operativa compartida. El riesgo depende de quién puede recuperarla, de si las clases están realmente separadas, de cómo se rota y de si el receptor comprueba el rol declarado. RFC 5418 no atribuye estas prácticas a ningún operador; son preguntas que cada operador debe resolver.

Los certificados permiten comprobaciones más específicas, pero el documento no considera que presentarlos equivalga a una política completa de alta. RFC 5418 describe un nombre de sujeto que incluye la dirección MAC y campos Extended Key Usage propios de los papeles AC y WTP. Esos controles sirven si el equipo receptor verifica que el nombre es admisible en esa red y aplica estrictamente la función autorizada. Si acepta un uso extendido genérico, la separación puede desaparecer sin controles adicionales del nombre.

Un certificado del fabricante informa de quién emitió la credencial; no responde qué AC debe aceptar el WTP en esta red ni qué WTP pertenecen a esta instalación. RFC 5418 señala que la autorización por certificados y la configuración sin intervención no encajan por completo. Su análisis presupone que el WTP identifica al AC correcto y que el AC identifica los WTP correctos; determinar esa selección inicial queda fuera del alcance. Esa frontera debe seguir visible en las compras y las revisiones de seguridad.

AAA tiene su propio responsable

En el ejemplo simplificado, el AC actúa como autenticador y se comunica con un servidor AAA mediante RADIUS o Diameter. RFC 5418 advierte que las credenciales de larga duración no únicas o de poca entropía en el enlace AC–AAA pueden debilitar seriamente toda la instalación. Recomienda una conexión con autenticación mutua, confidencialidad e integridad, y remite a RFC 4962 para la gestión de claves AAA.

Esta recomendación protege un enlace distinto del que une WTP y AC. Una sesión DTLS válida no verifica automáticamente el servidor AAA del controlador. Un método EAP sólido entre la estación y AAA no demuestra que solo el controlador previsto reciba las claves resultantes. Un intercambio inalámbrico correcto tampoco prueba que se entregaran las claves al WTP adecuado. El operador debe asignar un responsable a cada credencial y decisión de autorización.

El problema también es organizativo. El equipo inalámbrico puede gestionar el alta de dispositivos, seguridad puede administrar la política de certificados e identidad puede operar AAA. Cada grupo puede afirmar que su enlace está protegido mientras nadie verifica cómo encajan las garantías. Un registro útil vincula cada relación con quien emite la credencial, quien la valida, el rol otorgado y la evidencia de pertenencia a la red.

El túnel de control no revela la ruta de los datos

La identidad y el traslado de claves son solo parte de la arquitectura. RFC 5418 separa el plano de control del reenvío de datos y describe modos Split MAC, Local MAC y otras variantes. En Local MAC, el WTP procesa la mayoría de las funciones MAC y normalmente entrega las tramas de datos en la propia red del sitio. Los términos de CAPWAP no determinan de manera rígida cada opción de túnel.

RFC 5415 delimita el protocolo: los mensajes Discovery Request y Discovery Response circulan en claro para que el WTP localice controladores candidatos. Los demás mensajes de control CAPWAP deben usar DTLS. La protección de los paquetes de datos es opcional y depende de la política del AC. Por ello, una asociación de control protegida no permite concluir que los datos de clientes atraviesen el AC, usen un canal de datos protegido o se entreguen localmente a la red cableada.

La elección mueve el lugar donde se aplican las reglas. Un trayecto centralizado puede dar al controlador un punto de control, a cambio de añadir recorrido y dependencia. El puente local evita llevar todo el tráfico de vuelta a un controlador distante, pero desplaza la segmentación, inspección y vigilancia hacia el extremo y la red cableada conectada. Son compensaciones de arquitectura, no recomendaciones universales. Hay que comprobar que el trayecto elegido coincide con el que presuponen las políticas y el plan de respuesta a incidentes.

El cifrado tampoco elimina todas las amenazas. RFC 5418 aborda ataques de agotamiento de recursos, observación pasiva, análisis de tráfico e interferencia de un atacante capaz de descartar paquetes. También menciona ataques ajenos a CAPWAP, como la suplantación de DNS o DHCP y el envenenamiento de cachés ARP. Estas limitaciones no vuelven inútil a DTLS: delimitan lo que protege y dónde debe actuar otro responsable.

Una revisión útil sigue un grafo, no una casilla

Una revisión de CAPWAP debe partir de la topología real y preguntar:

  1. ¿Qué AC acepta cada WTP y cómo se demuestra que pertenece a esta instalación?
  2. ¿Qué WTP acepta cada AC y cómo se distinguen sus funciones?
  3. ¿Las claves compartidas son lo bastante exclusivas y limitadas para la clase que representan? ¿Quién puede verlas, instalarlas, reemplazarlas y revocarlas?
  4. ¿Qué controles sobre nombre y función aplica realmente cada equipo? ¿Qué pasa si el certificado es válido pero el dispositivo no consta en la lista autorizada?
  5. ¿Qué credenciales usa el AC con AAA y dónde quedan registradas la entrega de claves y su autorización?
  6. ¿Los datos de clientes pasan por el AC o se puentean localmente? ¿Dónde se cifra, segmenta, inspecciona y registra el trayecto?
  7. ¿Qué riesgos persisten pese a DTLS: agotamiento de recursos, análisis de tráfico, descarte de paquetes, manipulación de la búsqueda o un ataque a la red local adyacente?

Estas preguntas transforman «la WLAN usa certificados» en afirmaciones comprobables. Al reemplazar un punto de acceso hay que actualizar el inventario y los permisos de función, no solo confirmar la firma del fabricante. Al mover una sucursal a puente local, el plan de aplicación y observación de políticas debe desplazarse junto con los paquetes. La rotación de una clave AC–AAA no debería invalidar de forma inadvertida la identidad WTP–AC ni bloquear una ruta de contingencia.

Mantener los límites del documento

RFC 5418 retrata el modelo CAPWAP y 802.11 analizado en 2009. Sus ejemplos criptográficos y su terminología no son instrucciones actuales de configuración. RFC 5415 define el protocolo CAPWAP; RFC 5418 estudia la exposición creada al dividir las funciones del punto de acceso. Ninguno demuestra qué incluye hoy un producto, cómo está configurada una red concreta o si hubo un incidente.

Su aporte analítico es más acotado: un canal protegido es un enlace dentro de un grafo de confianza. La pregunta no es cuántos enlaces llevan un candado, sino si cada identidad aceptada corresponde a la red, el rol y los permisos correctos, y si los datos del cliente recorren la ruta que la organización cree administrar. Tener una credencial y gobernar el sistema que abre son cosas distintas.

Fuentes