ES2279308T3 - Control de acceso a una red de un terminal fuente que utiliza un tunel en modo bloqueante. - Google Patents
Control de acceso a una red de un terminal fuente que utiliza un tunel en modo bloqueante. Download PDFInfo
- Publication number
- ES2279308T3 ES2279308T3 ES04291363T ES04291363T ES2279308T3 ES 2279308 T3 ES2279308 T3 ES 2279308T3 ES 04291363 T ES04291363 T ES 04291363T ES 04291363 T ES04291363 T ES 04291363T ES 2279308 T3 ES2279308 T3 ES 2279308T3
- Authority
- ES
- Spain
- Prior art keywords
- authentication
- source terminal
- sour
- firewall
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 230000000903 blocking effect Effects 0.000 title claims description 35
- 238000000034 method Methods 0.000 claims abstract description 38
- 230000000737 periodic effect Effects 0.000 claims abstract description 19
- 238000013475 authorization Methods 0.000 claims abstract description 10
- 238000004590 computer program Methods 0.000 claims abstract description 8
- 230000004044 response Effects 0.000 claims abstract description 8
- 238000001914 filtration Methods 0.000 claims description 23
- 238000004891 communication Methods 0.000 claims description 19
- 238000012423 maintenance Methods 0.000 claims description 14
- 238000004458 analytical method Methods 0.000 claims description 11
- 238000012790 confirmation Methods 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 9
- 238000012795 verification Methods 0.000 claims description 4
- 238000013524 data verification Methods 0.000 claims description 2
- 230000001419 dependent effect Effects 0.000 claims description 2
- 230000000135 prohibitive effect Effects 0.000 claims 1
- 239000007943 implant Substances 0.000 abstract 1
- 230000006870 function Effects 0.000 description 18
- 238000005516 engineering process Methods 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 12
- 230000008569 process Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 4
- 230000006855 networking Effects 0.000 description 3
- 230000035515 penetration Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 210000000481 breast Anatomy 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000003071 parasitic effect Effects 0.000 description 1
- 238000000053 physical method Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Abstract
Procedimiento de control de acceso de un terminal fuente (T_SOUR) a una red que incluye un punto (P_ACC) de acceso para este terminal, un cortafuego (PF) conectado al punto (P_ACC) de acceso, y un portal (PORT) de autentificación que hace uso de una base de datos (BDD) de autentificación, disponiendo este portal (PORT) del cortafuego (PF) en un estado de autorización de acceso en respuesta a una petición inicial de acceso en modo de base que emana del terminal fuente (T_SOUR) y que incluye el suministro al portal (PORT) o al cortafuego (PF) de datos de autentificación válidos, a falta de los cuales el cortafuego se dispone en un estado de prohibición de acceso, permaneciendo el cortafuego (PF) en un estado de autorización de acceso en modo de base en respuesta al suministro periódico, por el terminal fuente (T_SOUR) y sobre un canal seguro de intercambio de ficha, de una ficha de autentificación válida a falta de la cual el cortafuego (PF) se sitúa en su estado de prohibición de acceso, y comunicando el terminal fuente (T_SOUR) selectivamente en modo túnel con un terminal (T_DEST) de destino de la red a través de un túnel bloqueante, caracterizado porque el suministro periódico de la ficha de autentificación se realiza al menos por medio de una transmisión sobre la capa de nivel 2 del modelo OSI del canal de intercambio de ficha establecido entre el terminal fuente (T_SOUR) y el cortafuego (PF), con el resultado de que el suministro periódico de la ficha de autentificación sigue estando asegurado durante una comunicación en modo túnel bloqueante.
Description
Control de acceso a una red de un terminal
fuente que utiliza un túnel en modo bloqueante.
La invención se refiere, de manera general, a
las técnicas de acceso a una red informática.
De manera más precisa, la invención se refiere a
un procedimiento de control de acceso de un terminal fuente a una
red que incluye un punto de acceso para este terminal, a un
cortafuego conectado al punto de acceso, y a un portal de
autentificación que hace uso de una base de datos de
autentificación, disponiendo este portal del cortafuego en un
estado de autorización de acceso en respuesta a una petición inicial
de acceso en modo de base que emana del terminal fuente y que
incluye el suministro al portal o al cortafuego de datos de
autentificación válidos, a falta de los cuales el cortafuego se
dispone en un estado de prohibición de acceso, manteniéndose el
cortafuego en estado de autorización de acceso en modo de base en
respuesta al suministro periódico, por parte del terminal fuente y
por medio de un canal seguro de intercambio de ficha, de una ficha
de autentificación válida, a falta de la cual el cortafuego se
dispone en su estado de prohibición de acceso, y el terminal fuente
comunica selectivamente, en modo túnel, con un terminal de destino
de la red a través de un túnel bloqueante.
El control de acceso a la red es el
procedimiento por el que el operador de una red permite o no permite
que un usuario potencial utilice su red.
Sin embargo, existen situaciones en las que no
es, por ahora, posible que el operador mantenga el control de
acceso a su red, debido a que el usuario elige utilizar un túnel en
modo de bloqueo, lo que hace que resulten imposibles las
comunicaciones entre el usuario y el operador de la red.
Por razones funcionales o por razones de
seguridad, el usuario de una red puede estar dispuesto, en efecto,
a establecer un túnel hacia un huésped remoto, túnel en cuyo seno
encapsula su tráfico. Según la configuración y las lógicas
utilizadas, este túnel puede estar en modo bloqueante, es decir,
rechazar todas las comunicaciones que no se valieran de este túnel
tanto en el sentido de la recepción como en el sentido de la
emisión.
Este modo de bloqueo constituye de hecho una
garantía de seguridad suplementaria para el usuario. En efecto, en
caso de que un usuario se conecte a través de un túnel a la red
privada o "intranet" de su empresa, un pirata no puede atacar
la máquina de este usuario para utilizarla como relé con el fin de
acceder a la intranet de la empresa de este último.
El interés y las modalidades de una protección
de ese tipo se encuentran descritas en particular en el artículo de
HAIDONG XIA & al: "Detecting and blocking unauthorized access
in Wi-Fi networks", NETWORKING 2004. NETWORKING
TECHNOLOGIES, SERVICES AND PROTOCOLS. THIRD INTERNATIONAL
IFIP-TC6 NETWORKING CONFERENCE (LECTURE NOTES IN
COMPUT. SCI., mayo de 2004, páginas 795-806, ISBN:
3-540-21959-5).
En este contexto, la invención tiene por objeto
proponer un procedimiento que permite al operador de una red
mantener el control de acceso a su red, incluso en el caso en que un
usuario elija utilizar un túnel en modo bloqueante.
A este fin, el procedimiento de la invención,
conforme por otra parte a la definición genérica que se da en el
preámbulo que antecede, está esencialmente caracterizado porque al
menos el suministro periódico de la ficha de autentificación se
realiza por medio de una transmisión sobre una capa de nivel 2 del
modelo OSI del canal de intercambio de ficha establecido entre el
terminal fuente y el cortafuego, de donde resulta que el suministro
periódico de la ficha de autentificación sigue estando asegurado
durante una comunicación en modo túnel de bloqueo.
Por ejemplo, el procedimiento de la invención
comprende, con posterioridad a una operación inicial conseguida de
autentificación del terminal fuente, al menos una operación de
elaboración de un secreto efectuada en el terminal fuente y/o en el
portal cautivo por parte de al menos uno de los respectivos
programas de aplicación, y operaciones de retransmisión de este
secreto a las entidades de autentificación correspondientes del
terminal fuente y del cortafuego.
Por conveniencia, se entiende que el término
"secreto" tal y como se utiliza en la presente descripción, en
su sentido estricto, no solo cubre un secreto particular, bien
definido y utilizable directamente, sino también como todos los
elementos que permiten derivar o reconstruir un secreto de ese tipo
en sentido propio.
El secreto puede ser transmitido ventajosamente
desde el portal cautivo hasta el terminal fuente en una ventana de
autentificación.
En este caso, en particular, la ventana de
autentificación puede asegurar asimismo la transmisión, desde el
portal cautivo hacia el terminal fuente, de un contador inicializado
a la vez desde el lado del terminal fuente y desde el portal
cautivo.
Además, la ventana de autentificación puede
incluir ventajosamente un botón de desconexión.
\newpage
Posteriormente a una operación inicial de
autentificación de terminal fuente conseguida, la ficha de
autentificación es suministrada, por ejemplo periódicamente, por la
entidad de autentificación del terminal fuente, con destino a la
entidad de autentificación del cortafuego, que verifica esta
ficha.
De igual modo, con posterioridad a una operación
inicial conseguida de autentificación del terminal fuente, el
contador es suministrado preferentemente de forma periódica por la
entidad de autentificación del terminal fuente, con destino a la
entidad de autentificación del cortafuego, que verifica este
contador.
Tras la verificación de datos proporcionados por
la entidad de autentificación del terminal fuente, la entidad de
autentificación del cortafuego permite disponer así de un módulo de
filtrado del cortafuego en estado de autorización o de prohibición
de acceso, en función del resultado de esta verificación.
La entidad de autentificación del terminal
fuente se realiza, por ejemplo, en lenguaje Java, telecargado
durante la autentificación inicial de este terminal fuente, y
ejecutado en la ventana de mantenimiento de sesión.
Por otra parte, la transmisión de nivel 2
establecida entre las entidades de autentificación del terminal
fuente y del cortafuego, es programada ventajosamente según una
extensión del protocolo ARP.
La invención se refiere igualmente a un primer
programa de ordenador que va a ser implantado en un terminal fuente
y que ha sido concebido para autorizar de manera condicionada una
conexión de este terminal fuente en modo túnel de bloqueo, con un
terminal de destino de una red a través de un cortafuego controlado
por un portal cautivo de la red, estando este primer programa
caracterizado porque comprende un módulo de inicialización
apropiado para recuperar un secreto compartido proveniente del
portal, y para inicializar un contador, un módulo de confirmación
periódica de autentificación solicitado por el módulo de
inicialización y apropiado para elaborar y para emitir con destino
al cortafuego, y sobre la capa 2 del modelo OSI, un autentificador
único dependiente al menos del secreto compartido y del contenido
del contador, y un módulo de actualización y de decisión solicitado
por el módulo de confirmación periódica de autentificación y
apropiado para incrementar el contador, para poner fin a la
conexión en caso de anomalía de la comunicación con el cortafuego, y
en caso contrario, para llamar de nuevo al módulo de confirmación
periódica de autentificación, de donde resulta que el terminal
fuente sigue siendo autentificado por el cortafuego durante la
conexión en modo túnel de bloqueo.
La invención se refiere igualmente a un segundo
programa de ordenador destinado a ser implantado en un cortafuego
instalado en una red, y controlado por un portal cautivo de la red,
para autorizar condicionalmente una conexión en modo túnel de
bloqueo, entre un terminal fuente y un terminal de destino de esta
red, a través del cortafuego, estando este segundo programa
caracterizado porque comprende un módulo de escucha de la red, un
módulo de selección, y un módulo de análisis y de decisión, porque
el módulo de escucha de la red resulta apropiado para recuperar, en
respuesta a una demanda de autentificación recibida desde el
terminal fuente, un secreto compartido proveniente de este terminal
fuente, porque el módulo de selección es solicitado por el módulo
de escucha y es apropiado para localizar, en un flujo de tramas que
circulan sobre la capa 2 del modelo OSI, las tramas de
autentificación del terminal fuente, y para direccionar las tramas
de autentificación hacia el módulo de análisis y de decisión, y
porque el módulo de análisis y de decisión verifica el contenido de
las tramas de autentificación, pone fin a la conexión del terminal
fuente en caso de anomalía, y actualiza las reglas de autorización
de conexión utilizadas por el cortafuego en caso
contrario.
contrario.
La invención se refiere igualmente a un sistema
para controlar el acceso de un terminal fuente a una red
informática, que comprende un cortafuego situado entre la citada
red informática y un punto de acceso para el citado terminal
fuente, y a un portal de autentificación que dirige el estado de
dicho cortafuego, en el que el cortafuego está capacitado para
mantener abierto un canal de comunicación segura para el terminal
fuente con la condición de que el terminal fuente envíe
periódicamente o por acontecimiento, una ficha de autentificación,
estando este sistema caracterizado porque:
- el cortafuego comprende un módulo de protocolo
de autentificación y un módulo de filtrado, siendo el citado módulo
de protocolo de autentificación susceptible de hacer que se vuelva
"pasante" o "bloqueante" el citado módulo de filtrado
para las comunicaciones entre el terminal fuente y la red
informática según resulte el terminal fuente autentificado o
no,
- el portal de autentificación comprende un
programa de aplicación capacitado para distribuir secretos al
módulo de protocolo de autentificación siempre que la
autentificación del terminal fuente en la red informática haya sido
conseguida,
- el terminal fuente comprende un módulo de
protocolo de autentificación y un programa de aplicación, estando
el citado programa de aplicación capacitado para distribuir secretos
hasta dicho módulo de protocolo de autentificación cuando se ha
alcanzado la autentificación inicial del terminal fuente en la red
informática,
y porque el módulo de protocolo de
autentificación está capacitado para enviar las citadas fichas de
autentificación al módulo de protocolo de autentificación a través
de la capa 2 del modelo OSI.
\newpage
Otras características y ventajas de la invención
se pondrán claramente de manifiesto a partir de la descripción que
se realiza a continuación, a título indicativo y en ningún caso
limitativo, con referencia a los dibujos anexos, en los que:
- la Figura 1 representa esquemáticamente los
medios funcionales necesarios para la puesta en práctica de la
invención;
- la Figura 2 representa los flujos de
informaciones utilizados entre el terminal fuente, el cortafuego y
el portal de autentificación, a partir del procedimiento de
autentificación del terminal fuente, y
- la Figura 3 representa los flujos de
informaciones utilizados entre el terminal fuente, el cortafuego y
el portal de autentificación, durante la utilización del túnel en
modo de bloqueo, y
- las Figuras 4A y 4B son organigramas que
representan respectivamente el programa de ordenador utilizado en
el terminal fuente, y el programa de ordenador utilizado en el
cortafuego.
Teniendo en cuenta la necesidad, para describir
con detalle el procedimiento de la invención de una manera
comprensible para el experto en la materia, de utilizar el
vocabulario estándar de este último, el lector poco familiarizado
con el sector al que se alude encontrará en lo que sigue
definiciones y referencias útiles para su propia comprensión de la
descripción.
Dirección IP: Dirección de un equipo que utiliza
IP (véase esta palabra) como protocolo de capa 3 del modelo OSI
(véase esta palabra).
Dirección MAC: Dirección de un equipo conectado
a un medio compartido, utilizado por la capa 2 del modelo OSI
(véase esta palabra).
ARP (Acrónimo obtenido del inglés "Address
Resolution Protocol"): Protocolo de resolución de direcciones IP
en direcciones MAC, de nivel 2 del modelo OSI (véase esta palabra),
que permite que se pongan en comunicación estaciones por una red de
base Ethernet. Las comunicaciones reales están basadas, en efecto,
en direcciones MAC de la fuente y del destinatario.
DHCP (Acrónimo obtenido del inglés "Dynamic
Host Configuration Protocol"): Protocolo de atribución dinámica
de direcciones sobre una red IP (véase esta palabra).
DNS (Acrónimo obtenido del inglés "Domain Name
Server" o "Domain Name System"): Servicio esencial de
Internet que asegura la conversión de los nombres de dominios en
direcciones IP (véase esta palabra).
Función de picado: esta expresión designa una
función que convierte una cadena de caracteres de cualquier
longitud, en una cadena de caracteres de tamaño fijo, de tamaño
inferior, denominándose esta cadena huella (hash). El resultado de
una función de picado es el mismo para la misma cadena de entrada,
pero en principio no existen dos resultados asemejables de función
de picado.
Función de picado en clave: esta expresión
designa una función de picado que, además de una cadena de
caracteres de cualquier longitud, toma a la entrada una clave
secreta.
HMAC-MD5 (Acrónimo obtenido del
inglés "Keyed-Hashing for Message
Authentification" - "Message Digest 5"): Algoritmo
criptográfico de tipo "función de picado en clave" (véase esta
expresión).
HMAC-SHA1 (Acrónimo obtenido del
inglés "Keyed-Hashing for Message
Authentification" - "Secure Hash Algorithm"): Algoritmo
criptográfico de tipo "función de picado en clave" (véase esta
expresión).
HTML (Acrónimo obtenido del inglés "HyperText
Markup Language"): Formato de documento de Internet definido por
la Norma RFC 1866.
HTTPS (Acrónimo obtenido del inglés "HyperText
Transfer Protocol Secure"): Protocolo de transmisión procedente
del navegador "Netscape" y ligado a una conexión segura.
IP (Acrónimo obtenido del inglés "Internet
Protocol"): Protocolo de nivel red utilizado en Internet,
orientado sin conexión (principio del datagrama).
IPsec (Acrónimo obtenido del inglés "Internet
Protocol Security"): Protocolo de seguridad utilizado en
Internet.
MAC (Acrónimo obtenido del inglés "Medium
Access Control"): Término general que designa la capa que genera
el reparto de un soporte de transmisión entre diferentes
estaciones.
Open Source (Expresión inglesa): Lógica libre
que responde a exigencias cualitativas definidas.
OSI (Acrónimo obtenido del inglés "Open System
Interconnection"): Modelo de interconexión de sistemas abiertos
en los que el conjunto de acciones que permiten que cooperen varios
equipos informáticos, está estructurado en capas que corresponden a
niveles de detalles diferentes.
SSL (Acrónimo obtenido del inglés "Secure
Socket Layer"): Norma de modo de comunicación segura sobre una
red, utilizada inicialmente por el navegador de marca
"Netscape", y después oficializada.
TCP (Acrónimo del inglés "Transport Control
Protocol"): Protocolo de transporte orientado, conexión que
permite un intercambio fiable de una cantidad cualquiera de datos
entre dos equipos (nivel 4 OSI - véase esta palabra) conectados por
medio de una o de varias redes que utilizan IP (véase esta
palabra).
TLS (Acrónimo obtenido del inglés "Transport
Layer Security"): Protocolo de provisión de seguridad de la capa
de transporte, definido por la norma RFC 2246. La versión 1.0 de TLS
es, de hecho, la versión 3 de SSL (véase esta palabra).
UDP (Acrónimo obtenido del inglés "User
Datagram Protocol"): Protocolo de transporte de bloques de datos
independientes, o "paquetes", que transitan por una red y que
contienen todas las informaciones necesarias para su
enrutamiento.
URL (Acrónimo obtenido del inglés "Uniform
Resource Locator"): Formato de dirección que permite volver a
encontrar un recurso.
VPN (Acrónimo obtenido del inglés "Virtual
Private Network"): Red privada virtual.
[ARP] Address Resolution Protocol, "An
Ethernet Address Resolution Protocol", RFC 826, noviembre
1982.
[HMAC-MD5] Krawczyk H.,
Bellare M., y Canetti R., "HMAC:
Keyed-Hashing for Message Authentification", RFC
2104, febrero 1997.
[IEEE-802.1X-2001]
Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network
Access Control", IEEE Standard 802.1X, septiembre de
2001.
[IEEE 802.3-2002] IEEE Standard
for Information Technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications.
[IEEE-802.11-1997]
Institute of Electrical and Electronics Engineers, "Information
Technology - Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Network - Specific
Requirements - Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", IEEE Standard 802.11,
1997.
[IEEE-802.11-1999]
Institute of Electrical and Electronics Engineers, "Information
Technology - Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Network - Specific
Requirements - Part I1: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", IEEE Standard 802.11,
1999.
[IEEE-802.11i] Institute of
Electrical and Electronics Engineers, "Unapproved Draft Supplement
to Standard for Telecommunications and Information Exchange Between
Systems - LAN/MAN Specific Requirements - Part Il: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Specifications:
Specification for Enhanced Security", IEEE Draft 802.1li (work
in progress), 2003.
[IPsec] Kent, S., and R. Atkinson,
"Security Architecture for the Internet Protocol", RFC 2401,
noviembre de 1998.
[OSI] International Organization for
Standardization, "Open Systems Interconnection", ISO 7498.
[TLS] Dierks, T. and Allen, C.,
"The TLS Protocol version 1.0", RFC 2246, enero de
1999.
[WPA] Wi-Fi Protected Access,
Wi-Fi Alliance, versión 1.2, diciembre de
2002.
El procedimiento que se describe a continuación,
se aplica típicamente a un escenario en el que el operador de la
red realiza un control de acceso al nivel TCP/IP, y en el que el
usuario desea utilizar un túnel tal como [IPsec] en modo
bloqueante.
La invención puede encontrar un uso pertinente
en las redes radioeléctricas IEEE 802.11
([IEEE-802.11-1997] y
[IEEE-802.11-1999]) de "primera
generación", es decir, que no utilizan las nuevas funcionalidades
de seguridad a nivel 2 del modelo [OSI] como WPA o 802.11i, y en
las redes filiarias IEEE 802.3 ([IEEE 802.3-2002]) y
Ethernet que realizan un control de acceso según el paradigma de
"portal cautivo".
Una fase preliminar al control de acceso
consiste en la autentificación. La autentificación permite al
operador de la red determinar con certeza la identidad del usuario
que pretende utilizar su red.
Para autentificar un usuario, el operador de una
red debe dialogar con este último.
En caso de que se haya logrado la
autentificación, el operador de la red decide en función de la
identidad del usuario si este último está autorizado o no para
acceder a la red.
Con el fin de evitar que usuarios ilegítimos se
aprovechen indebidamente de la red, se hace necesario para el
control de acceso:
- asegurarse de que solamente los usuarios que
el operador ha autorizado pueden utilizar la red, es decir, evitar
que un usuario no autorizado pueda utilizar la red, y
- mantener la relación de autentificación con el
usuario, es decir, asegurar que el usuario autorizado que utiliza
la red es el mismo que el autentificado, con el fin de evitar que un
usuario no autorizado usurpe la identidad de un usuario
autorizado.
Diversas técnicas permiten realizar un control
de acceso en la red, en particular:
- técnicas físicas: por ejemplo, las tomas que
permiten acceder a la red están situadas en locales cerrados con
llave, y
- técnicas lógicas: por ejemplo, el acceso a la
red está condicionado por la posición de un secreto que permite
emplear técnicas criptográficas.
En ausencia de mecanismos de seguridad que
incluyen el control de acceso al nivel 2 (enlace de datos) del
modelo de siete capas de la [OSI], o por el hecho de los costes
asociados al despliegue de tales mecanismos cuando existen y de los
muy bajos índices de penetración de estos últimos en el parque de
equipamiento de los usuarios, se ha desarrollado el paradigma de
"portal cautivo".
Este paradigma permite realizar un control de
acceso a las redes TCP/IP:
- realizando un filtrado sobre las direcciones
MAC e IP, y
- utilizando fichas de autentificación
intercambiadas entre el terminal fuente y el portal de
autentificación.
Durante su conexión a la red, el usuario es
invitado a abrir su navegador de Internet, y su primera pregunta
con la ayuda de este último es re-dirigida
automáticamente hacia el portal de autentificación del operador (de
ahí el nombre de portal cautivo). Este portal cautivo permite al
usuario autentificarse de manera segura, por ejemplo utilizando el
protocolo SSL/[TLS].
Todas las demás peticiones del usuario no
autentificado, son bloqueadas por medio de un cortafuego que realiza
un filtrado mediante la dirección MAC y/o la dirección IP. En caso
de que se logre la autentificación, y en caso de que el usuario
autentificado esté autorizado para acceder a la red, el cortafuego
se actualiza para dejar pasar el tráfico de este usuario.
La arquitectura de un portal cautivo (Figura 1),
que permite a un terminal fuente T_SOUR comunicar en modo túnel con
un terminal de destino T_DEST de la red, implica, así globalmente un
punto de acceso P_ACC, un cortafuego PF, el propio portal de
autentificación PORT, y una base de datos de autentificación
BDD.
El punto de acceso P_ACC ofrece al terminal
fuente T_SOUR una vía de conexión filiaria o sin hilos
(Wi-Fi por ejemplo) a la red Internet.
El cortafuego PF controla directamente el acceso
del terminal T_SOUR a la red Internet filtrando los paquetes
(típicamente a nivel IP y TCP), y activando un filtro mediante la
dirección MAC.
El portal PORT autentifica al usuario,
intercepta las peticiones de los usuarios no autentificados,
re-dirige estos usuarios hacia una página de
autentificación, hace que se verifiquen estos datos de
autentificación por parte de la base de datos BDD, modifica las
reglas del cortafuego PF en función del resultado de esta
verificación, y dirige después el estado del cortafuego.
La base de datos BDD contiene, en sí misma, los
datos válidos de los usuarios autorizados, y responde a las
peticiones del portal PORT.
Como el control de acceso mediante la dirección
MAC y la dirección IP es intrínsecamente débil (es, en efecto, muy
fácil, mediante una simple manipulación lógica, usurpar la dirección
MAC y la dirección IP de un usuario), el portal cautivo PORT
utiliza un control de acceso suplementario mediante ficha
intercambiada entre el terminal fuente y el portal de
autentificación.
El portal cautivo guarda, en efecto, un canal de
comunicación seguro abierto con el usuario, por el que el usuario
debe presentar periódicamente, o por acontecimiento, una ficha de
autentificación. La falta de presentación de esta ficha conlleva la
re-inicialización del cortafuego en estado de
bloqueo para este usuario. Así, un usuario no autorizado que usurpe
la dirección MAC y/o la dirección IP de un usuario autorizado, no
podrá presentar esta ficha y verá su conexión terminada. Incluso
aunque sea previsible la presencia simultánea de un usuario
autorizado encargado de presentar la ficha, y de un usuario no
autorizado que usurpe la dirección MAC y la dirección IP de este
usuario autorizado, los mecanismos de funcionamiento de los
protocolos TCP/IP volverán las conexiones inutilizables: el usuario
no autorizado, si desea aprovechar la conexión del usuario
autorizado, no tiene en ese momento otra opción que la de acallar
al usuario autorizado, por ejemplo mediante denegación de servicio.
Tras haber acallado al usuario autorizado, el usuario no autorizado
no puede aprovecharse del servicio mientras el portal cautivo no
exija la presentación de la ficha, intervalo de tiempo que puede ser
configurado a nivel del portal cautivo PORT.
El paradigma de "portal cautivo" tal como
el que se ha descrito en la presente, se aplica por ejemplo tanto a
las redes radioeléctricas que utilizan la tecnología IEEE 802.11,
como a las redes locales filiarias que utilizan las tecnologías
IEEE 802.3/Ethernet.
En el caso de las redes radioeléctricas que
utilizan la tecnología IEEE 802.11, los mecanismos de seguridad
previstos originalmente en la norma [IEEE
802.11-1997] y en la [IEEE
802.11-1999], han puesto de manifiesto rápidamente
problemas importantes que hacen que su utilización sea tan
complicada como ineficaz: éste es el fallo cometido en 2000 y 2001
por los mecanismos de seguridad conocidos bajo el acrónimo
"WEP".
Aunque se encuentren en curso de despliegue
[WPA] otros mecanismos de seguridad o de especificación
[IEEE-802.11i] más robustos, hasta ahora no
presentan una madurez suficiente como para ser desplegados a gran
escala.
Dos escenarios en los que se aplica el paradigma
de "portal cautivo" a las redes radioeléctricas que utilizan
la tecnología IEEE 802.11, son:
- las redes radioeléctricas locales, denominadas
"Hot-Spots", que utilizan la tecnología IEEE
802.11 y que están desplegadas en lugares frecuentados, por ejemplo
las recepciones de hoteles o las salas de espera de los
aeropuertos, donde la puesta a disposición de una conexión a
Internet presenta un gran valor añadido, y
- los accesos a una red ofrecidos por una
empresa a sus visitantes para permitir a estos últimos trabajar más
eficazmente, por ejemplo en las salas de reunión.
En el caso de las redes locales filiarias que
utilizan las tecnologías IEEE 802.3/Ethernet, no se ha previsto en
origen ningún mecanismo de seguridad. No ha sido hasta 2001, con la
adopción de la norma [IEEE 802.1X-2001], cuando los
mecanismos de seguridad han visto la luz para estas redes.
Sin embargo, su índice de penetración en el
parque de equipos de usuarios, es todavía bajo. Es por ello que una
empresa que desee ofrecer un acceso a red a sus visitantes, por
ejemplo en la sala de reunión, puede ser conducida a utilizar el
paradigma de "portal cautivo".
El punto débil de la técnica conocida de portal
cautivo, que refuerza el control de acceso mediante filtrado de la
dirección IP y/o de la dirección MAC mediante un intercambio de
ficha de autentificación, reside justamente en el hecho de que esta
técnica supone que el operador y el usuario sean capaces de dialogar
para poder intercambiarse la ficha.
Sin embargo, la aplicación más típica utilizada
por los usuarios en los escenarios presentados anteriormente,
consiste para estos usuarios en montar un túnel (creando así un VPN)
hacia la intranet de su empresa.
Por razones de seguridad, la mayor parte de las
aplicaciones de VPN impiden también todas las comunicaciones con
destino al, o provenientes del, usuario, distintas de las que pasan
por el interior de la VPN. Se trata por tanto de túneles en modo
bloqueante.
En este caso, no es así posible mantener el
intercambio de la ficha de autentificación, y en estos momentos no
se encuentra disponible ninguna solución para resolver el
problema.
\newpage
En consecuencia:
- o bien la provisión de seguridad por
intercambio de ficha ha sido entonces pura y simplemente abandonada
en el paradigma de "portal cautivo", en cuyo caso el control de
acceso a la red no consiste más que en un filtrado por medio de la
dirección IP y/o de la dirección MAC, lo que presenta
vulnerabilidades críticas,
- o bien se mantiene la provisión de seguridad
por intercambio de ficha y el usuario no puede montar un túnel en
modo de bloqueo, por ejemplo hacia la intranet de su empresa, puesto
que caducará la primera demanda de intercambio de ficha posterior
al establecimiento del túnel y quedará bloqueado el tráfico del
usuario.
La invención permite al operador de una red
mantener un control de acceso eficaz a su red, incluso en caso de
que el usuario elija utilizar un túnel en modo bloqueante.
Esta invención propone un modo de
re-autentificación periódica totalmente invisible
para el usuario. Por otra parte, el empleo de un canal de
transmisión no afectado por el modo bloqueante entre el terminal y
el portal cautivo, perite el intercambio de informaciones
suplementarias, como por ejemplo duraciones de conexión o volúmenes
consumidos.
La invención se basa en la observación del hecho
de que la técnica de modo bloqueante utilizada por ejemplo por los
usuarios de IPsec, tiene la propiedad de filtrar los paquetes de
datos a nivel 3 del modelo OSI.
Esta propiedad, no publicada por los editores de
lógicas, tiene como consecuencia el hecho de que la utilización de
un túnel en modo bloqueante no puede liberarse de las comunicaciones
efectuadas a nivel 2 del modelo OSI por el protocolo implicado, por
ejemplo el protocolo ARP.
La invención aprovecha esta propiedad para
mantener el intercambio de la ficha de autentificación, pero al
nivel 2 del modelo OSI, y no a los niveles 3 y superiores como en el
estado actual de la técnica.
La modificación así aportada permite a la vez
guardar el modo bloqueante del usuario IPsec, y utilizar un
protocolo de autentificación periódica fuerte.
Para todo esto, el control de sesión, es decir,
típicamente el mecanismo de intercambio de ficha entre el terminal
fuente T_SOUR y el portal PORT, se desplaza al nivel 2 del modelo
OSI (L2 en las Figuras 2 y 3), lo que permite volverlo
independiente de cualquier modo bloqueante (M_BLQ en la Figura 3)
utilizado eventualmente por el usuario del terminal T_SOUR sobre
las capas superiores de este modelo.
En efecto, no es posible, para el usuario de un
túnel en modo bloqueante, impedir las comunicaciones desde su
terminal T_SOUR a nivel 2 del modelo OSI, en la medida en que este
terminal debe imperativamente poder dialogar, a nivel 2, con las
pasarelas o enrutadores de la red, para emitir paquetes de datos
hacia el exterior y recibir desde el exterior, y donde se
encontraría completamente aislado de la red si este diálogo fuera
interrumpido.
Concretamente, la invención utiliza, por una
parte, una entidad (aún denominada "módulo") de protocolo PA1
de autenticación, y un programa de aplicación APPLI1 utilizado en el
terminal fuente T_SOUR, y por otra parte, una entidad (o
"módulo") de protocolo PA2 de autenticación y una función (aún
denominada "módulo") de filtrado FILT, utilizadas en el
cortafuego PF, y por último un programa de aplicación APPLI2
utilizado en el portal cautivo PORT.
La entidad de protocolo PA1 de autentificación
utilizada en el terminal T_SOUR debe poder interactuar (diálogo D2
en la Figura 2) con el programa de aplicación APPLI1 que le atribuye
los secretos cuando la autenticación del terminal T_SOUR en la red
(diálogo D1 en la Figura 2) ha sido conseguida.
La entidad de protocolo PA1 de autentificación
utilizada en el terminal T_SOUR debe estar asimismo en relación
directa con la capa 2 (L2) del modelo OSI, mediante la que comunica
con la entidad PA2 correspondiente utilizada en el cortafuego PF
(diálogo D1 de la Figura 3).
La entidad de protocolo PA2 de autentificación
utilizada en el cortafuego PF, debe poder interactuar (diálogo D3
en la Figura 2) con el programa de aplicación APPLI2 que le atribuye
los secretos cuando se ha conseguido la autentificación del
terminal T_SOUR sobre la red, y con la función FILT de filtrado de
paquetes (diálogo D3 en la Figura 3) para volverla "pasante"
cuando se ha conseguido la autentificación verificada por las
entidades PA1 y PA2, y "bloqueante" cuando la autentificación
verificada por las entidades PA1 y PA2 ha caducado.
La entidad de protocolo PA2 de autentificación
utilizada en el cortafuego PF debe estar igualmente en relación
directa con la capa 2 del modelo OSI, mediante la que comunica con
la entidad PA1 correspondiente utilizada en el terminal fuente
T_SOUR (diálogo D1 de la Figura 3).
A menos que se realice una adaptación particular
que será discutida posteriormente, el terminal T_SOUR y el
cortafuego PF deben estar en visión directa sobre la capa 2 del
modelo OSI, es decir, exentos de cualquier enrutador
intermedio.
Cronológicamente, el procedimiento comprende una
fase inicial de autentificación del terminal T_SOUR, y una fase
posterior periódica de re-autentificación de las
entidades PA1 y PA2.
Durante la fase de autentificación inicial, el
terminal fuente T_SOUR, o su usuario, se autentifica junto al
portal cautivo PORT intercambiando datos a través del enlace seguro
simbolizado por el diálogo D1 en la Figura 2, pudiendo este enlace
confidencial ser realizado en TLS/SSL de manera convencional.
Los secretos son extraídos de esta
autentificación, simétricamente en el terminal fuente T_SOUR y en el
portal cautivo PORT, por medio de los respectivos programas de
aplicación APPLI1 y APPLI2, y después retransmitidos por estos
últimos a las entidades de autentificación correspondientes PA1 y
PA2 (diálogos D2 y D3 de la Figura 2).
Una vez que las entidades PA1 y PA2 han recibido
los secretos que permiten un reconocimiento mutuo, éstas utilizan
periódicamente el protocolo de re-autentificación
del terminal T_SOUR por el cortafuego PF (diálogo D1 de la Figura
3).
Una vez que se ha logrado esta
re-autentificación, el módulo FILT de filtrado del
cortafuego PF es gobernado por la entidad PA2 (diálogo D3 de la
Figura 3) para mantenerse pasante para los datos del terminal T_SOUR
(diálogo D2 de la Figura 3), siendo este módulo FILT de filtrado,
en caso contrario, gobernado para que se vuelva bloqueante.
En estas condiciones, mientras el módulo FILT de
filtrado es pasante, el flujo de datos en el que se encuentra
implicado el terminal T_SOUR, puede circular libremente. Si este
terminal elige pasar al modo bloqueante, por ejemplo llamando en
IPsec con determinados tipos de lógicas, entonces puede continuar la
re-autentificación entre las entidades PA1 y PA2,
manteniéndose así válido el control de acceso a nivel del cortafuego
PF.
Esta parte de la descripción explica cómo puede
ser llevado a cabo el procedimiento de la invención, en un
mecanismo conocido de control de acceso por medio del "portal
cautivo".
Se presenta aquí el modo de funcionamiento
convencional de una conexión de un usuario a una red que soporta la
tecnología de "portal cautivo". Esta tecnología es utilizada en
numerosos productos comerciales, y se encuentra disponible
igualmente en un producto Open Source denominado NoCatAuth (descrito
especialmente en el sitio http://nocat.net).
Esta solución de "portal cautivo" Open
Source, dirige varios motores de filtro Open Source como
"iptables", "packetfilter" o "IPFilter", descritos
respectivamente en los sitios: http://iptables.org,
http://www.benzedrine.cx/pf.html, y http://www.ipfilter.org.
Esto permite dirigir estos motores de filtro
gracias a un diálogo entre el portal cautivo y una aplicación que
dirige el motor de filtro.
Las etapas del proceso estándar de conexión, son
las siguientes:
1. El usuario se conecta a la red cuyo control
de acceso se realiza por medio del portal cautivo;
2. La red le permite recuperar las informaciones
de conectividad clásica (dirección IP, direcciones de servidores
DNS, direcciones de pasarelas por defecto, ...), siendo todo esto
efectuado generalmente con la ayuda de intercambios DHCP;
3. El usuario decide autentificarse ante la red
con el fin de tener acceso a los servicios ofrecidos por el sitio
local (típicamente, Internet);
4. El usuario envía una petición hacia Internet,
que es interceptada por el motor de filtro (reglas por defecto), y
re-dirigida hacia el "portal cautivo". El
"portal cautivo" presenta entonces la banderola de
autentificación al usuario;
5. El usuario introduce sus datos de
autentificación (típicamente, un nombre de usuario y una palabra de
paso), que serán validados por el "portal cautivo";
6. El "portal cautivo" interactúa con el
motor de filtro con el fin de modificar las reglas de filtrado por
defecto para este usuario. En este momento, el usuario está
capacitado para comunicar con el exterior (típicamente, Internet),
en función de las nuevas reglas de filtrado comunicadas al motor de
filtrado;
7. El "portal cautivo" presenta una ventana
de autentificación periódica al usuario, permitiendo esta ventana
mantener la sesión entre el usuario y el portal cautivo gracias a la
noción de ficha de autentificación, y siendo incluso denominada
aquí "ventana de mantenimiento de sesión".
En la práctica, la ventana de mantenimiento de
sesión puede estar escrita en código HTML, permitiendo iniciar una
conexión de manera periódica hacia una URL bien formateada (que
contenga en particular la ficha de autentificación).
La utilización de la ventana de mantenimiento de
sesión, que está protegida por mecanismos criptográficos a base de
SSL/TLS (https en la Figura 2), permite extraer un secreto que es
apropiado para el terminal T_SOUR y para el portal cautivo PORT. La
invención puede entonces utilizar mecanismos criptográficos
específicos con el fin de asegurar la confidencialidad de las
informaciones transportadas en el nuevo protocolo especificado a
nivel 2 del modelo OSI, así como la función denominada
"anti-nueva representación", es decir, la
función destinada a bloquear los ataques parásitos de conexión
consistentes en hacer creer que un usuario está siempre activo y
recuperar su conexión en un momento elegido, por ejemplo durante una
desconexión intempestiva.
Teniendo en cuenta la multitud de posibilidades
ofrecidas por las herramientas conocidas por los expertos en la
materia para asegurar una protección criptográfica, la invención va
a ser descrita a continuación por medio de un único ejemplo
particular, no limitativo.
El secreto, protegido mediante SSL/TLS, es
transmitido desde el portal PORT hacia el terminal T_SOUR en la
ventana de autentificación, en respuesta a una autentificación
conseguida de este terminal T_SOUR. En la ventana de
autentificación se transmite igualmente un contador que se
inicializa a la vez desde el lado del terminal T_SOUR y desde el
lado del portal cautivo PORT, permitiendo este secreto y este
contador evitar a la vez los ataques de usurpación de identidad y
los ataques por "nueva presentación".
Un algoritmo criptográfico de tipo función de
picado en clave (tal como HMAC-MD5 o
HMAC-SHA1), capta a la entrada informaciones tales
como el contador y la dirección IP del terminal T_SOUR que son
conocidas por el portal cautivo, así como el secreto compartido
(utilizado como clave de la función de picado en clave). Ello da
como resultado una cadena de longitud fija que permite asegurar a la
vez la autentificación del usuario (gracias al secreto compartido)
y la autentificación de la máquina (gracias a la dirección IP).
El paquete se envía desde la entidad PA1 del
terminal T_SOUR hacia la entidad PA2 del cortafuego PF gracias al
protocolo de nivel 2 utilizado por la invención, y después se
analiza mediante el portal cautivo PORT, el cual verifica el
secreto y el ordenador.
Si la verificación concluye con éxito, entonces
se incrementa el contador.
En caso contrario, el sistema de control de
acceso del portal PORT considera que existe usurpación de identidad
y elige, en función de la política de seguridad, la decisión más
apropiada a la situación, tal como la que consiste en cerrar la
conexión enviando una instrucción al módulo de filtrado FILT, o en
ignorar el paquete y continuar a la espera de la recepción de un
paquete válido (siendo entonces cerrada la conexión sin que se haya
recibido ningún paquete válido con anterioridad a la expiración del
plazo correspondiente a la duración de validez de una
autentificación).
La invención se inserta a nivel de la 7ª etapa
del procedimiento estándar de conexión tal y como se ha definido
anteriormente, a saber aquella en la que el portal cautivo presenta
periódicamente una ventana de autentificación al usuario para
mantener la sesión entre este usuario y el portal cautivo gracias al
intercambio de una ficha de autentificación.
La invención conserva este procedimiento de
mantenimiento de sesión, pero utiliza una vía diferente para el
intercambio de la información de autentificación entre el usuario y
el portal cautivo.
En la práctica, la ventana de mantenimiento de
sesión comprende una lógica de aplicación PA1 que utiliza un
protocolo de autentificación asociado a un programa que presenta un
botón de desconexión que permite al usuario del terminal T_SOUR
desconectarse apropiadamente.
Esta técnica se basa en un desarrollo en modo
cliente servidor a nivel 2.
El recurso al lenguaje Java para la realización
de la lógica por el lado del terminal fuente, resulta ventajoso,
aunque no obligatorio.
Las etapas posteriores del proceso de conexión
según la invención son las siguientes:
8. La lógica de aplicación ejecutada en el
terminal T_SOUR envía periódicamente paquetes sobre el segmento
Ethernet hacia el cortafuego PF, indicando así que este terminal
está siempre activo; si un atacante presenta fichas de
autentificación inválidas, éstas serán detectadas por los
procedimientos criptográficos utilizados. La estrategia de
seguridad puede ser adaptada fácilmente a este tipo de
acontecimiento. Resulta entonces posible, por ejemplo, desconectar
el usuario y disparar una alarma ante los administradores del portal
cautivo. Resulta igualmente posible no tomar en consideración la
ficha usurpada, seguir a la espera de un paquete válido hasta el
final de un período predeterminado asignado a la conexión, y
disparar una alarma ante los administradores del portal
cautivo.
\newpage
9. Las informaciones contenidas en los paquetes
enviados por el terminal fuente T_SOUR son escuchadas por una
lógica de aplicación PA2 presente en el cortafuego PF. Este último
está capacitado, gracias a las informaciones contenidas en los
paquetes enviados, para determinar que el usuario del terminal
T_SOUR está bien legitimado, y que este terminal está siempre
conectado;
10. Son posibles dos casos para la desconexión
del terminal fuente T_SOUR:
- a.
- Si el usuario se desconecta bruscamente de la red, es decir, sin utilizar el botón de desconexión de la ventana de mantenimiento de sesión, cierra de golpe esta ventana de mantenimiento de sesión, de modo que la lógica de aplicación PA1 dejará de ser ejecutada. En consecuencia, el portal cautivo PORT no permitirá ya más la conexión del terminal T_SOUR más que durante un tiempo de sesión residual previamente fijado. El sistema de control de acceso del portal PORT considerará entonces que el usuario no está ya presente en la red y que no está autorizado para comunicar a través del cortafuego PF. El portal cautivo actualizará así las reglas de filtrado del cortafuego PF para impedir la conexión del terminal T_SOUR.
- b.
- Si el usuario se desconecta apropiadamente de la red, el sistema de control de acceso del portal PORT será informado de que este usuario desea desconectarse. Para esto, el usuario informará al sistema de control de acceso del portal PORT de su deseo de abandonar la red utilizando el botón de desconexión de la ventana de mantenimiento de sesión. El sistema de control de acceso del portal PORT considerará entonces que el usuario ya no está presente en la red, y que ya no está autorizado para comunicar a través del cortafuego PF. El portal cautivo actualizará por tanto las reglas de filtrado del cortafuego PF para impedir la conexión del terminal T_SOUR.
En la medida en que la comunicación entre el
terminal T_SOUR y el portal cautivo debe ser realizada por medio de
un protocolo de nivel 2, es posible utilizar protocolos ya
existentes tales como ARP para encapsular los datos útiles en las
zonas específicas del protocolo. El único imperativo a respetar
consiste en hacerlo de modo que la parte del servidor sea capaz de
comprender el protocolo especificado desde el lado del usuario. Sin
embargo, también es posible especificar un protocolo de base
Ethernet, siendo lo importante especificar un protocolo a nivel
2.
Al situarse el protocolo utilizado por la lógica
de aplicación de mantenimiento de sesión en el nivel 2 de la capa
OSI, no atraviesa los equipos de nivel 3, es decir, típicamente los
enrutadores. Por lo tanto, puede ser necesario especificar
igualmente un protocolo de encapsulamiento y de transporte
bidireccional de las tramas de capa 2 desde el usuario y/o hacia el
cortafuego remoto.
Esta limitación se aplica en el marco de
arquitecturas centralizadas entre varios "hot spots" repartidos
por lugares geográficos distintos, que están también todos ellos
conectados entre sí en un sitio central en el que estará situado un
portal cautivo central.
No obstante, otra solución consiste en desplegar
portales cautivos sobre cada "hot spot" remoto, y en no
realizar control de acceso sobre un sitio central.
Por otra parte, en la medida en que la invención
impone la presencia de una lógica de aplicación (PA1, Figura 2) a
ejecutar en el terminal fuente, puede ser ventajoso hacerlo de
modo:
- que esta lógica sea telecargada de manera
transparente desde el portal cautivo a continuación de la
autentificación lograda desde el terminal fuente junto a este
portal; esto puede ser realizado por medio de la ventana de
mantenimiento de sesión que transporta la ficha de autentificación
en el procedimiento actual;
- que esta lógica sea ejecutada en modo local en
el terminal fuente de manera transparente para el usuario, y
- que esta lógica sea desactivada al final de la
sesión mediante el cierre de la ventana de mantenimiento de
sesión.
La invención ofrece la ventaja suplementaria de
permitir hacer que transiten informaciones distintas de los datos
de autentificación. Por ejemplo, es posible aprovechar el canal de
comunicación abierto en la capa 2 y no susceptible de ser bloqueado
para hacer pasar las informaciones de facturación del operador desde
el portal cautivo hacia el usuario (volumen de datos
intercambiados, tiempo consumido, tiempo restante, ..., etc.),
pudiendo este tipo de información ser presentada en la ventana de
mantenimiento de sesión bajo la forma de un tablero de
instrumentos.
Los programas de ordenador utilizados en el
terminal fuente T_SOUR y en el cortafuego PF han sido ilustrados
respectivamente, de manera funcional y esquemática, en las Figuras
4A y 4B.
El programa ilustrado en la Figura 4A, que está
implantado en el terminal fuente T_SOUR, está concebido para
permitir condicionalmente una conexión de este terminal fuente en
modo túnel bloqueante con el terminal de destino T_DEST de la red a
través del cortafuego PF.
Este programa está esencialmente constituido por
un módulo M_INIT de inicialización, un módulo M_AUTH_PER de
confirmación periódica de autentificación, y un módulo M_MAJ_DEC de
actualización y de decisión.
El módulo de inicialización M_INIT tiene como
misión arrancar el proceso de autentificación.
Para esto, este módulo M_INIT, que es activado
tras la autentificación inicial del terminal fuente T_SOUR junto al
portal cautivo PORT, permite que este terminal fuente recupere el
secreto compartido S comunicado por el portal PORT, e inicialice un
contador n.
El módulo de confirmación periódica de
autentificación M_AUTH_PER, que es llamado por el módulo de
inicialización M_INIT, es apropiado para elaborar un autentificador
único y para emitir este autentificador sobre la capa 2 del modelo
OSI, con destino al cortafuego PF.
Según sugiere simbólicamente la Figura 4A, la
autentificación emitida es elaborada, por ejemplo, a modo de
función f de la dirección IP del terminal fuente, del contenido del
contador n, y del secreto compartido S.
El módulo M_MAJ_DEC de actualización y de
decisión, que es llamado por el módulo M_AUTH_PER de confirmación
periódica de autentificación, cumple esencialmente dos
funciones.
Inicialmente este módulo incrementa el contador
n con vistas a la próxima autentificación del terminal fuente.
Y por otra parte, el módulo M_MAJ_DEC mantiene
la comunicación con el cortafuego, con vistas a poner fin a la
conexión en caso de anomalía, y en particular en caso de silencio
prolongado por parte del cortafuego.
En ausencia de anomalía, el M_MAJ_DEC llama de
nuevo al módulo M_AUTH_PER de confirmación periódica de
autentificación para permitir a este último proceder a una nueva
autentificación del terminal fuente T_SOUR junto al cortafuego PF
durante la conexión en modo túnel bloqueante.
El programa ilustrado en la Figura 4B, que está
implantado en el cortafuego PF, está concebido para autorizar
condicionalmente una conexión en modo túnel bloqueante entre el
terminal fuente T_SOUR y el terminal T_DEST de destino de la red a
través de este cortafuego PF.
Este segundo programa comprende esencialmente un
módulo de escucha M_ECOUT, un módulo M_SELECT de selección, y un
módulo M_ANAL_DEC de análisis y de decisión.
El módulo M_ECOUT de escucha está
permanentemente a la escucha de la red.
El módulo M_SELECT de selección, que es llamado
por el módulo de escucha M_ECOUT, resulta apropiado para localizar,
en el flujo de tramas que circulan por la capa 2 del modelo OSI, las
tramas TR que constituyen las tramas TR_AUTH de autentificación del
terminal fuente T_SOUR, y para direccionar estas tramas TR_AUTH de
autentificación hacia el módulo de análisis y de decisión
M_ANAL_DEC.
El módulo M_ANAL_DEC de análisis y de decisión
tiene en sí mismo la función de verificar el contenido de las
tramas TR_AUTH de autentificación recibidas desde el terminal
fuente, es decir, elaborar una función de decisión g en base a
estas tramas TR_AUTH.
Si los datos contenidos en las tramas TR_AUTH no
son reconocidos como aceptables, el módulo de análisis y de
decisión M_ANAL_DEC dispara una operación INHIB_PF correspondiente a
la destrucción, en el cortafuego PF, de las reglas de acceso desde
el terminal T_SOUR.
Si, por el contrario, los datos contenidos en
las tramas TR_AUTH son correctas, el módulo de análisis y de
decisión M_ANAL_DEC libera una operación MAJ_PF correspondiente a la
creación o a la actualización, sobre el cortafuego PF, de las
reglas de acceso desde el terminal fuente T_SOUR.
Claims (13)
1. Procedimiento de control de acceso de un
terminal fuente (T_SOUR) a una red que incluye un punto (P_ACC) de
acceso para este terminal, un cortafuego (PF) conectado al punto
(P_ACC) de acceso, y un portal (PORT) de autentificación que hace
uso de una base de datos (BDD) de autentificación, disponiendo este
portal (PORT) del cortafuego (PF) en un estado de autorización de
acceso en respuesta a una petición inicial de acceso en modo de
base que emana del terminal fuente (T_SOUR) y que incluye el
suministro al portal (PORT) o al cortafuego (PF) de datos de
autentificación válidos, a falta de los cuales el cortafuego se
dispone en un estado de prohibición de acceso, permaneciendo el
cortafuego (PF) en un estado de autorización de acceso en modo de
base en respuesta al suministro periódico, por el terminal fuente
(T_SOUR) y sobre un canal seguro de intercambio de ficha, de una
ficha de autentificación válida a falta de la cual el cortafuego
(PF) se sitúa en su estado de prohibición de acceso, y comunicando
el terminal fuente (T_SOUR) selectivamente en modo túnel con un
terminal (T_DEST) de destino de la red a través de un túnel
bloqueante, caracterizado porque el suministro periódico de
la ficha de autentificación se realiza al menos por medio de una
transmisión sobre la capa de nivel 2 del modelo OSI del canal de
intercambio de ficha establecido entre el terminal fuente (T_SOUR) y
el cortafuego (PF), con el resultado de que el suministro periódico
de la ficha de autentificación sigue estando asegurado durante una
comunicación en modo túnel bloqueante.
2. Procedimiento de control de acceso según la
reivindicación 1, caracterizado porque comprende, con
posterioridad a una operación inicial conseguida de autentificación
del terminal fuente (T_SOUR), al menos una operación de elaboración
de un secreto efectuada en el terminal fuente (T_SOUR) y/o en el
portal cautivo (PORT) por al menos uno de los programas de
aplicación (APPLI1, APPLI2) respectivos, y las operaciones de
retransmisión (D2 y D3 en la Figura 2) de este secreto en las
entidades de autentificación (PA1, PA2) correspondientes del
terminal fuente (T_SOUR) y del cortafuego (PF).
3. Procedimiento de control de acceso según la
reivindicación 2, caracterizado porque el secreto es
transmitido, de forma segura, desde el portal cautivo (PORT) hasta
el terminal fuente (T_SOUR) en una ventana de autentificación.
4. Procedimiento de control de acceso según la
reivindicación 3, caracterizado porque la ventana de
autentificación asegura igualmente la transmisión, desde el portal
cautivo (PORT) hacia el terminal fuente (T_SOUR), de un contador
inicializado a la vez en el lado del terminal fuente (T_SOUR) y en
el del portal cautivo (PORT).
5. Procedimiento de control de acceso según una
cualquiera de las reivindicaciones 3 y 4, caracterizado
porque la ventana de autentificación incluye un botón de
desconexión.
6. Procedimiento de control de acceso según una
cualquiera de las reivindicaciones 2 a 5, caracterizado
porque, con posterioridad a una operación inicial conseguida de
autentificación del terminal fuente (T_SOUR), la ficha de
autentificación es suministrada periódicamente por la entidad (PA1)
de autentificación del terminal fuente (T_SOUR), con destino a la
entidad (PA2) de autentificación del cortafuego (PF), la cual
verifica esta ficha.
7. Procedimiento de control de acceso según las
reivindicaciones 4 y 6, caracterizado porque, con
posterioridad a una operación inicial conseguida de autentificación
del terminal fuente (T_SOUR), el contador es suministrado
periódicamente por la entidad (PA1) de autentificación del terminal
fuente (T_SOUR) con destino a la entidad (PA2) de autentificación
del cortafuego (PF), la cual verifica este contador.
8. Procedimiento de control de acceso según una
cualquiera de las reivindicaciones 6 y 7, caracterizado
porque la entidad (PA2) de autentificación del cortafuego (PF),
tras la verificación de datos proporcionados por la entidad (PA1)
de autentificación del terminal fuente (T_SOUR), dispone un módulo
de filtrado (FILT) del cortafuego en un estado de autorización o de
prohibición de acceso en función del resultado de esta
verificación.
9. Procedimiento de control de acceso según una
cualquiera de las reivindicaciones 2 a 8 anteriores,
caracterizado porque la entidad (PA1) de autentificación del
terminal fuente (T_SOUR) se ha realizado en lenguaje Java, se
telecarga durante la autentificación inicial de este terminal
fuente, y se ejecuta en la ventana de mantenimiento de sesión.
10. Procedimiento de control de acceso según una
cualquiera de las reivindicaciones 2 a 9 anteriores,
caracterizado porque la transmisión de nivel 2 establecida
entre las entidades (PA1, PA2) de autentificación del terminal
fuente (T_SOUR) y del cortafuego (PF), es programada según una
extensión del protocolo ARP.
11. Programa de ordenador destinado a ser
implantado en un terminal fuente (T_SOUR) y concebido para autorizar
de manera condicionada una conexión de este terminal fuente, en
modo túnel bloqueante, con un terminal (T_DEST) de destino de una
red a través de un cortafuego (PF) controlado por un portal cautivo
(PORT) de la red, caracterizado porque comprende un módulo
(M_INIT) de inicialización apropiado para recuperar un secreto
compartido (S) proveniente del portal (PORT), y para inicializar un
contador (n), un módulo (M_AUTH_PER) de confirmación periódica de
autentificación llamado por el módulo (M_INIT) de inicialización y
apropiado para elaborar y emitir, con destino al cortafuego (PF) y
sobre la capa 2 del modelo OSI, un autentificador único dependiente
al menos del secreto compartido (S) y del contenido del contador
(n), y un módulo de actualización y de decisión (M_MAJ_DEC) llamado
por el módulo (M_AUTH_PER) de confirmación periódica de
autentificación y apropiado para incrementar el contador (n), para
poner fin a la conexión en caso de anomalía de comunicación con el
cortafuego, y para llamar de nuevo al módulo (M_AUTH_PER) de
confirmación periódica de autentificación en caso contrario, lo que
da como resultado que el terminal fuente (T_SOUR) continúe siendo
autentificado por el cortafuego (PF) durante la conexión en modo
túnel bloqueante.
12. Programa de ordenador destinado a ser
implantado en un cortafuego (PF) instalado en una red, y controlado
por un portal cautivo (PORT) de la red, para autorizar de manera
condicionada una conexión en modo túnel bloqueante entre un
terminal fuente (T_SOUR) y un terminal (T_DEST) de destino de esta
red a través del cortafuego (PF), caracterizado porque
comprende un módulo (M_ECOUT) de escucha de la red, un módulo
(M_SELECT) de selección, y un módulo (M_ANAL_DEC) de análisis y de
decisión, porque el módulo (M_ECOUT) de escucha de la red es
apropiado, en respuesta a una petición de autentificación recibida
desde el terminal fuente (T_SOUR), para recuperar un secreto
compartido (S) proveniente de este terminal fuente, porque el módulo
(M_SELECT) de selección es llamado por el módulo (M_ECOUT) de
escucha y es apropiado para localizar, en un flujo de tramas que
circulan sobre la capa 2 del modelo OSI, las tramas (TR_AUTH) de
autentificación del terminal fuente (T_SOUR), y para direccionar
las tramas (TR_AUTH) de autentificación hacia el módulo (M_ANAL_DEC)
de análisis y de decisión, y porque el módulo (M_ANAL_DEC) de
análisis y de decisión verifica el contenido de las tramas (TR_AUTH)
de autentificación, pone fin a la conexión del terminal fuente
(T_SOUR) en caso de anomalía, y actualiza las reglas de
autorización de conexión utilizadas por el cortafuego (PF) en caso
contrario.
13. Sistema para controlar el acceso de un
terminal fuente a una red informática, que comprende un cortafuego
(PF) situado entre la citada red informática y un punto (P_ACC) de
acceso para el citado terminal fuente (T_SOUR), y un portal de
autentificación (PORT) que dirige el estado de dicho cortafuego
(PF), en el que el cortafuego (PF) está capacitado para mantener un
canal de comunicación segura abierto para el terminal fuente
(T_SOUR) con la condición de que el terminal fuente (T_SOUR) envíe
periódicamente, o por acontecimiento, una ficha de autentificación,
caracterizado porque:
- el cortafuego (PF) comprende un módulo de
protocolo (PA2) de autentificación y un módulo de filtrado (FILT),
siendo el citado módulo de protocolo (PA2) de autentificación capaz
de volver "pasante" o "bloqueante" el citado módulo de
filtrado (FILT) para las comunicaciones entre el terminal fuente
(T_SOUR) y la red informática en función de que el terminal fuente
(T_SOUR) sea autentificado o no,
- el portal (PORT) de autentificación comprende
un programa de aplicación (APPLI2) capacitado para distribuir
secretos al módulo de protocolo (PA2) de autentificación cuando la
autentificación inicial del terminal fuente (T_SOUR) sobre la red
informática ha sido conseguida,
- el terminal fuente (T_SOUR) comprende un
módulo de protocolo (PA1) de autentificación y un programa de
aplicación (APPLI1), siendo el citado programa de aplicación
(APPLI1) apto para distribuir secretos al citado módulo de
protocolo (PA1) de autentificación cuando la autentificación inicial
del terminal fuente (T_SOUR) sobre la red informática ha sido
conseguida,
y porque el módulo de protocolo (PA1) de
autentificación está capacitado para enviar las citadas fichas de
autentificación al módulo de protocolo (PA2) de autentificación a
través de la capa 2 del modelo OSI.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP04291363A EP1605660B1 (fr) | 2004-06-01 | 2004-06-01 | Contrôle d'accès à un réseau d'un terminal source utilisant un tunnel en mode bloquant |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2279308T3 true ES2279308T3 (es) | 2007-08-16 |
Family
ID=34931135
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04291363T Expired - Lifetime ES2279308T3 (es) | 2004-06-01 | 2004-06-01 | Control de acceso a una red de un terminal fuente que utiliza un tunel en modo bloqueante. |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7730527B2 (es) |
| EP (1) | EP1605660B1 (es) |
| AT (1) | ATE347773T1 (es) |
| DE (1) | DE602004003568T2 (es) |
| ES (1) | ES2279308T3 (es) |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2884000A1 (fr) * | 2005-04-05 | 2006-10-06 | St Microelectronics Sa | Coprocesseur securise comprenant des moyens pour empecher l'acces a un organe du coprocesseur |
| FR2883998A1 (fr) * | 2005-04-05 | 2006-10-06 | St Microelectronics Sa | Coprocesseur securise comprenant un circuit de detection d'un evenement |
| JP4545085B2 (ja) * | 2005-12-08 | 2010-09-15 | 富士通株式会社 | ファイアウォール装置 |
| EP1801720A1 (en) * | 2005-12-22 | 2007-06-27 | Microsoft Corporation | Authorisation and authentication |
| EP1826695A1 (en) * | 2006-02-28 | 2007-08-29 | Microsoft Corporation | Secure content descriptions |
| US8559369B2 (en) | 2006-02-22 | 2013-10-15 | Elad Barkan | Wireless internet system and method |
| US20080119177A1 (en) * | 2006-09-15 | 2008-05-22 | Speedus Corp. | Metadata Content Delivery System for Wireless Networks |
| US8650589B2 (en) | 2007-01-08 | 2014-02-11 | At&T Intellectual Property I, Lp | System for provisioning media services |
| US8527757B2 (en) * | 2007-06-22 | 2013-09-03 | Gemalto Sa | Method of preventing web browser extensions from hijacking user information |
| KR101323852B1 (ko) * | 2007-07-12 | 2013-10-31 | 삼성전자주식회사 | 공용 보안 정책을 기반으로 하는 가상 방화벽 시스템 및 그제어방법 |
| US20090048853A1 (en) * | 2007-08-13 | 2009-02-19 | Jeffrey Hall | Permission based field service management system |
| US8272039B2 (en) * | 2008-05-02 | 2012-09-18 | International Business Machines Corporation | Pass-through hijack avoidance technique for cascaded authentication |
| US8688841B2 (en) * | 2008-06-05 | 2014-04-01 | Modena Enterprises, Llc | System and method for content rights based on existence of a voice session |
| US20100015976A1 (en) * | 2008-07-17 | 2010-01-21 | Domingo Enterprises, Llc | System and method for sharing rights-enabled mobile profiles |
| US20100015975A1 (en) * | 2008-07-17 | 2010-01-21 | Kota Enterprises, Llc | Profile service for sharing rights-enabled mobile profiles |
| US20120117110A1 (en) | 2010-09-29 | 2012-05-10 | Eloy Technology, Llc | Dynamic location-based media collection aggregation |
| US8767526B1 (en) | 2010-12-27 | 2014-07-01 | Juniper Networks, Inc. | Supplicant framework to handle clientless devices on a dot1x platform |
| US9509513B2 (en) * | 2011-04-15 | 2016-11-29 | Comcast Cable Communications, Llc | Provisioning using a generic configuration |
| WO2013095425A1 (en) * | 2011-12-21 | 2013-06-27 | Warwick Valley Networks | Authentication system and method for authenticating ip communications clients at a central device |
| CA2775782C (en) * | 2012-05-08 | 2013-09-24 | Guest Tek Interactive Entertainment Ltd. | Automatic service activation for user device upon detecting its device identifier on network of hospitality establishment |
| US9088891B2 (en) | 2012-08-13 | 2015-07-21 | Wells Fargo Bank, N.A. | Wireless multi-factor authentication with captive portals |
| US10015162B2 (en) * | 2015-05-11 | 2018-07-03 | Huawei Technologies Co., Ltd. | Firewall authentication of controller-generated internet control message protocol (ICMP) echo requests |
| US10439990B2 (en) | 2015-11-25 | 2019-10-08 | Barracuda Networks, Inc. | System and method to configure a firewall for access to a captive network |
| US10044677B2 (en) * | 2015-11-25 | 2018-08-07 | Barracuda Networks, Inc. | System and method to configure a firewall for access to a captive network |
| US10594732B2 (en) * | 2016-11-08 | 2020-03-17 | Ca, Inc. | Selective traffic blockage |
| US10541990B2 (en) * | 2017-07-31 | 2020-01-21 | Hewlett Packard Enterprise Development Lp | Client device ticket |
| US10812463B2 (en) * | 2017-12-08 | 2020-10-20 | International Business Machines Corporation | Secure access to an enterprise computing environment |
| US12008343B2 (en) | 2018-11-21 | 2024-06-11 | Kony, Inc. | System and method for a registration system within an intelligent digital experience development platform |
| US11328052B2 (en) * | 2020-01-31 | 2022-05-10 | The Toronto-Dominion Bank | Automatic workstation functionality management based on login credentials |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7627860B2 (en) * | 2001-08-14 | 2009-12-01 | National Instruments Corporation | Graphically deployment of a program with automatic conversion of program type |
| US6839645B2 (en) * | 2002-04-17 | 2005-01-04 | General Electric Company | Method and apparatus to perform poly-phase instrumentation with single-phase instruments |
| US20030204744A1 (en) * | 2002-04-26 | 2003-10-30 | Robert-Claude Maltais | Network access control |
| US8942375B2 (en) * | 2002-09-17 | 2015-01-27 | Broadcom Corporation | Method and system for providing multiple encryption in a multi-band multi-protocol hybrid wired/wireless network |
| US7454622B2 (en) * | 2002-12-31 | 2008-11-18 | American Express Travel Related Services Company, Inc. | Method and system for modular authentication and session management |
-
2004
- 2004-06-01 ES ES04291363T patent/ES2279308T3/es not_active Expired - Lifetime
- 2004-06-01 AT AT04291363T patent/ATE347773T1/de not_active IP Right Cessation
- 2004-06-01 EP EP04291363A patent/EP1605660B1/fr not_active Expired - Lifetime
- 2004-06-01 DE DE602004003568T patent/DE602004003568T2/de not_active Expired - Lifetime
-
2005
- 2005-05-27 US US11/139,034 patent/US7730527B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20050273848A1 (en) | 2005-12-08 |
| DE602004003568T2 (de) | 2007-09-20 |
| DE602004003568D1 (de) | 2007-01-18 |
| EP1605660A1 (fr) | 2005-12-14 |
| EP1605660B1 (fr) | 2006-12-06 |
| ATE347773T1 (de) | 2006-12-15 |
| US7730527B2 (en) | 2010-06-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2279308T3 (es) | Control de acceso a una red de un terminal fuente que utiliza un tunel en modo bloqueante. | |
| Aboba et al. | RADIUS (remote authentication dial in user service) support for extensible authentication protocol (EAP) | |
| US7904945B2 (en) | System and method for providing security for a wireless network | |
| Patel et al. | Securing L2TP using IPsec | |
| ES2264756T3 (es) | Comunicacion entre una red privada y un terminal movil itinerante. | |
| US7636938B2 (en) | Controlling network access | |
| US8443435B1 (en) | VPN resource connectivity in large-scale enterprise networks | |
| CN102316093B (zh) | 用于移动设备的双模式多服务vpn网络客户端 | |
| US20100192202A1 (en) | System and Method for Implementing a Secured and Centrally Managed Virtual IP Network Over an IP Network Infrastructure | |
| US20020163920A1 (en) | Method and apparatus for providing network security | |
| US20040255037A1 (en) | System and method for authentication and security in a communication system | |
| CN101218576B (zh) | 管理对网络的访问的方法和系统 | |
| EP3272059B1 (en) | Apparatus and method for using certificate data to route data | |
| FI120021B (fi) | Valtuustiedon hankkiminen | |
| US20030191843A1 (en) | Secure network connection for devices on a private network | |
| CN1949705B (zh) | 一种用于安全访问专用局域网的动态隧道构建方法及用于该方法的装置 | |
| JP2004213632A (ja) | コンピュータシステムがネットワークにアクセスするように準備する際に自動化のレベルを高める方法、コンピュータプログラム及び記録媒体 | |
| Cisco | Security Setup | |
| Cisco | Security Setup | |
| Cisco | Security Setup | |
| Cisco | L2TP Security | |
| ES2400937T3 (es) | Compatibilidad entre varias normas WLAN | |
| Aboba et al. | RFC3579: RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) | |
| Kacic et al. | Malware injection in wireless networks | |
| Vishwakarma | Virtual private networks |