SDES

For the transfer of keys, SDP attachments are used in messages SIP - Invite. This assumes the confidentiality of the SIP transport channel, which should ensure that the investment is unavailable for a probable person in the middle (man in the middle) . This can be achieved using TLS transport, or some other method, such as S / MIME . The use of TLS implies that the next link in the SIP- proxy chain can be trusted, and this will ensure the security requirements of the Invite request. The advantage of this method is that it is extremely easy to implement. This method has already been implemented by several developers. Even though some developers do not use a fairly secure key exchange mechanism, it really helps to use this method as a de facto standard in most applications.

We illustrate this principle with an example in which the phone sends a request for a SIP call to a proxy server. The format of the SIP Invite request explicitly indicates that the subsequent call should be made as secure. The encryption key is encoded with the standard Base-64 code as an SDP attachment:

  INVITE sips: 111@mydomain.com; user = phone SIP / 2.0
 Via: SIP / 2.0 / TLS 10.20.30.40.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport
 From: "222" < sips: 222@mydomain.com >; tag = mogkxsrhm4
 To: < sips: 111@mydomain.com; user = phone >
 Call ID: 3c269247a122-f0ee6wcrvkcq @ CSCO79XX-000129287FC1
 CSeq: 1 INVITE
 Max-Forwards: 70
 Contact: < sip: 222@10.20.30.40: 1055; transport = tls; line = demoline >; reg-id = 1
 User-Agent: CSCO79XX / 8.3.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 10.20.30.40
 s = call
 c = IN IP4 10.20.30.40
 t = 0 0
 m = audio 42501 RTP / AVP 0 8 9 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: 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

The phone receives a response from the proxy server, and using the data received, it can thus establish a bidirectional (Tx / Rx) encrypted connection:

  SIP / 2.0 200 Ok
 Via: SIP / 2.0 / TLS 10.20.30.40.10:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96
 From: "222" < sips: 222@mydomain.com >; tag = mogkxsrhm4
 To: < sips: 111@mydomain.com; user = phone >; tag = 123456789
 Call ID: 3c269247a122-f0ee6wcrvkcq @ CSCO79XX-000413230A07
 CSeq: 1 INVITE
 Contact: < sip: 111@10.0.0.1: 5061; transport = tls >
 Supported: 100rel, replaces
 Allow-Events: refer
 Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO
 Accept: application / sdp
 User-Agent: Asterisk / 1.4.21-1
 Content-Type: application / sdp
 Content-Length: 298

  v = 0
 o = - 349587934875 349587934875 IN IP4 10.0.0.1
 s = -
 c = IN IP4 10.0.0.1
 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

A common security problem is that key exchange must occur before the first media packet arrives, in order to be able to encrypt these same media packets. To avoid unpleasant clicks at the beginning, the first media packets should be ignored. This is usually a very short period of time (less than 100 milliseconds), so this is not problematic.

The SDES method does not provide "from-and-to" media encryption. However, it is debatable how realistic this requirement is. On the one hand, the law enforcement authorities want access to the content of telephone conversations. On the other hand, many other parameters - IP addresses, port numbers, and STUN passwords may require protection against DoS attacks .

In addition, for the complete security of the "from-and-to" media, you must first establish a direct trust relationship with the other party (subscriber). If you use the key exchange infrastructure with the certificate authority as an intermediate link, then there is a delay in each connection setup, at which each party must authenticate their key in such a center, which creates additional difficulties to start a conversation. If peer-to-peer LAN is used , it is difficult to identify the other party. For example, the operator develops the B2BUA architecture and subscribers are forced to connect not directly, but through IP-PBX . In this case, the possibility of the “presence” of Man_the middle increases, and one cannot speak of complete security.

• MIKEY alternative key exchange method
• ZRTP key exchange protocol using the media channel

• RFC 4568