ES2769528T3 - Autentificación de usuarios - Google Patents

Autentificación de usuarios Download PDF

Info

Publication number
ES2769528T3
ES2769528T3 ES05759785T ES05759785T ES2769528T3 ES 2769528 T3 ES2769528 T3 ES 2769528T3 ES 05759785 T ES05759785 T ES 05759785T ES 05759785 T ES05759785 T ES 05759785T ES 2769528 T3 ES2769528 T3 ES 2769528T3
Authority
ES
Spain
Prior art keywords
service
request
user terminal
public key
identity
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.)
Active
Application number
ES05759785T
Other languages
English (en)
Inventor
Risto Mononen
Nadarajah Asokan
Pekka Laitinen
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.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
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 Nokia Technologies Oy filed Critical Nokia Technologies Oy
Application granted granted Critical
Publication of ES2769528T3 publication Critical patent/ES2769528T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations

Abstract

Un método para autentificar un terminal de usuario que busca acceso a un servicio desde un proveedor de servicios en una red de comunicación, comprendiendo el método: asignar al terminal de usuario una pluralidad de identidades específicas de servicio para acceder a servicios respectivos; emitir una solicitud desde el terminal de usuario, identificando la solicitud el servicio al que se accede y que incluye una clave pública del terminal de usuario; en una autoridad de certificación (10), autentificar la solicitud y emitir un certificado de clave pública para vincular una identidad específica del servicio con la clave pública en la solicitud y devolver el certificado de clave pública al terminal de usuario.

Description

