14.3.4 Secure MIME

Secure MIME or S/MIME (secure multipart Internet mail exchange) is a security protocol developed to secure e-mail. It provides authentication, integrity, and confidentiality services on an end-to-end basis. S/MIME usually uses digital certificates for keying, and the management of these certificates in endpoints makes deployment difficult.

14.4 SIP Security Model

This section will introduce the security model for SIP. Security begins with authentication, and there are a number ways a SIP message can be authenticated. One way is if it is received over an IPSec or VPN tunnel that has previously been authenticated. Another method is if it is received over a TLS connection that has been properly authenticated. The method by which TLS can provide SIP authentication will be discussed in Section 14.4.2. SIP messages can also include a digital signature, done using S/MIME. In addition, SIP can utilize HTTP digest authentication for a challenge/response authentication mechanism. This approach, discussed in Section 14.4.1, uses a simple shared secret for authentication.

14.4.1 SIP Digest Authentication

SIP digest authentication is based on HTTP digest [17]. A SIP server or UA can challenge a UA to resend a request proving knowledge of a shared secret. The shared secret is never sent in the SIP message, but instead a message digest 5 (MD5) hash is sent instead. This challenge can be done statelessly to prevent denial of service attacks. An example is shown in Figure 14.4. The initial INVITE receives a 401 Unauthorized response, which contains a WWW-Authenticate header field. The UA sends an ACK to complete the SIP transaction, then resends the INVITE with an Authorization header field. Usually, the same Call-ID and From tag is used, but a different branch ID and incremented CSeq. The Authorization header field contains the credential. If authentication succeeds, the INVITE is processed or forwarded. Note that a 401 response is usually sent by a UAS such

For mutual authentication, the Authentication-Info header field can be used, although this header field is rarely supported in UAs. Also, this approach relies on a shared secret in the server. Since a server can support thousands of clients, this approach does not scale well.

Also note that digest can only be used to authenticate requests. Responses cannot be challenged so they cannot be authenticated using digest. Also, ACK and CANCEL messages cannot be authenticated using digest since they cannot be challenged.

It is perhaps surprising in light of these shortcomings that often SIP digest is the only authentication used in some SIP deployments and environments.

14.4.2 SIP Authentication Using TLS

SIP can use TLS for authentication, confidentially, and integrity protection in a similar way that HTTP uses TLS for secure Web browsing. The registered SIP port for TLS is 5061, although using NAPTR and SRV records, other port numbers can be used. A client opens a TLS connection on this port and can request the server produce a certificate. If the certificate is signed by a certificate authority recognized by the client, the certificate can be used to authenticate the public key of the server. By producing a signature using the associated private key during the TLS handshake, the server can be authenticated. It is also possible for the server to request a certificate from the client. However, unless the client is another proxy server, it is not likely a SIP UA will have a certificate. As a result, TLS typically only provides one-way authentication. A digest challenge by the server can be done over the TLS connection, which provides a level of mutual authentication.

A SIP message can be authenticated if it is received over an authenticated TLS connection. In particular, if the domain of the From URI matches the subjectAltName (SAN) in the certificate presented during the TLS handshake, the request can be considered authenticated. Figure 14.6 shows how this can be done. TLS also provides integrity protection on a hop-by-hop basis. When a TLS connection is used for routing a SIP response, the response can also be authenticated over this single hop.

However, TLS cannot provide authentication over more than one hop. Consider the examples of Figure 14.4 and 14.5 where there are two SIP hops between the UAs. Each UA can only examine the certificate of the proxy it connects to. On receipt of a request, a UA can verify by examining the Via header fields that TLS has been used on every hop, but it must trust these Via header fields are accurate, and that each hop proxy has properly authenticated the connection and the certificate.

There are two types of connection reuse with SIP. One is sending a response over the same connection as the request. The other is reusing an existing

Figure 14.6 SIP authentication using TLS.

connection for a new SIP transaction or dialog. For example, in Figure 14.6, the TLS connection opened by the client for registration is reused by the server to send an incoming INVITE. Two work-in-progress SIP extensions relating to this are [18] and [19].

14.4.3 Secure SIP

Secure SIP or SIPS is a URI scheme for SIP that requires the use of TLS for every hop. As such, a proxy receiving a request with a SIPS Request-URI must either forward the request over a TLS connection or return an error message. This addition to SIP security has unfortunately seen little actual deployment due to some confusion in the specification and lack of support for TLS in some SIP systems and service providers. A working document describing clarifications and corrections in [20] may rectify this in the future.

14.4.4 Identity

Identity is another major issue in Internet communications that will be briefly covered in this section. In SIP, an identity is a SIP or SIPS URI. The identity of the originator of a SIP request will be the From header field URI. Note that this is not the same as the Contact URI, which may be the identity of the device or endpoint rather than the user. A response to a request in SIP does not carry the identity of the responder, as the To header field URI was set by the originator of