Una arquitectura de control de acceso a redes de área local inalámbricas

Transcripción

1 XIV JORNADAS DE PARALELISMO LEGANES, MADRID, SEPTIEMBRE Una arquitectura de control de acceso a redes de área local inalámbricas Manuel Sánchez Cuenca 1 y Oscar Canovas Reverte 1 Resumen En este artículo se presenta el diseño de un mecanismo de control de acceso para redes inalámbricas basado en el estándar IEEE 802.1X, y haciendo uso de certificados digitales para proporcionar tanto autenticación como autorización para el cliente. Estableciendo al final del proceso de conexión una clave para cifrar la comunicación inalámbrica entre el cliente y el punto de acceso. Palabras clave 802.1X, , control de acceso, autenticación, autorización, certificado. E I. INTRODUCCIÓN N la actualidad es común llegar a un lugar público como un aeropuerto o un hotel, y encontrarse con una infraestructura de red inalámbrica para poder hacer uso de ella con solo solicitarlo. Hasta ahora, el mecanismo para permitir que los usuarios se conectaran a una red había sido haciendo uso de bases de datos en las que se introducían manualmente los usuarios permitidos, por ejemplo, mediante login y password al estilo de UNIX. Pero esto podía llegar a ser un problema si las bases de datos crecían demasiado o los usuarios cambiaban frecuentemente, ya que se requería mucho tiempo para mantener actualizados estos datos. Gracias a los sistemas de autorización basados en certificados, este problema se soluciona enormemente, ya que permite que un usuario desconocido para el sistema pueda hacer uso de la red con solo proporcionarle el certificado adecuado. Además en este certificado puede incluirse información sobre el usuario como el tiempo máximo que puede utilizar la red, los servicios a los que puede acceder o los recursos que puede utilizar. Pero con las redes inalámbricas no solo existe el problema de cómo permitir el uso de la red a los usuarios de una forma sencilla, sino que debido a que cualquier equipo con tarjeta inalámbrica puede escuchar del medio, aparecen graves problemas de seguridad. Estos problemas están relacionados con el uso de la red por parte de usuarios no autorizados, la privacidad de los datos transmitidos o la disminución del rendimiento de la red por su uso sin autorización; problemas que no son fáciles de solucionar si no se introducen nuevos componentes para proporcionar un nivel de seguridad adicional al de las redes tradicionales. 1 Departamento de Ingeniería y Tecnología de Computadores, Universidad de Murcia En cuanto a las redes inalámbricas actuales, en los últimos años han ido apareciendo una serie de estándares o especificaciones de grupos de empresas para cubrir las distintas áreas de esta tecnología. Por ejemplo, podemos encontrar los estándares IEEE [1], con todas sus subespecificaciones de nivel físico, o HiperLAN [2] para redes inalámbricas de área local. Mientras que para las redes de área personal ha aparecido Bluetooth [1]. Estas especificaciones han ido proponiendo distintas soluciones a los problemas existentes en este área, como el uso de indentificadores de red, cifrado de las comunicaciones o control de acceso. Siendo esta última técnica la que puede proporcionar un nivel real de seguridad si se combina adecuadamente con las demás, como se verá a lo largo de este documento. Para realizar el control de acceso se dispone de varias alternativas, siendo unas más elaboradas que otras, y por lo tanto más adecuadas para entornos de mayor tamaño. Estas técnicas van desde simplemente realzar un filtrado por la dirección MAC de los usuarios, hasta un arquitectura completa definida por el estándar IEEE 802.1X [3], que puede realizar el control de acceso en base a certificados y establecer una clave inicial para cifrar la comunicación inalámbrica del usuario. Entre las entidades que se definen en el estándar IEEE 802.1X aparece el servidor de autenticación, que es un elemento encargado de descargar al punto de acceso del trabajo de realizar la autenticación de los usuarios. Es posible encontrar diferentes especificaciones para este elemento, entre las que se encuentra la de la arquitectura AAA [4], de la que tanto RADIUS [5] como DIAMETER [6] se basan. Como más adelante se detallará, 802.1X será la alternativa elegida para proporcionar control de acceso al protocolo que se está diseñando. Esta arquitectura, además del servidor de autenticación, tiene otras dos entidades: el cliente y el controlador de acceso. El cliente será el dispositivo que intenta conectarse a la red, mientras que la función de controlador de acceso la realizará el punto de acceso, que es el equipo que proporciona conexión al resto de la red al cliente. La idea es que el cliente sea un dispositivo móvil que en algún momento determinado puede entrar en el área de cobertura del punto de acceso. En cuanto el punto de acceso detecta esto, le pide que se identifique, y se

