The Importance of a Visual Identifier of Trusted Identity

As discussed at some length on the SIP and SIPPING mailing lists and recently summarized by John Elwell in there are significant challenges in identifying and authenticating the source of a SIP request outside of a single administrative domain. If an end user cannot trust the identity of the caller, there is the potential for all sorts of fraud and abuse. Imagine, for instance, if a home user thought that the call was coming from their bank or credit card company. Or if a business user thought that a call they received was from one of their suppliers. In both cases, confidential information could be divulged that could lead to identity theft or other forms of fraud. The capability to forge/spoof Caller ID certainly exists on the Public Switched Telephone Network (PSTN) and there are numerous web sites making this an easy task. However, regular phones connected to the PSTN do not have any way to indicate that the caller's identity can be trusted and in informal questioning the author has found that most people (outside the telecommunications industry) still put a high degree of trust in "Caller ID". This trust may undoubtedly continue for some time until sufficient abuse occurs. Unfortunately, in the world of SIP it is even easier than the PSTN to "spoof" what is normally presented as "Caller ID" through simple modification of the From or P-Asserted-Identity headers. This modification could occur conceivably at any point in the chain of transmission between the SIP source and destination. SIP Identity defined in attempts to address this issue but for reasons outlined in both and this mechanism often fails. The danger here is that if "identity" within the world of SIP rapidly becomes abused we will find ourselves in a situation where SIP identity is given the same amount of credibility as email sender addresses are given, which is to say almost none. The volume of email spam has reached a point where sender email addresses are very often viewed as suspicious. As we move to an increasingly interconnected SIP infrastructure, there exists the potential for SIP caller addresses to be viewed in a similar fashion. As efforts are underway to address this issue through either modification of RFC4474 SIP Identity or through the development of other identity mechanisms, it is suggested that consideration be given to how the "trusted identity" will be indicated to the end user when the end-to-end identity can in fact be authenticated.

It is recommended that a common visual identifier be developed that would be recommended for usage across SIP endpoints to indicated that a user is communicating with someone whose identity is "trusted". As an example, consider the "lock" icon used by most web browsers to indicate that a user is communicating using HTTPS and that the communication between the browser and web server is encrypted using SSL/TLS. Browsers may display the lock icon in different locations but if the user is consistently using that browser, he or she will become accustomed to where the lock is located. While it is not clear that users do in fact look for this lock icon before divulging confidential information, the fact remains that this icon is there on most browsers should the user choose to look for it. In the SIP world, it is not immediately clear what form this visual identifier should take. A lock icon is certainly one possibility, but it is used within web browsers to indicate the use of encrypted media and as discussed below, a call can have a trusted identity but not necessarily use encryption for media. Should this work move forward, more investigation needs to be done into what is the appropriate form of the visual identifier.

There are a number of challenges to both the development and deployment of such a visual identifier.

While many SIP endpoints may "IP phones" or "softphones" where the use of a visual identifier makes sense, there are certainly other SIP endpoints where a visual identifier may not be useful or even possible. For instance, interfaces developed for the visually-impaired would not have a visual display unit for the user. Similarly, command-line-based SIP endpoints may have no way of displaying visual indicators. It may be that the initial path forward is to standardize a common visual identifier for SIP endpoints where such an identifier can be displayed and then look separately at how to address the issue of indicating trust for endpoints where such an indicator does not make sense.

It goes without saying that for a common visual identifier to actually be useful to end users, it will need to ultimately be adopted by a significant number of SIP endpoint vendors. Development of such a visual identifier will need to be done in consultation with a wide range of vendors.

For some SIP endpoints, such as softphones, there may be no issue at all with adding additional icons or other symbols to the user interface. However, with some SIP endpoints, such as lower-end "hard" phones, the display space may be limited to only a few lines of text, much of which may be taken up by the Caller ID, time of the call and other information. There may not be space in the display to accomodate another visual identifier.

