Authentication and Authorization en SIP: Cómo Funciona y Ejemplos con Asterisk
En el mundo de la telefonía IP y VoIP, el protocolo SIP (Session Initiation Protocol) es el estándar más utilizado para establecer, modificar y finalizar sesiones multimedia, como llamadas de voz o videollamadas.
Uno de los aspectos más importantes para garantizar la seguridad en una infraestructura SIP es el proceso de autenticación y autorización.
✅ ¿Qué es la Autenticación en SIP?
La autenticación en SIP asegura que solo usuarios válidos puedan registrarse tu proxy o servidor SIP.
Cuando un cliente (softphone o teléfono IP) intenta registrarse.
- El cliente envía un mensaje un REGISTER al servidor.
- El servidor responde con un 401 Unauthorized (registrar)
- En la respuesta, el servidor incluye un nonce (número aleatorio único).
- El cliente usa ese nonce, junto con su usuario, contraseña y dominio (realm), para generar un hash MD5.
- El servidor calcula el mismo hash y, si coinciden, acepta la petición.
👉 De esta manera, la contraseña nunca viaja en texto plano por la red.
Código 401 Unauthorized
- Ocurre cuando un cliente SIP intenta registrarse en un registrar server (por ejemplo, Asterisk).
- El servidor responde con 401 Unauthorized porque no confía aún en el cliente.
- El mensaje incluye:
- Realm → dominio de autenticación.
- Nonce → número aleatorio único que evita ataques de repetición (replay attacks).
👉 Luego, el cliente responde con un nuevo REGISTER, pero esta vez agregando las credenciales cifradas (usuario + contraseña + nonce procesados con MD5).
Cliente SIP(UAC) Servidor SIP (UAS)
| |
| -------- REGISTER ----------->| (1) Cliente pide registrarse
| |
| <------- 401 Unauthorized --- | (2) Servidor regresa nonce
| |
| - REGISTER + Authorization -->| (3) Cliente reenvía con hash MD5
| |
| <---------- 200 OK -----------| (4) Servidor acepta el registro
| |✅ ¿Qué es la Autorización en SIP?
Una vez que el usuario está autenticado, el servidor necesita decidir qué puede hacer ese usuario.
La autorización define:
- ¿Puede este usuario hacer llamadas externas (salida a PSTN)?
- ¿Puede este usuario llamar solo a extensiones internas?
- ¿Tiene restricciones por horario o por IP?
Cliente SIP Proxy SIP
| |
| -------- INVITE ---------------> | (1) Cliente intenta la llamada
| |
| <--- 407 Proxy Authentication ---| (2) Proxy pide datos (nonce,realm)
| |
| - INVITE + ProxyAuthorization -> | (3) Cliente ReInvite con hashMD5
| |
| <------------ 100 Trying --------| (4) Proxy acepta autenticación
| <------------ 180 Ringing -------| (5) Teléfono destino está sonando
| <------------ 200 OK ------------| (6) Llamada aceptada
| |
| ------------- ACK -------------->| (7) Cliente confirma.
| |Código 407 Proxy Authentication Required
- Similar al 401, pero ocurre cuando un cliente intenta hacer una llamada pasando por un proxy SIP.
- El proxy devuelve 407 Proxy Authentication Required.
- El cliente debe entonces enviar de nuevo el INVITE, ahora con la cabecera de autenticación generada.
Ejemplo 407 Proxy Authentication Required
Analizando una respuesta 407 (capturada despues de un invite), podemos desglozar la parte que nos intereza de este modo.
Proxy-Authenticate: DIGEST realm=”VoipSwitch“, nonce=”0d71a81607cad9bd12130125509345336536”
Donde tenemos algunos puntos importantes.
- DIGEST → el método de autenticación usado (Digest Authentication).
- realm=”VoipSwitch” → el dominio de autenticación.
- nonce=… → un número único generado por el servidor para este reto (challenge).
Ahora, es tarea del cliente que deberá usar este realm, el nonce, su usuario y contraseña, y aplicar el algoritmo MD5 para generar un hash de respuesta válido y posteriormente enviarlo de vuelta.
La pregunta que no me dejo dormir es entonces: ¿hay forma de obtener la contraseña de autenticación solo con esa traza?. La respuesta es NO, debido a que el hashMD5 es calculado con los parámetros usuario, contraseña, Realm, nonce, método SIP y URI destino.
En si, la contraseña no viaja en texto plano, como los demás parámetros, pues ella solo vive en la base de datos del servidor y en la configuración del cliente (teléfono, softphone, etc.)
Ejemplo de Configuración en Asterisk con PJSIP
1. Definir un Endpoint (usuario SIP)
En el archivo pjsip.conf configuramos. Aquí el usuario 1001 necesitará autenticarse con username=1001 y password=superpasswordseguro.
[1001]
type=endpoint
context=interno
disallow=all
allow=ulaw
auth=auth1001
aors=1001
[auth1001]
type=auth
auth_type=userpass
username=1001
password=superpasswordseguro
[1001]
type=aor
max_contacts=1
2. Definir Autorización en el Dialplan, Regla interna: el usuario puede llamar a la extensión 1001. Regla externa (_9X.): si marca un número con 9 al inicio, se le permite salir por el trunk SIP (puerta de enlace a la PSTN).
[interno]
exten => 1001,1,Dial(PJSIP/1001)
exten => _9X.,1,NoOp(Llamada externa solicitada)
same => n,Set(CALLERID(num)=1001)
same => n,Dial(PJSIP/${EXTEN}@trunk-sip,60)
same => n,Hangup()