MX2009002507A

MX2009002507A - Autentificacion de seguridad y gestion de claves dentro de una red de multisalto inalambrica basada en infraestructura.

Info

Publication number: MX2009002507A
Application number: MX2009002507A
Authority: MX
Inventors: Charles R Barker Jr; Heyun Zheng; Amit Glandhi; Keith J Goldberg; Samer S Hanna; Surong Zeng
Original assignee: Motorola Inc
Priority date: 2006-09-07
Filing date: 2007-07-26
Publication date: 2009-03-25
Also published as: US7793104B2; US20090210710A1; US7499547B2; AU2011201655B2; KR101054202B1; BRPI0716507B1; RU2009112589A; CA2663168A1; CN101513092A; US20080065888A1; RU2407181C1; CA2663168C; BRPI0716507A2; AU2007292516A1; JP2010503326A; EP2060052A2; CN101513092B; EP2060052A4; EP2060052B1; AU2007292516B2

Abstract

Un sistema y método de autentificación de seguridad y esquema de gestión de claves en una red inalámbrica de multisalto se proporciona en la presente con un modelo de seguridad de salto por salto. El esquema adapta la jerarquía de clave 802.llr en la red de AP poligonal. En este procedimiento, un tenedor de claves superior (ROKFI) deriva y mantiene la Clave Maestra Dos a Dos (PMK_O) superior para cada dispositivo inalámbrico suplicante después del proceso de autentificación. Todo el AP de]. autentificador toma la función de tenedor de claves de nivel uno (R1KH) y recibe la Clave Maestra Dos a Dos (PMK_l) del siguiente nivel de ROKH. La clave de protección de datos del 'nivel de enlace se deriva de PMK1 mediante el saludo inicial de 4 vías 802.lli.

Description

AUTENTIFICACIÓN DE SEGURIDAD Y GESTIÓN DE CLAVES DENTRO DE UNA RED DE MULTISALTO INALÁMBRICA BASADA EN INFRAESTRUCTURA CAMPO DE LA INVENCIÓN La presente invención se refiere generalmente a comunicaciones inalámbricas y más particularmente a autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en infraestructura.

ANTECEDENTES DE LA INVENCIÓN Una red inalámbrica basada en infraestructura típicamente incluye una red de comunicación con puertos de enlace fijo y alámbrico. Muchas redes inalámbricas basadas en infraestructura emplean una unidad móvil o servidor que se comunica con una estación base fija que se acopla a una red alámbrica. La unidad móvil puede moverse geográficamente mientras se está comunicando sobre un enlace inalámbrico a la estación base. Cuando la unidad móvil se cambia de campo de acción de una estación base, puede conectarse o "transferirse" a una nueva estación base y comenzar a comunicarse con la red alámbrica a través de la nueva estación base.

SUMARIO DE LA INVENCIÓN En comparación con las redes inalámbricas basadas en infraestructura, tales como redes celulares o redes satelitales, y redes ad hoc son redes de autoformación que pueden operar en ausencia de cualquier infraestructura fija, y en algunos casos la red ad hoc se forma totalmente de nodos móviles. Una red ad hoc típicamente incluye un número de unidades potencialmente móviles, geográficamente distribuidas algunas veces referidas como "nodos" , las cuales se conectan inalámbricamente entre sí por uno o más enlaces (por ejemplo, canales de comunicación de radiofrecuencia) . Los nodos pueden comunicarse entre sí sobre un medio inalámbrico sin el soporte de una red basada en infraestructura o alámbrica. Conforme las redes de comunicación inalámbrica se vuelven más prevalentes, la seguridad continúa siendo una mayor preocupación para proveedores de redes de comunicación y usuarios finales. Esto es más evidente cuando se utiliza una red inalámbrica móvil donde el ambiente de seguridad puede ofrecer los mayores desafíos puesto que los datos pueden ser recibido y manipulados fácilmente por muchos nodos. Los enlaces de radio utilizados en una red inalámbrica exponen la señalización y los datos que recorren la red a fisgones y/o posibles piratas informáticos. En una red inalámbrica de multisalto, esto requiere cada enlace en los dispositivos conectados que tenga una asociación de seguridad única establecida a través del proceso de autentificación de multisalto y gestión de claves. Entonces, las tramas aéreas en el enlace pueden ser protegidas con las asociaciones de seguridad establecida .

