--boundary Content-ID: 123

Content-Type: application/pkix-cert

<Public certificate for Alice > --boundary

Content-ID: 456

Content-Type: application/pkcs8

<Private Key for Alice >

--boundary

14.6 Media Security

While SIP security relates to authentication, confidentiality, and integrity protection of the signaling information, the ability to establish secure media sessions is a related and equally important issue, which is discussed in this section. While potentially each media type can have unique security issues, they can be analyzed in two groups: non-RTP media and RTP media. To secure non-RTP media, the security challenge is how to establish a security protocol connection using SIP. For RTP media, the challenge is how to signal and key secure RTP or SRTP. These will be discussed in the following sections.

14.6.1 Non-RTP Media

The two most common security protocols for IP are IPSec and TLS as discussed in Sections 14.3.1 and 14.3.2. It is possible to use SIP to establish both of these protocols, although only the approach for TLS has been fully standardized by the IETF. The TLS approach is defined in [23] and is an extension of the approach used to establish connection-oriented media such as TCP using the offer/answer exchange. A partial example SDP offer is:

m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:new

a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49 :6B:19:E5:7C:AB

As defined in [24] the a=setup attribute is used to indicate the active/ passive role in the exchange, while the a=connection:new is used to indicate a new TCP connection should be opened instead of reusing an existing one. The a=fingerprint attribute is used to send a SHA-1 hash of the certificate to be used for authentication. This is designed to allow the use of certificates that are not signed by a trusted CA (i.e., a so-called self signed certificate). Note that this fingerprint only has value in authentication if the offer/answer exchange is

been deprecated in the current version of SDP since it is not able to negotiate all the parameters needed for SRTP. The first key management protocol developed was MIKEY (multimedia internet keying) [30]. However, the use of MIKEY in Internet communications with SIP was difficult, if not impossible, and the resulting deployment has been very limited. When transported with SIP in an offer/answer exchange, MIKEY uses the a=key-mgt SDP attribute [31]. A more deployable approach known as SDES (SDP security descriptions) was also standardized, which uses the a=crypto SDP attribute [32]. An example is shown below:

v=0

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar

i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe)

c=IN IP4 161.44.17.12/127 t=2873397496 2873404696 m=video 51372 RTP/SAVP 31

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 m=audio 49170 RTP/SAVP 0

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 m=application 32416 udp wb

a=orient:portrait

This example shows the specification of AES-CM with 128 bits keys and 80 bit HMAC SHA-1 authentication, a 2^20 key lifetime, and an MKI value of 1 and length of 32 bits. The SRTP master key and salt are included in base64 format. Since this approach effectively involves sending the SRTP key openly in the SDP offer or answer, SIP must provide confidentiality, authorization, and integrity protection for the keying material. While normal security requirements would mean that this required end-to-end S/MIME encryption of the SDP, in practice, many deployments rely instead on hop-by-hop transport over TLS. However, this does expose keying material to each SIP proxy server that forwards the INVITE request or 200 OK response.

Note the use of a secure audio video profile for RTP (SAVP) in the m=

line.

Both MIKEY and SDES keying approaches have limitations when used in actual SIP deployments. For example, when SIP forking, redirection, forwarding, and other features are invoked, the resulting security properties are problematic. Many of these issues are described in [34], which introduced new requirements for a media path keying method for SRTP. As a result, two new keying methods have been developed: DTLS-SRTP [33] and ZRTP [10]. Both of these keying methods perform the keying in the media path and thus solve many of the problems discussed in [34]. DTLS-SRTP uses the SIP offer/answer exchange to establish a DTLS connection between the SIP UAs over the same address and port as the media session. A secret from the DTLS handshake is used to derive SRTP keying material. The same methods described in Section 14.7.1 to establish TLS are used to establish the DTLS session. The same limitations of this method also apply to this keying approach—unless the SDP offer/ answer exchange has end-to-end integrity protection, the DTLS session cannot be properly authenticated and as a result the SRTP keying is susceptible to an active MitM attack. ZRTP keying is described in Section 14.7.5.

14.6.4 Best Effort Encryption

The offer/answer exchange using SDP was designed to allow many media parameters to be negotiated, as described in Chapter 13. However, it was never designed to allow RTP profiles to be negotiable. As a result, an offered media stream must be declared as either secure (SAVP profile) or nonsecure (AVP profile). If the other UA does not support the chosen RTP profile, the media line must be declined. As a result, a UA offering a secure media call to another UA that does not support secure media will result in a call failure. While this may be a desired outcome in some cases, in many cases, a graceful fallback to a nonsecure media call is more desirable. This is especially true during the transition in current deployments in Internet communication where almost no UAs support secure media, to a future when hopefully all UAs will support secure media. This feature, which was invented by Phil Zimmermann and implemented first in the ZRTP protocol, has become know as best effort encryption. ZRTP inherently supports this mode of operation without any extensions or support from other protocols. For other keying approaches, an SDP extension known as SDP media capabilities negotiation [35] is being developed to allow other keying methods besides ZRTP to support best effort encryption. However, this extension represents a major change to SDP offer/answer negotiation and is very complex. As a result, it is likely to be sometime after this extension is finished before it is deployed in SIP networks.