Similar to the limited display size, some SIP endpoints may be limited in the available fonts for display. Some endpoints may allow the display of any image or character, while others may only allow the use of very specific fonts. A visual identifier would need to be from those fonts - or it would not be visible on these SIP endpoints. One path may be that there is a visual identifier that is more of an image for use in softphones and other SIP endpoints that can use such an identifier and a different identifier, perhaps text-based, that is used by SIP endpoints that cannot display the image identifier.

While a visual indicator may work well in a call between two parties, it is not clear how the identifier should work in a situation where the call involves multiple parties and the call legs are being connected in the SIP endpoint itself, i.e. not in a conference bridge. If there are three parties in the call and both of the external parties have trusted identies, the visual identifier could still be used. But what if one party has a trusted identity but the other one does not? Some SIP endpoints such as softphones may be able to display a visual indicator on a per-user basis. Other endpoints may not be able to do so. It is not immediately clear what the best policy is in this situation.

As mentioned above, the lock icon might be a logical choice based on current browser usage, but in the browser world it is used to indicated an encrypted connection and that it is not necessarily true with trusted identity. With RFC4474, the identity of the caller is authenticated through the signing of portions of the SIP header. This in no way requires the encryption of the media stream but yet most users would probably think of an "encrypted phone call" as one in which the media stream is encrypted. In many cases, particularly those with the use of DTLS-SRTP, the media stream would be encrypted, but this encryption cannot be assumed for all connections. For that reason, the lock icon is not the best choice. [The author also believes that at least one vendor may already be using the lock icon to indicate media encryption is present.] Within web browsers, there is a similar issue going on where primarily due to concerns related to phishing and Internet fraud, some companies have moved to using Extended Validation SSL (EV SSL) certicates where the Certificate Authority issuing the SSL certificate conducts a more rigorous process to authenticate the identity of the entity to whom the certificate is issued. Browsers then indicate to the user in some fashion that the identity of the server site has been certified to a higher standard. To the author's knowledge, there is no common icon used but instead the major browsers seem to be changing the browsers address bar to be green and potentially providing server information on the bar as well. Obviously this exact mechanism would not work well in a SIP environment where many endpoints may have only black-and-white displays.

Perhaps the largest challenge from the author's point-of-view is the overarching question of whether or not the IETF is the correct place to be discussing this matter. For "trusted identity" to be successful in the SIP marketplace, it would seem that some type of visual identifier would be necessary for users to know when the caller's identity can be trusted. For maximum acceptance, it would be ideal if this visual identifier was a common identifier used by the majority of manufacturers of SIP endpoints, rather than each manufacturer developing such a visual identifier on their own. For such a common identifier to be developed, it would seem to require the coordination of some industry-wide and industry-neutral entity. However, this is not really a technical issue or a protocol issue but rather one of user interface design. Is this appropriate work for the IETF? Or should this perhaps be done by an industry organization such as the SIP Forum whose aim is more to coordinate activities between vendors? Is there a more appropriate home for this work?

As we work on improving mechanisms to develop end-to-end authenticated identification of parties involved in communication using SIP, it is worth considering that for widespread acceptance of the "trusted identity" by end users there exists the need for some common visual identifier (where appropriate) that end users can understand indicates the level of trust they should put in the caller identification. If such a common identifier can be developed and adopted by major manufacturers of SIP endpoints, this may help speed the user adoption and acceptance of trusted identity mechanisms developed by the IETF.

This document requires no IANA actions.

The key security issue with any system such as this is in ensuring that the visual identifier cannot be spoofed by an attacker. If end users grow to accept and trust the visual identifier to indicate that the other party has a "trusted identity", then it becomes worthwhile for an attacker to try to spoof this identifier in some fashion to trick the end user into believing that they are speaking with a caller whose identity they can trust. However this identifier is implemented by vendors, analysis will need to be done around how to protect against such attacks. Any such visual identifier is also subject to the inherent weakness of all SIP identity mechanisms that the identity of the SIP endpoint can be ascertained but not necessarily the person speaking into that endpoint. The identifier can indicate that the trusted identity of the SIP endpoint calling is "Dan York" but cannot indicate that Dan York is in fact the person speaking into the phone.

The author acknowledges that the decision to create this draft was made after reading a posting to the SIP mailing list by Paul Kyzivat.