ES2219163B2 - Seguridad con proxy de autentificacion. - Google Patents

Seguridad con proxy de autentificacion. Download PDF

Info

Publication number
ES2219163B2
ES2219163B2 ES200250023A ES200250023A ES2219163B2 ES 2219163 B2 ES2219163 B2 ES 2219163B2 ES 200250023 A ES200250023 A ES 200250023A ES 200250023 A ES200250023 A ES 200250023A ES 2219163 B2 ES2219163 B2 ES 2219163B2
Authority
ES
Spain
Prior art keywords
authentication
message
goalkeeper
ras
protocol
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 - Fee Related
Application number
ES200250023A
Other languages
English (en)
Other versions
ES2219163A1 (es
Inventor
Atle Raestad
Knut Snorre Bach Corneliussen
Dagfinn Aarvaag
Espen Iveland
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of ES2219163A1 publication Critical patent/ES2219163A1/es
Application granted granted Critical
Publication of ES2219163B2 publication Critical patent/ES2219163B2/es
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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/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
    • 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)
  • Small-Scale Networks (AREA)
  • Communication Control (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.
Campo de la invenció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.
Las áreas de problema
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.
Soluciones conocidas y problemas con éstas
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.
Objetos de la invención
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.
Breve descripción de la invención
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.
Descripción de los dibujos
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.
Descripción detallada de las realizaciones
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 (16)

1. Disposición de proxy de autentificación (2) en una red de telecomunicaciones H.323 para permitir la autentificación de un usuario final que opera desde un punto final (1) con H.323 sin soporte de autentificación H.323v2 o H.235 y con un Portero (3) que requiere la autentificación inicial de usuario final de acuerdo con un primer protocolo de autentificación H.323v2 utilizando un H.235, y sin ser soportado por el punto final (1), estando adaptado dicho proxy de autentificación (2) para formar una trayectoria de señalización para la autentificación del punto final (1) hacia el Portero (3), estando dispuesto el proxy de autentificación:
para recibir del punto final del usuario final, datos de autentificación que comprenden una clave de usuario final y una especificación de la situación del punto final de la red, los datos de autentificación siendo transmitidos al proxy de autentificación utilizando un segundo protocolo diferente de dicho primer protocolo,
caracterizada porque
el proxy de autentificación (2) estando dispuesto además:
para generar un primer mensaje RAS H.323 utilizando dicho primer protocolo, presentando dicho primer mensaje RAS H.323 los citados datos de autentificación recibidos e incluyendo una petición de autentificación que solicita la autentificación del usuario final por el Portero sobre las bases de los citados datos de autentificación,
para transmitir el citado primer mensaje RAS H.323 al Portero,
para recibir un segundo mensaje RAS H.323 del Portero in respuesta a dicho primer mensaje RAS H.323,
para interpretar dicho segundo mensaje RAS H.323 del Portero para detectar una confirmación o rechazo de dicha petición de autentificación, y
para generar y enviar a dicho punto final, al detectar dicha confirmación o rechazo de dicha petición de autentificación, un mensaje de confirmación o rechazo de autentificación, respectivamente, usando el segundo protocolo.
2. Disposición según la reivindicación 1, caracterizada porque la especificación de la situación del punto final de la red es una dirección (IP) de protocolo de Internet o un nombre de usuario.
3. Disposición según la reivindicación 1 ó 2, caracterizada porque se recibe la información de autentificación por medio de una forma html simple, una pequeña aplicación o un pequeño servidor.
4. Disposición según la reivindicación 3, caracterizada porque la pequeña aplicación es una pequeña aplicación firmada.
5. Disposición según cualquiera de las reivindicaciones anteriores, caracterizada porque el segundo protocolo incluye http o https.
6. Disposición según cualquiera de las reivindicaciones anteriores, caracterizada porque el citado primer mensaje RAS H.323 es un H.323.V.2 GRQ (Petición de Portero) o un RRQ (Petrición de Registro), respectivamente, incluyendo datos H.235 que incluyen los citados datos de autentificación.
7. Disposición según la reivindicación 6, caracterizada porque el segundo mensaje H.323 es un GCF (Confirmación de Portero) o un RCF (Confirmación de Registro).
8. Disposición según una cualquiera de las reivindicaciones 1 a 7, 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 segundo mensaje H.323 es un GRJ (Rechazo de Portero) o un RRJ (Rechazo de Registro).
9. Método que utiliza una disposición de proxy de autentificación (2) en una red de telecomunicaciones H.323 para permitir la autentificación de un usuario final que opera desde un punto final (1) con H.323 sin soporte de autentificación H.323v2 o H.235 e intentando operar con un Portero (3) que requiere la autentificación inicial de usuario final de acuerdo con un primer protocolo de autentificación que utiliza H.235, y sin ser soportado por el punto final (1), estando dispuesto dicho proxy de autentificación (2) para formar una trayectoria de señalización para la autentificación del punto final (1) hacia el Portero (3), incluyendo dicho método:
reciviendo del punto final del usuario final, datos de autentificación que comprenden una clave de usuario final y una especificación de la situación del punto final de la red, los datos de autentificación habiendo siendo transmitidos al proxy de autentificación utilizando un segundo protocolo diferente de dicho primer protocolo,
caracterizado porque el método incluye además
generar un primer mensaje RAS H.323 utilizando dicho primer protocolo, presentando dicho primer mensaje RAS H.323 los citados datos de autentificación recividos e incluyendo una petición de autentificación que solicita la autentificación del usuario final por el Portero sobre las bases de los citados datos de autentificación presentados,
transmitir el citado primer mensaje RAS H.323 al Portero,
recibir un segundo mensaje RAS H.323 del Portero in respuesta a dicho primer mensaje RAS H.323,
interpretar dicho segundo mensaje RAS H.323 del Portero para detectar una confirmación o rechazo de dicha petición de autentificación, y
generar y enviar a dicho punto final, al detectar dicha confirmación o rechazo de dicha petición de autentificación, un mensaje de confilinación o rechazo de autentificación, respectivamente, usando el segundo protocolo.
10. Método según la reivindicación 9, caracterizado porque la especificación de la situación del punto final de la red es una dirección (IP) de protocolo de Internet o un nombre de usuario.
11. Método según la reivindicación 9 o 10, caracterizado porque se recibe la información de autentificación por medio de una forma html simple, una pequeña aplicación o un pequeño servidor.
12. Método según la reivindicación 11, caracterizado porque la pequeña aplicación es una pequeña aplicación firmada.
13. Método según una cualquiera de las reivindicaciones 9 a 12, caracterizado porque el segundo protocolo incluye http o https.
14. Método según una cualquiera de las reivindicaciones 9 a 13, caracterizado porque el citado primer mensaje RAS H.323 es un H.323.V.2 GRQ (Petición de Portero) o un H.323.V2 RRQ (Petrición de Registro), respectivamente, incluyendo datos H.235 que incluyen los citados datos de autentificación.
15. Método según una cualquiera de las reivindicaciones 9 a 14, caracterizado porque el segundo mensaje H.323 es un GCF (Confirmación de Portero) o un RCF (Confirmación de Registro).
16. Método según una cualquiera de las reivindicaciones 9 a 15, caracterizado porque comprende además la etapa de enviar al punto final del usuario final una respuesta http que indica fracaso en la autentificación si el segundo mensaje H.323 es un GRJ (Rechazo de Portero) o un RRJ (Rechazo de Registro).
ES200250023A 1999-09-06 2000-09-04 Seguridad con proxy de autentificacion. Expired - Fee Related ES2219163B2 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO994334A NO994334L (no) 1999-09-06 1999-09-06 Sikkerhet med autentiseringsproxy
NO19994334 1999-09-06

Publications (2)

Publication Number Publication Date
ES2219163A1 ES2219163A1 (es) 2004-11-16
ES2219163B2 true 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)

