ES2219163A1 - Seguridad con proxy de autentificacion. - Google Patents
Seguridad con proxy de autentificacion.Info
- Publication number
- ES2219163A1 ES2219163A1 ES200250023A ES200250023A ES2219163A1 ES 2219163 A1 ES2219163 A1 ES 2219163A1 ES 200250023 A ES200250023 A ES 200250023A ES 200250023 A ES200250023 A ES 200250023A ES 2219163 A1 ES2219163 A1 ES 2219163A1
- Authority
- ES
- Spain
- Prior art keywords
- authentication
- proxy
- protocol
- endpoint
- user
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 claims description 8
- 230000011664 signaling Effects 0.000 claims description 6
- 238000012790 confirmation Methods 0.000 claims 8
- 235000020004 porter Nutrition 0.000 claims 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
-
- 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/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
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)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Abstract
Se propone una disposición para conseguir la autentificación de usuarios finales (1) y puntos finales (1) en una red a base de paquetes, que incluye componentes que soportan todas o partes de versiones diferentes de la norma H.323 recomendada. La autentificacion se consigue por medio de un proxy (2) de autentificación que soportará perfiles de seguridad soportados por uno o más porteros (3) asociados. La provisión de información sobre usuarios finales (1) y puntos finales para un proxy (2) de autentificación puede conseguirse por medio de comunicación estándar no propietaria y de un protocolo tal como http o https y un simple formulario html, una pequeña aplicación o un pequeño servidor, respectivamente, y para un portero (3) por medio de un mensaje RAS tal como una petición de portero (GRQ).
Description
Seguridad con proxy de autentificación.
La presente invención se refiere al campo de las
comunicaciones de audio, vídeo y datos a través de redes basadas en
paquetes, particularmente a la autentificación de usuarios finales
y puntos finales en redes que cumplen la especificación H.323 de la
Unión Internacional de Telecomunicaciones.
La recomendación UTI-T H.235 de
la Unión Internacional de Telecomunicaciones recomienda una norma
de seguridad y encriptación para terminales multimedia que cumplen
las recomendaciones de la serie H (H.323 y otra basada en la
H.235) de la Unión Internacional de Telecomunicaciones. H.235 es
una nueva característica en la versión 2 (H.323v2) de la
recomendación H.323. Añade diversos mecanismos de seguridad como
autentificación y comprobaciones de integridad a la norma H.323
recomendada. En la versión 1 (H.323v1) de la H.323 no había
mecanismos de seguridad y la red tenía que confiar en que los
usuarios finales fueran quienes afirmaban ser. Esto constituye un
problema cuando los usuarios finales tienen sus propios perfiles
confidenciales en el sistema que incluye un conjunto de servicios
suplementarios. La autentificación del usuario final es también un
prerrequisito cuando se factura al consumidor final por el tráfico
H.323 y cuando se construyen redes privadas virtuales sobre la red
H.323.
Incluso aunque el uso de H.235 parece prometedor,
quedan algunos problemas importantes por resolver. Un problema es
que hay un amplio uso en puntos finales de la H.323 versión 1. Como
se indicó antes, sólo los puntosfinales que cumplan H.323v2 pueden
soportar H.235. Otro problema es que muy pocos de los puntos finales
que cumplen H.323v2 que están en el mercado actualmente soportan
H.235. Estos dos problemas tienen que ser resueltos en una red H.323
que base su lógica en usuarios finales autentificados.
Otro área de problema es la propia H.235, puesto
que es muy genérica y necesita un perfil de seguridad para ser
aplicada. En una red es probable que muchos perfiles de seguridad
diferentes estén en uso por puntos finales distintos. Cuando los
perfiles de seguridad son diferentes, la conversión de un perfil de
seguridad a otro perfil de seguridad no puede hacerse ya que los
perfiles de seguridad generalmente realizarán una función de
comprobación diferente sobre datos distintos. En consecuencia, no
es práctico que los componentes de red H.323 soporten todos los
perfiles de seguridad.
Un ejemplo para ilustrar el problema con dos
clientes con diferentes perfiles de seguridad se muestra en la Fig.
1. En este ejemplo, el portero (gatekeeper) (3) necesita soportar
ambos perfiles de seguridad para poder autentificar los dos
usuarios finales (1) que usan los dos clientes H.323.
Una solución a los problemas con la H.235 es no
basar la autentificación en la H.235 en absoluto, y usar un
protocolo propietario para la autentificación del usuario final
(1). Esto, a su vez, conduce a dos problemas:
- 1)
- el usuario final (1) tiene que arrancar dos programas, el cliente de autentificación y el cliente H.323 cuando usa la red H.323, incluso aunque el cliente H.323 sea un cliente versión 2 con soporte H.235.
- 2)
- la red H.323 tiene que soportar un nuevo protocolo propietario además de la H.323.
Otra solución conocida es aplicar el perfil de
seguridad 1 IMTC (SP1) propuesto por el Consorcio Internacional de
Teleconferencia y Multimedia. Sin embargo, éste está centrado en la
autentificación e integridad mensaje a mensaje y no ha hecho una
distinción clara entre autentificación de usuario e integridad de
mensaje.
Por consiguiente, un objeto de la presente
invención es proporcionar una disposición en una red H.323 que
permita la autentificación de puntos finales que cumplan
H.323v1.
Otro objeto de la presente invención es
proporcionar una disposición en una red H.323 que permita la
autentificación de los puntos finales que cumplan H.323v2 pero que
no soporten H.235.
Un objeto más de la presente invención es
proporcionar una disposición en una red H.323 que permita la
autentificación de clientes de usuarios finales (1) con diferentes
perfiles de seguridad.
Los objetos anteriores se satisfacen en una
disposición prevista por la presente invención, en la que se
proporciona un proxy de autentificación y un portero soporta un
perfil de seguridad usado por un proxy de autentificación.
La Fig. 1 muestra cómo se realiza el
procedimiento de registro según la técnica anterior cuando dos
puntos finales, que soportan H.323v1 o H.323v2 sin soporte para
H.235, realizan un registro hacia un portero. En este escenario el
Portero tiene que confiar en que los puntos finales sean quienes
afirman ser, puesto que no son soportadas acciones de
autentificación.
La Fig. 2 muestra un ejemplo de una disposición
de la técnica anterior en la que el portero (3) se encuentra con
clientes diferentes con distintos perfiles de seguridad. El
registro sigue el mismo flujo de procedimiento que se muestra en la
Fig. 1 (pero ahora con H.235). En esta disposición el portero tiene
que soportar todos los perfiles diferentes usados por los puntos
finales que se están registrando. Esto constituye un problema ya
que el portero es un nodo de tráfico y el soportar varios perfiles
diferentes retardará sus operaciones normales.
La Fig. 3 muestra un ejemplo de flujo de señal de
una disposición según la invención.
La Fig. 4 muestra un ejemplo de una secuencia de
flujo de señal de una disposición según la invención que incluye
los mensajes enviados entre las diferentes entidades. En esta
secuencia, se muestra un esquema de autentificación de una
etapa.
La Fig. 5 muestra un ejemplo de una secuencia de
flujo de señal de una disposición según la invención que incluye
los mensajes enviados entre las diferentes entidades. En esta
secuencia, se muestra un esquema de autentificación de dos etapas
que es llamado esquema pregunta/respuesta.
La Fig. 6 muestra cómo una pequeña aplicación
puede ser recibida desde el proxy de autentificación. No es
necesario que la pequeña aplicación sea recibida desde el proxy de
autentificación; puede ser recibida desde cualquier otra entidad
siempre que envíe la petición de http con nombre de usuario y
palabra clave al proxy de autentificación. Puesto que los aspectos
de seguridad en el cliente se hacen más simples (no es un requisito
absoluto que la pequeña aplicación esté firmada) cuando la pequeña
aplicación es recibida desde el proxy de autentificación, este
escenario se usará de ahora en adelante.
La Fig. 7 muestra un diagrama de bloques para el
proxy de autentificación con un flujo de señalización numerado
para un esquema de autentificación simple (no pregunta/respuesta).
Si es usado un esquema pregunta/respuesta, entonces el flujo de
señalización debe ser extendido entre el punto 9 y 10 de acuerdo
con la figura 5.
La Fig. 8 muestra una representación esquemática
de un ejemplo de realización de una secuencia de flujo de señal en
una disposición según la invención.
A continuación, por medio de ejemplo, se
describirá la presente invención con más detalle.
Con referencia a la Fig. 7 se muestra un ejemplo
de una realización de la presente invención. Toda la información
que necesita el proxy de autentificación será requerida al usuario
final a través de la comunicación http estándar o cualquier otro
protocolo adecuado.
A continuación, sólo para el propósito de
explicar la presente invención el protocolo usado será http.
Al usuario final (1) podría serle presentada una
forma html simple, una pequeña aplicación (que puede estar
firmada), un pequeño servidor o similar para proporcionar su nombre
de usuario y palabra clave. Esto se muestra en las etapas 1 y 2 en
la Fig. 7. Si se usa una pequeña aplicación, ésta debería estar
firmada, de manera que el usuario final pueda estar seguro del
origen de la pequeña aplicación. La pequeña aplicación debe estar
firmada si es recibida desde otra entidad distinta al proxy de
autentificación. La razón es que la mayoría de los entornos que
ejecutan pequeñas aplicaciones no permiten que las pequeñas
aplicaciones se comuniquen con otras entidades distintas de su
origen a menos que estén firmadas.
La comprobación descrita en el perfil de
seguridad H.235 debería ser hecha por la pequeña aplicación si se
usa una pequeña aplicación. Si la comprobación no es realizada por
la pequeña aplicación (por ejemplo, según la Fig. 7), o es usado
algo más que una pequeña aplicación, el protocolo de comunicación
debería ser entonces SSL, es decir https en lugar de http. La razón
para añadir una capa para comunicaciones seguras para http es que
esto evitará que el nombre de usuario y la palabra clave viajen no
asegurados a través de la red. La comprobación será realizada
entonces en el proxy de autentificación, y el nombre de usuario y
la palabra clave estarán asegurados todo el camino hasta el
portero. En escenarios en los que el punto final soporta H.235 pero
con diferentes perfiles de seguridad (véase Fig. 2), el proxy de
autentificación puede ser usado para la conversión entre diferentes
perfiles de seguridad (como se muestra en la Fig. 3). Esto es
beneficioso porque mantiene la complejidad de entendimiento de
perfiles de seguridad diferentes fuera del portero.
Con referencia a la Fig. 7, el flujo de señal se
explica en lo que sigue por medio del ejemplo. Cuando el proxy de
autentificación (2) recibe la información del usuario a través de
http, https u otros protocolos estándar, genera un mensaje RAS
estándar tal como un H.323v2 GRQ (Petición portero) que lleva los
datos H.235. Éste es enviado directamente a un portero (3) según
H.323v2, donde se hace la autentificación real. El portero
comprueba entonces el nombre de usuario y la palabra clave, y envía
de vuelta un GCF. Un GRJ es enviado de vuelta si el nombre de
usuario y la palabra clave no casan. Cuando el proxy de
autentificación recibe el GCF enviará una respuesta http al cliente
{etapa 12). Si el proxy de autentificación recibe un GRJ informará
al punto final del intento de autentificación sin éxito en la
respuesta http. Si se usa la autentificación pregunta/respuesta, el
proxy de autentificación esperará un RRQ y una recuperación de un
RCF antes de que envíe la respuesta http de vuelta al usuario
(véase la Fig. 7).
El cliente H.323 puede ahora registrarse en el
portero (3) de una forma normal enviando GRQ y RRQ. El portero (3)
sabrá cuando reciba el GRQ y RRQ que el usuario/punto final (1) ya
está autentificado en base al nombre de usuario, la dirección (IP)
de protocolo de Internet o ambos.
Para evitar problemas en el portero (3) cuando
reciba dos GRQ (uno desde el proxy (2) y otro desde el punto final
(1)), el proxy de autentificación puede responder los GRQ enviados
desde los puntos finales (1) que cumplan H.323vl y los puntos
finales (1) que cumplen H.323v2 sin soporte H.235 directamente
(esto no se muestra en la figura 8). Puesto que el portero (3)
recibirá sólo los GRQ del tipo H.323v2 cuando esta característica
es añadida, el portero (3) no puede decidir, en base al GRQ, que
versión de la H.323 cumplen los diversos puntos finales (1). El
portero (3) debería en su lugar basar su decisión en los RRQ
recibidos u otros mensajes RAS adecuados desde los puntos finales.
Si este escenario es usado junto con autentificación
pregunta/respuesta, el RRQ debe también ser enviado al proxy de
autentificación (véase la Fig. 7). Debido a la naturaleza de H.323,
este escenario implica que toda la señalización RAS posterior tiene
que ir a través del proxy de autentificación.
El proxy de autentificación puede ser colocado en
cualquier parte en la red. En algunas redes en las que existe un
cortafuegos entre el cliente y el portero, puede ser acertado
colocar el proxy de autentificación en la zona desmilitarizada
(DMZ). Esto falla porque a veces es difícil dejar que una corriente
SSL pase a través de un cortafuegos.
Claims (13)
1. Disposición en una red de telecomunicaciones
H.323 para la autentificación de un usuario final que opera desde
un punto final (1) con H.323 pero sin soporte de autentificación
H.323v2 o H.235 y registrándose con un Portero (3) que requiere la
autentificación de usuario final de acuerdo con H.323v2 o H.235 u
otro perfil de seguridad no soportado por el punto final (1),
incluyendo dicha disposición un proxy (2) de autentificación
dispuesto en una trayectoria de señalización para la
autentificación del punto final (1) hacia el Portero (3), dispuesto
el proxy (2) de autentificación para obtener información de
autentificación y una dirección de punto de acceso de servicio de
protocolo de transporte (TSAP) del punto final del usuario final que
usa un primer protocolo, y autentificar al usuario final en base a
la información de autentificación obtenida, con el Portero usando
un segundo protocolo, caracterizada por usar un protocolo
H.323 con seguridad H.235 y un perfil de seguridad soportado por el
Portero en la autentificación del usuario final hacia el Portero y
proporcionar la dirección TSAP al Portero.
2. Disposición según la reivindicación 1,
caracterizada porque la dirección TSAP es una dirección
(IP) de protocolo de Internet.
3. Disposición según la reivindicación 1 ó 2,
caracterizada porque la información de autentificación
incluye un nombre y/o una palabra clave del usuario final.
4. Disposición según la reivindicación 1, 2 ó 3,
caracterizada porque se obtiene la información de
autentificación por medio de una forma html simple, una pequeña
aplicación o un pequeño servidor.
5. Disposición según la reivindicación 4,
caracterizada porque la pequeña aplicación es una pequeña
aplicación firmada.
6. Disposición según cualquiera de las
reivindicaciones anteriores, caracterizada porque el primer
protocolo es http o https.
7. Disposición según la reivindicación 1,
caracterizada porque el proxy de autentificación está
dispuesto para generar un mensaje RAS estándar tal como un
H.323.v.2 GRQ (Petición de Portero) que lleva datos H.235.
8. Disposición según una cualquiera de las
reivindicaciones 1, 2 ó 4, caracterizada porque el proxy de
autentificación está dispuesto para enviar al punto final del
usuario final una respuesta http que indica la autentificación con
éxito si el proxy de autentificación recibe un GCF desde el
Portero.
9. Disposición según una cualquiera de las
reivindicaciones 1, 2, 4 u 8, caracterizada porque el proxy
de autentificación está dispuesto para enviar al punto final del
usuario final una respuesta http que indica fracaso en la
autentificación si el proxy de autentificación recibe un GRJ desde
el Portero.
10. Método en una red de telecomunicaciones H.323
para autentificar un usuario final, operando el usuario final
desde un punto final (1) con H.323 sin soporte de autentificación
H.323v2 o H.235 y registrándose con un Portero (3) que requiere
autentificación de usuario final de acuerdo con H.323v2 o H.235 u
otro perfil de seguridad no soportado por el punto final (1),
incluyendo la telecomunicación H.323 un proxy (2) de
autentificación dispuesto en una trayectoria de señalización para la
autentificación del punto final (1) hacia el Portero (3),
comprendiendo el método: comunicar al usuario final la información
de autentificación desde el punto final del usuario final al proxy
de autentificación y obtener una dirección de punto de acceso de
servicio de protocolo de transporte (TSAP) del punto final, que
usa un primer protocolo, comunicar la información de
autentificación de usuario final desde el proxy de autentificación
al Portero que usa un segundo protocolo, y un mensaje de
confirmación de autentificación desde el portero al proxy de
autentificación, y comunicar un mensaje de confirmación de
autentificación desde el proxy de autentificación al punto final que
usa el primer protocolo, caracterizado porque la etapa de
comunicar la información de autentificación de usuario final al
Portero y comunicar un mensaje de confirmación de autentificación
desde el portero al proxy de autentificación incluye: transmitir la
información de autentificación de usuario final y la dirección de
punto de acceso de servicio de protocolo de transporte (TSAP) del
punto final desde el proxy de autentificación al Portero por medio
de un mensaje GRQ que especifica el punto final, que usa un
protocolo H.323 con seguridad H.235 y un perfil de seguridad
soportado por el Portero, y transmitir el mensaje de confirmación
de autentificación desde el portero al proxy de autentificación
por medio de un mensaje GCF que especifica el punto final.
11. Método en una red de telecomunicaciones H.323
para autentificar y registrar un usuario final que opera desde un
punto final (1) con 11.323 sin soporte de autentificación 11.323v2
o H.235 hacia un Portero (3) que requiere autentificación de usuario
final de acuerdo con H.323v2 o H.235 u otro perfil de seguridad no
soportado por el punto final (1), incluyendo la telecomunicación
11.323 un proxy (2) de autentificación dispuesto en una
trayectoria de señalización para la autentificación del punto final
(1) hacia el Portero (3), comprendiendo el método: comunicar la
información de autentificación del usuario final desde el punto
final del usuario final al proxy de autentificación y obtener una
dirección de punto de acceso de servicio de protocolo de transporte
(TSAP) del punto final que usa un primer protocolo, comunicar la
información de autentificación de usuario final desde el proxy de
autentificación al Portero que usa un segundo protocolo, y un
mensaje de confirmación de autentificación desde el portero al proxy
de autentificación, y comunicar un mensaje de confirmación de
autentificación desde el proxy de autentificación al punto final
que usa el primer protocolo, caracterizado porque la etapa
de comunicar la información de autentificación de usuario final al
Portero y un mensaje de confirmación de autentificación desde el
portero al proxy de autentificación incluye: transmitir desde el
proxy de autentificación al Portero un mensaje GRQ que especifica
la dirección de punto de acceso de servicio de protocolo de
transporte (TSAP) del punto final, transmitir desde el portero al
proxy de autentificación un mensaje GCF que incluye una pregunta
de autentificación, transmitir la información de autentificación
de usuario final desde el proxy de autentificación al Portero por
medio de un mensaje RRQ que especifique el punto final, que usa un
protocolo H323 con seguridad H.235 y un perfil de seguridad
soportado por el Portero, y transmitir una confirmación de
autentificación desde el portero al proxy de autentificación por
medio de un mensaje RCF que especifica el punto final.
12. Método según una cualquiera de las
reivindicaciones 10 u 11, caracterizado porque la
dirección TSAP es una dirección (IP) de protocolo de Internet.
13. Método según una cualquiera de las
reivindicaciones 10, 11 ó 12, caracterizado porque el
primer protocolo es http o https.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NO19994334 | 1999-09-06 | ||
| NO994334A NO994334L (no) | 1999-09-06 | 1999-09-06 | Sikkerhet med autentiseringsproxy |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2219163A1 true ES2219163A1 (es) | 2004-11-16 |
| ES2219163B2 ES2219163B2 (es) | 2007-04-16 |
Family
ID=19903743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200250023A Expired - Fee Related ES2219163B2 (es) | 1999-09-06 | 2000-09-04 | Seguridad con proxy de autentificacion. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7197766B1 (es) |
| AU (1) | AU6880800A (es) |
| DE (1) | DE10084960T1 (es) |
| ES (1) | ES2219163B2 (es) |
| GB (1) | GB2371455B (es) |
| NO (1) | NO994334L (es) |
| WO (1) | WO2001019018A1 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7836494B2 (en) * | 1999-12-29 | 2010-11-16 | Intel Corporation | System and method for regulating the flow of information to or from an application |
| NO313977B1 (no) * | 2001-05-28 | 2003-01-06 | Ericsson Telefon Ab L M | Tilstedev¶relsetjenester i H.323 baserte kommunikasjonsnett |
| US7650636B2 (en) * | 2004-03-03 | 2010-01-19 | Cisco Technology, Inc. | Network security enhancement methods and devices |
| DE102004039407A1 (de) * | 2004-08-13 | 2006-02-23 | Siemens Ag | Kommunikationssystem, Verfahren zum Anmelden in einem Kommunikationssystem und Netzwerkverbindungs-Rechner |
| JP5408910B2 (ja) * | 2008-06-10 | 2014-02-05 | キヤノン株式会社 | ネットワーク機器管理装置およびその制御方法、プログラム、記憶媒体 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5586260A (en) * | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9104909D0 (en) * | 1991-03-08 | 1991-04-24 | Int Computers Ltd | Access control in a distributed computer system |
| US5913025A (en) * | 1996-11-14 | 1999-06-15 | Novell, Inc. | Method and apparatus for proxy authentication |
| US5999525A (en) * | 1996-11-18 | 1999-12-07 | Mci Communications Corporation | Method for video telephony over a hybrid network |
| US6259691B1 (en) * | 1998-07-24 | 2001-07-10 | 3Com Corporation | System and method for efficiently transporting dual-tone multi-frequency/multiple frequency (DTMF/MF) tones in a telephone connection on a network-based telephone system |
-
1999
- 1999-09-06 NO NO994334A patent/NO994334L/no not_active Application Discontinuation
-
2000
- 2000-09-04 ES ES200250023A patent/ES2219163B2/es not_active Expired - Fee Related
- 2000-09-04 WO PCT/NO2000/000287 patent/WO2001019018A1/en active IP Right Grant
- 2000-09-04 DE DE10084960T patent/DE10084960T1/de not_active Withdrawn
- 2000-09-04 AU AU68808/00A patent/AU6880800A/en not_active Abandoned
- 2000-09-04 GB GB0204334A patent/GB2371455B/en not_active Expired - Fee Related
- 2000-09-06 US US09/655,871 patent/US7197766B1/en not_active Expired - Lifetime
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5586260A (en) * | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
Non-Patent Citations (2)
| Title |
|---|
| International Telecommunication Union, ITU-T Recommendation H.323 "Visual telephone systems and equipment for local area networks wich provide a non-guaranteed quality of service", paginas 7,8,32-35. * |
| International Telecommunication Union, ITU-T Recommendation H.323 "Visual telephone systems and equipment for local area networks wich provide a non-guaranteed quality of service", páginas 7,8,32-35. * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001019018A1 (en) | 2001-03-15 |
| GB2371455B (en) | 2004-06-30 |
| NO994334L (no) | 2001-03-07 |
| GB2371455A (en) | 2002-07-24 |
| DE10084960T1 (de) | 2002-08-01 |
| AU6880800A (en) | 2001-04-10 |
| ES2219163B2 (es) | 2007-04-16 |
| US7197766B1 (en) | 2007-03-27 |
| NO994334D0 (no) | 1999-09-06 |
| GB0204334D0 (en) | 2002-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7770007B2 (en) | Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication | |
| JP5069320B2 (ja) | Ｕｉｃｃなしコールのサポート | |
| US8515066B2 (en) | Method, apparatus and program for establishing encrypted communication channel between apparatuses | |
| US6674758B2 (en) | Mechanism for implementing voice over IP telephony behind network firewalls | |
| US20060274899A1 (en) | System and method for secure messaging with network address translation firewall traversal | |
| US7792065B2 (en) | Securely establishing sessions over secure paths | |
| US6792534B2 (en) | End-to end protection of media stream encryption keys for voice-over-IP systems | |
| US20100195811A1 (en) | Telephone Number Binding in a Voice-Over-Internet System | |
| US20040249974A1 (en) | Secure virtual address realm | |
| US8117273B1 (en) | System, device and method for dynamically securing instant messages | |
| US20090041006A1 (en) | Method and system for providing internet key exchange | |
| EP2044730B1 (en) | System and method for establishing a communication session between two endpoints that do not both support secure media | |
| JP2007538426A5 (es) | ||
| US8923279B2 (en) | Prevention of voice over IP spam | |
| Rasol et al. | An improved secure SIP registration mechanism to avoid VoIP threats | |
| US7684385B2 (en) | Inter-enterprise telephony using a central brokerage device | |
| ES2219163B2 (es) | Seguridad con proxy de autentificacion. | |
| US9002748B2 (en) | Method for securing IP connections for network operator combinatory connections | |
| Belmekki et al. | Enhances security for IMS client | |
| US11979389B1 (en) | End-to-end message encryption | |
| Jones et al. | RFC 9185: DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange | |
| US20090116474A1 (en) | Terminal, method, and computer program product for registering user address information | |
| Wagner | Implementation and evaluation of the interaction between host identity protocol and session initiation protocol | |
| Medvinsky | Scalable architecture for VoIP privacy | |
| Alsmairat | Securing SIP in VoIP Domain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20041116 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2219163B2 Country of ref document: ES |
|
| FD2A | Announcement of lapse in spain |
Effective date: 20211118 |