Our techie journey

802.11k

Una red inalámbrica Cisco necesita optimizar los servicios de roaming en situaciones donde se soportan servicios como voz, video o localización. Hoy comenzaremos por conocer un estándar y una enmienda que, aunque no encajan en la sección «Fast Secure Roaming», nos permiten mejorar la experiencia del usuario cuando necesita conectarse a otro punto de acceso (AP)

Siempre que el cliente sea compatible con 802.11k, los puntos de acceso (AP) y los controladores pueden interactuar con él para sugerir una lista de AP vecinos conocidos a los que puede conectarse. Esta interacción se realiza mediante action frames. Los siguientes pasos se llevan a cabo en el proceso de roaming asistido:»

1. El cliente se asocia al AP y puede solicitar en cualquier momento una lista de AP vecinos que ofrezcan el mismo SSID, junto con sus números de canal (esto se conoce como neighbor list)
2. En cualquier momento, el AP también puede solicitar al cliente que escanee uno o más canales e informe sobre los AP detectados (esto se conoce como un informe beacon report). Este informe puede ayudar al AP a refinar la lista de vecinos según el punto de vista del cliente y su posición en la celda.
3. A medida que el cliente se acerca al borde de la celda, puede solicitar un informe de vecinos actualizado al AP, o usar el que ya obtuvo como una lista reducida, para escanear solo los canales donde sabe que tiene la posibilidad de encontrar un AP vecino.
4. El cliente se reasocia con el AP con mejores cualidades.

Es importante destacar que 802.11k delega la decisión de cambiar de AP al cliente en lugar de al AP. Sin embargo, el AP (junto con su controlador) colabora en este proceso al ofrecer una lista de posibles AP candidatos. En el primer paso, el AP envía una lista de AP vecinos que se genera dinámicamente. Esta información dinámica proviene de la lista de vecinos RRM, la cual se recopila a partir de los anuncios NDP enviados entre AP.

802.11v

Los AP también pueden utilizar 802.11v para enviar solicitudes no solicitadas a un cliente, con el fin de sugerir que es hora de que el cliente se desplace o realice una transición de BSS. La intensidad de la señal del cliente en el AP podría estar disminuyendo lo suficiente como para que realmente le convenga más reasociarse a un AP diferente. O el AP podría sugerir el desplazamiento como un medio para aligerar la carga del cliente en el AP actual.

Las solicitudes de transición de BSS no solicitadas son precisamente eso: el AP sugiere, pero no obliga, un desplazamiento. El cliente es libre de decidir si desea o no desplazarse; si no lo hace, el AP puede seguir monitorizando al cliente y disociarlo si finalmente no se desplaza

RSN en pocas palabras

La enmienda 802.11i definió una red de seguridad robusta (RSN) como una red inalámbrica que aprovecha la criptografía para asegurar la integridad y el contenido de los datos que pasan entre los puntos de acceso (AP) y sus clientes asociados. Las medidas de seguridad requieren una jerarquía de claves criptográficas que deben generarse, derivarse y luego utilizarse durante una sesión inalámbrica. Además, una RSN requiere WPA2 o WPA3 para implementar la generación de claves necesaria y los mecanismos para una seguridad robusta

Es importante recordar que WPA2 y WPA3 tienen modos personales y empresariales que pueden autenticar a los clientes inalámbricos con una clave precompartida (PSK) y 802.1X, respectivamente. Con una PSK, todos los clientes inalámbricos y AP permitidos para participar en una WLAN se configuran con la misma cadena de clave. Con 802.1X, se aprovecha EAP para que un servidor RADIUS externo pueda autenticar y autorizar a los clientes para conectarse.

Una vez que un cliente se ha asociado con el AP, debe ser autenticado y se deben generar claves criptográficas para su sesión. Se debe generar toda una jerarquía de claves, comenzando con la Master Session Key (MSK). Si se está utilizando WPA2-Personal o WPA3-Personal, entonces la MSK se deriva del pre-shared key. De lo contrario, la MSK se deriva durante el intercambio de EAP mientras el cliente es autenticado por el servidor RADIUS.A su vez, se deriva una Pairwise Master Key (PMK) a partir de la MSK y se utilizará para derivar más claves relacionadas con la comunicación unidireccional y el cliente.

El controlador también genera una Group Master Key (GMK) que se utilizará para derivar más claves para proteger el tráfico de multicast y broadcast. Dado que la GMK se utiliza para el tráfico de multicast y broadcast, está destinada a varios clientes al mismo tiempo. Por lo tanto, la GMK se genera de forma independiente a cualquier asociación de cliente, pero las claves derivadas de ella se compartirán con cada cliente asociado a la WLAN

Una vez que las master keys están listas, el cliente y el AP (en realidad, su controlador) deben llevar a cabo un intercambio de cuatro frames de EAP over LAN (EAPoL). Esto se conoce como 4-way handshake, que se utiliza para derivar las claves temporales pairwise (PTK) y de grupo (GTK). Estas claves se convertirán en la base para cualquier otra clave que sea necesaria para proteger la integridad de los datos (MIC) y cifrar los contenidos de los datos (AES) de las tramas inalámbricas hacia y desde un cliente específic