BREVE DESCRIPCIÓN DE LAS FIGURAS Las figuras anexas, donde números de referencia similares se refieren a elementos idénticos o funcionalmente similares a través de las vistas separadas y que junto con la descripción detallada siguiente se incorporan en y forman parte de la especificación, sirven para ilustrar adicionalmente varias modalidades y para explicar varios principios y ventajas todo de acuerdo con la presente invención. La FIGURA 1 ilustra una red inalámbrica de multisalto basada en infraestructura ejemplar de acuerdo con algunas modalidades de la presente invención. La FIGURA 2 ilustra un formato de mensaje ejemplar de acuerdo con algunas modalidades de la presente invención. La FIGURA 3 es un diagrama de flujo que ilustra un proceso de distribución de claves y autorización de funciones de acuerdo con algunas modalidades de la presente invención . La FIGURA 4 ilustra un procedimiento de autentificación, de acuerdo con algunas modalidades de la presente invención. La FIGURA 5 es un diagrama de flujo de mensajes que ilustra mensajes de autentificación intercambiados entre varios elementos de la red de la FIGURA 1, de acuerdo con algunas modalidades de la presente invención. La FIGURA 6 ilustra más detalle del intercambio de mensajes de la FIGURA 5, de acuerdo con algunas modalidades de la presente invención. Aquellos con experiencia en la técnica apreciarán que elementos en las figuras se ilustran para simplicidad y claridad y no necesariamente se han dibujado a escala. Por ejemplo, las dimensiones de algunos de los elementos en las figuras pueden exagerarse con respecto a otros elementos para ayudar a mejorar el entendimiento de las modalidades de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Antes de describir en detalle las modalidades que son de acuerdo con la presente invención, se debe observar que las modalidades que residen principalmente en combinaciones de etapas de métodos y componentes de aparatos relacionados con autentificación de seguridad y gestión de claves. Por consiguiente, los componentes de aparatos y etapas de métodos se han representado donde es apropiado por símbolos convencionales en las figuras, mostrando sólo esos destalles específicos que son pertinentes para entender las modalidades de la presente invención para no obscurecer la descripción con detalles que fácilmente serán aparentes para aquellos de experiencia ordinaria en la técnica teniendo el beneficio de la descripción en la presente. En este documento, términos relaciónales tales como primero y segundo, superior e inferior, y similares pueden utilizarse solamente para distinguir una entidad o acción de otra entidad o acción sin requerir necesariamente o implicar ninguna relación actual u orden entre tales entidades o acciones. Los términos "comprende", "que comprende", o cualquier otra variación de los mismos, se pretenden para cubrir una inclusión no exclusiva, de modo que un proceso, método, artículo o aparato que comprende una lista de elementos no incluye sólo esos elementos sino que puede incluir otros elementos no expresamente listados o inherentes para tal proceso, método, artículo o aparato. Un elemento precedido por "comprende ... uno" , sin más restricciones, no impide la existencia de elementos idénticos adicionales en el proceso, método, artículo o aparato que comprende el elemento. Se apreciará que las modalidades de la invención descritas en la presente pueden comprenderse de uno o más procesadores convencionales y de instrucciones de programación almacenadas únicas que controlan uno o más procesadores para implementar, junto con ciertos circuitos sin procesador, algunas, la mayoría o todas las funciones de autentificación de seguridad y gestión de claves descritas en la presente. Los circuitos sin procesador pueden incluir, pero no se limitan a un receptor de radio, un transmisor de radio, excitadores de señales, circuitos de reloj , circuitos de fuente de energía, y dispositivos de entrada de usuario. Como tales, estas funciones pueden interpretarse como etapas de un método para realizar autentificación de seguridad y gestión de claves. Alternativamente, algunas o todas las funciones podrían implementarse por una máquina de estado que no tiene instrucciones de programación almacenadas, o en uno o más circuitos integrados de aplicación especifica (ASIC) , en los cuales cada función o algunas combinaciones de ciertas funciones se implementan como lógica a medida. Desde luego, una combinación de los dos procedimientos podría utilizarse. De este modo, métodos y medios para estas funciones se han descrito en la presente. Además, se espera que alguien con experiencia ordinaria en la técnica, sin importar un esfuerzo posiblemente significante y muchas opciones de diseño motivadas por, por ejemplo, el tiempo disponible, la tecnología actual y consideraciones económicas, cuando son guiadas por los conceptos y principios descritos en la presente serán fácilmente capaz de generar tales instrucciones y programas de software e IC con mínima experimentación. La presente invención proporciona una autentificación de seguridad y esquema de gestión de claves para una red inalámbrica de multisalto basado en infraestructura con un modelo de seguridad de salto por salto. Los bloques de construcción básicos de la presente invención son IEEE 802. lli e IEEE 802. lx. Para una transferencia rápida, características en 802. llr se incluyen . IEEE 802. lx es una nueva tecnología que proporciona escalabilidad casi ilimitada con gastos de administración mínimos. También permite que diferentes métodos de autentificación sean seleccionados por los usuarios o los operadores. En la presente invención, la Seguridad de Capa de Transporte Canalizado (TTLS) se utiliza para la autentificación de usuario y dispositivo debido a su seguridad relativamente fuerte y al costo de despliegue menor. Para los dispositivos la Autentificación de Seguridad de Capa de Transporte (TLS) es una característica opcional. Para autentificación centralizada y soporte 802. llr, el tenedor de claves de nivel superior (R0KH) para la jerarquía de clave 802. llr se diseña para ser localizado en la red alámbrica. El transporte de mensajes entre el tenedor de claves de nivel superior (nivel cero) y los tenedores de claves de nivel 2 (R1KH) pueden estar ya sea en la capa 2 o en la capa de Protocolo de Internet (IP) . En la presente invención, una jerarquía de clave basada en 802. llr se adapta entre los puntos de acceso conectados, los cuales toman la función de los tenedores de claves de nivel uno. El flujo de mensajes de gestión de seguridad entre los tenedores de claves se proporciona. La gestión de claves puede soportar ambas estaciones inalámbricas que cumplen con 802. lli y 802. llr. También puede soportar puntos de acceso virtuales posibles, identificadores de conjuntos de servicios múltiples posibles (SSID) desplegados. El flujo de mensajes de seguridad entre los tenedores de claves de nivel cero y nivel uno puede ser transportado sobre la capa 2 o capa 3 dependiendo de la ubicación del tenedor de claves de nivel cero. Cuando todos los tenedores de claves de nivel cero se despliegan en el mismo segmento de capa 2 con los tenedores de claves de nivel uno, el transporte de comunicación de capa 2 puede utilizarse y de otra forma, el transporte de comunicación de capa 3 debe utilizarse. Una Clave de Distribución de Claves (KDK) se deriva durante el proceso de autentificación inicial y se utiliza para asegurar el material de clave transportado desde el tenedor de claves de nivel superior a los tenedores de clave de siguiente nivel. La función del tenedor de claves de nivel uno R1KH se autoriza por el tenedor de claves de nivel superior basándose en la información de autorización del Servidor de Autentificación . Un sistema y método de autentificación de seguridad y esquema de gestión de claves en una red inalámbrica de multisalto se proporciona en la presente con un modelo de seguridad de salto por salto. El esquema se adapta a la jerarquía de claves 802. llr en la red de punto de acceso (AP) poligonal. En ese procedimiento, un tenedor de claves de nivel superior (ROKH) deriva y mantiene la Clave Maestra Dos a Dos (PMK_0) superior para cada dispositivo inalámbrico suplicante después del proceso de autentificación . Todos los puntos de acceso (AP) del autentificador toman el nivel de la función del tenedor de claves de nivel uno (R1KH) y recibe la Clave Maestra Dos a Dos (PMK_1) del siguiente nivel del tenedor de claves de nivel superior ROKH. La clave de protección de datos de nivel de enlace se deriva de PMK_1 mediante saludo inicial de 4 vías tal como un saludo inicial de cuatro vías 802. lli . La FIGURA 1 ilustra una red 100 inalámbrica de multisalto basada en infraestructura ejemplar de acuerdo con algunas modalidades de la presente invención. En la red 100 ejemplar de la FIGURA 1, los canales de comunicación de nivel 2 entre los tenedores de clave se utilizan y un tenedor de claves de nivel superior ROKH se conecta a un conmutador de Ethernet central. De este modo, el tenedor de claves de nivel superior ROKH está en el mismo segmento L2 con todos los dispositivos controlados de punto de acceso inteligente (LAP) y punto de acceso poligonal (MAP) . Un cliente de servicio de usuario de marcación de autentificación remota (RADIUS) y autentificador 802. IX también se implementan dentro de la red 100 de acuerdo con algunas modalidades de la presente invención. Se apreciará por aquellos con experiencia ordinaria en la técnica que cuando los canales de comunicación de capa de IP se utilizan para el tenedor de claves de nivel superior ROKH y el tenedor de claves de nivel uno R1KH, el ROKH puede localizarse en cualquier ubicación. De acuerdo con una implementación ejemplar, ROKH se localiza dentro del mismo servidor que el sistema de gestión de red. Todos los dispositivos R1KH conectados al mismo ROKH se identifican a través de un Identificador de Dominio de Movilidad (MD1) el cual se anuncia en todas las tramas de baliza. Como se ilustra, la red 100 incluye uno o más puntos de acceso poligonales (MAP) 135-n los cuales se utilizan para enrutar los paquetes de datos de uno o más puntos de acceso inteligente (IAP) 130-n a uno o más dispositivos de suscriptor inalámbrico (SD) 140-n (también referidos como estaciones (STA) ) . Uno o más IAP 130-n entonces se enrutan en los paquetes a un conmutador 125 de Ethernet central acoplado comunicativamente a un enrutador 115 central, y un tenedor de claves de nivel superior (ROKH) 120. El enrutador 115 central se acopla mediante una infraestructura 110 alámbrica a un servidor 105 de autentificación . Aunque sólo las trayectorias para los dispositivos del suscriptor (SD) a la red 125 alámbrica se muestran, se apreciará por aquellos de experiencia ordinaria en la técnica que las conexiones poligonales pueden establecerse siempre y cuando dos dispositivos vecinos tales como el dispositivo 140-1 de suscriptor y el dispositivo 140-2 de suscriptor puedan comunicarse entre sí . El servidor 105 de autentificación funciona para proporcionar servicios de autentificación al ROKH 120 y se describirá después de esto. En general, el servidor 105 de autentificación realiza la función de autentificación necesaria para comprobar las credenciales de un suplicante a nombre del autentificador e indica si el suplicante está autorizado para acceder a los servicios del autentificador . En una modalidad de la presente invención, el servidor 105 de autentificación se localiza en la sección de red alámbrica donde la seguridad física de un servidor puede proporcionarse. Por ejemplo, el servidor 105 de autentificación puede ser un servidor de servicio de usuario de marcación de autentificación remota (RADIUS) habilitado por protocolo de autentificación extensible-Seguridad de Capa de Transporte Canalizado/protocolo de autentificación extensible-protocolo de capa de transporte (EAP-TTLS/EAP-TLS) para la autentificación centralizada. Como se apreciará por aquellos con experiencia ordinaria en la técnica, los dispositivos 140-n de suscriptor en la red 100 se les puede requerir enviar y recibir datos encriptados . Cualquier dispositivo dentro de la red 100 que requiera/desee acceso a los servicios ofrecidos por el sistema de autentificador se refieren como suplicante. Un dispositivo que autentifica otros dispositivo (suplicante) que requiere/desea utilizar los servicios protegidos por el autentificador se refiere como autentificador . El autentificador ejecuta el control de acceso basándose en el resultado de autentificación . Como se apreciará por aquellos de experiencia ordinaria en la técnica, cada nodo en la red 100 (es decir, los IAP 130-n, los MPA 135-n, y los SD 140-n) se autentifican a la red 100 antes de que se una a la red poligonal. Las credenciales para la autentificación pueden basarse por ejemplo, en una contraseña, un módulo de identidad de suscriptor (SIM) , identificación de tarjeta (I.D.), u otra I.D., la cual es única para un nodo particular y se almacena en el servidor 105 de autentificación. Cada nodo utiliza su relación con el servidor 105 de autentificación para autentificar un MAP o IAP poligonal con seguridad de un salto el cual ha establecido una conexión de seguridad a ROKH 120. El ROKH 120 utilizará los servicios de autentificación proporcionados por el servidor 105 de autentificación . El servidor 105 de autentificación también ayuda al nodo particular que está autentificando para establecer una relación confiable con sus nodos vecinos al distribuir un material de clave maestra de sesión que se encripta en el ROKH 120. El ROKH 120 deriva Claves Maestras Dos a Dos de nivel cero y nivel uno (PMK_0. PMK_1) . El ROKH 120 también mantiene el PMK_0 y envía PMK_1 al autentificador MAP o IAP el cual está tomando la función del tenedor de claves de nivel uno. En una modalidad de la presente invención, la red 100 incorpora la operabilidad IEEE 802. llr. 802. llr proporciona las transiciones BSS rápido ("Conjunto de Servicio Básico"). 802. llr de este modo facilita la conectividad a bordo de vehículos en movimiento, con transferencia rápida de una estación base a otra manejada en una forma inalámbrica. La aplicación primaria visualizada actualmente para el estándar 802. llr es VOIP ("voz sobre IP"), o telefonía basada en Internet) mediante teléfonos móviles diseñados para funcionar con redes inalámbricas de Internet, en lugar de (o además de) redes de celular estándares . 802. llr refina el proceso de transición de un cliente móvil conforme se mueve entre puntos de acceso. El protocolo permite a un cliente inalámbrico establecer un estado de seguridad y calidad de servicio (QoS) en un nuevo punto de acceso antes de hacer una transición, lo cual lleva a una mínima pérdida de conectividad e interrupción de aplicación. Los cambios generales para el protocolo no presentan nuevas vulnerabilidades de seguridad. Esto preserva el comportamiento de las estaciones actuales y los puntos de acceso. 802. llr proporciona mecanismos para que clientes móviles de itinerancia se comuniquen con puntos de acceso candidatos, establezcan asociaciones de seguridad y reserven recursos de QoS. De acuerdo con la presente invención, dentro de la red 100 de la FIGURA 1, una jerarquía de clave basada en 802. llr se aplica a un AP poligonal, por el cual hace posible una transferencia rápida para uno o más AP móviles. En esta jerarquía de clave, una clave de nivel superior PMK_0 se genera en el R0KH 120 a partir del material de clave maestra recibido del servidor 105 de autentificación . En el siguiente nivel, un PMK_1 se deriva en el ROKH 120 del PMK_0. El PMK_1 se deriva al R1KH . La clave transitoria dos a dos (PTK) se deriva de PMK_1 entre el suplicante y el autentificador a través de un saludo inicial de 4 vías 802. lli. De acuerdo con algunas modalidades de la presente invención, el tenedor de claves de nivel superior ROKH 120 se localiza en la sección de red alámbrica y se conecta al conmutador 125 de Ethernet central y todos los otros puntos de acceso poligonales (MAP) 135-n y los IAP 130-n tomarán la función de tenedor de claves de nivel uno. En algunos despliegues de la presente invención, ROKH 120 puede contenerse dentro de IAP 130-n, de este modo todos los MAP 135-n asociados con ese IAP 130-n serán R1KH bajo ese ROKH 120 (no mostrado) . Cuando los canales de comunicación de capa IP se utilizan para ROKH y R1KH el ROKH y R1KH pueden localizarse en un segmento diferente de capa 2.

