SDES

SDES ( Session Description Protocol Security Descriptions ) para Media Streams es una forma de negociar la clave para el Protocolo de Transporte Seguro en Tiempo Real . ^{[ 1 ]} Se propuso su estandarización al IETF en julio de 2006 (véase RFC 4568 ). 

Las claves se transportan en el archivo adjunto SDP de un mensaje SIP . Esto significa que la capa de transporte SIP debe asegurarse de que nadie más pueda ver el archivo adjunto. Esto se puede lograr utilizando la capa de transporte TLS u otros métodos como S/MIME . El uso de TLS presupone que el siguiente salto en la cadena de proxy SIP es confiable y se encargará de los requisitos de seguridad de la solicitud.

La principal ventaja de este método es su extrema simplicidad. El método de intercambio de claves ya ha sido adoptado por varios proveedores, aunque algunos no utilizan un mecanismo seguro para la transmisión de la clave. Esto contribuye a alcanzar la masa crítica de implementaciones necesaria para convertir este método en el estándar de facto .

Para ilustrar este principio con un ejemplo, el teléfono realiza una llamada al servidor proxy. Mediante el esquema SIP, se indica que la llamada debe ser segura. La clave está codificada en base64 en el archivo adjunto SDP.

INVITE sips:*97@ietf.org;user=phone SIP/2.0 Vía: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport De: "123" < sips:123@ietf.org >;tag=mogkxsrhm4 Para: < sips:*97@ietf.org;user=phone > ID de llamada: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 1 INVITACIÓN Máximo de delanteros: 70 Contacto: < sip:123@172.20.25.100:2049;transport=tls;line=gyhiepdm >;reg-id=1 Agente de usuario: snom360/6.2.2 Aceptar: aplicación/sdp Permitir: INVITACIÓN, ACK, CANCELAR, ADIÓS, REFERENCIA, OPCIONES, NOTIFICAR, SUSCRIBIRSE, PRACK, MENSAJE, INFORMACIÓN Permitir eventos: hablar, retener, referir Compatible con: temporizador, 100rel, reemplaza, identificador de calle Session-Expires: 3600;refresher=uas Min-SE: 90 Tipo de contenido: aplicación/sdp Longitud del contenido: 477 v=0 o=root 2071608643 2071608643 EN IP4 172.20.25.100 s=llamada c=IN IP4 172.20.25.100 t=0 0 m=audio 57676 RTP/SAVP 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 evento telefónico/8000 a=fmtp:101 0-16 a=ptime:20 a=cifrado:opcional a=enviarrecibir

El teléfono recibe la respuesta del proxy y ahora puede haber una llamada segura bidireccional:

SIP/2.0 200 Ok Vía: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96 De: "123" < sips:123@ietf.org >;tag=mogkxsrhm4 Para: < sips:*97@ietf.org;user=phone >;tag=237592673 ID de llamada: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 1 INVITACIÓN Contacto: < sip:*97@203.43.12.32:5061;transport=tls > Compatible con: 100rel, reemplaza Permitir eventos: consultar Permitir: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Aceptar: aplicación/sdp Agente de usuario: pbxnsip-PBX/1.5.1 Tipo de contenido: aplicación/sdp Longitud del contenido: 298 v=0 o=- 1996782469 1996782469 EN IP4 203.43.12.32 s=- c=IN IP4 203.43.12.32 t=0 0 m=audio 57076 RTP/SAVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 evento telefónico/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=enviarrecibir

Un problema común con los medios seguros es que el intercambio de claves podría no haber finalizado cuando llega el primer paquete de datos. Para evitar clics iniciales, esos paquetes deben descartarse. Por lo general, esto solo ocurre durante un breve período de tiempo (menos de 100 ms), por lo que no suele ser un problema grave.

El método SDES no aborda el cifrado de medios de extremo a extremo. Por ejemplo, si el usuario A se comunica con el usuario B a través de un proxy P, SDES permite la negociación de claves entre A y P o entre B y P, pero no entre A y B. Para lograr la seguridad de medios de extremo a extremo, primero debe establecer una relación de confianza con la otra parte. Si utiliza un intermediario de confianza para esto, el retardo en el establecimiento de la llamada aumentará significativamente, lo que dificulta aplicaciones como la función pulsar para hablar. Si lo hace de igual a igual, podría resultarle difícil identificar a la otra parte. Por ejemplo, su operador podría implementar una arquitectura B2BUA y desempeñar el papel de la otra parte, por lo que aún no tendría seguridad de extremo a extremo. Los protocolos más recientes y modernos, como ZRTP , ofrecen cifrado de extremo a extremo para llamadas SIP/RTP.

• Método de intercambio de claves MIKEY
• Propuesta de intercambio de claves de extremo a extremo de ZRTP
• Estándar IETF para el intercambio de claves de extremo a extremo DTLS-SRTP

• Presentación sobre diferentes métodos de intercambio de claves ( formato Microsoft PowerPoint ).