Cada vez que un cliente se desplaza a un AP diferente, debe pasar por todo el proceso nuevamente ya debe de ser autenticado por un nuevo AP. Se deben generar nuevas claves criptográficas nuevamente porque no se comparten entre los AP. Este proceso puede tardar un segundo o más en completarse. Durante ese tiempo, el cliente debe esperar, y cualquier flujo de datos que ya esté en progreso se verá interrumpido, lo cual es especialmente notable para las aplicaciones de voz y en tiempo real.

PMKID Caching or SKC Caching

El almacenamiento en caché Pairwise Master Key ID (PMKID)

El cliente y un AP forman una asociación de seguridad después de un exitoso proceso de 4-way handshake e intercambio de claves. Si el cliente se desplaza a otro lugar y luego regresa a un AP al que se había unido anteriormente, puede identificarse en
re-association request frame que hace referencia a su PMK. El cliente y el AP aún deben pasar por 4-way handshake, pero la interacción completa de EAP con un servidor RADIUS puede ser omitida y el PMK no tiene que ser generado nuevamente.

El almacenamiento en caché de PMKID tiene algunas limitaciones. La caché solo es significativa localmente para APs específicos, por lo que no es una solución global. Un cliente solo puede beneficiarse cuando se reasocia con un AP que ha visitado anteriormente. Los APs y controladores generalmente tienen un límite en el número de PMKs que se pueden almacenar en caché, lo que puede convertirse en un problema en una red con un gran número de clientes. El almacenamiento en caché de PMKID es una característica opcional que no es ampliamente compatible con los dispositivos cliente, y no es compatible durante los desplazamientos entre controladores en los WLC de Cisco.

Opportunistic Key Caching (OKC)

Opportunistic Key Caching (OKC) es muy similar al almacenamiento en caché de PMKID, ya que se genera y almacena una PMK por cliente. La PMK se guarda durante el tiempo de vida del cliente en la WLAN y se comparte entre todos los AP que están conectados al mismo controlador. El OKC se diferencia del almacenamiento en caché de PMKID en que solo se necesita una PMKID por cliente. Los clientes pueden reasociarse a cualquier AP, sin asociación previa, siempre que el OKC haya compartido la información de la PMK del cliente con antelación. El OKC está limitado por su compatibilidad entre plataformas, ya que no está definido en el estándar 802.11.»

Preauthentication

Su objetivo es permitir que un cliente se asocie con un AP y luego instruya al AP para que envíe suficiente información a una lista de AP vecinos, de modo que puedan preautenticar al cliente incluso antes de que se asocie con ellos. La comunicación entre APs ocurre a través del sistema de distribución (DS) es decir, a través de la infraestructura Ethernet. Cada uno de los AP vecinos puede ejecutar la autenticación EAP y la generación de PMK para el cliente por adelantado. Luego, cuando el cliente se desplace y se reasocie a uno de los AP vecinos, puede omitir los pasos de EAP y PMK, que consumen mucho tiempo, y pasar directamente al 4-way handshake.

a preautenticación tiene más limitaciones que beneficios. Por ejemplo, nunca fue ampliamente adoptada y no es compatible con los APs o WLCs de Cisco. Los recursos de RADIUS pueden verse sobrecargados a medida que los clientes intentan la preautenticación con múltiples APs en un área

CCKM

Cisco Centralized Key Management es un método propietario de roaming seguro y rápido. Un cliente inalámbrico pasa por todo el proceso de autenticación EAP y el 4-way handshake, y luego el controlador almacena en caché la PMK del cliente durante 1 hora. Si el cliente se desplaza de regreso al AP original o a un AP diferente en el mismo controlador, la PMK ya está en caché, por lo que solo es necesario generar la PTK. Esto significa que el cliente reasociado puede omitir tanto los procesos de EAP como 4-way.

CCKM también funciona a través de múltiples controladores y grupos de movilidad, ya que los controladores pasan la información de las credenciales del cliente como parte del traspaso de movilidad. Sin embargo, es propietario de Cisco y requiere que el cliente ejecute una versión de CCX que soporte el método EAP específico en uso.

802.11r: Fast Transition

Un cliente capaz de usar 802.11r comienza con una asociación completa al AP, como se muestra en la figura. La figura se parece mucho al proceso normal de asociación con el AP de la Figura 8-11, con dos pequeños cambios. Durante la authentication y los association request/response , el cliente indica que le gustaría usar 802.11r al incluir elementos de información RSN y FT dentro del contenido de sus solicitudes. Si el AP también soporta 802.11r FT, incluye esos elementos en sus respuestas. Los frames también contienen información sobre las llaves que se usarán en la sesión segura del cliente.

Podrías haber notado otro cambio en las derivaciones de llaves en la parte de ‘PSK o 802.1X’ de la figura. El 802.11r todavía depende de una jerarquía de claves criptográficas, pero amplía el alcance y el uso de estas. Como resultado, los nombres de las llaves son algo diferentes de las claves RSN normales. Cada cliente todavía tiene un MSK, pero la PMK se divide en dos. La PMK-R0 se deriva del MSK, mientras que la PMK-R1 se deriva de la PMK-R0. La idea básica es distribuir el material PMK de un cliente entre múltiples ‘poseedores de claves’ dentro de la red. Por ejemplo, la PMK-R0 de un cliente podría ser retenida por un controlador, mientras que la PMK-R1 es retenida por algunos AP. Cada cliente todavía deriva una PTK y una GTK con el poseedor de la PMK-R1.»