Representante de EAPOL entre Tenedores de Clave Un protocolo ejemplar utilizado para comunicaciones entre los nodos y el servidor 105 es EAP (Protocolo de Autentificación Extensible) . El protocolo de EAP define un formato de mensaje y saludo inicial de intercambio para soportar múltiples métodos de autentificación . EAP típicamente se ejecuta directamente sobre capas de enlace de datos tales como el protocolo de Punto a Punto (PPP) o IEEE 802, sin requerir un IP. EAP proporciona su propio soporte para eliminación de duplicados y retransmisión, pero se basa en garantías de órdenes de capa inferior. La fragmentación no es soportada dentro del EAP mismo. Sin embargo, métodos individuales de EAP pueden soportar fragmentación tales como EAP-TLS donde los datos de certificados grandes necesitan transmitirse en varios paquetes. Para 802. IX, por ejemplo, los mensajes EAP entre el suplicante de autentificación y ROKH 120 se encapsulan en formatos de mensaje EAPOL (EAP sobre red de área local (LAN) ) . EAP es flexible y extensible para soportar múltiples mecanismos de autentificación tales como contraseña de usuario, autentificación basada en certificado, contraseña de una sola vez, ficha de autentificación o tarjeta inteligente, y similares. Se proporciona un vehículo para negociar y utilizar mecanismos apropiados de autentificación que incluyen aquellos que derivan material de claves en el nodo y el servidor 105 de autentificación . Un procedimiento de autentificación comienza cuando un nodo trasmite una solicitud de autentificación utilizando por ejemplo, un protocolo de autentificación extensible (EAP) que comprende paquetes de EAP Sobre la Red de Área Local (EAPOL) . El proceso de autentificación involucra varios paquetes de EAPOL que se transmiten y reciben, comenzando con un paquete de inicio de EAP y terminando con un paquete de mensaje de éxito de EAP o un paquete de mensaje de falla de EAP. El servidor de autentificación almacena las credenciales de autentificación de un dispositivo móvil (típicamente llamado Suplicante) que se está autentificando. Los servidores de autentificación también pueden conectarse a otros servidores de autentificación para obtener credenciales de autentificación de Suplicante que no se almacenan localmente . Cuando la jerarquía de clave 802. llr se utiliza para la gestión de claves, los mensajes de EAPOL para la autentificación y gestión de claves tienen que transportarse entre el tenedor de claves de nivel superior ROKH y el tenedor de claves de siguiente nivel RIKH. La FIGURA 2 ilustra un formato 200 de mensaje para su uso en la operación de algunas modalidades de la presente invención. Específicamente, la FIGURA 2 ilustra una encapsulación de mensaje EAP para una trama de comunicación de tenedor de claves L2 de acuerdo con algunas modalidades de la presente invención. El encabezado 205 de Control de Acceso a Medios (MAC) contiene las direcciones de MAC de origen de destino de cada salto. El encabezado 210 de Enrutamiento Ad Hoc (AHR) contiene las direcciones de MAC de origen y destino del autentificador y el dispositivo de finalización de ruta poligonal (es decir, R1KH y ROKH) . Un id de protocolo especial se coloca en el campo de id de protocolo del encabezado 210 de AHR para representar el paquete de representante de EAPOL . Una dirección 220 de MAC de suplicante también se incluye entre el encabezado 210 de AHR y el paquete 230 de EAPOL dentro del formato 200 de mensaje. El formato 200 de mensaje incluye un indicador 215 de i/r en el primer byte del cuerpo de carga útil poligonal para soportar ambos suplicantes 802. lli y 802. llr. El formato de mensaje además incluye un elemento 225 de información SSID para soportar AP virtuales. La dirección 220 de MAC suplicante se necesita para que el ROKH 120 conozca qué dispositivo de suplicante será capaz de enlazar el PMK_0 y PMK_1 a ese suplicante particular. Cuando el indicador 215 de i/r indica un suplicante 802. lli, el ROKH 120 deriva el PMK basándose en el estándar 802. lli y distribuye el PMK al R1KH. Cuando el indicador 215 de i/r indica un suplicante 802. llr, el ROKH 120 deriva al PMK_0 y PMK_1 basándose en una jerarquía de clave 802. llr y distribuye el PMK_1 al autentificador (R1KH) . El SSID 225 se necesita para la derivación de PMK_0 y PMK_1. Para AP virtuales, el suplicante puede seleccionar un SSID de un número de SSID disponibles . De acuerdo con la presente invención, cuando los mensajes entre los tenedores de claves que se transportan en la capa de red, la trama 230 de EAPOL junto con los campos i/r 215, SPA 220 y SSID 225 se colocan en la carga útil del paquete de IP (protocolo de internet) . Adicionalmente , al enviar la dirección de MAC del tenedor de claves también se incluye en la carga útil de IP, la cual se necesita para derivar PMK_1. Como se conoce bien en la técnica, como se ilustra en la FIGURA 2, la trama 230 de EAPOL incluye una versión 235 de protocolo la cual es un número binario sin signo, cuyo valor es la versión del protocolo de EAPOL. La trama 230 de EAPOL además incluye un tipo 240 de paquete el cual es un número binario sin signo, cuyo valor determina el tipo de paquete como sigue: a) EAP-paquete ; b) EAPOL-Inicio; c) EAPOL-Cerrar sesión; d) EAPOL-Clave; e) EAPOL-Encapsulado-ASF-Alerta . La trama 230 de EAPOL además incluye una longitud 245 del cuerpo de paquete la cual es un binario sin signo, cuyo valor define la longitud en octetos del campo de cuerpo de paquete. La trama 230 de EAPOL también incluye un cuerpo 250 de paquete el cual se presenta si el tipo de paquete contiene el valor de EAP-Paquete, EAPOL-Clave, de otra forma, no se presenta. Como se conoce bien en la técnica, como se ilustra en la FIGURA 2, el cuerpo 250 de paquete EAP incluye un campo 255 de código que identifica el tipo de paquete de EAP. Los Códigos de EAP se asignan como sigue: 1 = Solicitud; 2 = Respuesta; 3 = Éxito; 4 = Falla. El cuerpo 250 de paquete de EAP además incluye un campo 260 de identificador el cual ayuda a correlacionar respuestas con solicitudes. El cuerpo 250 de paquete de EAP además incluye un campo 265 de longitud que identifica la longitud del paquete de EAP que incluye el Código 255, Identificador 260, Longitud 265 y Campos 275 de Datos. El cuerpo 250 de paquete de EAP además incluye un campo 270 de tipo. El campo de tipo indica el tipo de la solicitud o respuesta. Este puede ser un tipo de identidad o un método de autentificación particular. El cuerpo 250 de paquete de EAP también incluye un campo 275 de datos tipo. El formato del campo 275 datos se determina por el campo 255 de Código y el campo 270 de tipo.