* Cited by examiner, † Cited by third party
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 キヤノン株式会社 ネットワーク機器管理装置およびその制御方法、プログラム、記憶媒体

Family Cites Families (5)

* Cited by examiner, † Cited by third party
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
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
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
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", páginas 7,8,32-35. *

Also Published As

Publication number Publication date
WO2001019018A1 (en) 2001-03-15
ES2219163A1 (es) 2004-11-16
GB2371455B (en) 2004-06-30
NO994334D0 (no) 1999-09-06
DE10084960T1 (de) 2002-08-01
GB2371455A (en) 2002-07-24
AU6880800A (en) 2001-04-10
US7197766B1 (en) 2007-03-27
NO994334L (no) 2001-03-07
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) Ｕｉｃｃなしコールのサポート
ES2397063T3 (es) Autenticación para protocolos de aplicación IP basados en procedimientos IMS del 3GPP
EP1490995B1 (en) End-to-end protection of media stream encryption keys for voice-over-IP systems
US10516660B2 (en) Methods, systems, devices and products for authentication
US8117273B1 (en) System, device and method for dynamically securing instant messages
US20050182937A1 (en) Method and system for sending secure messages over an unsecured network
US20060274899A1 (en) System and method for secure messaging with network address translation firewall traversal
US20090041006A1 (en) Method and system for providing internet key exchange
US20200313901A1 (en) Method of Identity Authentication for Voice over Internet Protocol Call and Related Device
CN1658547B (zh) 密钥分发方法
ES2241275T3 (es) Metodo, disposicion y aparato para autentificacion.
JP2006217446A (ja) 遠隔会議システム
ES2290167T3 (es) Procedimiento y nudo de acceso a internet para la identificacion de usuarios de internet.
ES2219163B2 (es) Seguridad con proxy de autentificacion.
US7684385B2 (en) Inter-enterprise telephony using a central brokerage device
RU2006140776A (ru) Возможность быстрого и защищенного соединения для подвижного узла
KR20030013496A (ko) 다중 터널 브이피엔 게이트웨이를 이용한 데이터 전송 장치
US11146536B2 (en) Method and a system for managing user identities for use during communication between two web browsers
US7966657B2 (en) Method for a secure information transfer
US11979389B1 (en) End-to-end message encryption
CN114205170B (zh) 跨接口平台组网通信及服务加密调用方法
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
JP2001320359A (ja) 暗号通信システム

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