DESCRIPCIÓN
Autentificación de usuarios
Campo de la invención
La presente invención se refiere a la autentificación de usuarios, particularmente en el contexto de proporcionar servicios a los usuarios (suscriptores) de una red de comunicaciones inalámbricas.
Antecedentes de la invención
Una forma de mantener la privacidad del usuario es que un usuario proporcione diferentes identidades a diferentes proveedores de servicios. Estas identidades se denominan en el presente documento identidades específicas del servicio. En tal caso, sin embargo, es necesario que el operador de una red para los suscriptores proporcione un servicio de gestión de identidad que pueda asociar identidades específicas del servicio con suscriptores autorizados. También es útil si un proveedor de gestión de identidad puede hacer autorizaciones no solo en nombre de sí mismo, sino también en nombre de otros proveedores de servicios. Esto significa que los usuarios pueden invocar servicios personalizados sin tener que iniciar sesión por separado en cada sitio de perfil de servicio.
Esta disposición se conoce como federación de identidad y permite a los proveedores de servicios leer la identidad de un usuario desde un lugar centralizado. Un usuario no tiene que proporcionar a todos los proveedores de servicios información de identidad específica.
Actualmente hay dos métodos de autentificación significativos especificados para redes de comunicación inalámbricas en las que un equipo de usuario (UE) en forma de terminal móvil desea acceder a un servicio desde un proveedor de servicios en la red. El llamado estándar Liberty Alliance (LA) utiliza un método de autentificación en el que un cliente con libertad habilitada (LEC) es un cliente que tiene, o sabe cómo obtener, conocimiento sobre el proveedor de identidad que el usuario desea usar con el proveedor de servicios. Especifica la asignación de identidad específica del servicio en un proveedor de identidad (IDP). Cada suscriptor tiene múltiples identidades para acceder a los proveedores de servicios (SP). Un directorio de federación en el proveedor de identidad almacena las relaciones entre usuarios, sus identidades y los servicios. El proveedor de identidad afirma una identidad específica del servicio hacia el proveedor del servicio que reconoce al usuario por esa identidad específica del servicio. La capacidad de presentar diferentes identidades a diferentes proveedores de servicios permite mantener la privacidad del suscriptor. De acuerdo con el estándar de Liberty Alliance, el usuario puede evitar revelar su identidad real al invocar servicios. En lugar de revelar su verdadera identidad, el usuario puede invocar los servicios de forma anónima o usar un seudónimo (una identidad específica del servicio). El directorio de la federación asigna la identidad real del usuario a sus seudónimos o identidades específicas del servicio para que el proveedor del servicio no conozca la identidad real. Con el seudónimo y el servicio de mapeo, el proveedor de servicios puede acceder a, por ejemplo, la ubicación del usuario o el estado de presencia. Esto permite que un proveedor de servicios use el seudónimo para acceder a la ubicación del usuario desde un proveedor de servicios de identidad a través de la asignación en la base de datos de la federación. El estándar Liberty Alliance especifica el enlace HTTP/soap firmado que se utilizará para las aserciones. Sin embargo, existen muchos servicios existentes que no conocen las afirmaciones de Liberty pero dependen de otras formas de "aserciones" para acceder, como los certificados de clave pública tradicionales. Un ejemplo de dicho servicio es el control de acceso a redes privadas virtuales (VPN) corporativas.
Otra forma de autentificación existente es el soporte 3GPP para certificados de suscriptor (SSC) [3GPP TS 33.221]. Esto se implementa como una arquitectura de autentificación genérica (GAA) 3GPP [3GPP TS 33.220] y especifica una forma de solicitar un certificado de suscriptor para una identidad específica de la autoridad de certificación (CA). En este caso, la identidad específica es la identidad del usuario y no es específica del servicio. De acuerdo con la técnica GAA/SSC, la arquitectura de arranque genérico (GBA) implantada en el equipo del usuario autentifica el equipo del usuario junto con un servidor de autentificación en el proveedor de servicios, y acuerdan un material de clave compartida. La arquitectura de arranque genérico entrega el material de clave compartida a una autoridad de certificación CA. Los equipos de usuario generan un par de claves públicas/privadas asimétricas y solicitan la certificación de la autoridad de certificación. Si está autorizado, se devuelve un certificado que asocia la clave pública con la identidad del usuario solicitante. El método de certificación está protegido por el material de clave compartida. El lenguaje de federación de servicios web (Federación WS), versión 1.0, del 8 de julio de 2003 divulga un sistema en el que un solicitante puede solicitar a un proveedor de identidad una señal a un campo de confianza. El proveedor de identidad busca un seudónimo y emite una señal que se puede utilizar en un recurso específico. Los operadores móviles pueden autentificar a sus suscriptores móviles utilizando USIM, ISIM, par de nombre de usuario/contraseña o certificados de clave pública X.509. En el caso de los certificados, la identidad autentificada está en el campo nombreSujeto o en la extensión NombreAltSujeto del certificado [RFC 3280].
El método de autentificación 3GPP/GAA/SSC no tiene un mecanismo para indicar el proveedor de servicios al que desea acceder el suscriptor. Solo la identidad del usuario puede ser indicada y autentificada por el certificado. No hay soporte para la autentificación basada en certificados de múltiples identidades o identidades específicas del servicio. Aunque la extensión NombreAltSujeto se puede usar para transportar múltiples identidades e identidades específicas del servicio, el problema es que el equipo del usuario debe poder indicar durante el método de certificación la identidad o identidades previstas, es decir, servicio o servicios con los que planea usar el certificado. No quiere poner todas las identidades posibles en un solo certificado, porque descubrir los enlaces entre diferentes identidades sería muy fácil, ya que el certificado es público.
Sumario de la invención
Es un objetivo de la presente invención proporcionar un sistema de autentificación que no esté sujeto a los límites de los dos sistemas descritos anteriormente.
De acuerdo con un aspecto de la invención, se proporciona un método para autentificar un terminal de usuario que busca acceso a un servicio de un proveedor de servicios en una red de comunicación, comprendiendo el método: asignar al terminal de usuario una pluralidad de identidades específicas de servicio para acceder a servicios respectivos; emitir una solicitud desde el terminal de usuario, identificando la solicitud el servicio al que se accede y que incluye una clave pública del terminal de usuario; en una autoridad de certificación, autentificar la solicitud y emitir un certificado de clave pública para vincular la identidad específica del servicio con la clave pública en la solicitud y devolver el certificado de clave pública al terminal de usuario.
En la siguiente realización descrita, la solicitud incluye un identificador de servicio que identifica el servicio al que se va a acceder y un identificador de solicitante que identifica el terminal de usuario. El método comprende la etapa adicional de, en la autoridad de certificación, mapear el identificador de servicio, emparejar el identificador del solicitante con la identidad específica del servicio que se autentificará. Sin embargo, también es posible implementar la invención cuando la solicitud identifica la identidad específica del servicio y en el que el método comprende la etapa adicional de la autoridad de certificación que verifica que el terminal de usuario está autorizado para usar la identidad específica de servicio.
En un ejemplo, la etapa de emisión comprende emitir la solicitud que comprende un mensaje que incluye una pluralidad de campos, conteniendo uno de dichos campos un identificador de servicio para identificar el servicio al que se accede. En un ejemplo, el campo que contiene el identificador de servicio es un campo sujeto. En un ejemplo, la etapa de emisión comprende emitir la solicitud que comprende un mensaje PKCS#10. En un ejemplo, la etapa de emisión comprende emitir la solicitud que comprende un mensaje CRMF. En un ejemplo, la etapa de emisión comprende emitir la solicitud que comprende un mensaje HTTP. En un ejemplo, el método comprende implementar las etapas de asignación, emisión, autentificación y devolución en una red de comunicaciones inalámbricas.
La invención es particularmente útil en el contexto de redes de comunicaciones inalámbricas, aunque se apreciará que la invención también es aplicable a otros tipos de redes de comunicación.
Otro aspecto de la invención proporcionó un terminal de usuario para el usuario en una red de comunicaciones que comprende: medios para emitir una solicitud que identifica un servicio al que se accede a través de la red de comunicaciones inalámbricas e incluye una clave pública; medios para recibir un certificado de clave pública emitido por una autoridad de certificación que asocia una identidad específica del servicio para acceder al servicio con la clave pública; y medios para reenviar el certificado de clave pública a un proveedor de servicios para autentificar la identidad específica del servicio para el terminal de usuario y autorizar así el acceso al servicio.
En un ejemplo, el terminal de usuario comprende medios para establecer material de clave compartida con la autoridad de certificación antes de emitir la solicitud. En un ejemplo, el terminal de usuario comprende medios para generar un par de claves asimétricas que incluyen la clave pública y una clave privada. En un ejemplo, el terminal de usuario comprende medios para emitir dicha solicitud a través de una interfaz inalámbrica. En un ejemplo, la solicitud identifica el servicio utilizando al menos uno de: una cadena transparente; una dirección de campo, un identificador universal de recursos; un nombre distinguido. En un ejemplo, la identidad específica del servicio no está incluida en la solicitud.
Un aspecto adicional de la invención proporciona un sistema de autentificación para usar en una red de comunicaciones para permitir el acceso a un servicio desde un proveedor de servicios, comprendiendo el sistema: una autoridad de certificación que comprende medios para recibir una solicitud de un terminal de usuario, identificando la solicitud el servicio al que se accede y que incluye una clave pública del terminal de usuario; y en el que la autoridad de certificación está dispuesta para autentificar la solicitud y emitir un certificado de clave pública para una identidad específica del servicio a la que se accederá y devolver el certificado de clave pública al terminal de usuario.
En un ejemplo, el sistema de autentificación comprende un servidor de autentificación configurado para autentificar la identidad del terminal de usuario que emite la solicitud. En un ejemplo, la autoridad de certificación comprende una base de datos de federación, configurándose la base de datos de federación para asignar el servicio y los identificadores del solicitante a las identidades específicas del servicio para acceder a servicios respectivos. En un ejemplo, los medios para recibir dicha solicitud comprenden medios para recibir dicha solicitud a través de una interfaz inalámbrica.
Para una mejor comprensión de la presente invención y para mostrar cómo la misma puede llevarse a efecto, se hará ahora referencia, a modo de ejemplo, a los dibujos adjuntos.
Breve descripción de los dibujos
La figura 1 es un diagrama esquemático que muestra una red de comunicaciones donde un suscriptor puede acceder a uno o más servicios;
La figura 2 ilustra una arquitectura de ejemplo para implementar una realización de la invención;
La figura 3 es un diagrama esquemático de un directorio de federación;
La figura 4 ilustra el flujo de mensajes entre el suscriptor y el servidor de autentificación; y
La figura 5 ilustra el flujo de mensajes entre el suscriptor y la autoridad de certificación.
Descripción de las realizaciones preferidas
La figura 1 es un diagrama de bloques esquemático de una red de comunicaciones inalámbricas para proporcionar servicios a un suscriptor. El suscriptor se indica en forma de un equipo de usuario (UE), que puede ser un terminal móvil tal como un teléfono móvil, ordenador personal o cualquier otro tipo de dispositivo de comunicación móvil. El equipo de usuario UE tiene un circuito de recepción/transmisión 50 que es capaz de recibir y transmitir datos, tal como mensajes de solicitud y respuesta, a la red a través de un enlace de radio RL capaz de soportar comunicaciones inalámbricas. El equipo de usuario UE también incluye una memoria 52 para contener información de autentificación como se describe con más detalle a continuación. El terminal móvil es capaz de ejecutar software de cliente como se describe con más detalle a continuación. El UE del suscriptor se comunica con varios proveedores de servicios diferentes SP1, SP2...SPN a través de una red de operador. La red incluye o tiene acceso a un subsistema de autorización 26 que actúa como un proveedor de identidad centralizado para los proveedores de servicios que acceden a la red. Un suscriptor que desee acceder a un servicio será autorizado en función de su identidad autentificada.
La figura 2 ilustra una arquitectura de ejemplo para implementar una realización de la presente invención. Ilustra una arquitectura de autentificación genérica (GAA) que incluye un cliente 4 de arquitectura de arranque genérico (GBA) ejecutado en el terminal móvil conectado a un servidor de autentificación (función de servidor de arranque - BSF) a través de una interfaz Ub. El servidor de autentificación 6 está conectado a un servidor de suscriptor doméstico (HSS)/registro de ubicación de origen (HLR) 8, que almacena datos de autentificación, incluyendo claves K y la identidad internacional del suscriptor móvil (IMSI) para los suscriptores. El servidor de autentificación 6 está conectado a una autoridad de certificación (CA) 10 a través de una interfaz Zn. La autoridad de certificación 10 incluye un directorio de federación. El directorio de federación (FD) se ilustra en la figura 3. Asocia cada identidad de suscriptor con una pluralidad de identidades específicas de servicio (SSI) que el suscriptor utiliza como su cara para acceder a diferentes servicios de los proveedores de servicios. La identidad del suscriptor en el directorio de federación es el nombre de usuario por el cual la red del operador conoce al suscriptor. El número de referencia 12 indica un dominio de certificado de clave pública PKC. El dominio de certificado de clave pública 12 comprende un cliente de certificación 14 (ejecutado en el terminal móvil que está conectado al cliente de autorización 4 a través de una interfaz PK, y a la autoridad de certificación 10 a través de una interfaz Ua. El dominio de certificado de clave pública 12 también incluye una función de puerta de enlace de seguridad (Seguridad de la capa de transporte) SEC (TLS) 16 que está conectada al cliente de certificación 14 a través de una interfaz PK1. La puerta de enlace SEC (TLS) 16 es parte del servidor HTTP que realiza la parte de autentificación TLS en nombre del servidor HTTP.
Debe tenerse en cuenta que en la siguiente descripción, el ejemplo que se proporciona se implementa con servicios basados en http. Sin embargo, el principio subyacente se puede utilizar para IPSec (seguridad de protocolo de Internet), VPN (redes privadas virtuales) o WLAN (redes inalámbricas de área local) también.
El número de referencia 18 indica un dominio http que comprende un cliente http 20, por ejemplo, en forma de navegador, que está conectado al cliente de certificación 14 del dominio PKC a través de una interfaz HT3 y al cliente de autorización del dominio GAA a través de una interfaz TE-AA. El cliente http 20 está conectado a un clasificador http 22 a través de una interfaz HT1. El clasificador http está conectado a una función de servidor http 24 a través de una interfaz HT4. El clasificador http 22 está conectado al cliente de certificación del dominio p Kc a través de una interfaz HT2. La función de servidor http 24 está conectada a la función de puerta de enlace SEC (TLS) 16 del dominio PKC a través de una interfaz interna SP-AA. El cliente http y el clasificador se ejecutan en el terminal móvil UE. La función del servidor http 24 está asociada con uno de los proveedores de servicios SP de la figura 1.
Volviendo al dominio GAA 2, el cliente de autentificación GBA 4 en el equipo de usuario UE se autentifica en el servidor BSF, y acuerdan un material de clave compartida. El servidor BSF 6 se usa para autentificar el equipo del usuario utilizando el protocolo de autentificación con resumen HTTP y acuerdo de clave (AKA) especificado en la solicitud de comentarios (RFC) 3310, dando como resultado un material clave compartido entre el servidor BSF 6 y el equipo de usuario UE. El servidor BSF 6 interactúa con el servidor de abonado doméstico/registro de ubicación de inicio 8 para obtener la información de autentificación correspondiente, en forma de autentificación de triplete/vectores. La autoridad de certificación 10 actúa como un portal PKI y puede emitir un certificado para el equipo del usuario y entregar un certificado de CA de operador. En ambos casos, las solicitudes y respuestas están protegidas por el material de clave compartida que se ha establecido previamente entre el equipo del usuario y el servidor de autorización.
Ahora se describirá un método de acuerdo con una realización de la invención para permitir que un suscriptor que usa el equipo de usuario UE acceda a un servicio proporcionado por uno de los proveedores de servicios SP. El cliente GBA 4 se comunica con el servidor de autentificación BSF para autentificar al suscriptor en función de su identidad de suscriptor (por ejemplo, nombre de usuario) y para acordar un material de clave compartida Ks. El material de clave compartida se deriva de la información de autentificación tanto en el cliente de autorización 4 como en la autoridad de certificación 10. El cliente 4 deriva el material de clave compartida Ks con el protocolo HTTP con resumen AKA que requiere una clave secreta y una función criptográfica para destilar el material de clave compartida Ks del desafío de autentificación. El material de clave compartida se mantiene en el directorio de federación FD en asociación con la identidad de suscriptor relacionada para esta sesión autentificada. El material de clave compartida toma la forma de un código de cifrado.
El equipo de usuario UE genera entonces un par de clave pública/clave privada y los almacena con un identificador de servicio SIi que identifica el servicio al que desea acceder el suscriptor. Se pueden almacenar en la memoria 52 en el equipo del usuario o en una tarjeta inteligente accesible por el equipo del usuario.
Se invoca al cliente de certificación 14 para solicitar un certificado. Una solicitud incluye el identificador de servicio y la clave pública: la clave privada se mantiene en secreto. La solicitud del certificado está protegida con el material de clave compartida y se transmite a través de la interfaz Ua a la autoridad de certificación CA. La identidad del suscriptor también se transmite con la solicitud.
En la autoridad de certificación 10, el directorio de federación FD asigna el identificador de servicio SIi a la identidad específica de servicio SSIi para ese servicio y ese nombre de usuario.
La autoridad de certificación 10 obtiene el material de clave compartida Ksi basado en el nombre de usuario del servidor BSF 6 y verifica el encabezado de autorización de la solicitud. Esto se discute en TS 33.221. Suponiendo que la solicitud es válida, la autoridad de certificación 10 emite un certificado que asocia la clave pública con la identidad específica del servicio para el servicio identificado por el identificador de servicio en la solicitud. El certificado se devuelve al suscriptor UE a través de la interfaz Ua, y el UE lo almacena en la memoria 52 o tarjeta inteligente. En el caso de múltiples dispositivos, el UE puede reenviar el certificado a otro dispositivo (ordenador portátil) posiblemente con la clave privada a menos que el otro dispositivo haya generado la clave privada.
El cliente de certificación 14 avisa al cliente http 20 sobre la interfaz HT3 que se ha recibido un certificado válido y reenvía el certificado para la autentificación a la función de puerta de enlace SEC (TLS) 16 a través de la interfaz PK1. El cliente http 20 invoca entonces la función 24 del servidor http del proveedor de servicios para el servicio al que desea acceder e incluye el certificado. También incluye evidencia por la cual el proveedor de servicios puede validar el certificado, incluyendo, por ejemplo, una firma digital que comprende datos cifrados con la clave privada. La puerta de enlace SEC (TLS) 16 valida el certificado a través de la interfaz PK3 contra una lista de autoridades de certificación y, una vez que el certificado ha sido autentificado, se puede invocar el servicio para el suscriptor. La función de puerta de enlace SEC (TLS) 16 también desafía al cliente y verifica la respuesta para autentificar al cliente (PK1), y hace que la función 24 del servidor http brinde el servicio solicitado a los clientes autorizados (HT4). La autentificación a través de la interfaz Ub se lleva a cabo de acuerdo con los estándares 3GGP TS 33.220, con la autentificación realizada basándose en HTTP con resumen AKA [RFC 3310], La autentificación también podría llevarse a cabo utilizando SIM 2G.
La figura 4 muestra parte del flujo de mensajes entre el equipo de usuario UE que implementa el cliente de autorización 4 (UE) y el servidor de autorización 6 (BSF) durante el método de arranque. El cliente GBA 4 inicia un método de autentificación emitiendo una solicitud de autentificación 30 de solicitud GET. La solicitud de autentificación identifica al usuario utilizando la identidad del suscriptor; en este ejemplo es la IMPI (identidad privada multimedia IP). La otra alternativa podría ser IMSI, o el UE podría generar un pseudo IMPI a partir del IMSI (como se especifica en TS 23.003). Se devuelve una respuesta HTTP 32 que reconoce la identidad de usuario IMPI y devuelve una palabra que contiene RAND y AUTN de AKA que identifica de forma exclusiva la solicitud. El cliente de autentificación 4 en el equipo de usuario devuelve una solicitud HTTP 34 con una contraseña adecuada derivada de AKA, y el servidor de autorización (BSF) 6 responde devolviendo información de autentificación que incluye el identificador de transacción de arranque (B-TID) (no se muestra en la figura 4) que se utiliza como nombre de usuario en la interfaz Ua, y el material de clave compartida se deriva de la información de autentificación. Quedará claro que el BSF ha accedido a la información de autentificación desde el HSS, pero esta interacción no se muestra en la figura 2 porque ya se conoce.
Después de que el material clave compartido haya sido acordado por el intercambio de mensajes de la figura 4, entonces el cliente de certificación en el equipo del usuario genera una solicitud de certificación PKCS#10 que se transfiere a través de la interfaz Ua a la CA. Esto se muestra en la figura 5. La solicitud de certificación incluye varios campos de acuerdo con el estándar establecido de la siguiente manera:
POST /certificaterequest/ HTTP/1.1
Authorization: Digest
username="adf..adf",
realm="ca-naf@operator.com",
qop="auth-int",
algorithm="MD5",
uri="/certificaterequest/",
nonce="dffef12..2ff7",
nc=00000001,
cnonce="0a4fee..dd2f'',
response="6629..af3e",
opaque="e23f45..dff2"
<base64 encoded PKCS#10 request>
Los campos se conocen por RFC 2617. En este ejemplo, el mensaje HTTP contiene un encabezado HTTP de Autorización donde el "nombre de usuario" podría ser B-TID, y el campo "opaco" puede incluir identificadores de servicio.
La "Autorización" es el encabezado HTTP asociado con la autentificación HTTP con resumen [RFC 2617]. Los parámetros en el encabezado de autorización se utilizan para autentificar y proteger la integridad de la solicitud. La solicitud PKCS#10 contiene la propia solicitud de certificación, incluyendo la clave pública del usuario y el identificador del servicio.
De acuerdo con una realización de la invención, la solicitud de certificación PKCS#10 también incluye un campo de identificador de servicio que identifica el servicio al que debe acceder el usuario. El servicio se puede identificar de varias maneras, por ejemplo, mediante una cadena transparente, una dirección de campo, un URI (identificador universal de recursos), un nombre distinguido, etc. Todo lo que se necesita es el identificador único para el servicio particular al que debe acceder el usuario. El identificador de servicio se incluye en la solicitud PKCS#10, como una de las extensiones. Como un ejemplo, hay un atributo "Solicitud de extensión" en PKCS#9 que se puede usar con PKCS#10, con NombreAltsujeto como la extensión solicitada.
Alternativamente, en CRMF (Formato de mensaje de solicitud de certificado) [RFC 2511] podría ser la extensión NombreAltsujeto en el campo de plantilla de certificado (PlantillaCert).
La CA(NAF) obtiene el material de clave compartida del servidor de autorización BSF basado en el nombre de usuario (B-TID) suministrado en la solicitud de certificación PKCS#10 y verifica el encabezado de autorización utilizando el material de clave compartida. Si tiene éxito, procesa la solicitud de certificación y devuelve una respuesta de certificado etiquetada CERT en la figura 5. La respuesta del certificado tiene el siguiente formato:
HTTP/1.1 200 OK
Content Type: application/x509-user-cert
Authentication-info:nextnonce="4ff232dd...dd"
qop=auth-int
rspauth="4dd34...55d2"
cnonce="0a4fee...dd2f''
nc=00000001
<base 64 encoded subscriber x509 certificate>
El equipo de usuario almacena el certificado en el equipo de usuario en la memoria o tarjeta inteligente. El certificado activa la clave pública con el identificador de servicio y puede autentificarse utilizando el par asimétrico de clave pública/clave privada.
Al agregar el identificador de servicio a la solicitud de certificación, esto permite a los suscriptores tener múltiples certificados para múltiples servicios. Sin embargo, el usuario puede retener una identidad única para cada servicio porque cada certificado de suscriptor está asociado con una identidad de suscriptor específica de un servicio en particular, en lugar de con una identidad común ("global") cuya actividad podría rastrearse, violando la privacidad del suscriptor. En otras palabras, hemos reemplazado las afirmaciones de Liberty Alliance específicas del suscriptor y del servicio con certificados de clave pública específicos del suscriptor y del servicio. En la realización descrita anteriormente, la CA identifica la identidad de usuario específica del servicio en función del material de clave compartida y la asignación que se mantiene en la base de datos de la federación.
En una realización alternativa, el equipo de usuario UE podría enviar una solicitud de certificación indicando su identidad preferida, por ejemplo, en el caso de que un suscriptor tenga varios nombres para acceder a un proveedor de servicios.
En la CA (o en el directorio de la federación), el par (identificador de solicitante, identificador de servicio) se asigna a una identidad de abonado específica del servicio que se mantiene en la base de datos de la federación. La autoridad de certificación firma el certificado de clave pública para la identidad asignada y lo devuelve al equipo del usuario. Esto permite a los suscriptores tener múltiples identidades en múltiples certificados. Las claves públicas en los certificados deben diferir para evitar vincular las identidades. Por lo tanto, la realización de la invención descrita anteriormente admite los estándares de privacidad de Liberty Alliance (LA) mediante el mapeo de identidad con la tecnología de certificado de clave pública, pero puede alcanzar una gama más amplia de aplicaciones que el mecanismo de afirmación de LA.
En la realización descrita anteriormente, el identificador de servicio se incluye en un campo de extensión adicional en el mensaje PKCS#10. El identificador de servicio se asigna a una identidad específica de servicio en la base de datos de federación FD asociada con la autoridad de certificación CA.
De acuerdo con una primera realización alternativa, es posible enviar la identidad específica del servicio en la solicitud de certificación. Es decir, el UE mismo asigna la identidad del suscriptor a la identidad específica del servicio deseada para el certificado. En ese caso, la autoridad de certificación debe verificar que el suscriptor en cuestión posee realmente la identidad solicitada y debe mantener una base de datos de identidad para esa verificación. Por lo tanto, la arquitectura resultante es más compleja que la realización descrita anteriormente, pero el protocolo estándar PKCS#10 se puede utilizar sin adiciones entre el equipo del usuario y la red.
Una alternativa adicional permite que se indique alguna forma de cadena de nombre en el campo de asunto del mensaje PKS#10. Por ejemplo, en el caso de nombre usuario@campo, la parte del campo puede ser el identificador de servicio. En el caso de un nombre distinguido, la parte de la organización podría ser el identificador de servicio. Por ejemplo, nombre distinguido "CN=nombre de usuario, O=campo" podría usarse, como se describe en RFC 3280. Como se ha mencionado anteriormente, la invención puede implementarse en arquitecturas distintas de la arquitectura del servidor http descrita anteriormente. En particular, las funciones de la puerta de enlace SEC (TLS) y el servidor http y las interfaces relacionadas (PK1, PK3, HT4, SP-AA) podría reemplazarse con una única función que recibe el certificado de suscriptor para la autentificación, opcionalmente valida el certificado (PK3), desafía al cliente y verifica la respuesta para autentificar al cliente (PK1), y proporciona el servicio solicitado a los clientes autorizados (HT4).

Claims (19)

REIVINDICACIONES
1. Un método para autentificar un terminal de usuario que busca acceso a un servicio desde un proveedor de servicios en una red de comunicación, comprendiendo el método:
asignar al terminal de usuario una pluralidad de identidades específicas de servicio para acceder a servicios respectivos;
emitir una solicitud desde el terminal de usuario, identificando la solicitud el servicio al que se accede y que incluye una clave pública del terminal de usuario;
en una autoridad de certificación (10), autentificar la solicitud y emitir un certificado de clave pública para vincular una identidad específica del servicio con la clave pública en la solicitud y devolver el certificado de clave pública al terminal de usuario.
2. El método según la reivindicación 1, en el que la solicitud incluye un identificador de servicio que identifica el servicio al que se va a acceder y un identificador de solicitante que identifica el terminal de usuario, comprendiendo el método la etapa adicional de:
en la autoridad de certificación (10), correlacionar el identificador de servicio y el identificador solicitante con la identidad específica del servicio que se autentificará.
3. El método según la reivindicación 1, en el que la solicitud identifica la identidad específica del servicio y en donde el método comprende la etapa adicional de:
verificar por parte de la autoridad de certificación (10) que el terminal de usuario está autorizado para usar la identidad específica del servicio.
4. El método según la reivindicación 1, en el que la etapa de emisión comprende emitir la solicitud que comprende un mensaje que incluye una pluralidad de campos, conteniendo uno de dichos campos un identificador de servicio para identificar el servicio al que se accede.
5. El método según la reivindicación 4, en el que el campo que contiene el identificador de servicio es un campo sujeto.
6. El método según la reivindicación 4 , en el que la etapa de emisión comprende emitir la solicitud que comprende un mensaje PKCS#10.
7. El método según la reivindicación 4 , en el que la etapa de emisión comprende emitir la solicitud que comprende un mensaje CRMF.
8. El método según la reivindicación 4 , en el que la etapa de emisión comprende emitir la solicitud que comprende un mensaje HTTP.
9. El método según la reivindicación 1, que comprende implementar las etapas de asignación, emisión, autentificación y devolución en una red de comunicaciones inalámbricas.
10. Un terminal de usuario para usar en una red de comunicaciones que comprende:
medios (50) para emitir una solicitud que identifica un servicio al que se debe acceder e incluye una clave pública;
medios (50) para recibir un certificado de clave pública emitido por una autoridad de certificación (10) que asocia una identidad específica del servicio para acceder al servicio con la clave pública; y
medios (50) para reenviar el certificado de clave pública a un proveedor de servicios para autentificar la identidad específica del servicio para el terminal de usuario y autorizar así el acceso al servicio.
11. El terminal de usuario según la reivindicación 10, que comprende además medios para establecer material clave compartido con la autoridad de certificación (10) antes de emitir la solicitud.
12. El terminal de usuario según la reivindicación 10, que comprende medios para generar un par de claves asimétricas que incluyen la clave pública y una clave privada.
13. El terminal de usuario según la reivindicación 10, que comprende medios para emitir dicha solicitud a través de una interfaz inalámbrica.
14. El terminal de usuario según la reivindicación 10, en el que la solicitud identifica el servicio utilizando al menos uno de: una cadena transparente; una dirección de campo, un identificador universal de recursos; un nombre distinguido.
15. El terminal de usuario según la reivindicación 10, en el que la identidad específica del servicio no está incluida en la solicitud.
16. Un sistema de autentificación para su uso en una red de comunicaciones para permitir el acceso a un servicio desde un proveedor de servicios, comprendiendo el sistema:
una autoridad de certificación (10) que comprende medios para recibir una solicitud desde un terminal de usuario, identificando la solicitud el servicio al que se accede y que incluye una clave pública del terminal de usuario; y
en donde la autoridad de certificación (10) está dispuesta para autentificar la solicitud y emitir un certificado de clave pública para una identidad específica de servicio del servicio al que se accederá y devolver el certificado de clave pública al terminal de usuario.
17. El sistema de autentificación según la reivindicación 16, que comprende un servidor de autentificación (6) configurado para autentificar la identidad del terminal de usuario que emite la solicitud.
18. El sistema de autentificación según la reivindicación 16, en el que la autoridad de certificación (10) comprende una base de datos de federación (FD), estando configurada la base de datos de federación para asignar el servicio y los identificadores del solicitante a las identidades específicas del servicio para acceder a servicios respectivos.
19. El sistema de autentificación según la reivindicación 16, en el que dichos medios para recibir dicha solicitud comprenden medios para recibir dicha solicitud a través de una interfaz inalámbrica.
ES05759785T 2004-06-28 2005-06-24 Autentificación de usuarios Active ES2769528T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0414421.8A GB0414421D0 (en) 2004-06-28 2004-06-28 Authenticating users
PCT/IB2005/002035 WO2006003499A1 (en) 2004-06-28 2005-06-24 Authenticating users

Publications (1)

Publication Number Publication Date
ES2769528T3 true ES2769528T3 (es) 2020-06-26

Family

ID=32800306

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05759785T Active ES2769528T3 (es) 2004-06-28 2005-06-24 Autentificación de usuarios

Country Status (6)

Country Link
US (1) US7788493B2 (es)
EP (1) EP1763947B1 (es)
CN (1) CN1977514B (es)
ES (1) ES2769528T3 (es)
GB (1) GB0414421D0 (es)
WO (1) WO2006003499A1 (es)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2256457T3 (es) * 2001-04-19 2006-07-16 Ntt Docomo, Inc. Sistema de comunicacion entre terminales.
FI20041447A0 (fi) * 2004-11-09 2004-11-09 Nokia Corp Avainderivointitoiminnon määrittäminen
US8543814B2 (en) * 2005-01-12 2013-09-24 Rpx Corporation Method and apparatus for using generic authentication architecture procedures in personal computers
US7784092B2 (en) * 2005-03-25 2010-08-24 AT&T Intellectual I, L.P. System and method of locating identity providers in a data network
EP1891598A4 (en) * 2005-05-17 2012-01-18 Telcordia Licensing Company Llc SECURE VIRTUAL SERVICE POINT FOR WIRELESS 3G NETWORKS
DE102005026982A1 (de) * 2005-06-10 2006-12-14 Siemens Ag Verfahren zur Vereinbarung eines Sicherheitsschlüssels zwischen mindestens einem ersten und einem zweiten Kommunikationsteilnehmer zur Sicherung einer Kommunikationsverbindung
CN100379315C (zh) * 2005-06-21 2008-04-02 华为技术有限公司 对用户终端进行鉴权的方法
US7383044B2 (en) * 2005-08-05 2008-06-03 Telefonaktiebolaget L M Ericsson (Publ) Method and database for performing a permission status check on a mobile equipment
US20070188298A1 (en) * 2006-02-11 2007-08-16 Radioframe Networks, Inc. Establishing secure tunnels for using standard cellular handsets with a general access network
CN101416541A (zh) * 2006-03-31 2009-04-22 奥特拉有限公司 移动通信设备的电话号码发现以及电话号码认证的方法和系统
PL2039199T3 (pl) * 2006-07-06 2019-06-28 Nokia Technologies Oy System poświadczania urządzenia użytkownika
US8527770B2 (en) 2006-07-20 2013-09-03 Research In Motion Limited System and method for provisioning device certificates
DE602006019230D1 (de) * 2006-07-20 2011-02-10 Research In Motion Ltd Vorrichtung und Verfahren zur Versorgung von Apparatzertifikaten
WO2008028508A1 (en) * 2006-09-07 2008-03-13 Fujitsu Limited Distributed computing and communications protocol
US8347090B2 (en) 2006-10-16 2013-01-01 Nokia Corporation Encryption of identifiers in a communication system
US7974235B2 (en) 2006-11-13 2011-07-05 Telecommunication Systems, Inc. Secure location session manager
FI121560B (fi) * 2006-11-20 2010-12-31 Teliasonera Ab Todentaminen matkaviestintäyhteistoimintajärjestelmässä
US8423470B2 (en) * 2007-09-21 2013-04-16 Microsoft Corporation Distributed secure anonymous conferencing
CN101163010B (zh) * 2007-11-14 2010-12-08 华为软件技术有限公司 对请求消息的鉴权方法和相关设备
US8516133B2 (en) * 2008-02-07 2013-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for mobile device credentialing
US8468576B2 (en) * 2008-02-11 2013-06-18 Apple Inc. System and method for application-integrated information card selection
US10015158B2 (en) * 2008-02-29 2018-07-03 Blackberry Limited Methods and apparatus for use in enabling a mobile communication device with a digital certificate
US9479339B2 (en) * 2008-02-29 2016-10-25 Blackberry Limited Methods and apparatus for use in obtaining a digital certificate for a mobile communication device
US8438385B2 (en) * 2008-03-13 2013-05-07 Fujitsu Limited Method and apparatus for identity verification
EP2159653B1 (de) * 2008-09-02 2014-07-23 Siemens Aktiengesellschaft Verfahren zur Einräumung einer Zugriffsberechtigung auf ein rechnerbasiertes Objekt in einem Automatisierungssystem, Computerprogramm und Automatisierungssystem
WO2010041347A1 (en) * 2008-10-10 2010-04-15 Telefonaktiebolaget L M Ericsson (Publ) Gateway apparatus, authentication server, control method thereof and computer program
US8402519B2 (en) * 2008-10-16 2013-03-19 Verisign, Inc. Transparent client authentication
CN101483525A (zh) * 2009-01-22 2009-07-15 中兴通讯股份有限公司 一种认证中心的实现方法
US8632003B2 (en) 2009-01-27 2014-01-21 Novell, Inc. Multiple persona information cards
US8370509B2 (en) * 2009-04-09 2013-02-05 Alcatel Lucent Identity management services provided by network operator
US9301191B2 (en) 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US8621203B2 (en) * 2009-06-22 2013-12-31 Nokia Corporation Method and apparatus for authenticating a mobile device
CN102474412A (zh) * 2009-07-17 2012-05-23 上海贝尔股份有限公司 Sem内的drm方法和设备以及提供drm服务的方法
US9294918B2 (en) * 2009-07-23 2016-03-22 Mohammed Naser S. Shaikh Method and system for secure remote login of a mobile device
US20110126197A1 (en) * 2009-11-25 2011-05-26 Novell, Inc. System and method for controlling cloud and virtualized data centers in an intelligent workload management system
US8935529B2 (en) * 2009-11-30 2015-01-13 Telefonaktiebolaget L M Ericsson (Publ) Methods and systems for end-to-end secure SIP payloads
US8375204B2 (en) 2009-12-16 2013-02-12 Symantec Corporation Method and system to combine multiple digital certificates using the subject alternative name extension
US8364954B2 (en) * 2009-12-16 2013-01-29 Symantec Corporation Method and system for provisioning multiple digital certificates
US9055059B1 (en) 2009-12-16 2015-06-09 Symantec Corporation Combining multiple digital certificates
US9680819B2 (en) * 2009-12-23 2017-06-13 Symantec Corporation Method and system for co-termination of digital certificates
CN101783957B (zh) * 2010-03-12 2012-04-18 清华大学 一种视频预测编码方法和装置
WO2012021662A2 (en) * 2010-08-10 2012-02-16 General Instrument Corporation System and method for cognizant transport layer security (ctls)
US8978100B2 (en) * 2011-03-14 2015-03-10 Verizon Patent And Licensing Inc. Policy-based authentication
WO2012140308A1 (en) * 2011-04-13 2012-10-18 Nokia Corporation Method and apparatus for identity based ticketing
FR2980062B1 (fr) * 2011-09-13 2014-02-21 Sagemcom Broadband Sas Procede d'echanges securises de donnees, dispositif et systeme de communication le mettant en oeuvre
US9544271B2 (en) 2011-09-16 2017-01-10 Telecommunication Systems, Inc. Anonymous messaging conversation
US9479344B2 (en) 2011-09-16 2016-10-25 Telecommunication Systems, Inc. Anonymous voice conversation
US8874915B1 (en) * 2011-09-28 2014-10-28 Amazon Technologies, Inc. Optimized encryption key exchange
WO2013062393A1 (ko) * 2011-10-28 2013-05-02 삼성전자 주식회사 이동 통신 시스템 에서 단일 사용자 승인을 지원하는 관리 방법 및 장치
US8893244B2 (en) * 2011-11-30 2014-11-18 Verizon Patent And Licensing Inc. Application-based credential management for multifactor authentication
US8984591B2 (en) 2011-12-16 2015-03-17 Telecommunications Systems, Inc. Authentication via motion of wireless device movement
US9384339B2 (en) * 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US9380038B2 (en) * 2012-03-09 2016-06-28 T-Mobile Usa, Inc. Bootstrap authentication framework
US9137235B2 (en) 2012-03-23 2015-09-15 Cloudpath Networks, Inc. System and method for providing a certificate based on list membeship
US9338153B2 (en) 2012-04-11 2016-05-10 Telecommunication Systems, Inc. Secure distribution of non-privileged authentication credentials
WO2014015525A1 (zh) * 2012-07-27 2014-01-30 华为技术有限公司 一种用户在线状态的查询方法和装置
US9639318B2 (en) * 2012-09-26 2017-05-02 Tencent Technology (Shenzhen) Company Limited Systems and methods for sharing image data
US8843741B2 (en) 2012-10-26 2014-09-23 Cloudpath Networks, Inc. System and method for providing a certificate for network access
US9600689B2 (en) * 2013-01-25 2017-03-21 Apple Inc. Variable anonymous identifier value
US9294468B1 (en) * 2013-06-10 2016-03-22 Google Inc. Application-level certificates for identity and authorization
US9524380B2 (en) * 2013-12-30 2016-12-20 Cellco Partnership Secure element-centric digital rights management
US10601809B2 (en) 2015-01-20 2020-03-24 Arris Enterprises Llc System and method for providing a certificate by way of a browser extension
GB2536044A (en) 2015-03-05 2016-09-07 Bell Identification Bv Method and apparatus for authenticating and processing secure transactions using a mobile device
US9717004B2 (en) 2015-03-17 2017-07-25 Qualcomm Incorporated Apparatus and method for sponsored connectivity to wireless networks using application-specific network access credentials
US9755837B2 (en) * 2015-03-17 2017-09-05 Qualcomm Incorporated Apparatus and method for sponsored connectivity to wireless networks using application-specific network access credentials
US9825938B2 (en) 2015-10-13 2017-11-21 Cloudpath Networks, Inc. System and method for managing certificate based secure network access with a certificate having a buffer period prior to expiration
JP2018067854A (ja) * 2016-10-21 2018-04-26 株式会社プラットフィールド 情報通信システム
CN108696348A (zh) * 2017-04-06 2018-10-23 中国移动通信有限公司研究院 一种实现ca互信的方法、装置、系统和电子设备
US11418364B2 (en) 2017-06-07 2022-08-16 Combined Conditional Access Development And Support, Llc Determining a session key using session data
EP3824609A1 (en) 2018-07-17 2021-05-26 Telefonaktiebolaget LM Ericsson (publ) Multi-x key chaining for generic bootstrapping architecture (gba)
CN114143016A (zh) * 2020-08-14 2022-03-04 中兴通讯股份有限公司 基于通用引导架构gba的鉴权方法、及对应装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001054374A2 (en) * 2000-01-17 2001-07-26 Certicom Corp. Customized public key infrastructure and developing tool
ES2256457T3 (es) 2001-04-19 2006-07-16 Ntt Docomo, Inc. Sistema de comunicacion entre terminales.
US7996888B2 (en) * 2002-01-11 2011-08-09 Nokia Corporation Virtual identity apparatus and method for using same

Also Published As

Publication number Publication date
US7788493B2 (en) 2010-08-31
US20050287990A1 (en) 2005-12-29
CN1977514A (zh) 2007-06-06
GB0414421D0 (en) 2004-07-28
EP1763947B1 (en) 2019-10-16
EP1763947A1 (en) 2007-03-21
CN1977514B (zh) 2012-06-27
WO2006003499A1 (en) 2006-01-12

Similar Documents

Publication Publication Date Title
ES2769528T3 (es) Autentificación de usuarios
EP3752941B1 (en) Security management for service authorization in communication systems with service-based architecture
US10638321B2 (en) Wireless network connection method and apparatus, and storage medium
US10284555B2 (en) User equipment credential system
US9490984B2 (en) Method and apparatus for trusted authentication and logon
KR101374810B1 (ko) 가상 가입자 식별 모듈
ES2687238T3 (es) Método de arquitectura de arranque de seguro basado en autenticación de resumen basada en contraseña
JP5688087B2 (ja) 信頼できる認証およびログオンのための方法および装置
CN1929371B (zh) 用户和外围设备协商共享密钥的方法
US20090063851A1 (en) Establishing communications
EP3180934A1 (en) Methods and nodes for mapping subscription to service user identity
Aiash et al. An integrated authentication and authorization approach for the network of information architecture
Kumar et al. A secure n-secret based client authentication protocol for 802.11 WLANs
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
KR100904004B1 (ko) 사용자들의 인증
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
CN114915494B (zh) 一种匿名认证的方法、系统、设备和存储介质
Chang et al. SSOV: A Single Sign-on Protocol for Accessing Vehicular Application Services with the Support of Secret Credential Management System
Almuhaideb et al. Toward a Ubiquitous Mobile Access Model: A roaming agreement-less approach
Mahshid et al. An optimized authentication protocol for mobile networks
Rao et al. An authentication and authorization approach for the network of knowledge architecture.
Astorga et al. Security for Heterogeneous and Ubiquitous Environments Consisting of Resource-Limited Devices: An Approach to Authorization Using Kerberos
Moon et al. A study on ticket-based AAA mechanism including time synchronization OTP in ubiquitous environment
Riaz Wireless Authentication for secured and Efficient Communication
Pala How to Bootstrap Trust among Devices in Wireless Environments via EAP-STLS