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:

INVITE sips:*97@ietf.org;user=phone SIP/2.0
Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport
From: "123" <sips:123@ietf.org>;tag=mogkxsrhm4
To: <sips:*97@ietf.org;user=phone>
Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:123@172.20.25.100:2049;transport=tls;line=gyhiepdm>;reg-id=1
User-Agent: snom360/6.2.2
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces, callerid
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 477

v=0
o=root 2071608643 2071608643 IN IP4 172.20.25.100
s=call
c=IN IP4 172.20.25.100
t=0 0
m=audio 57676 RTP/AVP 0 8 9 2 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=encryption:optional
a=sendrecv

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

SIP/2.0 200 Ok
Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96
From: "123" <sips:123@ietf.org>;tag=mogkxsrhm4
To: <sips:*97@ietf.org;user=phone>;tag=237592673
Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07
CSeq: 1 INVITE
Contact: <sip:*97@203.43.12.32:5061;transport=tls>
Supported: 100rel, replaces
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO
Accept: application/sdp
User-Agent: pbxnsip-PBX/1.5.1
Content-Type: application/sdp
Content-Length: 298

v=0
o=- 1996782469 1996782469 IN IP4 203.43.12.32
s=-
c=IN IP4 203.43.12.32
t=0 0
m=audio 57076 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx
a=ptime:20
a=sendrecv

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.

Véase también

• Mikey.
• ZRTP.
• [1]: presentación de Dan Wing describiendo los diferentes métodos de intercambio de claves.