The Importance of a Visual Identifier of Trusted Identity
draft-york-sip-visual-identifier-trusted-identity-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 9, 2009.

Abstract

This document discusses the need for a visual identifier in Session Initiation Protocol (SIP) endpoints to indicate to the end user that they are speaking with someone whose identity is trusted.

Table of Contents

1.  Introduction
2.  Recommendation
3.  Challenges
    3.1.  Non-visual Endpoints
    3.2.  Many Vendors
    3.3.  Limited Display Size
    3.4.  Fonts
    3.5.  Multiple Callers
    3.6.  Trusted Identity does not mean a 'secure call'
    3.7.  Is the IETF the correct organization to address this issue?
4.  Conclusions
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

As discussed at some length on the SIP and SIPPING mailing lists and recently summarized by John Elwell in [I‑D.elwell‑sip‑e2e‑identity‑important] (Elwell, J., “End-to-End Identity Important in the Session Initiation Protocol (SIP),” February 2009.) 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 (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) [RFC3325] headers. This modification could occur conceivably at any point in the chain of transmission between the SIP source and destination. SIP Identity defined in [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) attempts to address this issue but for reasons outlined in both [I‑D.elwell‑sip‑e2e‑identity‑important] (Elwell, J., “End-to-End Identity Important in the Session Initiation Protocol (SIP),” February 2009.) and [I‑D.kaplan‑sip‑uris‑change] (Kaplan, H., “Why URIs Are Changed Crossing Domains,” February 2008.) 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.

2.  Recommendation

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.

3.  Challenges

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

3.1.  Non-visual Endpoints

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.

3.2.  Many Vendors

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.

3.3.  Limited Display Size

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.

3.4.  Fonts

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.

3.5.  Multiple Callers

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.

3.6.  Trusted Identity does not mean a 'secure call'

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.

3.7.  Is the IETF the correct organization to address this issue?

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?

4.  Conclusions

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.

5.  IANA Considerations

This document requires no IANA actions.

6.  Security Considerations

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.

7.  Acknowledgements

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

8. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.