Clave de Distribución de Clave y Autorización de Función Como se apreciará por aquellos de experiencia ordinaria en la técnica, existen dos tipos de dispositivos suplicantes dentro de la red 100. Los dos tipos de dispositivos suplicantes dentro de la red 100 son los dispositivos de MAP 135-n y los dispositivos STA 140-n. De acuerdo con algunas modalidades de la presente invención, los dispositivos de MAP 135-n funcionan como R1KH para la jerarquía de clave 802. llr. Para proteger la distribución de PMK_1 del tenedor de claves superior ROKH 120 a R1KH, una Clave de Distribución de Clave (KDK) dos a dos se deriva para cada par de ROKH y MAP/IAP como se ilustra en la FIGURA 3. La FIGURA 3 es un diagrama de flujo que ilustra un proceso 300 de distribución de clave y autorización de función de acuerdo con algunas modalidades de la presente invención. Como se ilustra en la FIGURA 3, la operación comienza con una etapa 305 de autentificación inicial. La autentificación inicial, por ejemplo, puede ser una autentificación inicial de TTLS o TLS . Después, en la Etapa 310, el ROKH 120 obtiene los atributos de autorización del servidor 105 de autentificación en el mensaje final "éxito de autentificación" para el suplicante autentificado. Después, en la Etapa 315, se determina si el atributo de la función de suplicante autentificado es o no un tenedor de claves de nivel uno. Cuando el atributo de función de suplicante autentificado es un tenedor de claves de nivel uno, el proceso continúa en la Etapa 320 en la cual ROKH y R1KH suplicante inician un saludo inicial de 4 vías estilo 802. lli con PMK_0 para derivar KDK. Después, en la Etapa 320, la KDK se deriva como: KDK=KDF-KDKLen ( PMK_0 , "KDK Key derivation" , Snonce || Anonce || AA || SPA) . Donde : • KDF-256 se define en las secciones 8.5A.3 de 802. llr . · SNonce es un número aleatorio generado por RIKH, y ANonce es un número aleatorio generado ROKH. • los dos números aleatorios se intercambian durante los primeros dos mensajes de saludo inicial de 4 vías • AA es la dirección de MAC ROKH • SPA es la dirección de MAC RIKH Se apreciará por aquellos de experiencia ordinaria en la técnica que cuando un RIKH se mueve, la KDK sigue siendo la misma a menos que ROKH inicie un nuevo saludo inicial de cuatro vías KDK.

