Seguridad en SIP – Session Initiation Protocol

Medidas de seguridad

SIP dispone de mecanismos que utilizándolos correctamente permiten garantizar las comunicaciones de una forma bastante alta. Estos mecanismos se dividen en dos aspectos principales: autenticación y encriptación.

Para la autenticación se utiliza principalmente HTTP Digest, y aunque lo veremos en más detalle en el siguiente punto, lo que se busca es minimizar el riesgo de que un atacante se pueda hacer pasar por otro. En lo que respecta a la encriptación el objetivo es garantizar la confidencialidad de la comunicación, para lo cual se utilizan algoritmos como AES o DES. Por otro lado, la encriptación de la información puede hacerse de dos formas, hop-by-hop o end-to-end. En la primera, hop-by-hop, se encriptan los datos entre los participantes en la comunicación utilizando tecnologías externas a SIP como TLS o IPSec, de forma que la información que va entre los UA y los proxys, así como entre los proxys, vaya encriptada.

Con la encriptación end-to-end se encripta mediante S/MIME toda la información que no es necesario que sea vista por los sistemas intermedios. No es posible hacer una encriptación end-to-end con TLS o IPSec debido a que los sistemas intermedios deben poder acceder a información de las cabeceras. Hay que tener en cuenta que incluso con S/MIME hay determinadas cabeceras que deben ir en texto plano ya que son necesarias en puntos intermedios. En estos casos no se puede mantener la confidencialidad de esa información, pero se mantiene la integridad haciendo que esa información vaya también dentro de la parte encriptada, de forma que se pueda comparar a posteriori y detectar posibles modificaciones.

En el siguiente gráfico se muetra un resumen de los mecanismos de seguridad habitualmente utilizados:

Es importante tener en cuenta que incluso una buena implementación de estos mecanismos no puede garantizarnos al 100% la seguridad de las comunicacaciones, por ejemplo HTTP Digest no protege todos los parámetros de la cabecera, lo cual podría provocar fallos de integridad. S/MIME es susceptible a ataques del tipo man-in-the-middle, al igual que otros sistemas basados en clave pública como SSH, si un atacante intercepta el primer intercambio de claves. TLS no puede utilizarse sobre UDP, por lo que estamos obligados a utilizar conexiones TCP que la mayor parte del tiempo estarán inactivas, pero que podría utilizarse para ataques DoS. Por último, no todas las implementaciones de SIP soportan todos los mecanismos, por lo que puede haber casos en los que haya que relajar la seguridad para poder realizar la comunicación.

Autenticación en SIP

La autenticación se utiliza en la comunicación user-to-proxy o proxy-to-user y está basado en HTTP Digest. Inicialmente se utilizaba un mecanismo de autenticación basado en HTTP Basic, pero actualmente está declarado obsoleto debido a su absoluta falta de seguridad, al enviarse el usuario y la contraseña en texto plano. El mecanismo de HTTP Digest es relativamente sencillo como puede verse en la siguiente imagen.

El cliente realiza una petición REQUEST al proxy y éste genera un valor aleatorio nonce que se lo devuelve en el mensaje CHALLENGE junto al realm (dominio) contra el que se va a autenticar. En el siguiente paso el cliente envía una nueva REQUEST al proxy, indicando en esta ocasión el nonce, el realm, el nombre de usuario, la uri, y un atributo response que contiene una encriptación de los atributos anteriores conjuntamente con el password. De esta forma conseguimos enviar la autenticación al servidor sin hacer visible el password. El servidor tiene entonces que comparar el valor de response con el resultado de encriptar el también por su cuenta los mismos datos, con el password que tiene el registrado para el usuario.

En la siguiente imagen se ve el flujo completo de mensajes generados en la autenticación.

A continuación se muestra un ejemplo con los mensajes SIP que se generarían en la autenticación:

HTTP Digest – Challenge

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>;tag=3b6c2a3f
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 1 INVITE
<span style="color:#f00">Proxy-Authenticate: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch"</span>
Content-Length: 0

HTTP Digest – Invite Request

INVITE sip:bob@zhwin.ch SIP/2.0
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 2 INVITE
<span style="color:#f00">Proxy-Authorization: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch",
<span style="color:#00f">response="142311a910a4d57ba49afdbe5646768c",</span>
uri="sip:bob@zhwin.ch",
username="alice"</span>
Max-Forwards: 70
Contact: <sip:alice@dskt6816.zhwin.ch:5060>
Content-Type: application/sdp
Content-Length: 239
<Session Description Protocol not shown>