2 2 Sánchez y Cánovas: Una arquitectura de control de acceso a redes de área local inalámbricas comunica con el servidor de autenticación para que, en base a la información que el cliente le ha proporcionado, determine si está autorizada a hacer uso de la red, y en tal caso en que condiciones. Además, una vez que se acepta al cliente, se establece una clave para cifrar sus comunicaciones a través del medio inalámbrico, que periódicamente irá cambiando para proporcionarle un mayor nivel de seguridad. En el siguiente apartado se realiza un análisis de las tecnologías estudiadas para realizar este diseño, que se detallará en el apartado III. A continuación, en el apartado IV se muestra la implementación de un prototipo del sistema mediante la modificación de algunas aplicaciones ya existentes. Las conclusiones alcanzadas tras este estudio y diseño del protocolo se especifican en el apartado V. Y por último en el apartado VI se indican las referencias utilizadas para realizar el estudio. A. Objetivo II. ANÁLISIS El objetivo de este estudio es diseñar un sistema de control de acceso a una red inalámbrica proporcionando autenticación y autorización, de manera que además se establezca un clave única para cifrar la comunicación del cliente hasta llegar al punto de acceso, solucionando así el problema de la inseguridad de las redes inalámbricas de una forma transparente para el usuario. Pero no solo esto, sino que una vez que se ha establecido la conexión, periódicamente debe renegociarse la clave para no darle a un potencial atacante el tiempo necesario para que pueda romper esta clave. B. Redes inalámbricas Ya se ha comentado que en el campo de las redes inalámbricas han aparecido una serie de normas que intentan cubrir todos los ámbitos de su uso. De entre estas, el estándar IEEE [1] es el más extendido en la actualidad. Este estándar describe una arquitectura modular basada en celdas básicas o BSS, donde un conjunto de dispositivos intentan acceder al medio haciendo uso de una misma función de coordinación. Estas unidades pueden conectarse mediante una red o sistema de distribución de manera que dos equipos que estén en diferentes celdas puedan comunicarse. El elemento que sirve de puente entre la red inalámbrica y la red cableada es el punto de acceso. Éste será el que se encargue de realizar el control de acceso sobre los nuevos clientes y de comunicarse con el servidor de autenticación, que deberá estar accesible a través del sistema de distribución. Antes de que un equipo que se conecta a un punto de acceso pueda transmitir los datos, debe realizar una fase de asociación, en la que da a conocer su identificador al punto de acceso para que éste informe al resto de la red de que dicho equipo se encuentra bajo su área de cobertura. Es tras esta fase cuando debe realizarse el proceso de control de acceso para ver si realmente el cliente tiene permiso para hacer uso de la red. Uno de los mecanismos utilizados por las redes para intentar proporcionar un nivel mínimo de seguridad es el cifrado de los datos que se transmiten entre el cliente y el punto de acceso para que ningún equipo que no esté autorizado pueda escuchar dicha trasmisión. Para ello se utiliza el algoritmo WEP [1], que se basa en el uso de un secreto compartido de 40 bits o clave WEP entre los dos extremos de la comunicación. El algoritmo de cifrado consiste en generar una secuencia pseudoaleatoria de bits del mismo tamaño que los datos a trasmitir, utilizando como semilla del generador la concatenación del secreto compartido y un vector de inicialización de 24 bits. La secuencia resultante se utiliza para realizar un XOR bit a bit con el paquete a mandar, y al final se añade el vector de inicialización al criptograma antes de mandarlo. En el receptor, una vez que se recibe el paquete, se recupera el vector de inicialización y se concatena con la clave WEP que este extremo comparte, para poder generar la secuencia pseudoaleatoria correspondiente para descifrar el criptograma. De entre las especificaciones físicas de la norma , la más utilizada actualmente es la b, que trabaja en la frecuencia de 2.5 GHz para conseguir transmisiones de hasta 11 Mbps. Teniendo en cuentea su popularidad, ésta será la especificación utilizada para desarrollar este protocolo C. Control de acceso La especificación IEEE 802.1X [3] es un estándar de control de acceso desarrollado por el IEEE que permite utilizar diferentes mecanismos de autenticación. Su funcionamiento se basa en el concepto de puerto, visto éste como el punto a través del que se puede acceder a un servicio proporcionado por un dispositivo, que en este caso será el punto de acceso. En principio todos los puertos está desautorizados, excepto uno que el punto de acceso utiliza para comunicarse con el cliente. Cuando un nuevo cliente entra en su área de cobertura, le pasa al punto de acceso información de autenticación, dependiendo del mecanismo utilizado, que éste reenvía al servidor de autenticación. Cuando éste le contesta, si la respuesta es que el cliente puede hacer uso de la red, autoriza un puerto para que lo utilice el cliente. La Figura 1 muestra la estructura general de un sistema IEEE 802.1X. Figura 1. Arquitectura IEEE 802.1X