Autentificación e Inicio de Reautentificación La FIGURA 4 ilustra un procedimiento 400 de autentificación de acuerdo con algunas modalidades de la presente invención. Como se ilustra en la FIGURA 4, la operación comienza con un nodo 135 -n que se enciende en la Etapa 405. Después, en la Etapa 415, el nodo escucha para/explora las tramas de baliza de sus dispositivos vecinos que pueden ser ya sea un MAP 135 -n o un IAP 130-n. Después, en la Etapa 415, el nodo selecciona un IAP o MAP para comenzar el proceso de autentificación al elegir un dispositivo que ha indicado que tiene una conexión a un servidor 105 de autentificación . Después en la Etapa 420, una primera autentificación se completa para el nodo con el dispositivo de MAP vecino seleccionado. En la Etapa 425, después de la primera autentificación, el nodo puede iniciar la re-autentificación con otros dispositivos MAP vecinos que se han conectado y autentificado a un IAP dentro del mismo dominio de movilidad. Esta re-autentificación utiliza el proceso de transferencia rápida 802. llr para evitar la transacción completa de autentificación .

Flujo de Mensajes de Autentificación La FIGURA 5 es un diagrama 500 de flujo de mensaje que ilustra mensajes de autentificación intercambiados entre varios elementos de la red de la FIGURA 1 de acuerdo con algunas modalidades de la presente invención. Específicamente, la FIGURA 5 es un diagrama 500 de flujo de mensajes que ilustra mensajes de autentificación intercambiados entre un dispositivo suplicante y un MAP de R1KH (o IAP) . El puerto controlado 802. lx de MAP de R1KH es desbloqueado para estos mensajes desde un dispositivo no autentificado. Un MAP de R1KH es un dispositivo de MAP o IAP que tiene una conexión segura a ROKH; y se presume ya autentificado. Tomará la función R1KH para el dispositivo suplicante. En el escenario ejemplar del diagrama 500 de la FIGURA 5, MAPI 135-1 de R1KH y MAP2 135-2 de R1KH ya autentifican y tiene una conexión segura con ROKH 120. Por ejemplo, pueden ser un multisalto lejos de ROKH 120 como se ilustra por la trayectoria 505 de multisalto de la FIGURA 5. El suplicante (es decir, el dispositivo 140-1) en este escenario ejemplar, no se ha autentificado para MAPI 135-1 de R1KH y MAP2 135-2 de R1KH, los cuales son vecinos de un salto del suplicante. En este escenario ejemplar, los mensajes entre ROKH 120 y el servidor 105 de autentificación se transportan sobre el protocolo de servicio de usuario de marcación de autentificación remota (RADIUS) basada en el Protocolo de Datagrama de Usuario (UDP) . Los mensajes son protegidos al utilizar un mecanismo de seguridad de protocolo de RADIUS. Además, en este escenario ejemplar, los mensajes de autentificación entre R1KH 135-1 y ROKH 120 se transportan sobre el mecanismo intermediario de protocolo de autentificación extensible sobre red de área local (EAPOL) y los materiales de clave son protegidos con KDK entre el ROKH y R1KH. R1KH 135-1 notifica a ROKH 120 del SSID seleccionado por el suplicante 140-1 para la implementación de punto de acceso (AP) virtual. Como se ilustra en la FIGURA 5, el proceso de autentificación comienza cuando el suplicante 140-1 inicia una solicitud 510 de asociación a su MAPI 135-1 vecino. En respuesta, el MAPI 135-1 envía una respuesta 515 de asociación. Por ejemplo, el proceso de autentificación 802. lx será iniciado por el suplicante 140-1 (EAPOL-Inicio de suplicante) si la autentificación 520 de EAP 802. IX se selecciona a través de los primeros dos mensajes de asociación. Después de una autentificación exitosa de EAP 802. lx, un MSK será derivado del servidor 105 de autentificación a ROKH 120 en el mensaje de Aceptación de Acceso junto con el paquete de EAP-Éxito y otros atributos de autorización. Después de obtener MSK, ROKH 120 calcula un PMK_0 y un PMK_1 como se describe en el estándar 802. llr . Para decidir si un proceso de derivación de KDK va a llevarse a cabo o no, ROKH 120 comprueba la función del suplicante a partir de los atributos de autorización regresados del servidor 105 de autentificación secundario. Si el suplicante 140-1 tiene una función R1KH, se lleva a cabo el intercambio 525 de mensaje de derivación KDK. De otra manera, ningún proceso de derivación de KDK se comienza para el suplicante 140-1. Para generar los nombres únicos para el PMK_0 y PMK_1, ROKH 120 genera un número aleatorio denominado ANonce para utilizarse para derivar el nombre de PMK_0 y el nombre de PMK_1. Este A once se envía a MAPI 135-1 junto con PMK_1 y el nombre de PMK_1 en el mensaje 530. El ANonce se utilizará por MAPI 135-1 en el saludo inicial de 4 vías con el suplicante 140-1. El suplicante 140-1 entonces utilizará el mismo ANonce para derivar los mismos nombres de claves. Después de recibir el PMK_1 530 de ROKH 120, MAP 1 inicia un saludo inicial 535 de 4 vías con el suplicante 140-1 para generar un PTK para proteger el enlace entre el suplicante 140-1 y MAP3 135-3 (no mostrado en la FIGURA 5) . Después de esto, MAPI 135-1 y el suplicante 140-1 pueden comunicarse dentro de un enlace 540 seguro. La FIGURA 6 ilustra un intercambio 600 de mensaje detallado ejemplar como se describe previamente en la presente en la FIGURA 5 cuando la autentificación 802. lx es EAP-TTLS de acuerdo con algunas modalidades de la presente invención. Como se ilustra en la FIGURA 6, el suplicante 140-1 envía una trama 605 EAPOL-inicio al MAP 135-1 de R1KH cuando se selecciona la autentificación 802. lx. R1KH 135-1 entonces transporta esta trama 610 a ROKH 120. El ROKH 120 toma el control de todo el flujo de mensaje entre el suplicante 140-1 y el servidor 105 de autentificación . El MAP 135-1 de R1KH implementa una máquina de estado de reintento para que EAPOL-Inicio envíe al ROKH 120. El último mensaje PMK_1 ACK 615 completa la máquina de estado en ROKH 120. El último mensaje 620 de ROKH 120 a R1KH 135-1 contiene PMK_1, el Nombre Rl y Añonee . Si el suplicante 140-1 es un dispositivo 802. lli, sólo PMK 802. lli se distribuye a R1KH 135-1.

