- 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:
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
Categoría:- Protocolos de Internet
Wikimedia foundation. 2010.