3 XIV JORNADAS DE PARALELISMO LEGANES, MADRID, SEPTIEMBRE En esta arquitectura, la información de autenticación se encapsula en el protocolo EAP [7], que es el que permite que haya varios mecanismos de autenticación, ya que proporciona varios subprotocolo, entre los que por ejemplo se encuentran EAP-MD5, que basa la autenticación del cliente en el uso de login y password, o EAP-TLS [8], que se basa en el uso del protocolo TLS [9] y permite autenticación mutua entre los dos extremos. EAP-TLS es el mecanismo que se utilizará en este protocolo para proporcionar autenticación, ya que TLS utiliza certificados X.509 [16] para identificar a las partes, lo que permite realizar el proceso de autenticación sin necesidad de hacer uso de bases de datos de usuarios permitidos, que es uno de los problemas que se ha comentado en la introducción. Además tras el proceso de conexión se genera una clave compartida por los dos extremos que puede utilizarse para derivar una clave para el cifrado de las transmisiones inalámbricas, que es uno de los objetivos de este diseño. Los datos del protocolo EAP que se intercambian entre el cliente y el punto de acceso se transmiten mediante el protocolo EAPOL [3], que especifica como encapsular los paquetes EAP en una red de área local. D. Autenticación en WLAN La especificación de AAA [4] define lo que debe ser un servidor de autenticación. Esta arquitectura se basa en el uso de servidores AAA comunicándose mediante un protocolo estándar para autenticar usuarios, manejar peticiones de autorización y realizar la contabilidad del sistema. Un servidor AAA debe ser capaz de recibir peticiones, examinar el contenido de dichas peticiones, determinar que autorización se está pidiendo, recuperar las políticas que necesite de un repositorio, evaluar la petición y obtener la respuesta a la petición, o reenviar la petición a otro servidor AAA. RADIUS [5] es un servidor AAA donde los clientes son servidores de acceso a la red (NAS). Éstos, mandan información al servidor cuando un nuevo cliente intenta conectarse, entonces el servidor realiza el proceso de autenticación del usuario, y devuelve al NAS la información de configuración necesaria para que éste trate al cliente de la manera adecuada. Como servidor AAA que es, también puede actuar como proxy del NAS y reenviar la petición a otro servidor RADIUS. Toda la comunicación entre el NAS y RADIUS se encuentra cifrada mediante un secreto compartido que nunca se transmite por la red. Un servidor RADIUS soporta varios métodos para autenticar al usuario. Además, este protocolo es extensible ya que trabaja mediante 3-tuplas de atributos formadas por el nombre, longitud y valor, lo que permite que se puedan añadir nuevos atributos sin perjudicar las implementaciones existentes de RADIUS. DIAMETER [6] es otro servidor AAA que en principio mejora a RADIUS, ya que al aumentar la complejidad y densidad de los routers y NAS s RADIUS se ha vuelto inapropiado. El problema de este protocolo es que en el momento de realizar este estudio aún se encontraba en estado de draft, por lo que podía ser arriesgado utilizarlo. Por ello en este proyecto se ha hecho uso de RADIUS como servidor de autenticación a pesar de los problemas que tiene. E. Autorización en WLAN Para proporcionar autorización a un cliente, si no se quiere mantener una base de datos con los permisos de cada usuario, puede hacerse uso de un certificado digital, que es una estructura que contiene información del usuario en cuanto a identidad o permisos, y que va firmado digitalmente por una entidad de confianza. Los certificados X.509 [16] son los primeros que aparecieron, y contienen, además de la información básica del usuario, información sobre la entidad de autorización, el algoritmo de firma y la caducidad del certificado entre otras. Este tipo de certificados tiene algunas deficiencias como no permitir la delegación, no poder asignarse a grupos o no definir un algoritmo para obtener decisiones a partir de los certificados. Los certificados SPKI [10] definen una estructura más sencilla y tres tipos de certificados, y al contrario que X.509 si que define un algoritmo para obtener decisiones, permite delegación y formación de grupos. Es por estas ventajas que los certificados SPKI se utilizarán en este diseño para proporcionar autorización Figura 2. Arquitectura general del sistema

