318 |
SIP: Understanding the Session Initiation Protocol |
the request and may not be the actual destination of the request (due to forwarding, redirection, and so forth).
Another issue with SIP identity is that sometimes the From URI set by the initiator may not be the appropriate identity for a request. For example, a SIP user may have a SIP identity (SIP URI) and also a PSTN identity (tel URI). When the request routes over SIP, the SIP identity is the correct one to be presented. However, if the call routes over the PSTN, the PSTN identity is the correct one to assert.
Another issue is that a UA may intentionally or unintentionally set an incorrect identity in a From URI. As such, there is no protocol way for this to be discovered or detected. This could be done within a domain in the following way. A proxy for the example.com domain could challenge all SIP requests sent by UAs in the example.com domain. This would make this proxy a default outbound proxy for these UAs. After the authentication challenge, the proxy could compare the authenticated identity (username and password of the digest challenge) with the From header field URI. If they did not match, the request could be rejected with a 400 Bad Request response. The proxy would only forward requests in which they matched. If a proxy in another domain trusted that the proxy in the other domain did this authentication and checking, the From URI could be trusted and treated as an authenticated identity.
A solution for these identity issues led to the development of the P-Asserted-Identity header field. This header field, which may carry one SIP or SIPS URI and one tel URI is inserted by a proxy after authentication, and may be different from the From URI. It is commonly used in PSTN interworking scenarios. However, this approach still requires proxies to trust each other. A better extension is described in the next section.
14.4.5 Enhanced SIP Identity
The enhanced SIP identity [21] extension attempts to improve on the P-Asserted-Identity by providing a cryptographically verifiable SIP identity assertion. The approach was developed specifically for the interdomain interconnection context. A new SIP header field, Identity, is inserted by a proxy server when forwarding a request. The proxy first authenticates the request to make sure it is being sent by the identity in the From header field. If it was, specific parts of the request are signed and the signature included in the Identity header field. An Identity-Info header field is used to provide a link to the certificate used to sign the message. As such, a small number of proxy servers within a domain using a small number of CA-signed certificates can provide verifiable identity assertions for many users in the domain.
When a UA or proxy receives a request containing the Identity and header fields, the UA or proxy first fetches the certificate of the
SIP Security |
319 |
proxy that signed the request. After the certificate is validated, the signature can be checked. If the signature validates, the From URI can be treated as an authenticated identity. This exchange is shown in Figure 14.7.
The parts of a SIP message that are protected by the identity signature are listed in Table 14.2.
14.5 SIP Certificate Service
The combination of certificates and TLS provides good security for SIP. However, there is significant difficulty in managing certificates in endpoints. These issues include:
Figure 14.7 Enhanced SIP identity call flow.
|
Table 14.2 |
|
Parts of a SIP Message Protected by Enhanced SIP Identity |
To URI |
Original destination of the request. |
From URI |
Identity of the sender of the request. |
Call-ID |
Uniquely identifies the particular dialog. |
CSeq |
Uniquely identifies the transaction within the dialog. |
Date |
Used to prevent replay attacks. |
Contact URI |
Identifies the device used. |
Message body |
Identifies the SDP, message, or other end-to-end SIP message content. |
320 |
SIP: Understanding the Session Initiation Protocol |
1.How to issue certificates in UAs without incurring typical costs of commercial CA-signed certificates. While it is reasonable to have a CAsigned certificate in a few proxies and servers in a domain, having them in every UA is cost prohibitive.
2.How to install and manage certificates in endpoints. Getting a username and password installed on a SIP phone or soft client is easy, but securely importing a certificate is difficult.
3.How users of UA certificates can validate the certificates if they are not commercial CA-signed certificates. Without this validation step, their use is limited.
4.A SIP user of multiple devices will need to synchronize private keys across multiple devices. When keys are reissued, the new private key needs to be distributed in real time to all devices of the user.
An approach to solve this problem is a SIP certificate service for SIP [22]. This approach uses SIP to store, retrieve, and validate certificates. Each of the issues has a solution in this approach.
1.The approach makes so-called self-signed certificates usable. A selfsigned certificate does not incur any per year or per user costs. However, the approach relies on enhanced SIP identity, so proxy servers in the domain will need to have a CA-signed certificate.
2.The approach defines how a certificate can be retrieved using SIP. A SUBSCRIBE to the SIP certificate server results in a NOTIFY, which contains the certificate in a message body. In addition, the subscription allows any changes or updates to the certificate to be applied in realtime, via an additional NOTIFY. When used to store private keys, the key can be encrypted by a pass phrase, so that only the user can utilize the private key even if the certificate server has been compromised.
3.A self-signed SIP certificate can be validated not by the certificate itself but by the method the certificate was fetched. In particular, when delivered in a NOTIFY that has an Identity header field that can be validated, the public key in the certificate can be trusted.
4.Multiple devices utilized by a user can all subscribe to the certificate server of the user. If one device generates a new public/private key pair and hence a new certificate, a PUBLISH is sent to the server, which then sends NOTIFYs to the other devices. As a result, the devices can all synchronize on the same certificate.
Figure 14.8 shows a call flow showing certificate management UA1 and UA2 are associated with the same user, so they use the same public and private
|
|
|
|
|
|
|
|
|
|
|
|
SIP Security |
321 |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 14.8 SIP certificate service.
keys. UA3 is another user who only accesses the user’s public key. An example NOTIFY is shown here:
NOTIFY alice@atlanta.example.com SIP/2.0 Subscription-State: active; expires=7200
....
From: <sip:bob@biloxi.example.com>;tag=1234
Identity: “NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/” Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha1
....
Event: certificate
Content-Type: application/pkix-cert Content-Disposition: signal
< certificate data >
An example PUBLISH is shown here:
PUBLISH sips:alice@atlanta.example.com SIP/2.0
...
Event: credential
Content-Type: multipart/mixed;boundary=boundary Content-Disposition: signal