RE-Autentificación (Transición Rápida) Con referencia nuevamente a la FIGURA 5, después de la primera autentificación con MAPI 135-1, el suplicante 140-1 puede iniciar el proceso de re-autentificación (transferencia rápida) con cualquiera de los dispositivo 135-n de MAP vecinos que han anunciado una conexión segura a un servidor 105 de autentificación y están en el mismo dominio de movilidad. El proceso de re-autentificación sigue la transición BSS rápida 802. llr: mecanismo base sobre el aire. La solicitud de re-autentificación incluye ROName, RIName, SNonce y su nombre ROKH- ID del tenedor de claves de nivel superior asociado. ROName y RIName también se incluyen. Como se ilustra en la FIGURA 5, después de que se completa el procedimiento de autentificación entre el suplicante 140-1 y MAPI 135-1, el suplicante 140-1 inicia un procedimiento de re-autentificación con su siguiente dispositivo vecino MAP2 135-2 de R1KH. Por ejemplo, un primer mensaje con transferencia rápida 545 se envía desde el suplicante 141-1 a MAP2 135-2. En respuesta, AP2 135-2 envía una solicitud 550 de PMK a ROKH 120 que solicita el PMK_1 correspondiente de ROKH 120 si no contiene ese PMK_1 identificado por RI ame . La solicitud PMK_1 a ROKH debe incluir el ROName . En respuesta, ROKH 120 envía PMK_1 555 a MAP2 135-2. Después de esto, el MAP2 135-2 envía el segundo mensaje al suplicante 140 cuando MAP2 135-2 obtiene el PMK_1 correspondiente. El suplicante 140-1 y MAP2 135-2 completan los mensajes 560 de transferencia rápida y resultan en un enlace 565 seguro. Se apreciará por aquellos de experiencia ordinaria en la técnica que esta re-autentificación de transferencia rápida puede repetirse para cualquier número de dispositivos de MAP o IAP dentro del campo de acción de comunicación (en el vecindario) del suplicante . En la especificación anterior, modalidades especificas de la presente invención se han descrito. Sin embargo, alguien de experiencia ordinaria en la técnica aprecia que varias modificaciones y cambios pueden hacerse sin apartarse del alcance de la presente invención como se establece en las reivindicaciones siguiente. Por consiguiente, la especificación y las figuras se interpretarán como en un sentido ilustrativo en lugar de uno restrictivo, y todas las modificaciones se pretenden para incluirse dentro del alcance de la presente invención. Los beneficios, ventajas, soluciones a los problemas, y cualesquier elementos que pueden provocar algún beneficio, ventaja o solución para presentarse o pronunciarse más no se interpretarán como una característica o elemento crítico, requerido o esencial de cualquiera o todas las reivindicaciones. La invención se define solamente por las reivindicaciones anexas que incluyen cualesquier enmiendas durante hechas durante el estado pendiente de esta solicitud y todos los equivalentes de estas reivindicaciones como se emitieron.