4 4 Sánchez y Cánovas: Una arquitectura de control de acceso a redes de área local inalámbricas a los clientes, aunque para la autenticación se usarán certificados X.509, ya que TLS trabaja con ellos. III. DISEÑO Se puede ver una imagen general de cómo sería el sistema donde aplicar este protocolo en la Figura 2. En ella se pueden ver varios puntos de acceso y un servidor de autenticación conectados mediante una red, y un conjunto de clientes que cuando entran por primera vez en el área de cobertura de un punto de acceso inician el proceso de conexión. Este proceso consta básicamente de tres fases: autenticación, autorización y distribución de la clave; pero una vez conectado el cliente, se realiza periódicamente el proceso de renegociación de clave, y si entra en el área de cobertura de otro punto de acceso, se reutiliza la conexión anterior para que el proceso de conexión sea más rápido. En la Figura 3 se puede ver el esquema de las fases del protocolo, indicando las partes implicadas en cada una de las fases. Figura 3. Esquema del protocolo A. Fase de autenticación La primera fase funciona siguiendo el estándar IEEE 802.1X, es decir cuando el cliente entra en el área de cobertura del punto de acceso, este le pide su identidad, y el cliente se la proporciona. Aunque en este punto se ha modificado el estándar para que el cliente no tenga que dar ningún nombre de usuario, ya que como la finalidad de este diseño es obtener un sistema anónimo basado en certificados, esta es una carga innecesaria para el protocolo. Tras esta fase inicial, como estamos utilizando EAP- TLS, se realiza el proceso de establecimiento de conexión TLS entre los extremos o handshake TLS, donde según el estándar tanto el cliente como el servidor de autenticación se autentican mutuamente mediante certificados X.509 y negocian los parámetros de configuración necesarios para establecer el canal de comunicación seguro. En este punto, volviendo a la idea de que el cliente va a ser anónimo y por lo tanto no debe autenticarse de ninguna manera, se vuelve a modificar el protocolo para que el cliente no tenga que presentar su certificado X.509. Una vez terminado el handshake TLS y si todo ha ido bien, se ha establecido un canal TLS entre el cliente y el servidor de autenticación, y por lo tanto ambos tienen un misma clave maestra que posteriormente se utilizará para derivar la clave WEP. B. Fase de autorización En esta fase, el cliente indica al servidor de autenticación cual es el tipo de conexión que desea en cuanto al ancho de banda requerido y el tiempo que va a estar conectado, junto con los certificados SPKI que demuestran que dicho usuario está autorizado a realizar el uso de la red que pide. Entonces el servidor evalúa los certificados y comprueba si todo es correcto y si el nivel de privilegios del cliente es el necesario, continuando con el protocolo si todo va bien y desautorizando al cliente a acceder a la red si hay algún problema. Los parámetros del cliente se mandan en una estructura firmada PKCS#7 [11], de manera que el servidor de autenticación pueda estar seguro de que nadie ha modificado estos parámetros. Además, toda la información relativa a la autorización del cliente, parámetros y certificados, se manda a través del canal TLS establecido anteriormente, de manera que solo pueden haber sido enviados por parte del cliente con el que se ha iniciado el proceso de conexión. Dicha estructura PKCS#7 contiene el certificado del cliente con el que se ha realizado la firma para que el servidor pueda verificar que la firma es correcta. En el mensaje mediante el cual el servidor le pide al cliente sus parámetros de conexión, se incluye un identificador de 4 bytes aleatorio, que posteriormente se utilizará para derivar la clave WEP junto con la dirección MAC del punto de acceso y la clave maestra de la conexión TLS anteriormente establecida. C. Fase de distribución de clave En esta fase del protocolo únicamente participan el punto de acceso y el servidor de autenticación, y consiste en que éste último le pase al primero la clave WEP que debe utilizar con el cliente, y los parámetros de utilización de la red necesarios. Esta clave WEP la habrá generado el servidor haciendo un hash MD5 sobre la concatenación de la clave maestra generada por EAP- TLS, la dirección MAC del punto de acceso, y los cuatro bytes aleatorios generados anteriormente. Por su parte, el punto de acceso debe comprobar que en su situación actual puede soportar las necesidades del nuevo cliente, es decir debe comprobar que la suma total del ancho de banda necesitado por todos los usuarios que actualmente hay conectados, junto con el requerido por el nuevo cliente, no sobrepase su capacidad; y que vaya a estar disponible el tiempo que el cliente requiere; informando al servidor de autenticación sobre la decisión que tome. Tras estas fases, el proceso de conexión ha terminado, y si todo se ha realizado correctamente, el servidor de autenticación avisa al punto de acceso de que puede dejar al cliente hacer uso de la red, avisando este a su vez al cliente. Por su parte el cliente, que habrá generado

