Español | English
rss facebook linkedin Twitter

IMS: Control de acceso, registro y autenticación. Parte II

En el post de hoy continuaremos explicando los entresijos de la arquitectura de autenticación de IMS. En el post anterior, explicamos algunos de los mecanismos utilizados para la utenticación en IMS, tales como el IMS AKA. A continuación explicaremos brévemente que es y en que consiste la GAA o "Generic Authentication Architecture".

GAA (Generic Authentication Architecture)

La GAA es la arquitectura de autenticación que hace posible extender los mecanismos de autenticación existentes en IMS a nivel de aplicación/servicio. GAA define dos tipos de implementaciones: una de ellas basada en criptografía asimétrica y PKI (SSC - Support for Subscriber Certificates) y la otra basada en la posesión de un secreto compartido (GBA - Generic Bootstrapping Architecture) que se deriva de las claves utilizadas en la autenticación AKA. De las dos alternativas, la basada en secretos compartidos es la que está teniendo mayor aceptación, al menos entre los suministradores de redes de telecomunicación, y la que está teniendo un mayor recorrido en 3GPP y está siendo adoptada por algunos servicios de OMA como OMA XDMS o el Smartcard Profile de OMA BCAST (mobile TV).

En la imagen observamos los protocolos, interfaces y especificaciones que intervinen en la GAA:

gaa.jpg

La gran ventaja de GAA/GBA es que permite la creación de "asociaciones de seguridad" entre el agente de usuario y las distintas aplicaciones. Estas asociaciones consisten fundamentalmente en compartir una clave (el secreto compartido) que permite la autenticación posterior del agente de usuario frente a la aplicación, y, si son necesarias, otras características de seguridad como la garantía de confidencialidad e integridad de la información (mediante cifrado y firma digital), no repudio (firma digital), etc. (estas últimas características son usadas, por ejemplo, por el Smartcard Profile de OMA BCAST).

Otro punto a tener en cuenta a favor de GAA es que 3GPP y OMA han especificado que ciertas aplicaciones deben utilizar GAA/GBA como marco de autenticación, no pudiendo acogerse a otros mecanismos. Esto convierte a GAA en un requisito a tener en cuenta a la hora de generar una solución que incluya autenticación.

Entrar en detalle en cada una de las especificaciones de la GAA resultaría bastante extenso, es por esto que se deja de mano del lector indagar en los detalles de éstas especificaciones.

GAA, Lyberty Alliance y el SSO o Single Sing On

El Liberty Alliance es un consorcio de empresas que se dedica a la creación de especificaciones en torno a aspectos relacionados con la autenticación, privacidad y gestión segura de las identidades de usuarios de aplicaciones "online". Uno de los conceptos manejados por este consorcio de empresas es el de SSO o Single Sign On, propiedad gracias a la cual un usuario solo necesita autenticarse una sola vez para acceder a diferentes aplicaciones/servicios.

El 3GPP ha introducido una recomendación para la combinación de GAA/GBA y los mecanismos de autenticación y SSO definidos por Liberty Alliance y SAML v2.0. De esta forma, es posible beneficiarse de una autenticación fuerte, basada en AKA, con los mecanismos definidos por SAML v2.0 y Liberty Alliance para proporcionar SSO. Esta recomendación es la TR.33980, recomendación en la que se especifican diferentes maneras de complementar la arquitectura GAA con las especificaciones del Liberty Alliance. Así pues, parece que usando alguno de los mecanismos definidos por al GAA en conjunto con los mecanismos definidos por la Liberty Alliance y SAML v2.0 se podría obtener una solución completa de gestión de la identidad en entornos IMS (en esencia, gestión del acceso y uso de aplicaciones/servicios construidos sobre la arquitectura IMS).

No obstante, la mayor desventaja de GAA/GBA es que ha sido diseñada para agentes de usuario que cuenten con soporte de algún tipo de tarjeta inteligente (la GAA asume por defecto autenticación basada en SIM). Ello origina que cuando este soporte no está disponible, las especificaciones no sean de ayuda y cada aplicación deba encontrar una solución ad hoc para su problema de autenticación de usuarios. OMA ha especificado soluciones de autenticación, por ejemplo basadas en HTTP Digest con credenciales de usuario, para terminales que no dispongan de tarjeta SIM, como por ejemplo en las especificaciones de OMA XDMS.

Además, no sólo no tiene en cuenta otros mecanismos de autenticación, sino que tampoco proporciona ninguna manera para integrar la información que a este respecto el operador podría tener ya (fruto de autenticaciones previas), no proporcionando por tanto una solución completa de gestión de la identidad.

En el siguiente post nos acercaremos un poco más a la capa de aplicación y trataremos algunas de las implementaciones existentes cara a ofrecer servicios basados en la arquitectura IMS, tales como Parlay/Parlay X.


Asier Marruedo

S21sec e-crime

1 comentario:

Chema dijo...

¡Hola! Hago el proyecto fin de carrera sobre IMS y reconozco que habéis hecho un gran trabajo al sintetizar algo tan complicado como IMS.

Del lado de la capa de aplicación, las operadoras no sueltan prenda, y aunque deduzco que se optará por los web services para proteger el core, por qué no aplicaciones alojadas en los mismos ASs de la operadora protegida tras un SDP? Bueno, es que estoy impaciente por vuestra nueva entrada y me gustaría saber cuándo podré leerla :D, jeje.

¡Muchas gracias!


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login