Claims

NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención se considera como novedad y por lo tanto se reclama como propiedad lo descrito en las siguientes reivindicaciones.
REIVINDICACIONES 1. Un método de autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en la infraestructura, el método caracterizado porque comprende: autentificar inicialmente un suplicante que incluye determinar uno o más atributos de función de suplicante autentificados con un servidor de autentificación; obtener uno o más atributos de autorización del servidor de autentificación mediante un tenedor de claves de nivel superior; determinar si el atributo de la función de solicitante autentificado es un tenedor de claves de nivel uno mediante el tenedor de claves de nivel superior; iniciar un saludo inicial de cuatro vías entre el tenedor de claves de nivel superior y el suplicante con una clave maestra dos a dos (PMK)_0 para derivar una Clave de Distribución de Clave (KDK) cuando el atributo de función de suplicante autentificado es un tenedor de claves de nivel uno; y cuando el atributo de función de suplicante autentificado no es un tenedor de claves de nivel uno; comunicar una clave maestra dos a dos de nivel uno (PMK)_1 del tenedor de claves de nivel superior a un tenedor de claves de nivel uno, iniciar un saludo inicial de cuatro vías entre el tenedor de claves de nivel uno y el suplicante con la clave maestra de dos a dos de nivel uno (PMK)_1 para generar un enlace de comunicación segura entre el suplicante y el tenedor de claves de nivel uno, y comunicarse en el enlace seguro entre el tenedor de claves de nivel uno y el suplicante. 2. El método de autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en la infraestructura de conformidad con la reivindicación 1, caracterizado porque el saludo inicial de cuatro vías entre el tenedor de claves de nivel superior y el tenedor de claves de nivel uno comprende un saludo inicial de cuatro vías estilo 802. lli para derivar una KDK entre el tenedor de claves de nivel superior y el tenedor de claves de nivel uno; y además donde el saludo inicial de cuatro vías entre el tenedor de claves de nivel uno y el suplicante comprende un saludo inicial de cuatro vías estilo 802. lli para derivar una clave transitoria dos a dos
(PTK) entre el tenedor de claves de nivel uno y el suplicante . 3. El método de autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en la infraestructura de conformidad con la reivindicación 1, caracterizado porque la KDK se deriva como : KDK = KDF-KDKLen (PMK_0 , "KDK Key derivation" , SNonce II ANonce || AA || SPA) . donde : KDF-256 es un número predefinido, SNonce es un número aleatorio generado por el suplicante , ANonce es un número aleatorio generado por el tenedor de claves de nivel superior, los dos números aleatorios se intercambian durante los primeros dos mensajes del saludo inicial de cuatro vías, AA es la dirección de MAC del tenedor de claves de nivel superior, y SPA es la dirección de MAC del suplicante
4. El método de autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en la infraestructura de conformidad con la reivindicación 1, caracterizado porque la etapa de autentificación inicial incluye comunicación de un mensaje final de "éxito de autentificación" , y además donde uno o más atributos de autorización se obtienen del mensaje final de "éxito de autentificación" .
5. El método de autentificación segura de un nodo dentro de una red de multisalto inalámbrica basada en la infraestructura de conformidad con la reivindicación 1, el método caracterizado además porque comprende: iniciar una re-autentificación con otro tenedor de claves de nivel uno por el suplicante, donde otro tenedor de claves de nivel uno ha sido autentificado y conectado al tenedor de claves de nivel superior dentro de un mismo dominio de movilidad en donde la re-autentificación comprende: comunicar un mensaje utilizando un proceso de transferencia rápida desde el suplicante hasta el otro tenedor de claves de nivel uno; comunicar la clave maestra dos a dos del nivel uno (PMK)_1 del tenedor de claves de nivel superior al otro tenedor de claves de nivel uno; completar una transferencia rápida entre el otro tenedor de claves de nivel uno y el suplicante utilizando la clave maestra dos a dos de nivel uno (PMK)_1 para generar un enlace de comunicación segura entre el suplicante y el otro tenedor de claves de nivel uno; y comunicarse en el mismo enlace seguro entre el otro tenedor de claves de nivel uno y el suplicante.
6. Un método para comunicar entre un tenedor de claves de nivel superior y un tenedor de claves de nivel uno para autentificación de seguridad y gestión de claves dentro de una red de multisalto inalámbrica basada en la infraestructura, caracterizado porque comprende: comunicar un mensaje que tiene un formato de mensaje que comprende: un encabezado de Control de Acceso a Medios (MAC) que contiene direcciones de MAC de origen y destino de por lo menos un salto; un encabezado de Enrutamiento Ad Hoc (AHR) que contiene : unas direcciones de MAC de origen y un destino del tenedor de claves de nivel uno y el tenedor de claves de nivel superior, y una identificación de protocolo que representa un paquete representante de protocolo de autentificación extensible sobre red de área local (EAPOL) ; una dirección de MAC suplicante; un indicador de i/r; y un SSID.
7. El método de conformidad con la reivindicación 6, caracterizado porque la dirección de MAC de suplicante identifica qué dispositivo suplicante enlaza una clave maestra dos a dos_0 (PMK_0) y una PMK_1.
8. El método de conformidad con la reivindicación 6, caracterizado porque el indicador de i/r que indica un suplicante 802. lli identifica que el PMK se deriva basándose en un estándar 802. lli y el PMK se distribuirá a un R1KH.
9. El método de conformidad con la reivindicación 6, caracterizado porque el indicador de i/r que indica un suplicante 802. llr identifica que el PMK_0 y PMK_1 se derivan basándose en la jerarquía de clave 802. llr y el PMK_1 se distribuirá al autentificador .
10. El método de conformidad con la reivindicación 6, caracterizado porque el SSID se utiliza para la derivación de PMK_0 y PMK_1 para un punto de acceso virtual, y además donde un suplicante selecciona un SSID de una pluralidad de SSID disponibles.
11. El método de conformidad con la reivindicación 6, caracterizado porque el mensaje se transporta en una capa de comunicación seleccionada de un grupo que comprende una capa 2 y una capa 3 , y además, en donde cuando el formato de mensaje se coloca en la carga útil de paquete de protocolo de Internet (IP), una dirección de MAC R1KH se agrega en los contenidos de un mensaje.