5 XIV JORNADAS DE PARALELISMO LEGANES, MADRID, SEPTIEMBRE la clave WEP de la misma forma que el servidor, puede comenzar a hacer uso de la red, cifrándose sus comunicaciones con el punto de acceso mediante la clave única que se acaba de generar. En este punto del diseño hay que dejar una puerta abierta a una probable modificación futura, ya que es posible que al aumentar la potencia de los ordenadores, una clave WEP de hasta 16 bytes (tamaño del hash MD5) no proporcione suficiente seguridad, por lo que el protocolo dejaría de ser seguro. Por ello, en el caso de necesitar una clave WEP de mayor tamaño, podría hacerse un hash MD5 de los tres valores anteriores, junto con el hash inicial, y los 16 bytes resultantes concatenárselos a los 16 bytes iniciales. Este proceso puede repetirse el número de veces que sea necesario para obtener claves WEP de cualquier tamaño. Este mecanismo de extensión de la longitud de la clave puede verse en la Figura 4. WEP = MD5( CM, PA, N) 0 WEPn = WEPn 1 MD5( CM, PA, N, WEPn 1) CM Clave PA Direción N Nonce o maestra MAC valor del punto aleatorio Figura 4. Obtención de la clave WEP D. Fase de renegociación de acceso Periódicamente y dependiendo esta periodicidad del nivel de seguridad que quiera el usuario, es posible renegociar la clave WEP que se está utilizando para cifrar la comunicación entre el cliente y el punto de acceso. Para ello, el cliente inicia un proceso de renegociación de conexión TLS, y cuando el servidor detecta el inicio de este proceso de renegociación, vuelve a activar el protocolo de conexión en la fase de petición de parámetros. Pero en esta ocasión, se indica que no es necesario que el cliente mande sus parámetros, a no ser que quiera cambiarlos, sino que únicamente se realiza esta fase para indicar al cliente cual es la nueva cadena aleatoria para generar la clave WEP. De esta manera al terminar el nuevo proceso de conexión, tanto el punto de acceso como el cliente tendrán la nueva clave WEP a utilizar para cifrar sus comunicaciones. E. Fase de movilidad Esta fase se apoya en la anterior, ya que cuando un cliente detecta que está en el área de cobertura de un nuevo punto de acceso, en lugar de iniciar el proceso de conexión descrito desde el principio, inicia un proceso de renegociación de conexión TLS. De esta manera la nueva conexión TLS se basa en la anterior, por lo que ya no se realiza el proceso de negociación de la conexión ni se manda el certificado del servidor. Además de forma automática se inicia la fase de renegociación de clave, por lo que tampoco será necesario que el cliente pase sus parámetros de conexión, a no ser que éste quiera lo contrario. De esta manera, al cambiar de punto de acceso no se realiza el proceso de conexión completo. Si esto no se hiciera de esta manera, al cambiar de punto de acceso el cliente estaría un periodo de tiempo, mientras se realiza la conexión, sin poder hacer uso de la red; y en el caso de que este cambio se realizara frecuentemente, podría perjudicar seriamente el rendimiento del sistema. IV. IMPLEMENTACIÓN La implementación del prototipo de este protocolo se ha basado en una serie de aplicaciones y librerías ya existentes, a las que se le ha añadido el soporte para las nuevas fases. A. HostAP Hostap [12] es un driver para Linux que permite que un ordenador con una tarjeta inalámbrica funcione como punto de acceso, además ya lleva implementado el código del estándar IEEE 802.1X. La versión utilizada en este desarrollo ha sido la del 12/10/2002 y el equipo sobre el que se ha instalado ha sido un AMD k6-2 a 400 MHz con Red Hat Linux 6.2 instalado en él. En cuanto a las modificaciones realizadas sobre este software, se han centrado en añadirle soporte para la fase de distribución de la clave, donde debe guardar la clave para cada cliente, y cuando reciba la respuesta del servidor de autenticación, si esta es afirmativa, establecer la clave previamente guardada para la comunicación con el cliente. Durante el resto del protocolo, este dispositivo únicamente funciona como elemento de paso, es decir reenvía todo lo que le llega desde el cliente al servidor de autenticación y viceversa. Función que ya realizaba por implementar el estándar IEEE 802.1X. B. XSupplicant XSupplicant [13] es una aplicación que pertenece al proyecto Open1X, un intento de obtener una implementación completa y abierta del estándar IEEE 802.1X para Unix, pero que actualmente solo tiene disponible el cliente. La versión utilizada de éste programa es la 0.5 sobre un Pentium IV a 2 GHz con Red Hat Linux 7.0 instalado en él. Las modificaciones realizadas sobre XSupplicant se centran básicamente en la fase de autorización, ya que al seguir el estándar IEEE 802.1X la autenticación ya la incorpora y en la fase de distribución de la clave no interviene. Aunque también hay que incorporar soporte para la renegociación de clave y la movilidad. Para la fase de autenticación, debe contestar al servidor de autenticación cuando éste se lo solicite, con los parámetros de conexión que puede obtener de un fichero de perfil del usuario. Además debe guardar los 4 bytes aleatorios que recibe para posteriormente utilizarlos al generar la clave WEP.

