This chapter covers some aspects regarding the management of the identity of SIP request originators. This includes aspects about how to assert such an identity—and also about how to hide it. First we present a general discussion about the topic, and then we describe three different approaches for identity management in SIP.
For the purpose of this chapter, we will use the expression “SIP identity management” to refer to the mechanisms for asserting and withholding the SIP identity of a user who is generating a request.
In the context of this discussion, two aspects are critical to our definition of SIP identity:
It is a “logical” concept, not a “physical” one (e.g., a user’s identity is not his or her IP address).
It is not an alias; it is an identifier that allows other users to set up communications with the user represented by the identity.
Therefore, we do not consider an IP address to be a valid SIP identity for a user. On the other hand, an address of record would be a valid SIP identity.
In IP communication scenarios, it is important that, whenever John originates a SIP request, he has the means to voluntarily assert his identity. By asserting his identity, we mean that John is claiming that he can receive requests sent to that identity.
Asserting the requestor’s identity provides mainly two features:
It gives information to the recipients of the request. They may use this information in several ways:
It gives information to SIP entities to determine which processing rules to apply to a request (for example, automatic call rejection).
Delivering the previous features implies at least two aspects. First there must be a header field in the SIP requests with the right semantics to express our concept of identity as stated above. Second, SIP entities that may use such a header field should be capable of authenticating its validity.
Another related topic is identity hiding (privacy). Sometimes when a user makes a multimedia call, he or she would like to withhold their identity from the called party. There may be several reasons for that. For instance, the user might not want to be associated with the information that they are going to impart, or they might not want to give information that allows the called party to call them back later on.
Obviously, when a user invokes identity privacy, he or she is inhibiting our feature No. 1. The effect of identity privacy in feature No. 2 is not so clear. For instance, a user may want to withhold his or her identity from the called party, but the user may still want some services to be applied on their behalf by some trusted entity. Such a trusted entity should have access to the user’s authenticated identity in order to apply some service logic. In some cases—for instance, in a pure Internet environment—the user might want to hide his or her identity from any entity the call goes through, including (or not) the recipient. In yet other types of scenarios, such as those that may occur in SIP networks controlled by telecom operators, there may be other types of requirements (e.g., regulatory) that preclude the user’s identity from being hidden from specific network nodes irrespective of the user’s wishes.
Another aspect of the privacy topic is the fact that there are also other headers, different from the From header, in the SIP signaling that might also convey personal information about the originator of the request (e.g., Contact header, Via header, etc.). Moreover, the session traffic may also include parameters that convey personal information (e.g., IP addresses in RTP packets, and so on). A full solution for user privacy should address all these issues, as we will see in the next sections.
All in all, the identity-management problem is not an easy one, and is further complicated by the fact that there may be quite different scenarios for implementation of IP communication services ranging from a pure Internet environment to more-controlled SIP networks administered by a single entity (e.g., a telecom operator or a small company).
In the next sections, we will review three different approaches for SIP identity management. The first one, which we will call “Basic Identity Management,” reflects the approach contained in the base SIP spec [RFC 3261], with the enhancements for privacy defined in [RFC 3323]. The second one, “Private Header for Network Asserted Identity” is an approach that has been defined to cope with identity-management requirements in the remit of networks composed of trusted nodes. It is defined in [RFC 3325]. The last one, “Enhanced Identity Management,” defines a general-purpose mechanism to the problem-identity assertion that is appropriate for Internet-wide deployments.
We saw in Chapter 6 that the base SIP specification defines a mechanism for users to assert their identity by using the From header. The From header might be presented to the recipient of the request. Additionally, the From header might be used by SIP entities as an input parameter for service logic execution.
The base SIP specification also defines mechanisms for authenticating the senders of SIP requests by using, for instance, SIP digest (see Chapter 14).
From the above, one could conclude that the problem of asserting the identity in SIP is already solved in baseline SIP. However, the solution depicted above has some drawbacks. The first one is the semantics of the From header. The From header contains a logical identity, possibly an address of record, but nothing precludes the SIP user from introducing in the From header just an alias. If that were the case, the called user would not be able to return the call based on the identity in the From header. The second drawback has to do with authentication. The fact is that few User Agents today support the end-user certificates needed to authenticate themselves. Moreover, digest authentication is limited by the fact that the originator and the recipient must share a prearranged secret. This represents an issue because it is desirable that User Agents are able to send requests to users with whom they have no previous association, and still allow the recipient to have a reasonable assurance that the displayed identity truly represents the originator of the request.
In the next sections, we will see other approaches to the problem of identity management that solve these problems.
Now we will see several approaches for dealing with privacy in the basic scenario we depicted in the previous section. The different approaches are tackled by [RFC 3323].
If a user wanted to hide his or her identity from the called party, the user might set the From header field to the following value:
“Anonymous” <sip:[email protected]>
This approach to obtain privacy by having the UA manipulate the header fields is typically referred to as user-provided privacy. User-provided privacy has two main drawbacks.
The first one refers to the fact that if the network gets no indication of the identity of the user, it would be impossible for the network to apply any services on behalf of that user.
The second drawback refers to the fact that there are other headers, in addition to the From header, that can convey personal information about the caller. For instance, the Contact header may contain the IP address of the calling party, or a hostname that resolves to that address. Likewise, the Via header also gives information about the IP address of the originator. Furthermore, the Record-Route header might also divulge information about the administrative domain of the caller. These headers, unlike what happens with the From header, are used in the routing of SIP responses or of subsequent requests. Therefore, so as not to cause improper routing of messages, they should not be modified by User Agents. Consequently, in order to hide the personal information implicit in these headers, there is a need to have support from the network. More specifically, a network-provided privacy service is needed. A User Agent, when sending a SIP request, might request such a service by including in the request a Privacy header field set to the value “header.” The privacy header is a SIP extension defined in [RFC 3323].
The privacy service would implement at least the following three functions:
Remove all Via headers that have been added to any received request prior to its arrival at the privacy service, and add a single Via header representing itself.
Replace the value of the Contact header in received messages with a URI that does not refer to the originator of the message, but rather, to the privacy service itself.
Strip any Record-Route headers that have been added to a request before it reaches the privacy service.
Obviously, the privacy service must locally persist the values of any of the above headers that are so removed. When further requests or responses associated with the dialog reach the privacy service, it must restore the values for the Via, Record-Route, and Contact headers that it has previously removed in the interests of privacy.
The privacy service could be implemented as a transparent B2BUA[1] that effectively terminates and reoriginates the messages that initiate a session.
Figure 20.1 shows a call flow with a privacy service implemented as a B2BUA.
So far, we have referred only to the identities carried in the SIP signaling. But the media plane (the session) may also carry personal information about the caller, such as IP addresses and so on. In some cases, the calling party may also wish to hide such information. In order to withhold the identities (e.g., IP addresses) present in the media flows, there is a need for having in the media plane an intermediary entity that effectively terminates and reoriginates the media traffic. Such an entity would be controlled by the privacy service (B2BUA).
A User Agent might request such a session privacy service by including a Privacy header field set to the value “session.” When the privacy server detects that session privacy is required, it would involve the media intermediary as appropriate. Figure 20.2 shows a call flow that illustrates the scenario for session privacy.
In addition to the values “header” and “session,” the privacy header may also indicate that no privacy is to be applied (“none” value), or that it is critical that privacy is applied (“critical” value), therefore urging the privacy service to reject the call if, for whatever reason, it is unable to apply privacy.
As we saw in the previous section, the basic mechanism for assertion of identity in baseline SIP has two major drawbacks: the From header semantics and the authentication issue.
The problem of the From header semantics might be overcome by defining a new header field that carries a true SIP asserted identity. For deployments in controlled network environments (so-called Trust Domains), a solution to the second problem might also be found. That solution is described next.
The solution is based on having a bit of support from the network. We saw in previous chapters that, in order to obtain multimedia services, users typically need to subscribe to a service provider. In order to access SIP services, users will need to authenticate against their home SIP server. As a result of that process, the network can obtain an authenticated identity of the user. Such an identity is a SIP, SIPS, or TEL URI that, when used as the Request-URI of a SIP request, would cause the message to be routed to the user associated with that identity, possibly passing through one or more SIP servers or SIP proxies.
When John originates a call, first the network authenticates his identity. Once it is authenticated, the network can insert John’s identity into the call signaling, and exchange it with other trusted nodes or with other User Agents that have secure connections to such a trusted node. User Agent servers that receive the asserted identity may render the value of the asserted identity to the called user.
A network of trusted nodes is referred to as a Trust Domain. A node can be a member of a Trust Domain, T, only if the node is known to be compliant to a certain set of specifications, Spec(T), which characterize the handling of the network asserted identity within the Trust Domain. Spec(T) is not a specification in the sense of a written document; rather, it is an agreed-upon set of information that all the elements in the Trust Domain are aware of.
Spec(T) specifies behavior for, among others, such things as:
end-user authentication mechanisms.
mechanisms to secure the communication among nodes in the Trusted Domain.
mechanisms to secure the communication among nodes in the Trusted Domain and UAs.
The requirements for network asserted identity are specified in [RFC 3324]. Another document, [RFC 3325], defines a SIP extension for network asserted identity. This SIP extension introduces two new P-header fields:
P-Asserted-Identity. It is the header field used to convey the authenticated identity of the originating user among trusted SIP entities. If the called party receives a P-Asserted-Identity from a node it trusts, the called party’s User Agent may render the value of the P-Asserted-Identity to the user in order to show the identity of the caller.
P-Preferred-Identity. In cases where the user has multiple identities, the user can use this header field in order to indicate to the network which particular identity he or she wishes to appear in the P-Asserted-Identity after authentication is performed.
Figures 20.3 and 20.4 show examples of the use of these two headers. In both examples, we assume that:
Proxy1 and Proxy2 are proxies belonging to the Trust Domain.
John and Suzanne have secure connections to Proxy1 and Proxy2 and are authenticated (authentication process is not shown).
John has just one identity: sip: [email protected].
Suzanne has two identities: sip: [email protected] and [email protected].
Figure 20.3 shows a call from John to Suzanne. Figure 20.4 shows a call from Suzanne to John. Given that Suzanne has two identities, she chooses one to be presented to John by setting the P-Preferred-Identity header field to [email protected].
The P-Asserted-Identity header has found widespread deployment in spite of the fact that it is defined as a P-header (which implies that it has limited applicability).
[RFC 3325] also defines the privacy value “id.” A user may insert such a value into a Privacy header of a request if he or she wishes that network nodes forwarding the request to nontrusted entities remove the P-Asserted-Identity header. Figure 20.5 illustrates this behavior, where proxy1 and proxy2 belong to the same Trust Domain, whereas proxyA does not.
The previous approach for identity management assumes a managed network of nodes with strict mutual-trust relationships. Such an assumption is not compatible with widespread Internet deployment.
[RFC 4474] defines another approach to identity management based on specifying a means of sharing a cryptographic assurance of end-user SIP identity that is suitable for Internet-wide deployment.
It is based on an “authentication service” that would typically be instantiated by the user’s outbound proxy. Let us see how it works.
Let us imagine that John makes an Internet call to Alice. Let us assume that they are registered with different service providers, and there is no trust relationship between the two domains. Still, John wants to assert his identity and let Alice have access to it at call initiation.
John generates an INVITE, and places his identity (possibly his address of record: sip:[email protected]) in the From header field of the request. He sends the request over TLS to his outbound proxy. His outbound proxy instantiates an authentication service that authenticates John (SIP digest might be used for this), and validates that he is authorized to assert the identity that he placed in the From header field. John’s outbound proxy then computes a hash over some particular headers, including the From header field and the bodies in the message. Then the proxy signs the hash with the certificate for John’s domain (in our example, sea.com), and inserts it into a new header field in the SIP message, the “Identity” header. The proxy, as the holder of the private key of its domain, is asserting that the originator of this request has been authenticated, and that he is authorized to claim the identity that appears in the From header field. The proxy also inserts a companion header field, Identity-Info, that tells the recipient of the request how to acquire the certificate, if he or she doesn’t already have it.
When Alice’s inbound proxy receives the request, it verifies the signature provided in the Identity header. Therefore, it can validate that the domain present in the From header authenticated John, and also permitted him to assert the identity present in the From header. Once the request reaches Alices’s UA, it might perform the same validation operation.
The previous approach for enhanced identity management is, in principle, compatible with the privacy mechanisms defined in [RFC 3323]. There are, however, some aspects that need to be considered. These aspects are detailed in [RFC 4474]. For instance, when a user that desires privacy places the value [email protected] in the From header, it would be impossible to apply the previous mechanisms for identity assertion, because an authentication service must possess a certificate corresponding to the host portion (“anonymous.invalid” is not a real domain). Otherwise, if the user places the value [email protected], the mechanisms described before are perfectly applicable. The called party would learn that the originator of the request has been authenticated by ocean.com, and that the originator wants to withhold his or her identity.
In this chapter, we learned about several possible approaches to handle the identity aspects in the SIP protocol. The network asserted identity approach will prove to be instrumental for the delivery of multimedia services in controlled network environments such as IMS (Chapter 24).
Another aspect that is also crucial for the delivery of multimedia services is the quality of service. This is an aspect that can be used by service providers in order to offer a competitive advantage versus a pure Internet environment. In the next chapter, we will describe the possible architectures to offer quality of service in the remit of multimedia communications.
[1] A transparent B2BUA is a particular type of B2BUA that forwards SIP messages in a SIP proxy–like way, and that also benefits from some features of a User Agent (UA) element.