Session Description Protocol Security Descriptions for Media Streams
# Session Description Protocol Security Descriptions for Media Streams

Session Description Protocol Security Descriptions for Media Streams o SDES es un método para negociar la clave criptográfica para SRTP. Ha sido estandarizado por el IETF en julio de 2006 como el RFC 4568.

## Cómo funciona

Durante el intercambio, las claves son transportadas en el adjunto SDP dentro de un mensaje SIP. Por lo tanto, la capa de transporte de SIP deberá hacerse cargo de que nadie más puede ver ese adjunto. Esto puede hacer usando TLS u otros métodos como S/MIME. Al usar TLS supones que el próximo salto en la cadena de proxys SIP es confiable y tendrá en cuenta los requisitos de seguridad de la petición.

La gran ventaja de este método es que resulta extremadamente simple. El método de intercambio de claves ha sido elegido ya por varios fabricantes. A pesar de que algunos de ellos no usen un mecanismo seguro para transportar la clave, este hecho ayuda a alcanzar la masa crítica de implementación necesaria para convertir a este método en un estándar de facto.

Para ilustrar su funcionamiento con un ejemplo, veamos como un teléfono envía una llamada al proxy utilizando el esquema SIP e indicando que la llamada debe hacerse segura. La clave está codificada en base-64 en el adjunto SDP:

El teléfono recibe la respuesta desde el proxy y ya puede establecerse una llamada segura en los dos sentidos:

## Discusión

Un problema común al asegurar un flujo de datos multimedia es que el intercambio de claves puede no haber terminado cuando llega el primer paquete de datos multimedia. Esos paquetes deben ser descartados para evitar problemas iniciales. Normalmente suele tomar un breve periodo de tiempo (por debajo de los 100 ms), por lo que no representa un gran problema.

El método SDES no realiza un cifrado de datos "end-to-end". Sin embargo, la aplicabilidad de este requisito está en entredicho. Por una parte, las agencias gubernamentales quiere tener acceso a las llamadas de teléfono. Por otra parte, es discutible si otros parámetros de la comunicación como las direcciones IP, los números de puerto (para ataques DoS), o las contraseñas de servidores STUN son también relevantes para la seguridad y precisan ser protegidos.

Además, para establecer un cifrado de datos "end-to-end" es preciso establecer previamente una relación de confianza con el otro extremo. Si se utiliza un intermediario confiable para esto, el retraso en el establecimiento de llamada podría incrementarse significativamente, haciendo complicado el uso de aplicaciones del tipo "push-to-talk". Si la comunicación es peer-to-peer, puede ser complicado identificar al otro extremo. Por ejemplo, tu operador podría implementar una arquitectura B2BUA y tomar el rol del otro extremo, por lo que no podrías tener todavía seguridad end-to-end.

