ES2300792T3 - Metodo para distribuir claves de acceso (passwords). - Google Patents
Metodo para distribuir claves de acceso (passwords). Download PDFInfo
- Publication number
- ES2300792T3 ES2300792T3 ES04741888T ES04741888T ES2300792T3 ES 2300792 T3 ES2300792 T3 ES 2300792T3 ES 04741888 T ES04741888 T ES 04741888T ES 04741888 T ES04741888 T ES 04741888T ES 2300792 T3 ES2300792 T3 ES 2300792T3
- Authority
- ES
- Spain
- Prior art keywords
- authentication
- remote server
- identity
- server
- access
- 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
- 238000000034 method Methods 0.000 title claims abstract description 42
- 238000012546 transfer Methods 0.000 claims description 5
- 238000012790 confirmation Methods 0.000 claims description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000003756 stirring 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
- Burglar Alarm Systems (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
Abstract
Un método de generar una clave de acceso para usar por un dispositivo de usuario final, UE, para acceder a un servidor distante; que comprende: enviar una petición de acceso desde el UE al servidor distante; crear una identidad temporal para el UE; enviar a un nodo de autenticación en la red doméstica de UE detalles de la petición de acceso; en el nodo de autenticación o el servidor distante, generar un impulso de interrogación (challenge), de Protocolo de Transferencia de Hipertexto, (HTTP), Digest usando un algoritmo capaz de generar claves de acceso de usuario final, incluyendo detalles de la identidad temporal del UE; en el UE, generar una clave de acceso basada en el impulso de interrogación de HTTP Digest, estando dicha clave de acceso asociada con la identidad del servidor distante y la identidad del UE; y almacenar la clave de acceso y la identidad temporal del UE en el UE.
Description
Método para distribuir claves de acceso
(passwords).
La invención se refiere un método para
distribuir claves de acceso (passwords). En particular, aunque no
exclusivamente, la invención se refiere a un método para generar
una clave de acceso para usar por un dispositivo de usuario final
para acceder a un servidor distante, en el que la clave de acceso es
retenida para uso subsiguiente.
La creación y distribución de claves de acceso
de usuario final para aplicaciones y apoderados (proxies) de
aplicaciones es problemática. Por una parte, los usuarios finales
tienden a crear claves de acceso que son sencillas y cortas y que
por tanto corren el riesgo de ser descubiertas por participantes no
autorizados. Por otra parte, averiguar la relación entre las
identidades de usuarios finales y sus claves de acceso es con
frecuencia inseguro y costoso.
Hay mecanismos disponibles que permiten la
reutilización de claves de acceso previamente existentes entre
diferentes dominios de asociaciones (trusts), tales como soluciones
de Single-Sign-On desarrolladas por
Liberty Alliance. Sin embargo, es con frecuencia necesario basarse
en un tercer participante para realizar la autenticación. Cuando se
utiliza una tal disposición, el proveedor de servicios no toma parte
activamente de la autenticación. Por otra parte, la gestión de la
clave de acceso por el proveedor de servicios no siempre es
apropiada debido a la manipulación de claves de acceso en
servidores de aplicaciones requiere procedimientos de gestión
complejos y costosos, por ejemplo mantenimiento de los tiempos de
vida útil de claves de acceso, solape de valores de claves de
acceso, políticas respecto a valores válidos, etc. Además, los
usuarios finales no desean recordar muchas claves de acceso y
tienden a utilizar la misma clave de acceso con varios servidores de
aplicaciones, lo que disminuye claramente el nivel de
seguridad.
El entramado de autenticación de Protocolo de
Transferencia de Hipertexto (HTTP: Hypertext Transfer Protocol)
Digest, según se describe en el documento RFC 2617 de IETF, puede
incluir métodos capaces de generar claves de acceso de usuario
final. Por ejemplo la Autenticación de HTTP Digest que utiliza
Acuerdo de Autenticación y Clave (AKA: Authentication and Key
Agreement), como se describe en RFC 3310, es un método para crear
claves de acceso de usuario final que usan infraestructura de
autenticación existente de tercera generación (3GPP) basada en
credenciales de AKA almacenadas en un dispositivo a prueba de
violaciones, la denominada tarjeta ISIM/USIM/SIM. Detalles de los
anteriores entramados se pueden encontrar en
http://www.ietf.org/rfc.html. Incluso aunque HTTP Digest AKA
proporciona un modo flexible para generar nuevas claves de acceso
sin implicación del usuario, no incluye un modo estándar para
delegar estas claves de acceso a terceras partes, tales como
servidores de aplicaciones o apoderados. Además, HTTP Digest AKA
asume que las claves de acceso pueden ser utilizadas sólo una
vez.
Es un objeto de la invención superar o al menos
mitigar los anteriores problemas. En particular, es un objeto de la
presente invención delegar las claves de acceso generadas usando
HTTP Digest AKA en terceras partes de modo que las claves de acceso
puedan ser utilizadas de manera segura para autenticación
subsiguiente.
Este y otros objetos se consiguen mediante la
autenticación inicial que está siendo hecha entre el dispositivo de
usuario final y su red doméstica utilizando HTTP Digest con un
algoritmo capaz de generar claves de acceso, por ejemplos HTTP
Digest AKA. Durante la autenticación inicial, la red doméstica
inicia un proceso en el que la nueva clave de acceso está vinculada
a la identidad de una tercera parte, tal como un servidor de
aplicación o un apoderado, y a una nueva identidad temporal de
usuario final para esa tercera parte. El dispositivo de usuario
final y la terc4ra parte pueden comenzar usando la nueva clave de
acceso e identidades relacionadas usando Digest de HTTP como un
método de autenticación.
De acuerdo con un aspecto de la presente
invención, se proporciona un método de generar una clave de acceso
para usar por parte de un dispositivo de usuario final (UE:
end-user) para acceso a un servidor distante, que
comprende:
enviar una petición para acceso desde el UE al
servidor distante;
crear un identidad temporal para el UE;
enviar a un nodo de autenticación en la red
doméstica del UE detalles de la petición de acceso;
en el nodo de autenticación o el servidor
distante, generar un impulso de interrogación (challenge) de
Hypertext Transfer Protocol (HTTP) Digest usando un algoritmo capaz
de generar claves de acceso de usuario final, incluyendo detalles de
identidad temporal del UE;
en el UE, generar una clave de acceso basada en
el impulso de interrogación de HTTP Digest, estando dicha clave de
acceso asociada con la identidad del servidor distante y la
identidad del UE; y
almacenar la clave de acceso y la identidad
temporal del UE en el UE.
El algoritmo para generar las claves de acceso
de usuario final es preferiblemente Acuerdo de Autenticación y
Clave (AKA) de HTTP Digest, aunque se apreciará que se pueden
utilizar otros algoritmos.
Preferiblemente la identidad del servidor
distante es enviada al nodo de autenticación, haciendo posible la
generación del impulso de interrogación de HTTP Digest para incluir
la identidad del servidor distante. La identidad del servidor
distante se almacena también preferiblemente en el UE:
La identidad temporal del UE se crea
preferiblemente en el servidor distante.
En una realización, el paso de enviar detalles
de la petición de acceso al nodo de autenticación puede incluir
volver a dirigir la petición de acceso al nodo de autenticación. El
impulso de interrogación de HTTP Digest puede ser generado en el
nodo de autenticación y enviado desde el nodo de autenticación
directamente al UE. La clave de acceso es preferiblemente
almacenada en el nodo de autenticación.
Después de haber sido generada la clave de
acceso, el UE es preferiblemente autenticado en el nodo de
autenticación y la petición de acceso dirigida nuevamente desde el
nodo de autenticación al servidor distante.
En una realización alternativa, el paso de
enviar detalles de la petición de acceso al nodo de autenticación
puede incluir que el servidor distante establezca contacto
directamente con el nodo de autenticación. El impulso de
interrogación de HTTP Digest puede ser generado en el nodo de
autenticación y enviad desde el nodo de autenticación al servidor
distante. Alternativamente, el servidor distante puede generar el
impulso de interrogación de HTTP Digest. El impulso de
interrogación de HTTP Digest es entonces enviado directamente desde
el servidor distante al UE.
Una clave de acceso de impulso de interrogación
de HTTP Digest AKA puede ser incluida en la información enviada
desde el nodo de autenticación al servidor distante, haciendo
posible que el UE sea autenticado en el servidor distante.
Alternativamente, el UE puede ser autenticado en el nodo de
autenticación y el resultado de la autenticación devuelto al
servidor distante.
Los métodos descritos anteriormente dan lugar a
una clave de acceso asociada con la identidad del UE y el servidor
distante, siendo almacenada en el UE y en el nodo de autenticación o
servidor distante. Esto hace posible el subsiguiente acceso desde
el UE al servidor distante sin necesidad de generar clave de acceso
adicional. De acuerdo con un aspecto más de la presente invención,
se proporciona un método de acceder a un servidor distante desde un
dispositivo de usuario final, comprendiendo el método:
generar y almacenar una clave de acceso
utilizando el método según se ha descrito anteriormente;
enviar una petición de acceso desde el UE al
servidor distante;
en el servidor distante, generar una impulso de
interrogación de HTTP Digest que incluya detalles de la identidad
del servidor distante y la identidad temporal del UE y enviar el
impulso de interrogación al UE; y
en el UE, enviar una respuesta de autenticación
que incluya la identidad temporal del UE y una prueba de posesión
de la clave de acceso al servidor distante.
Si la clave de acceso no es almacenada en el
servidor distante, puede ser necesario enviar una petición de
autenticación desde el servidor distante al nodo de autenticación.
La clave de acceso puede ser entonces enviada desde el nodo de
autenticación al servidor distante, haciendo posible la
autenticación del UE en el servidor distante. Alternativamente, el
UE puede ser autenticado en el nodo de autenticación y la
confirmación de autenticación enviada desde el nodo de autenticación
al servidor distante.
La figura 1 es una ilustración esquemática de
una red.
La figura 2A ilustra una secuencia para la
generación de claves de acceso y acuerdo de identidad entre un
dispositivo de usuario final (UE) y un servidor de aplicación.
La figura 2B ilustra una secuencia alternativa
para generación de claves de acceso y acuerdo de identidad entre un
dispositivo de usuario final (UE) y un servidor de aplicación;
La figura 3 ilustra la secuencia implicada en el
uso de una nueva clave de acceso.
Aunque la invención es susceptible de varias
modificaciones y formas alternativas, en los dibujos se han mostrado
realizaciones concretas de la misma a modo de ejemplo y se
describirán en la presente memoria con detalle. Se ha de entender,
sin embargo, que esta memoria no pretende limitar la invención a las
formas particulares descritas en ella, sino que, por el contrario,
la intención es cubrir todas las modificaciones, equivalentes y
alternativas que caigan dentro del alcance de la invención, según se
define en las reivindicaciones adjuntas.
La figura 1 ilustra una disposición típica en la
que un dispositivo de usuario final (UE) 101 conectado a una red
doméstica 102, por ejemplo una red de Universal Mobile
Telecommunications System (UMTS), desea acceso a un servidor de
aplicación 103 conectado a una red adicional 104. El UE 101
incorpora un dispositivo a prueba de violaciones, tal como un
Módulo de Identidad de Servicios de Multimedia de IP (ISIM: IP
Multimedia Services Identity Module) en el que se puede almacenar
información. De acuerdo con el entramado de Acuerdo de Autenticación
y Clave (AKA) de HTTP Digest, se establece un secreto compartido de
antemano entre el ISIM del UE 1 y un autenticador 105 en la red
doméstica 102. El secreto es almacenado en el ISIM del UE 101.
El autenticador 105 produce un vector de
autenticación, basado en el secreto compartido y un número de
secuencia. El vector de autenticación contiene un impulso de
interrogación aleatorio, un testigo (token) de autenticación de
red, un resultado de autenticación esperado, una clave de sesión
para verificación de integridad y una clave de sesión para
encripción. El vector de autenticación es descargado al servidor de
aplicación 103. El servidor de aplicaciones 103 crea una petición
de autenticación que contiene el impulso de interrogación aleatorio
y el testigo de autenticador de red, que es suministrado al UE
101.
Usando el secreto compartido y el número de
secuencia, el UE 101 verifica el testigo de autenticación de red
contenido en la petición de autenticación con el ISIM. Si la
verificación tiene éxito, la red ha sido autenticada. El UE 101
produce entonces una respuesta de autenticación, usando el secreto
compartido y el impulso de interrogación aleatorio, y suministra
esto al servidor de aplicación 103. El servidor de aplicación 103
compara la respuesta de autenticación recibida del UE 101 con la
respuesta esperada recibida del autenticador 103. Si las dos
coinciden, el usuario ha sido autenticado con éxito, y las claves
de sesión en el vector de autenticación pueden ser usadas para
proteger comunicaciones adicionales entre el UE 101 y el servidor de
aplicación 103. Sin embargo, la siguiente vez que el UE 101 desee
acceder al servidor de aplicación 103 debe ser seguido el mismo
procedimiento para autenticar la red y obtener claves de sesión; no
existe mecanismo para almacenar una clave de acceso para uso futuro
por parte del UE 101.
La figura 2A muestra una realización de un
sistema para autenticar el UE 101 para el servidor de aplicación
(AS: application server) 103. En la primera fase, el UE 101 es
autenticado usando HTTP Digest AKA, y la clave de acceso creada es
vinculada a identidades del servidor de aplicación 103 y al UE 101.
Con el fin de comprender el proceso mostrado en la figura 2A es
necesario definir do conceptos usados en el entramado de
autenticación de HTTP
Digest.
Digest.
Un "reino" ("realm") es una cadena que
indica al UE 101 qué nombre de usuario y clave de acceso utilizar.
Esta cadena contiene al menos el nombre del centro de autenticación
103 y podría adicionalmente indicar la colección de usuarios que
podrían tener acceso. Un ejemplo podría ser
"registered_{-}user@home.com". En el contexto de
3GPP/AKA, el reino de la red doméstica se almacena típicamente en la
tarjeta SIM/USIM/ISIM del UE 101.
Un "nombre de usuario" es el nombre de
usuario en el reino especificado. Esta cadena es usada por el
servidor de aplicación 103 para encontrar la clave de acceso
correcta para el usuario. En el contexto de 3GPP/AKA, el nombre de
usuario utilizado con la red doméstica es normalmente almacenado en
tarjeta SIM/USIM/ISIM del UE 101. En la mayoría de los casos, el
nombre de usuario es el mismo que la denominada Identidad Privada
(IMPI: Private Identity). Un nombre de usuario de 3GPP identifica
la subscripción, y por esta razón las claves de acceso son
específicas para el dispositivo de usuario final en lugar del
usuario final real. En un entramado de autenticación de HTTP
normal, el nombre de usuario y la clave de acceso son introducidos
mediante el teclado por el usuario final, pero en el contexto de
3GPP/AKA estos campos son automáticamente archivados por el UE
101.
Como se muestra en la figura 2A, en la primera
fase el UE 101 y el servidor de aplicación 103 no tienen un secreto
compartido. El UE 101 se autentica inicialmente utilizando HTTP
Digest AKA, y la clave de acceso creada se vincula a las
identidades del UE 101 y del servidor de aplicación 103. El
procedimiento tiene las siguientes fases:
1a) El UE envía una petición de HTTP
(normalmente GET de HTTP) al servidor de aplicación 103.
2a) Puesto que el servidor de aplicación 103 y
el UE 101 no tienen un secreto compartido, el servidor de aplicación
103 dirige nuevamente la petición al autenticador 105. Antes de
volver a dirigir la petición, el servidor de aplicación 103 puede
definir un nuevo nombre de usuario temporal para el UE 101. El
servidor de aplicación 103 incluye este nombre de usuario en su
propia información de identidad en la petición. La información de
identidad es normalmente codificada en el parámetro de URI en algún
formato estándar, por ejemplo "username@realm".
3a) El autenticador 105 verifica si el servidor
de aplicación 103 está autorizado para hacer la nueva dirección de
HTTP y pedir una nueva clave de acceso de HTTP Digest AKA para el UE
101. Si este es el caso, entonces el autenticador 105 toma la
información de identidad de la petición, y codifica esta información
en un impulso de interrogación (challenge) de HTTP Digest AKA, que
es enviado al UE 101. En una realización, el autenticador 105 pone
por el momento la información de identidad en los denominados
"datos de servidor" de HTTP Digest AKA, como se describe en
RPC 3310. Incluyendo la identidad en el impulso de interrogación, el
autenticador 105 puede estar seguro de que la identidad del
servidor de aplicación 103 o la identidad temporal del usuario
final no pueden ser cambiadas por ningún participante (tal como un
atacante) entre el UE 101 y el autenticador 103, debido a que el
impulso de interrogación es devuelto de nuevo al autenticador 105 en
el siguiente mensaje.
4a) El UE 101 autentica la red (según se define
en el protocolo de AKA estándar) y genera una nueva clave de
acceso basada en el impulso de interrogación de HTTP Digest AKA. El
UE 101 almacena la identidad del servidor de aplicación 103 y la
clave de acceso recién generada, para ser usadas posteriormente para
autenticación mutua con el servidor de aplicación 103. Si el
impulso de interrogación incluía también un nuevo "nombre de
usuario" temporal generado por el servidor de aplicación 103,
este nombre de usuario se almacena también con la clave de acceso y
la identidad del servidor de aplicación 103. Tanto el servidor de
aplicación como las identidades de UE son codificadas en el impulso
de interrogación de HTTP Digest AKA, usando, por ejemplo, el
formato "username@realm". El UE 101 envía la respuesta de
autenticación al autenticador 105.
El nuevo "nombre de usuario" es marcado
como un nombre de usuario temporal por el UE 101. Este nombre de
usuario y la clave de acceso de HTTP Digest AKA relacionada son
eliminados cuando son generados un nuevo "nombre de usuario" y
una nueva clave de acceso para el mismo reino. Si el impulso de
interrogación no incluye un nuevo nombre de usuario temporal,
entonces se puede reutilizar el nombre de usuario existente.
5a) El autenticador 105 autentica el UE 101 y,
si tiene éxito, almacena la nueva clave de acceso y las identidades
del UE 101 y del servidor de aplicación 103 para ser usados
posteriormente. La petición es nuevamente dirigida al servidor de
aplicación 103.
Si es apropiado, el servidor de aplicación puede
confiar en la autenticación inicial realizada por el autenticador
105. Si se percibe que el autenticador 105 no es seguro, el servidor
de aplicación 103 puede también volver a interrogar al UE 101
utilizando ahora la clave de acceso recién generada. Esta vez, no
es usado HTTP Digest AKA para autenticación. En lugar de ello, se
utiliza HTTP Digest con algún otro algoritmo, por ejemplo, MSD, como
se describe en RFC 2617.
La figura 2B muestra una realización alternativa
de un sistema para autenticar el UE 101 para el servidor de
aplicación (AS) 103. La primera fase se realiza usando un
procedimiento diferente, que tiene los siguientes pasos:
1b) El UE envía una petición de HTTP
(normalmente GET de HTTP) al servidor de aplicación 103.
2b) Puesto que el servidor de aplicación 103 y
el UE 101 no tienen un secreto compartido, el servidor de aplicación
103 solicita un impulso de interrogación de HTTP Digest AKA
directamente del autenticador 105. Como en la realización
previamente descrita, la petición puede incluir la identidad del
servidor de aplicación 103 y una nueva identidad temporal del UE
101.
3b) El autenticador 105 verifica si el servidor
de aplicación 103 está autorizado a solicitar una nueva clave de
acceso de HTTP Digest AKA para este UE 101.
Si este es el caso, entonces el autenticador
toma la identidad del servidor de aplicación y la identidad temporal
del usuario final (si existe) de la petición, y codifica esta
información en el impulso de interrogación de HTTP Digest AKA como
en la realización anteriormente descrita. Alternativamente, el
servidor de aplicación 103 puede incluir también esta información
en el impulso de interrogación en el paso 4b descrito más abajo. La
información de identidad es codificada en algún formato estándar,
por ejemplo \underline{username@realm} o
temporary_username@remote_realm. La información precisada por el
servidor de aplicación 103 para crear el impulso de interrogación de
HTTP Digest AKA es enviada de nuevo al servidor de aplicación 103.
Si estos parámetros incluyen clave de acceso de HTTP Digest AKA
entonces los pasos siguientes 6b) y 7b) del proceso pueden no ser
necesarios.
4b) El UE 101 es interrogado por un impulso de
interrogación de autenticación de HTTP Digest AKA. El servidor de
aplicación 103 puede añadir las identidades de servidor de
aplicación y de usuario final al impulso de interrogación de
autenticación para el UE 101. Sin embargo, en este caso, el servidor
de aplicación 103 debe ser el punto final para autenticación, y
posee la clave de acceso de HTTP Digest AKA.
5b) El UE 101 autentica la red (según está
definida en el protocolo estándar de AKA) y genera una nueva clave
de acceso basada en el impulso de interrogación de HTTP Digest AKA.
El UE almacena localmente la identidad del servidor de aplicación
103 (por ejemplo el "reino"), la clave de acceso recién
generada y el nuevo "nombre de usuario" temporal para él mismo
(si existe) para ser usado posteriormente por el servidor de
aplicación 103 para autenticación mutua con el servidor de
aplicación - si existe. El UE 101 envía la respuesta de
autenticación al servidor de aplicación 103. Como en la realización
anteriormente descrita, el UE 101 marca el nuevo "nombre de
usuario" potencial como nombre de usuario temporal.
6b) Si el servidor de aplicación 103 no ha
recibido la clave de acceso de usuario final en el paso 3b anterior,
solicita ahora al autenticador 105 que realice la
autenticación.
\newpage
7b) Si el servidor de aplicación 103 no recibió
la clave de acceso de usuario final en el paso 3b anterior y
solicitó autenticación en el paso 6b, el autenticador 105 autentica
el UE 101, y revuelve el resultado apropiado al servidor de
aplicación 103. El autenticador 105 puede enviar también la clave de
acceso de usuario final al servidor de aplicación 103 en esta etapa
o en alguna posterior.
8b) Si tuvo éxito la autenticación de UE, el
servicio es suministrado al UE 101.
El seguimiento de cualquiera de los
procedimientos descritos anteriormente con referencia a la figura 2A
o la figura 2B da lugar a que el servidor de aplicación 103 y UE
101 tengan un secreto compartido. La siguiente vez que el servidor
de aplicación 103 necesite autenticar el UE 101 (que puede ser
directamente después de los procedimientos previos, o después de
algún periodo de tiempo más largo; por ejemplo la siguiente vez que
el UE 101 se pone en contacto con el servidor de aplicación 103), el
procedimiento es como se muestra en la figura 3.
1c) El UE 101 envía una petición de HTTP
(normalmente GET de HTT) a un servidor de aplicación 103.
2c) Puesto que el servidor de aplicación 103 y
el UE 101 tienen ahora un secreto compartido, el servidor de
aplicación 103 interroga al UE 101 con un impulso de interrogación
de HTTP Digest. El impulso de interrogación incluye la identidad
del servidor de aplicación 103 en el parámetro de "reino".
3c) El UE 101 envía una respuesta de
autenticación (normalmente en petición de GET de HTTP) en retorno al
servidor de aplicación 103 usando el nuevo "nombre de usuario"
temporal y la clave de acceso para el servidor de aplicación 103
creado durante la fase previa (descrita anteriormente con respecto
a las figuras 2B ó 2C). Si el nuevo nombre de usuario temporal no
fue creado, entonces es usado el nombre de usuario específico de
AKA normal. El UE 101 utiliza el parámetro de "reino" para
identificar la clave de acceso correcta.
4c) Si el servidor de aplicación 103 posee la
clave de acceso de usuario final, no son necesarios este paso y el
siguiente paso (5c). Si el servidor de aplicación 103 no posee la
clave de acceso de usuario final, entonces el servidor de usuario
final 103 solicita del autenticador 105 (o de alguna otra entidad de
red (no mostrada) donde el autenticador 105 ha almacenado la clave
de acceso específica de UE), para autenticación.
5c) Hay dos posibilidades diferentes en esta
etapa. El autenticador 105 puede ocuparse de la autenticación en
nombre del servidor de aplicación 103. Es este caso, el servidor de
aplicación 103 no necesita conocer la clave de acceso, y el
autenticador simplemente devuelve información al servidor de
aplicación 103 en cuanto a si tuvo éxito o no la autenticación.
Alternativamente, el autenticador 105 puede enviar la clave de
acceso al servidor de aplicación 103, que realiza entonces la
autenticación.
Si la autenticación tuvo éxito, el AS suministra
el servicio al UE.
Se apreciará que pueden caer todavía dentro del
alcance de la invención variaciones de las realizaciones
anteriormente descritas. Por ejemplo, como se hace observar en RFC
2617, el autenticador no necesita realmente conocer la clave de
acceso de despejar texto del usuario. Siempre que el valor resumido
del nombre de usuario, reino y clave de acceso estén disponibles
para el servidor, puede ser verificada la validez de un
encabezamiento de autenticación.
Claims (17)
1. Un método de generar una clave de acceso para
usar por un dispositivo de usuario final, UE, para acceder a un
servidor distante; que comprende:
enviar una petición de acceso desde el UE al
servidor distante;
crear una identidad temporal para el UE;
enviar a un nodo de autenticación en la red
doméstica de UE detalles de la petición de acceso;
en el nodo de autenticación o el servidor
distante, generar un impulso de interrogación (challenge), de
Protocolo de Transferencia de Hipertexto, (HTTP), Digest usando un
algoritmo capaz de generar claves de acceso de usuario final,
incluyendo detalles de la identidad temporal del UE;
en el UE, generar una clave de acceso basada en
el impulso de interrogación de HTTP Digest, estando dicha clave de
acceso asociada con la identidad del servidor distante y la
identidad del UE; y
almacenar la clave de acceso y la identidad
temporal del UE en el UE.
2. Un método según la reivindicación 1, en el
que el algoritmo capaz de generar claves de acceso de usuario final
es Acuerdo de Autenticación y de Clave, AKA, de HTTP Digest.
3. Un método de acuerdo con la reivindicación 1
o la 2, que comprende además enviar la identidad del servidor
distante al nodo de autenticación, en el que el paso de generar el
impulso de interrogación de HTTP Digest incluye utilizar la
identidad del servidor distante, y en el que la identidad del
servidor distante se almacena en el UE.
4. Un método de acuerdo con la reivindicación 1,
la 2 o la 3, en el que la identidad temporal del UE es creada en el
servidor distante.
5. El método de acuerdo con cualquier
reivindicación precedente, en el que el paso de enviar detalles de
la petición de acceso al nodo de autenticación incluye volver a
dirigir la petición de acceso al nodo de autenticación.
6. Un método de acuerdo con la reivindicación 5,
en el que el impulso de interrogación de HTTP Digest es generado en
el nodo de autenticación y enviado desde el nodo de autenticación
directamente al UE.
7. Un método de acuerdo con la reivindicación 5
o la 6 en el que la clave de acceso es almacenada en el nodo de
autenticación.
8. Un método de acuerdo con la reivindicación 5,
6 ó 7, que comprende además autenticar el UE en el nodo de
autenticación y volver a dirigir la petición de acceso desde el nodo
de autenticación al servidor distante después de haber sido
generada la clave de acceso.
9. Un método de acuerdo con las reivindicaciones
1 a 4, en el que el paso de enviar detalles de la petición de
acceso al nodo de autenticación incluye el que el servidor distante
contacte con el nodo de autenticación directamente.
10. Un método de acuerdo con la reivindicación
9, en el que el impulso de interrogación de HTTP Digest es generado
en el nodo de autenticación y enviado desde el nodo de autenticación
al servidor distante.
11. Un método de acuerdo con la reivindicación
9, en el que el impulso de interrogación de HTTP Digest es generado
en el servidor distante.
12. Un método de acuerdo con la reivindicación
10 o la 11, que comprende además enviar el impulso de interrogación
de HTTP Digest desde el servidor distante al UE.
13. Un método de acuerdo con la reivindicación
11, que comprende además incluir una clave de acceso de impulso de
interrogación de HTTP Digest AKA en la información enviada desde el
nodo de autenticación al servidor distante y autenticar el UE en el
servidor distante.
14. Un método de acuerdo con cualquiera de las
reivindicaciones 9 a 12, que comprende además autenticar el UE en
el nodo de autenticación y devolver un resultado de autenticación al
servidor distante.
15. Un método de acceder a un servidor distante
desde un dispositivo de usuario final, UE, comprendiendo el
método:
generar y almacenar una clave de acceso
utilizando un método de acuerdo con cualquiera de las
reivindicaciones precedentes;
enviar una petición de acceso desde el UE al
servidor distante;
en el servidor distante, generar un impulso de
interrogación de Protocolo de Transferencia de Hipertexto, (HTTP),
Digest que incluya detalles de la identidad del servidor distante y
enviar el impulso de interrogación al UE; y
en el UE, enviar una respuesta de autenticación
que incluya la identidad temporal del UE y una prueba de posesión
de la clave de acceso al servidor distante.
16. Un método de acuerdo con la reivindicación
15, que comprende además enviar una petición de autenticación desde
el servidor distante al nodo de autenticación, enviar la clave de
acceso desde el nodo de autenticación al servidor distante, y
autenticar el UE en el servidor distante.
17. Un método de acuerdo con la reivindicación
15, que comprende además enviar una petición de autenticación desde
el servidor distante al nodo de autenticación, autenticar el UE en
el nodo de autenticación y enviar confirmación de autenticación
desde el nodo de autenticación al servidor distante.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0314971.3A GB0314971D0 (en) | 2003-06-27 | 2003-06-27 | Method for distributing passwords |
| GB0314971 | 2003-06-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2300792T3 true ES2300792T3 (es) | 2008-06-16 |
Family
ID=27637440
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04741888T Expired - Lifetime ES2300792T3 (es) | 2003-06-27 | 2004-06-24 | Metodo para distribuir claves de acceso (passwords). |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US20070005730A1 (es) |
| EP (1) | EP1639782B1 (es) |
| KR (1) | KR20060032602A (es) |
| CN (1) | CN100556033C (es) |
| AT (1) | ATE387795T1 (es) |
| DE (1) | DE602004012103T2 (es) |
| ES (1) | ES2300792T3 (es) |
| GB (1) | GB0314971D0 (es) |
| RU (1) | RU2325774C2 (es) |
| WO (1) | WO2005002166A2 (es) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3791489B2 (ja) * | 2002-12-13 | 2006-06-28 | ソニー株式会社 | ポータブルサーバ |
| KR100664312B1 (ko) | 2005-01-20 | 2007-01-04 | 삼성전자주식회사 | 홈 네트워크 환경에서 홈 디바이스 인증 방법 및 장치 |
| JP4643657B2 (ja) * | 2005-01-28 | 2011-03-02 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 通信システムにおけるユーザ認証及び認可 |
| US7631346B2 (en) * | 2005-04-01 | 2009-12-08 | International Business Machines Corporation | Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment |
| US7861077B1 (en) * | 2005-10-07 | 2010-12-28 | Multiple Shift Key, Inc. | Secure authentication and transaction system and method |
| CN101317181B (zh) * | 2005-10-21 | 2010-05-19 | 诺基亚公司 | 用于移动终端中安全鉴权响应的设备以及方法 |
| CN101366037A (zh) * | 2005-12-05 | 2009-02-11 | 诺基亚公司 | 在移动终端中用于安全http摘要响应验证以及完整性保护的计算机程序产品、装置以及方法 |
| US8712802B1 (en) | 2007-10-08 | 2014-04-29 | United Services Automobile Association (Usaa) | Transferring a document |
| US8156550B2 (en) * | 2008-06-20 | 2012-04-10 | Microsoft Corporation | Establishing secure data transmission using unsecured E-mail |
| US20130275492A1 (en) * | 2012-04-13 | 2013-10-17 | Microsoft Corporation | Enabling Web Clients to Provide Web Services |
| CN103647695A (zh) * | 2013-10-31 | 2014-03-19 | 北京奇虎科技有限公司 | 一种客户端应用程序的用户注册方法、移动终端及服务器 |
| US11095449B2 (en) * | 2016-12-16 | 2021-08-17 | Visa International Service Association | System and method for securely processing an electronic identity |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6891819B1 (en) * | 1997-09-05 | 2005-05-10 | Kabushiki Kaisha Toshiba | Mobile IP communications scheme incorporating individual user authentication |
| US6092196A (en) * | 1997-11-25 | 2000-07-18 | Nortel Networks Limited | HTTP distributed remote user authentication system |
| US6223287B1 (en) * | 1998-07-24 | 2001-04-24 | International Business Machines Corporation | Method for establishing a secured communication channel over the internet |
| JP2000092046A (ja) * | 1998-09-11 | 2000-03-31 | Mitsubishi Electric Corp | 遠隔認証システム |
| FI19992343A (fi) * | 1999-10-29 | 2001-04-30 | Nokia Mobile Phones Ltd | Menetelmä ja järjestely käyttäjän luotettavaksi tunnistamiseksi tietokonejärjestelmässä |
| US6839761B2 (en) * | 2001-04-19 | 2005-01-04 | Microsoft Corporation | Methods and systems for authentication through multiple proxy servers that require different authentication data |
| US7191467B1 (en) * | 2002-03-15 | 2007-03-13 | Microsoft Corporation | Method and system of integrating third party authentication into internet browser code |
| US7380124B1 (en) * | 2002-03-28 | 2008-05-27 | Nortel Networks Limited | Security transmission protocol for a mobility IP network |
| FI20020733A0 (fi) * | 2002-04-16 | 2002-04-16 | Nokia Corp | Menetelmä ja järjestelmä tiedonsiirtolaitteen käyttäjän autentikointiin |
| JP2004032253A (ja) * | 2002-06-25 | 2004-01-29 | Hitachi Ltd | ネットワーク通信装置および通信方式 |
| US20040043756A1 (en) * | 2002-09-03 | 2004-03-04 | Tao Haukka | Method and system for authentication in IP multimedia core network system (IMS) |
| US7865931B1 (en) * | 2002-11-25 | 2011-01-04 | Accenture Global Services Limited | Universal authorization and access control security measure for applications |
| US7421732B2 (en) * | 2003-05-05 | 2008-09-02 | Nokia Corporation | System, apparatus, and method for providing generic internet protocol authentication |
-
2003
- 2003-06-27 GB GBGB0314971.3A patent/GB0314971D0/en not_active Ceased
-
2004
- 2004-06-24 DE DE602004012103T patent/DE602004012103T2/de not_active Expired - Lifetime
- 2004-06-24 RU RU2006102352/09A patent/RU2325774C2/ru not_active IP Right Cessation
- 2004-06-24 CN CNB2004800179849A patent/CN100556033C/zh not_active Expired - Fee Related
- 2004-06-24 KR KR1020057025078A patent/KR20060032602A/ko not_active Application Discontinuation
- 2004-06-24 WO PCT/EP2004/051233 patent/WO2005002166A2/en active IP Right Grant
- 2004-06-24 AT AT04741888T patent/ATE387795T1/de not_active IP Right Cessation
- 2004-06-24 ES ES04741888T patent/ES2300792T3/es not_active Expired - Lifetime
- 2004-06-24 US US10/595,016 patent/US20070005730A1/en not_active Abandoned
- 2004-06-24 EP EP04741888A patent/EP1639782B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| KR20060032602A (ko) | 2006-04-17 |
| WO2005002166A2 (en) | 2005-01-06 |
| DE602004012103D1 (de) | 2008-04-10 |
| RU2006102352A (ru) | 2006-08-27 |
| DE602004012103T2 (de) | 2009-03-12 |
| CN1813455A (zh) | 2006-08-02 |
| GB0314971D0 (en) | 2003-07-30 |
| ATE387795T1 (de) | 2008-03-15 |
| RU2325774C2 (ru) | 2008-05-27 |
| EP1639782A2 (en) | 2006-03-29 |
| WO2005002166A3 (en) | 2005-05-26 |
| US20070005730A1 (en) | 2007-01-04 |
| CN100556033C (zh) | 2009-10-28 |
| EP1639782B1 (en) | 2008-02-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10411884B2 (en) | Secure bootstrapping architecture method based on password-based digest authentication | |
| Niemi et al. | Hypertext transfer protocol (HTTP) digest authentication using authentication and key agreement (AKA) | |
| ES2706540T3 (es) | Sistema de credenciales de equipos de usuario | |
| ES2424474T3 (es) | Método y aparato para establecer una asociación de seguridad | |
| ES2584862T3 (es) | Autenticación en comunicación de datos | |
| KR101461455B1 (ko) | 인증 방법, 시스템 및 장치 | |
| ES2389250T3 (es) | Un método para autenticar un terminal de usuario en un subsistema multimedia IP | |
| ES2397063T3 (es) | Autenticación para protocolos de aplicación IP basados en procedimientos IMS del 3GPP | |
| ES2769528T3 (es) | Autentificación de usuarios | |
| CN102160357B (zh) | 通信网络中的密钥管理 | |
| US20060059344A1 (en) | Service authentication | |
| US20060171541A1 (en) | Method for creating and distributing cryptographic keys in a mobile radio system and corresponding mobile radio system | |
| CA2661922A1 (en) | Method and system for providing authentication service for internet users | |
| WO2006000144A1 (fr) | Procede d'identification de protocole initial de session | |
| US20070143614A1 (en) | Method, system and devices for protection of a communication or session | |
| ES2300792T3 (es) | Metodo para distribuir claves de acceso (passwords). | |
| JP5342818B2 (ja) | 管理装置、登録通信端末、非登録通信端末、ネットワークシステム、管理方法、通信方法、及びコンピュータプログラム。 | |
| KR102049527B1 (ko) | 사용자 인증 서버 및 시스템 | |
| Edris et al. | Formal verification of secondary authentication protocol for 5G secondary authentication | |
| US11146536B2 (en) | Method and a system for managing user identities for use during communication between two web browsers | |
| EP1636963A1 (en) | Method and apparatuses for bootstrapping a local authorization system in ip networks | |
| Moon et al. | An AAA scheme using ID-based ticket with anonymity in future mobile communication | |
| CN114915494B (zh) | 一种匿名认证的方法、系统、设备和存储介质 | |
| ES2357564T3 (es) | Método y sistema de autentifcación de usuario en respuesta a instancia. | |
| Niemi et al. | RFC3310: Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) |