Autenticación en SIP para LINUX

El protocolo SIP utiliza la autenticación digest para la autenticación de los clientes. La autenticación digest es un mecanismo simple de autenticación desarrollada originalmente para HTTP (se le llama con frecuencia HTTP digest). El mecanismo de autenticación es muy simple, está basado en hashes criptográficos que evitan que se envíe la contraseña de los usuarios en texto claro.

La autenticación digest verifica que las dos partes que se comunican conocen un secreto compartido, que es la contraseña. Cuando un servidor quiere autenticar a un usuario, genera un desafío digest y se lo manda al usuario. Un ejemplo de desafío puede ser el siguiente:

Digest realm="iptel.org", qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5

Consiste en una serie de parámetros que son enviados al usuario. El usuario entonces utiliza los parámetros para generar una respuesta digest adecuada y enviársela al servidor. Los parámetros del desafío digest son los siguientes:

  1. realm: Es un parámetro obligatorio y debe estar presente en todos los desafíos. Su propósito es identificar las credenciales dentro de un mensaje SIP. Normalmente es el dominio del cual el servidor proxy SIP es responsable.
  2. nonce: es un string de datos generado únicamente cada vez que un servidor genera un desafío digest. Se construye a partir del hash MD5 de algún dato. Dicho dato normalmente incluye un sello de tiempo y la frase secreta (contraseña) que tiene el servidor. De esta manera se asegura que cada nonce tenga un tiempo de vida limitado (que no puede volver a ser usado más tarde) y también es único (ningún otro servidor será capaz de generar el mismo nonce). Los clientes generan la respuesta digest a partir del nonce, así el servidor recibirá el contenido del nonce en una respuesta digest. Normalmente verifica la validez del nonce antes de que compruebe el resto de la respuesta digest. De manera que, el nonce es un tipo de identificador que se asegura de que las credenciales digest recibidas han sido realmente generadas para un desafío digest concreto, y además limita el tiempo de vida de la respuesta digest, evitando que se vuelvan a lanzar ataques en el futuro.
  3. opaque: es un string de datos que se envía al usuario en el desafío. El usuario pasará el string de datos de vuelta al servidor en la respuesta digest. Esto permite a los servidores no mantener información sobre el estado. Si hay algún estado que ellos necesitan mantener entre el desafío y la respuesta, pueden pasárselo al cliente utilizando este parámetro y leerlo otra vez más tarde cuando la respuesta digest venga.
  4. algoritmo: el algoritmo utilizado para calcular los hashes. Sólo está soportado MD5.
  5. qop: la protección de la calidad. Especifica qué esquemas de protección soporta el servidor. El cliente elegirá una opción de la lista. El valor “auth” indica sólamente autenticación, el valor “auth-int” indica autenticación con protección de la integridad.

Después de recibir el desafío digest, un agente de usuario pedirá al usuario el nombre de usuario y la contraseña (si no está preconfgurado), generará la respuesta digest y la enviará al servidor. Una respuesta digest podría ser así:

Digest username="jan", realm="iptel.org",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org",
qop=auth, nc=00000001, cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", opaque=""

Como podemos ver, la respuesta digest es similar al desadío digest. Los parámetros que coinciden tienen el mismo significado que en el desafío digest. Vamos a describir brevemente sólo los siguientes parámetros:

  1. uri: contiene el uri al que el cliente quiere acceder.
  2. qop: el nivel de protección elegido por el cliente.
  3. nc: contador de nonce, el valor es el contador en hexadecimal del número de peticiones (incluyendo la petición actual) que el cliente ha enviado con el nonce en su petición. Por ejemplo, en la primera petición enviada en respuesta a un nonce dado, el cliente manda “nc=00000001″. La finalidad de esta directiva es permitir que el servidor detecte peticiones de replay manteniendo su propia copia de este contador.
  4. cnonce: el valor es un string proporcionado por el cliente y utilizado tanto por el cliente como por el servidor para evitar ataques de texto plano elegidos, para proporcionar autenticación mutua y protección de la integridad del mensaje.
  5. response: es un string generado por el agente de usuario (cliente) que prueba que el usuario sabe la contraseña.

Desde la recepción de una respuesta digest, el servidor recalcula el valor de la respuesta para comparar, utilizando los atributos que da el cliente y el password almacenado en el servidor. Si el resultado es idéntico a la respuesta recibida desde el cliente entonces dicho cliente está autenticado.

Cuando un servidor SIP recibe una petición SIP y quiere verificar la autenticidad del usuario antes de procesar las peticiones, comprueba si la petición contiene las credenciales de digest. Si no hay credenciales en la petición SIP, generará una respuesta final negativa e incluirá el desafío digest en la respuesta.

Cuando el cliente recibe la respuesta conteniendo el desafío digest, debe calcula la respuesta digest adecuada y enviar la petición de nuevo, esta vez incluyendo las credenciales digest. El servidor entonces verifica la respuesta digest y procesa que la petición se ha realizado con éxito. Los agentes de usuario SIP utilizan la respuesta “401 Unauthorized” para incluir el desafío digest.