6 6 Sánchez y Cánovas: Una arquitectura de control de acceso a redes de área local inalámbricas Una vez que todo el proceso de conexión ha terminado y XSupplicant recibe la autorización de hacer uso de la red, es necesario establecer la clave WEP que previamente se ha generado mediante el hash de las partes apropiadas. Por último es necesario añadir soporte para iniciar la renegociación de clave. Y para detectar cuando se debe reutilizar una conexión anterior en lugar de iniciar un proceso completo de establecimiento de conexión. Además de estas modificaciones principales, como ya se ha comentado en el diseño, ya no se manda ningún nombre de usuario al punto de acceso ni el certificado del cliente, aunque esto último lo realiza OpenSSL de forma automática al no recibir la petición de mandar este certificado por parte del servidor. C. FreeRADIUS FreeRADIUS [14] es una implementación abierta para UNIX de RADIUS, que tiene la ventaja de que se ha comprobado su interoperabilidad con XSupplicant en [17]. Se usará la versión 0.8.1, instalándose en el mismo equipo que hará de punto de acceso. La mayor parte de los cambios realizados se han producido en FreeRADIUS, debido a que ya sea con el cliente o con el punto de acceso, pero el servidor de autenticación siempre está implicado en alguna fase del protocolo. La primera modificación realizada consiste en no pedirle al cliente ningún certificado al realizar el handshake TLS. Para ello, tanto al crear el contexto SSL como al crear una sesión SSL concreta, se indicado que no pida este certificado, ya que por defecto FreeRADIUS siempre lo pide. Fuera de esta modificación, todo lo demás tiene que ver con el soporte para las nuevas fases del protocolo, ya que aquí únicamente se realizaba el handshake TLS y si todo iba bien se autorizaba al cliente. Primero, en la fase de autorización se comunica con el cliente para enviarle los 4 bytes aleatorios necesarios para generar la clave WEP, y para obtener sus parámetros y certificados. Si los certificados autorizan al cliente a realizar el uso que pide, se guardan estos parámetros. Para posteriormente, en la fase de distribución de la clave pasárselos al punto de acceso. Pero antes de esto, se le manda al punto de acceso la clave WEP generada. Para soportar la renegociación de clave y la movilidad, como estas fases se basa en la renegociación de la sesión TLS no hay que añadir nada, ya que esto lo hace OpenSSL, excepto que cuando se pasa el valor aleatorio al cliente, se debe avisar de que no es necesario que proporcione los parámetros de conexión. D. OpenSSL OpenSSL [15] es una implementación de SSL para Unix. La versión utilizada en este diseño ha sido la 0.9.7a. Esta librería es necesaria para poder instalar tanto FreeRADIUS como XSupplicant, ya que al usar EAP- TLS necesitan de una implementación de TLS que aquí se proporciona. En cuando a modificaciones, no se ha tenido que realizar ninguna sobre este software, ya que únicamente se utiliza por los extremos en la fase de autenticación para establecer el canal TLS y así además generar la clave maestra; y en la fase de autorización para pasar los parámetros a través del canal TLS. Y este uso es el normal de TLS. V. CONCLUSIONES Tras este estudio de las tecnologías inalámbricas actuales y el posterior diseño de un protocolo para proporcionar control de acceso y una conexión con el punto de acceso cifrada, se ha podido llegar a la conclusión de que las redes inalámbricas, si no se introduce ningún elemento adicional, son inseguras. Pero que mediante un sistema de control de acceso basado en certificados, debidamente ampliado con el uso de claves WEP, y la posterior renegociación de estas, se puede obtener la seguridad necesaria para poder utilizar estas redes en entornos públicos. VI. REFERENCIAS [1] W. Stallings, Wireless Communications and Networks, 2001, Prentice Hall [2] J. Schiller, Mobile Communications, 2000, Addison-Wesley [3] IEEE 802.1X Port-Based Network Access Control, IEEE, 2001 [4] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, RFC 2903: Generic AAA Architecture, Agosto 2000 [5] C. Rigney, S. Willens, A. Rubens, W. Simpson, RFC 2865: Remote Authentication Dial In User Service (RADIUS), Junio 2000 [6] P. R. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, Draft-ietf-aaa-diameter-11: Diameter Base Protocol, Junio 2002 [7] L. Blunk, J. Vollbrecht, RFC 2284: Extensible Authentication Protocol (EAP), Marzo 1998 [8] B.Aboba, D.Simon, RFC 2716: PPP EAP TLS Authentication Protocol, Octubre 1999 [9] S. Thomas, SSL and TLS Essentials. Securing the Web, 2000, Wiley [10] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, RFC 2693: SPKI Certificate Theory, Septiembre 1999 [11] PKCS#7: Cryptographic Message Syntax, Version 15, Laboratorios RSA, Noviembre 1993 [12] Página web de HostAP, < [13] Página web de Open1X, < [14] Página web de FreeRADIUS, < [15] Página web de OpenSSL,< [16] W. Ford, M. S. Baum, Secure Electronic Commerce, 1997, Prentice Hall PTR [17] HOWTO on EAP/TLS authentication between FreeRADIUS and XSupplicant, <